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)
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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）とSoftwire「ハブとスポーク」ソリューションの枠組みを説明しています。この文書で指定された実装の詳細は、異なるベンダーの実装間の相互運用性を達成するために従うべきです。
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プロトコルはSoftwireで展開「ハブとスポーク」解空間を対象としてSoftwiresワーキンググループでは、レイヤ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は、IPv4のみのアクセスネットワークを介したIPv6のみのアクセスネットワークを介してIPv4接続、またはIPv6接続とホームネットワークを提供するために設立されました。 L2TPv2はSoftwireのコンテキストで使用される場合、自発的トンネリングモデルが適用されます。 ISPでSoftwireコンセントレータ（SC）がの役割を担っている一方で、ホームネットワークでSoftwireイニシエータ（SI）は、（L2TPトンネル/セッション及びPPPリンクの両方を開始する）L2TPアクセスコンセントレータ（LAC）クライアントの役割を担っていますL2TPネットワークサーバ（LNS）。用語自発的トンネリングと強制的なトンネリングは[RFC3193]のセクション1.1で定義されています。 L2TPv2強制的トンネリングモデルがSoftwiresには適用されませんので、それは要求されたか、光栄れるべきではありません。この文書では、Softwiresに適用されるすべての自発的トンネリング関連L2TPv2属性を識別し、実装におけるあいまいさを避けるために、このような属性の処理メカニズムを指定します。この文書はまた、L2TPv2のセットがSoftwiresに適用され、無視するかSoftwireのコンテキスト内でその効果を無効にするメカニズムを指定しない強制的トンネリングモデルに固有の属性を識別します。
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は、[RFC2661]に記載L2TPv2動作に従わなければならないときに実行Softwire確立、解体、および運用、管理、および管理（OAM）。 L2TPv2と、Softwireは、L2TPv2コントロール接続で構成され、単一のL2TPv2セッション、およびセッションでネゴシエートPPPリンク（制御チャネルとも呼ばれます）。 Softwireを確立するために、SIは、最初の要求を受け入れ、制御チャネルを終了SCにL2TPv2制御チャネルを開始します。 L2TPv2は、SIとSCの両方が制御チャネルの確立を進める前に手振っの初期段階で互いの身元を検証することを可能にするオプションの相互制御チャネル認証をサポートしています。 L2TPv2コントロールチャネルはSIとSCの間で確立された後、SIは、SCにL2TPv2セッションを開始します。そして、PPP / IPリンクはSIとSCの間L2TPv2セッションを介して交渉しています。 PPP / IPリンクが確立された後、それは別のアドレスファミリのアクセスネットワークを介して1つのアドレスファミリ（AF）のIPトラフィックをトンネリングするためにSIとSCの間Softwireとして機能します。
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の両方がSoftwireとピアL2TPコントロール接続のエンドポイント（LCCE）の健全性を監視するためのL2TPv2キープアライブhelloメッセージを送信し、潜在的にNAT / NAPT（ネットワークアドレス変換/ネットワークポートアドレスリフレッシュしますCPE時またはアクセスリンクの他端の翻訳）エントリー。必要に応じて、リンク制御プロトコル（LCP）エコーメッセージは、同じ目的のためにキープアライブとして使用することができます。キープアライブタイムアウトまたはSoftwireの行政シャットダウンした場合には、SIまたはSCのいずれかは、[RFC2661]で指定されたL2TPv2コントロールチャネルとのセッションを切断することによりSoftwireを取り壊す場合があります。
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は、ピアLCCEによってリモートシステムからトンネルされるPPPセッションの論理的な終端点です。 （[RFC2661]を参照）。
SC Softwire Concentrator, the node terminating the Softwire in the service provider network. (See [RFC4925].)
SC Softwireコンセントレータ、サービスプロバイダーネットワーク内でSoftwireを終了するノード。 （[RFC4925]を参照）。
SI Softwire Initiator, the node initiating the Softwire within the customer network. (See [RFC4925].)
SI Softwireイニシエータ、顧客のネットワーク内Softwireを開始ノード。 （[RFC4925]を参照）。
SPH Softwire Payload Header, the IP headers being carried within a Softwire. (See [RFC4925].)
SPH Softwireペイロードヘッダーは、IPヘッダはSoftwire以内に実施されます。 （[RFC4925]を参照）。
STH Softwire Transport Header, the outermost IP header of a Softwire. (See [RFC4925].)
STH Softwire転送ヘッダ、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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".
このドキュメントのいくつかのセクションでは、相互運用性とSoftwireの実装が正しく動作するために必要なされていない注意事項が含まれています。これらのセクションのタイトルは 『留意事項』で始まるマークされています。
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.
「ハブとスポーク」Softwireは、ネットワークアドレス変換（NAT）およびネットワークアドレスポート変換を通過することができなければならないが、問題のシナリオは、非を含む場合にデバイス[RFC3022]（NAPT、またポート・アドレス変換またはPATと呼ばれます）アップグレード、NAT / NAPTを実行するアクセスリンクのもう一方の端にNAT / NAPTまたはいくつかのキャリアの設備を行ったIPv4ホームゲートウェイを既存の。 L2TPv2は、UDP上で実行することができますので、L2TPv2 Softwire（すなわち、制御チャネルおよびセッション）が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「自動検出」と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]及び[RFC3193]のセクション4の8.1節で述べたように、L2TPスタートコントロール接続応答（SCCRP）レスポンダ（SC）は、イニシエータのスタートからのものとは異なるIPアドレス及び/又はUDPポートを選択することができます-control-接続要求（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.
「ハブとスポーク」モデルでは、キャリアはより多くのハブを追加することによってSoftwireイニシエータの数百万の溶液を拡張することができなければならない（すなわち、Softwireコンセントレータ）。 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との間には、ダイナミックルーティングプロトコルはありません。 SCへのSIからデフォルトルートが使用されています。
Multicast protocols simply run transparently over L2TPv2 Softwires together with other regular IP traffic.
マルチキャストプロトコルは、単に他の通常のIPトラフィックと一緒にL2TPv2 Softwiresの上に透過的に実行されます。
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は、認証と承認の両方のために（例えば、RADIUSなど）AAA溶液とよく統合します。市場で利用可能なほとんどのL2TPv2実装は、認証および承認イベントのロギングをサポートしています。
L2TPv2 integration with RADIUS accounting (RADIUS Accounting extension for tunnel [RFC2867]) allows the collection and reporting of L2TPv2 Softwire usage statistics.
RADIUSアカウンティング（トンネルのRADIUSアカウンティング拡張[RFC2867]）とL2TPv2の統合は、L2TPv2 Softwire使用統計の収集とレポート作成を可能にします。
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.
フルペイロードのセキュリティが必要とされていないSoftwireの展開では、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は、最後のデータまたは制御メッセージは、トンネル上で受信されてから指定された期間は、（[RFC2661]のセクション5.5を参照）が経過した後に、HELLO制御メッセージを噴射する任意のインバンドキープアライブ機構をサポートします。ハロー制御メッセージが確実に配信されていない場合は、制御チャネルとそのセッションが切断されます。 Softwireの文脈では、L2TPv2キープアライブは、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こんにちはキープアライブを使用する必要があり、加えて、デッドエンド検出を確実にするため、および/またはNAT / NAPT変換エントリをリフレッシュするためにPPP LCPエコーメッセージを使用するかもしれません。これら二つの機構の組合せは、最適化として使用することができます。
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]は、このような制御チャネルとセッション、制御チャネルのポーリングとセッションの状態とそれらのトラフィックの統計情報と制御チャネルとセッションUP / DOWNイベントの通知の設定などの管理操作の完全なスイートをサポートしています。
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の「自動検出」をサポートしていませんので、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つのシナリオのそれぞれにおいて、異なるホーム機器はSoftwireイニシエータの役割を果たしています。このセクションでは、SoftwireプロトコルとしてL2TPv2、溶液を完了するために関与する他の可能なプロトコルと各シナリオを詳しく説明します。このセクションでは、IPv6オーバーIPv4の（セクション3.1）とIPv4オーバーの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イニシエータ（SI）は、デュアルスタックである（直接モデムに接続された）宿主CPE、です。他のゲートウェイデバイスはありません。 IPv4トラフィックはSoftwireを通過すべきではありません。図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
このシナリオでは、L2TPv2制御チャネルとセッション確立およびPPP LCPネゴシエーション（および必要に応じてPPP認証）が成功した後、IPv6の制御プロトコル（IPV6CP）も割り当てるISPのための能力を提供するIPv6のオーバーPPPをネゴシエート64ビットのホストCPEへのインターフェイス識別子又は二PPP 2つのインタフェース識別子の一意性検証を行うには、[RFC5072]を終了します。 IPv6のオーバーPPPがアップした後、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.
以下のような他の非アドレスの設定オプションながら、ステートレスアドレス自動設定/近隣探索がIPv6オーバーPPPリンク上で動作し、LNSは、ルータ広告（RA）を介してステートレスアドレス自動設定に使用するプレフィックスのホスト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イニシエータ（SI）は、デュアルスタックデバイスであるルータCPE、です。 IPv4トラフィックはSoftwireを通過すべきではありません。図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：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
このシナリオでは、L2TPv2制御チャネルとセッション確立およびPPP LCPネゴシエーション（および必要に応じてPPP認証）が成功した後、IPV6CPはまた、64ビットを割り当てるISPのための能力を提供するIPv6のオーバーPPPをネゴシエート
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.
ルータCPEのインターフェイス識別子又は二PPP 2つのインタフェース識別子の一意性検証を行うには、[RFC5072]を終了します。 IPv6のオーバーPPPがアップした後、IPv6のステートレスアドレスの自動構成/近隣探索は、IPv6オーバーPPPリンク上で動作し、LNSは、ルータ広告（RA）を介してステートレスアドレス自動設定に使用するプレフィックスのルータCPEを知らせることができます。 DHCPv6の（例えば、ホーム・ネットワーク[RFC3633]内で使用される接頭辞を委任）は、IPv6プレフィックス委任を実行し、ルータCPEに（例えばDNS [RFC3646]のような）他の非アドレス構成オプションを伝達するために使用することができます。
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イニシエータ（SI）は、IPv6ホストCPEとして作用する（IPv4のみCPE後ろ）デュアルスタックホストです。 IPv4トラフィックはSoftwireを通過すべきではありません。図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：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
このシナリオでは、L2TPv2制御チャネルとセッション確立およびPPP LCPネゴシエーション（および必要に応じてPPP認証）が成功した後、IPV6CPはまた、64ビットを割り当てるISPのための能力を提供するIPv6のオーバーPPPをネゴシエート
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.
ホストへのインターフェイス識別子又は二PPP 2つのインタフェース識別子の一意性検証を行うには、[RFC5072]を終了します。 IPv6のオーバーPPPがアップした後、IPv6のステートレスアドレスの自動構成/近隣探索は、IPv6オーバーPPPリンク上で動作し、LNSは、ルータ広告（RA）しばらくを通じてステートレスアドレス自動設定に使用するプレフィックスのホストに知らせることができます（例えば、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イニシエータ（SI）は、ホームネットワーク内のIPv6のCPEルータとして動作する（IPv4のみCPEの背後にある）デュアルスタックデバイスです。 IPv4トラフィックはSoftwireを通過すべきではありません。図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はまた、64ビットのインターフェイス識別子を割り当てるISPのための能力を提供するIPv6のオーバーPPPをネゴシエートまたはV4 / V6ルータへの2つのPPP端[RFC5072]に2つのインタフェース識別子の一意性検証を行います。 IPv6のオーバーPPPがアップした後、（IPv6のステートレスアドレスの自動構成/近隣探索は、IPv6オーバーPPPリンク上で動作し、LNSは、ルータ広告を通じてステートレスアドレス自動設定に使用するプレフィックスのV4 / v6のルータに通知することができますRA）。 DHCPv6の（例えば、ホーム・ネットワーク[RFC3633]内で使用される接頭辞を委任）は、IPv6プレフィックス委任を実行し、V4 / V6ルータに（例えばDNS [RFC3646]のような）他の非アドレス構成オプションを伝達するために使用することができます。
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イニシエータ（SI）は、デュアルスタックである（直接モデムに接続された）宿主CPE、です。他のゲートウェイデバイスはありません。 IPv6トラフィックはSoftwireを通過すべきではありません。図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）も割り当てるISPのための能力を提供するのIPv4オーバー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イニシエータ（SI）は、デュアルスタックデバイスであるルータCPE、です。 IPv6トラフィックはSoftwireを通過すべきではありません。図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：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 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アドレスを割り当てるためのISPのための能力を提供するのIPv4オーバーPPPをネゴシエートCPE。グローバルIPv4アドレスもDHCP経由で割り当てることができます。他の設定オプションが（DNSなど）IPCP [RFC1877]またはDHCP [RFC2132]を介してルータCPEに搬送することができます。ホームネットワークのIPv4プレフィックス委任の場合は、DHCP [サブネット-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イニシエータ（SI）は、IPv4ホストのCPEとして働く（のIPv6 CPE後ろ）デュアルスタックホストです。 IPv6トラフィックはSoftwireを通過すべきではありません。図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開始剤として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アドレスを割り当てるためのISPのための能力を提供するのIPv4オーバーPPPをネゴシエート。グローバル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イニシエータ（SI）は、ホームネットワーク内のIPv4のCPEルータとして動作する（IPv6のみのCPEの背後にある）デュアルスタックデバイスです。 IPv6トラフィックはSoftwireを通過すべきではありません。図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はまた、V4にグローバルIPv4アドレスを割り当てるためのISPのための能力を提供するのIPv4オーバーPPPをネゴシエート/ v6のルータ。グローバルIPv4アドレスもDHCP経由で割り当てることができます。他の設定オプションが（DNSなど）IPCP [RFC1877]またはDHCP [RFC2132]を介しV4 / V6ルータに搬送することができます。ホームネットワークのIPv4プレフィックス委任の場合は、DHCP [サブネット-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.
この項では、グループのSoftwire「ハブとスポーク」ソリューションの枠組みを設計するために使用される技術を記述し、インターネットの標準化からの文書。これは、できるだけ多くの既存の規格を再利用するSoftwireのモチベーションを強調しています。このリストは、標準化過程（標準化提案、ドラフト標準、および標準）および情報提供文書の両方が含まれています。文書とそのステータスのリストには、説明のみを目的として使用する必要があります。
RFC 2661 "Layer Two Tunneling Protocol 'L2TP'" [RFC2661].
RFC 2661 "レイヤ2トンネリングプロトコル 'L2TP'" [RFC2661]。
* For both IPv4 and IPv6 payloads (SPH), support is
complete.
* 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].
[RFC2865] RFC 2865 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
* Updated by [RFC2868], [RFC3575], and [RFC5080].
* [RFC2868]、[RFC3575]、および[RFC5080]で更新。
RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol Support" [RFC2867].
RFC 2867 "トンネルプロトコルサポートのためのRADIUSアカウンティングの変更" [RFC2867]。
RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868].
RFC 2868 [RFC2868] "RADIUSは、トンネルプロトコルサポートのための属性"。
RFC 3162 "RADIUS and IPv6" [RFC3162].
RFC 3162 "RADIUSと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 [RFC1473]「ポイントツーポイントプロトコルのIPネットワーク制御プロトコルのための管理オブジェクトの定義」。
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のステートレスアドレス自動設定" [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 [RFC3633] "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
RFC 3646 "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3646].
[RFC3646] RFC 3646 "IPv6の動的ホスト構成プロトコル（DHCPv6の）用DNSの設定オプション"。
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].
*進行中の作業、[サブネット-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.
Softwireは、潜在的に任意のIPsec関連ステップ0が先行する三つの異なる段階（図9参照）で確立されています。まず、単一のセッションにL2TPv2トンネルはSCにSIから確立されます。第二に、PPPセッションは、L2TPv2セッションを介して確立され、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：Softwireの確立のための手順
Figure 10 depicts details of each of these steps required to establish a Softwire.
図10はSoftwireを確立するために必要なこれらの各手順の詳細を示します。
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：Softwireの確立に詳細な手順
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で説明されています。過剰のIPv4 Softwires、とIPv4オーバーのIPv6 SoftwiresためIPCP IPv6-ステップ2使用IPV6CPにおけるPPPネットワーク制御プロトコル（NCP）交渉（セクション5.2.4を参照）。 IPv6のオーバーのIPv4 Softwires、とIPv4オーバーのIPv6 SoftwiresためDHCPv4のステップ3のDHCPv6で任意DHCP交渉（セクション5.4を参照）。さらに、IPv6オーバーIPv4のSoftwiresために、（DNSなど）、非アドレス構成のためのDHCPv6交換は、情報要求にステートレスDHCPv6の、2つのメッセージ交換を使用してメッセージを返信することができる（[RFC3315]のセクション1.2を参照して[ 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は、次にL2TPネットワークサーバー（LNS）にL2TPv2トンネルを開始します。 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「ハブとスポーク」でモデルを、Softwireイニシエータ（SI）は、LACクライアントとSoftwireコンセントレータ（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定義以下：「トンネルは制御接続と0個以上の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は、メッセージが交換され、属性値ペア（AVPの）はSI（LAC）及びSC（LNS）との間にトンネルを確立するために使用説明します。ここで説明するメッセージとのAVPは[RFC2661]で定義されたもののサブセットのみです。 Softwiresは、L2TPv2機能のサブセットのみを使用するためです。 Softwiresにも適用可能であるL2TPコントロール接続管理のAVPのサブセットごとの制御メッセージに基づいて、必須のAVPおよびオプションのAVPに分類される（図11参照）。各制御メッセージのために、必須のAVPは、制御メッセージのための[RFC2661]からのすべての「存在していなければなりません」AVPを含む、およびオプションのAVPは、その制御にSoftwireコンテキストで使用されている[RFC2661]から「存在しているかもしれません」AVPを含みますメッセージ。 Softwire環境では、SIは常にトンネルを開始することに注意してください。 L2TPv2のAVPは隠されるべきではありません。
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セッションで表されます。 Softwire環境では、トンネルは、単一のユーザの情報を運びます。その結果、トンネルごとに1つだけL2TPv2セッションが存在します。図12は、メッセージが交換とのAVPは、SI（LAC）及びSC（LNS）との間のセッションを確立するために使用説明します。ここで説明するメッセージとのAVPは[RFC2661]で定義されたもののサブセットのみです。 Softwiresは、L2TPv2機能のサブセットのみを使用するためです。 Softwiresにも適用可能であるL2TPコールマネージメント（即ち、セッション管理）のAVPのサブセットが（図12参照）ごとの制御メッセージに基づいて必須のAVPおよびオプションのAVPに分類されます。各制御メッセージのために、必須のAVPは、制御メッセージのための[RFC2661]からのすべての「存在していなければなりません」AVPを含む、およびオプションのAVPは、その制御にSoftwireコンテキストで使用されている[RFC2661]から「存在しているかもしれません」AVPを含みますメッセージ。 Softwire環境では、SIは、常にセッションを開始することに注意してください。 SoftwireためのL2TPv2セッションのセットアップはのみ着信モデルを使用しています。発信またはアナログ通話（セッション）何が許可されていません。 L2TPv2のAVPは隠されるべきではありません。
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.3スルー5.1.1.1）は、オプションであり、L2TPv2トンネル確立のために関連しないことが要求される（メッセージは、それぞれ、図11及び12に流れる参照）コントロール接続およびセッションの確立のAVPをより詳細に説明しますSoftwireの。 [RFC2661]で定義されるように明示的にこれらのセクションに記載されていない特定L2TPv2プロトコルメッセージとフローが処理されます。
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.
このセクションでは、それらがSoftwireコンテキストで使用されるように、Softwire確立するために使用されるメッセージの一つ以上に存在する（[RFC2661]によって）必要とされるのAVPの特定の値を規定します。これは、セクション5.1.1にすべての制御メッセージから必要なすべてのAVPを兼ね備え、かつSoftwire固有の使用のガイダンスを提供します。
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）ビットがこのAVPは、受信機によって無視されるべきである1に設定されるべきです。
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 Softwireコンテキストでは意味がありません。その値は0に設定され、受信機によって無視されるべきです。
Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call Serial Number AVP, and Assigned Session ID AVP
メッセージタイプAVP、プロトコルバージョンAVP、割り当てられたトンネルID AVP、シリアル番号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.
このセクションはオプションでのAVPの特定の値を規定する（[RFC2661]によって必要とされていない）が、Softwireの文脈で使用されます。これは、セクション5.1.1におけるすべての制御メッセージからすべてのオプションAVPを兼ね備え、かつSoftwire固有の使用のガイダンスを提供します。
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を指定し、Softwiresとは無関係です。彼らはSoftwire確立フローには適用されませんので、彼らは（Softwiresのみ着信メッセージ・フローを使用しながら、例えば、それらは唯一、発信コール確立メッセージ交換に使用されている）Softwiresに無関係であることができ、またはそれらはオプションのAVPであるため、使用されていない。 Softwiresに関連するL2TPv2ののAVPは、セクション5.1.1、5.1.1.1、および5.1.1.2で覆われていました。 Softwire実装はSoftwiresに関連していない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ハロー、LCP ECHOメッセージ（エコー要求およびエコー応答コード）と組み合わせて使用することができます。使用する場合、LCP ECHOメッセージは、L2TPv2 HELLOメッセージの値より低い再放出のタイマーを持っているべきです。 HELLOメッセージの再送信間隔のために[RFC2661]のセクション6.5で推奨されるデフォルト値は60秒です。使用される場合、LCP ECHOメッセージ要求間隔の間（のみガイダンスのためにここに含まれる）推奨値の組は、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で指定されるように行われます。この場合、Softwiresに固有のアクションはありません。
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).
Softwire「ハブとスポーク」のフレームワークを、L2TPv2は、IPインIPトンネルの一部として、UDPの上に積層されています。 [RFC2661]のセクション8.1は、UDP / IP上でL2TPを説明しています。彼らはIPベースのトラフィックを運ぶUDPトンネリングのシナリオに関係したがって、[RFC5405]で指定された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は、リンクMTUマイナス一緒にIP、UDP、L2TPv2、およびPPPヘッダのサイズである必要があります。 1500バイトに等しいMTUとIPv4リンク上で、これは、典型的には、1460バイトのMTU PPPを意味するかもしれません。リンクはIPsecのによって管理されている場合は、このMTUは、アカウントにESPのカプセル化を取るように小さくする必要があります（[SW-SEC]）。 MTUの値は、（[RFC2661]を参照）L2TPメッセージヘッダの先頭ビットによって定義されるように、L2TPヘッダの大きさに応じて変化してもよいです。また、断片化の問題の詳細な議論のための[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]に記載されているように、SI及びSCは、LCPを交渉することによって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イニシエータとSoftwireコンセントレータの両方でサポートされなければなりません。たとえば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としてIPv4のSPHとしてIPv6のIPV6CP（セクション5.2.4.1を参照）、及び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.
[RFC5072]で定義されたIPv6オーバーIPv4のシナリオ（セクション3.1を参照）、オプションの認証フェーズ後、Softwireイニシエータは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のオーバーのIPv6シナリオでは（セクション3.2を参照）、Softwireイニシエータは、IPCP [RFC1332]を交渉しなければなりません。 SIは、SCからIPv4アドレスを取得するためにIPCPを使用しています。 IPCPはまた、[RFC1877]に記載されているように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を使用して自動設定リンクローカルアドレスに加えて）Softwireエンドポイントに割り当てられることが期待されます。 Softwireイニシエータは、IPV6CPネゴシエートインタフェース識別子を使用し、ステートレスアドレス自動設定[RFC4862]を用いて、及び/又はステートレスアドレス自動設定[RFC4941]のためのプライバシー拡張を使用して、グローバルIPv6アドレス割り当て（セクション5に記載されているように[RFC5072]）、および/またはまたは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.
IPV6CPが完了した後のIPv6 SoftwireのSoftwireイニシエータはSoftwireコンセントレータにルータ要請メッセージを送らなければなりません。 Softwireコンセントレータは、ルータ広告に答える必要があります。近隣探索が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イニシエータは、Softwireエンドポイントのアドレスを設定するには、DHCPv6のリクエストを送らなければなりません。
Duplicate Address Detection ([RFC4861]) MUST be performed on the Softwire in both cases.
重複アドレス検出（[RFC4861]）は、両方の場合においてSoftwire上で実行されなければなりません。
The Softwire Initiator MAY use DHCP to get additional information such as delegated prefix and DNS servers.
Softwireイニシエータは、委任プレフィックスとDNSサーバなどの追加情報を取得するためにDHCPを使用するかもしれません。
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.
SIは、DHCPv6のをサポートしている場合は、セクション3.1でのシナリオでは、それはより多くの情報が入手可能であるかどうかを確認するために要請メッセージを送信する必要があります。
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のSoftwireを確立するSIは（セクション3.1.2および3.1.4でのシナリオではすなわち、）ルータとして動作する場合には、DHCPv6の要請メッセージにプレフィックス委任のためのアイデンティティ協会（IA_PD）オプション[RFC3633] [RFC3315を含まなければなりません] 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.
DHCPv6のを返すことによってSIにIPv6プレフィックスを委任がIA_PDとIP_PDプリフィックスオプション[RFC3633]のメッセージを広告するとき、SCは、関連Softwireにトラフィックを転送するために、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].
[RFC3646]で指定し、[RFC3315]及び[RFC3736]に従って送信としてDNSの構成が行われなければなりません。一般的に、すべての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のSoftwireを確立するSIは、サブネット割り当てオプション[サブネット-ALL]を含むDHCP要求を送信することができます。この方法は一般的ではないが、セクション3.2.2及び3.2.4で定義され、Softwiresを使用して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つのサブネット・リクエスト・サブオプションは、「1」に設定ビットが「H」を設定する必要があります。サブネット・リクエスト・サブオプションの「I」ビットがプレフィックスが割り当てられている場合、プレフィックスは、後続の要求で要求し、「1」に「0」最初の時間に設定されるべきです。プレフィックス長のサブオプションは、デフォルトでは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.
SIへのIPv4プレフィックスを委任するとき、セクション3.2でのシナリオでは、SCは、関連Softwireにトラフィックを転送するために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コンセントレータがSoftwireエンドポイント用とSoftwireイニシエータの背後にあるサブネットの委任アドレスを管理する方法について説明します。一つの一般的な方法は、SCにルーティング1つのプレフィックスにエンドポイントのアドレスおよび委任プレフィックスを集約することです。主な利点は、（SIのための新しいプレフィックスを委任する場合）SC後続経路注射で単離することにより、ルーティング方式を容易にするためです。
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.
SoftwireコンセントレータはSoftwireエンドポイントにグローバルにルーティング可能なアドレスを提供する必要があります。こうしたユニークローカルアドレス（ULAs）など他のタイプのアドレスは、[RFC4193]はありませんグローバルな接続とプライベートネットワークにSoftwireエンドポイントに対処するために使用することができます。単一/ 64は、両方のSoftwireエンドポイントに対処するSoftwireに割り当てられるべきです。
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.
グローバルアドレスまたはULAsは（セクション3.1.1を参照）シナリオ「Softwire開始剤としてホストCPE」が配備されると考えられているエンドポイントに割り当てられなければなりません。他のシナリオでは、リンクローカルアドレスを使用することもできます。
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コンセントレータは、グローバルにルーティング可能なまたはプライベートのどちらかIPv4アドレスを提供することができます。エンドポイント上でIPv4プライベートアドレス[RFC1918]を使用する場合、ネストされた-NAT状況につながることができますよう、SIへのIPv4プライベートプレフィックスを委任することは推奨されません。
The endpoints of the PPP link use host addresses (i.e., /32), negotiated using IPCP.
PPPリンク用ホストアドレス（つまり、/ 32）のエンドポイントは、IPCPを使用してネゴシエート。
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も、根本的なアドレス指定方式が変更された場合、自動トンネリングに反対し、安定したアドレスを提供することができます。 Softwireコンセントレータは、常に再接続のユーザーに同じアドレスとプレフィックスを提供する必要があります。 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コンセントレータへの再接続時に変更することが予想されます。しかし、Softwireサービスを提供する組織は、より細分化ルーティングテーブルのコストに異なるSoftwireコンセントレータで同じアドレスとプレフィックスを提供することができます。プレフィックスがSCにトポロジー的近い場所に集約されている場合、ルーティングフラグメンテーション問題が制限されてもよいです。いくつかのSCSは、ロードバランシングの目的のために並列に配置されている場合、これは、例えば、ケースになります。
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コンセントレータは、例えば、AAAサーバのクライアントとしてRADIUSサーバとして機能することが期待されます。 PPP認証フェーズ中に、RADIUSサーバはAccess-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.
Softwireコンセントレータは、トンネルタイプおよびトンネルメディアタイプが設定されているSoftwireのタイプのヒントを提供するために、アクセス要求メッセージに[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サーバフレームを選ぶ・インタフェース-Id属性[RFC3162]を含んでいる場合、Softwireコンセントレータは、その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.
Framed-IPv6-Prefixアトリビュート[RFC3162]が含まれている場合は、その接頭辞は、SIに送信されたルータアドバタイズメントで使用する必要があります。フレームを選ぶ-のIPv6プレフィックスが存在しないが、額縁-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.
Framed-IP-Address属性[RFC2865]が存在する場合は、SoftwireコンセントレータはIPCPアドレスネゴシエーション中にSoftwireイニシエータにそのアドレスを提供しなければなりません。 SoftwireイニシエータはSoftwireコンセントレータ、額縁-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.
[RFC4818]-のIPv6プレフィックス委任属性がRADIUS Access-Acceptメッセージに存在している場合は、IPv6プレフィックスの委任にSoftwireコンセントレータによって使用する必要があります。ユーザ名にプレフィックス委任が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サーバの間の相互作用は、[RELAY-RAD]で提案されたメカニズムに従うことができます。この場合、Softwire認証フェーズ中に、PPPは、RADIUSは、委任-のIPv6プレフィックスとしてユーザの属性を収集します。特定のDHCPv6リレーはSoftwireに割り当てられます。 DHCPv6リレーは、DHCPv6サーバへのDHCPv6要求を転送する前に、オプション（RRAO）のDHCPv6オプション属性リレーエージェントRADIUSでこれらの属性を記入します。
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-ネットマスクは、[RFC2865]を属性）SoftwireイニシエータにIPv4のプレフィックスを委任するSoftwireコンセントレータによって使用されてもよいです。 Softwireコンセントレータは、ネクストホップとして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.
このような行為は、Framed-IP-Address属性は、IPv4オーバーのIPv6シナリオでは、例えば（SoftwireイニシエータへのIPv4プレフィックスを委任するSoftwireコンセントレータを伝えるとともに、Framed-IP-Netmask属性を含めることを使用していたとしてSoftwireイニシエータがルータです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方法を含むロギング目的のために補助又は付帯情報を搬送するための既存のプロトコル機構は、挙動がSoftwireに記載されていることを通知テキストを含む「ハブとスポーク」（この文書で指定された実装の詳細次の）フレームワークをすることができます。
RADIUS Accounting for L2TP and PPP are documented (see Section 4.3).
L2TPおよびPPPのためのRADIUSアカウンティングは、（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]).
一つのデザインの目標は「ハブとスポーク」の問題が非常に強く、すでに展開されたプロトコル（[RFC4925]を参照）の再利用を検討することです。別の設計目標は、非常に高いスケーリング特性を持つソリューションです。 L2TPv2 [RFC2661]はSoftwireで使用されるフェーズ1のプロトコルである「ハブとスポーク」解空間を、そしてL2TPv2のセキュリティ問題は、（[RFC2661]のセクション9を参照）は、この文書に適用されます。
The L2TPv2 Softwire solution adds the following considerations:
L2TPv2 Softwireソリューションは、次の注意事項を追加します。
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トンネル認証（セクション5.1.1と[RFC2661]の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 Softwire環境では、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
OセキュリティL2TPv2 IPsecを使用して、 "バージョン2"（IKEv1の）は、[RFC3193]、[RFC3947]及び[RFC3948]で指定されています。 L2TPv2はSoftwireのコンテキストで使用される場合、自発的トンネリングモデルが適用されます。 [RFC3193]はIPsecとL2TPv2の間の相互作用を説明し、そして
is deployed. [RFC3193] MUST be supported, given that deployed technology must be very strongly considered [RFC4925] for this 'time-to-market' solution.
配備されています。 [RFC3193]は展開技術は非常に強く、この「タイム・トゥ・マーケットのソリューションのために[RFC4925]考慮されなければならないことを考えると、サポートしなければなりません。
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]はまた、 "バージョン3"（のIKEv2）IPsecでL2TPv2を確保するための新たな（互換性のない）ソリューションを特定します。 [SW-SEC]のセクション3.5のIKEv2を使用する利点を説明し、この溶液を将来のフェーズのために考慮される必要があります。
Additional discussion of Softwire security is contained in [SW-SEC].
Softwireセキュリティの更なる議論は[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.
フロラン親、ジョルディPaletマルティネス、オレTroan、宮川晋、カール・ウィリアムズ、マークTownsley、フランシスデュポン、ラルフDroms、Hemantシン、そしてアラン・デュラン：著者は、本書に役立つ入力を提供し、次の貢献者を承認したいと思います。
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.
著者らはまた、香港、中国、スペイン、バルセロナで開催されたSoftwires暫定会議の参加を承認したいと思います。中国大学の中間会合の分 - 香港（2月23-24、2006）は、<http://www.ietf.org/proceedings/06mar/isoftwire.html>です。カタロニア工科大学の中間会合の分 - バルセロナ（9月14-15、2006）は、<http://www.ietf.org/proceedings/06nov/isoftwire.html>で到達可能です。 <http://bgp.nu/~dward/softwires/>で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ラストコール中および後に、有益なコメントや議論はヤリArkko、デビッド・ブラック、ラースEggertの、パシEronen、およびダンRomascanuによって提供されました。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー、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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル "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.
、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル" [RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、ゾルン、G.、およびD.ミットン、 "RADIUSと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]パテル、B.、Aboba、B.、ディクソン、W.、ゾルン、G.、およびS.ブース、 "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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、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]の洞窟、E.、カルフーン、P.、およびR.ウィーラー、 "レイヤ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、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[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.ボルペ、 "IKEにおけるNATトラバーサルのネゴシエーション"、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.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "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委任-のIPv6-prefix属性"、RFC 4818、2007年4月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC5072] S.Varada、ハスキンズ、D.、およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 5072、2007年9月。
[RELAY-RAD] Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", Work in Progress, February 2006.
[RELAY-RAD]ラウ、W.は、進歩、2006年2月に、仕事を "DHCPv6のリレーエージェントRADIUSは、オプション属性"。
[RFC1471] Kastenholz, F., "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol", RFC 1471, June 1993.
、RFC 1471、1993年6月[RFC1471] Kastenholzと、F.、「ポイントツーポイントプロトコルのリンク制御プロトコルのための管理オブジェクトの定義」。
[RFC1473] Kastenholz, F., "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol", RFC 1473, June 1993.
、RFC 1473、1993年6月[RFC1473] Kastenholzと、F.、「ポイントツーポイントプロトコルのIPネットワーク制御プロトコルのための管理オブジェクトの定義」。
[RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses", RFC 1877, December 1995.
[RFC1877]コブ、S.およびF.ベイカー、 "ネームサーバーアドレスのための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]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
[RFC2433]ソーン、G.とS.コブ、 "マイクロソフトPPP CHAP拡張機能"、RFC 2433、1998年10月。
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RFC2867]ソーン、G.、Aboba、B.、およびD.ミトン、 "トンネルプロトコルサポートのためのRADIUSアカウンティングの変更"、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]ゾルン、G.、Leifer、D.、ルーベンス、A.、シュライバー、J.、ホールドレッジ、M.、およびI. Goyret、RFC 2868、2000年6月 "RADIUSトンネルプロトコルサポートのための属性"。
[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月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646] Droms、R.、RFC 3646、2003年12月の "IPv6のための動的ホスト構成プロトコル（DHCPv6）のためのDNSの設定オプション"。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、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]ラウ、J.、Townsley、M.、およびI. Goyret、 "レイヤ2トンネリングプロトコル - バージョン3（L2TPv3の）"、RFC 3931、2005年3月。
[RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005.
[RFC4087]ターラー、D.、 "IPトンネルMIB"、RFC 4087、2005年6月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] HindenとR.とB.ハーバーマン、 "ユニークローカル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、 "擬似ワイヤエミュレーションエッジ・ツー・エッジ（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.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、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.、シンプソン、W.、およびH.ソリマン、 "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.、ドーキンス、S.、ウォード、D.、およびA.デュラン、 "Softwire問題文"、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.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、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]ネルソン、D.とA. DeKok、RFC 5080、2007年12月 "ユーザーサービス（RADIUS）の実装の問題と推奨修正に共通のリモート認証ダイヤル"。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]エッゲルト、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]ジョンソン、R.、Kumarasamy、J.、キニア、K.、およびM.スタップ、 "サブネット割り当てオプション"、進歩、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.、デュポン、F.、およびD.ビネー、 "Softwiresに会計処理" 進行中、仕事、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]山本、S.、ウィリアムズ、C.、親、F.、およびH.横田、 "Softwireセキュリティの分析と要件"、進歩、2009年5月での作業。
Authors' Addresses
著者のアドレス
Bill Storer Cisco Systems 170 W Tasman Dr San Jose, CA 95134 USA
ビル・ストアラーシスコシステムズ170 Wタスマン博士サンノゼ、CA 95134 USA
EMail: bstorer@cisco.com
メールアドレス：bstorer@cisco.com
Carlos Pignataro (editor) Cisco Systems 7200 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA
カルロスPignataro（編集者）、シスコシステムズ7200キットクリーク道路私書箱14987リサーチトライアングルパーク、NC 27709 USA
EMail: cpignata@cisco.com
メールアドレス：cpignata@cisco.com
Maria Alice Dos Santos Cisco Systems 170 W Tasman Dr San Jose, CA 95134 USA
マリア・アリス・ドス・サントスシスコシステムズ170 Wタスマン博士サンノゼ、CA 95134 USA
EMail: mariados@cisco.com
メールアドレス：mariados@cisco.com
Bruno Stevant (editor) TELECOM Bretagne 2 rue de la Chataigneraie CS17607 Cesson Sevigne, 35576 France
ブルーノStevant（編集者）ルー・デ・ラ・Chataigneraie CS17607セッソンセヴィニエ、フランス35576 TELECOMブルターニュ2
EMail: bruno.stevant@telecom-bretagne.eu
メールアドレス：bruno.stevant@telecom-bretagne.eu
Laurent Toutain TELECOM Bretagne 2 rue de la Chataigneraie CS17607 Cesson Sevigne, 35576 France
ローランToutain TELECOM Bretagneの2ルー・デ・ラ・Chataigneraie CS17607セッソンセヴィニエ、フランス35576
EMail: laurent.toutain@telecom-bretagne.eu
メールアドレス：laurent.toutain@telecom-bretagne.eu
Jean-Francois Tremblay Videotron Ltd. 612 Saint-Jacques Montreal, QC H3C 4M8 Canada
ジャン=フランソワ・トランブレビデオトロン株式会社612サンジャックモントリオール、QC H3C 4M8カナダ
EMail: jf@jftremblay.com
メールアドレス：jf@jftremblay.com