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
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)
具有第二层隧道协议版本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和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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（L2TPv2）的软线“中心辐射”解决方案的框架。应遵循本文件中规定的实施细节，以实现不同供应商实施之间的互操作性。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Abbreviations ..............................................5
1.2. Requirements Language ......................................5
1.3. Considerations .............................................6
2. Applicability of L2TPv2 for Softwire Requirements ...............6
2.1. Traditional Network Address Translation (NAT and NAPT) .....6
2.2. Scalability ................................................7
2.3. Routing ....................................................7
2.4. Multicast ..................................................7
2.5. Authentication, Authorization, and Accounting (AAA) ........7
2.6. Privacy, Integrity, and Replay Protection ..................7
2.7. Operations and Management ..................................8
2.8. Encapsulations .............................................8
3. Deployment Scenarios ............................................8
3.1. IPv6-over-IPv4 Softwires with L2TPv2 .......................9
3.1.1. Host CPE as Softwire Initiator ......................9
3.1.2. Router CPE as Softwire Initiator ...................10
3.1.3. Host behind CPE as Softwire Initiator ..............11
3.1.4. Router behind CPE as Softwire Initiator ............12
3.2. IPv4-over-IPv6 Softwires with L2TPv2 ......................14
3.2.1. Host CPE as Softwire Initiator .....................14
3.2.2. Router CPE as Softwire Initiator ...................15
3.2.3. Host behind CPE as Softwire Initiator ..............16
3.2.4. Router behind CPE as Softwire Initiator ............16
4. References to Standardization Documents ........................17
4.1. L2TPv2 ....................................................18
4.2. Securing the Softwire Transport ...........................18
4.3. Authentication, Authorization, and Accounting .............18
4.4. MIB .......................................................18
4.5. Softwire Payload Related ..................................19
4.5.1. For IPv6 Payloads ..................................19
4.5.2. For IPv4 Payloads ..................................19
5. Softwire Establishment .........................................20
5.1. L2TPv2 Tunnel Setup .......................................22
5.1.1. Tunnel Establishment ...............................22
5.1.1.1. AVPs Required for Softwires ...............25
5.1.1.2. AVPs Optional for Softwires ...............25
5.1.1.3. AVPs Not Relevant for Softwires ...........26
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
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.
Softwire工作组已选择第二层隧道协议版本2（L2TPv2）作为将部署在Softwire“中心辐射”解决方案空间的第一阶段协议。本文档描述了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.
在“中心辐射”解决方案空间中，建立了一条软线，以通过仅IPv6接入网络为家庭网络提供IPv4连接，或通过仅IPv4接入网络提供IPv6连接。当L2TPv2用于软线环境时，将应用自愿隧道模型。家庭网络中的软线启动器（SI）扮演L2TP接入集中器（LAC）客户端的角色（启动L2TP隧道/会话和PPP链路），而ISP中的软线集中器（SC）扮演L2TP网络服务器（LNS）的角色。[RFC3193]第1.1节对自愿隧道和强制隧道进行了定义。由于L2TPv2强制隧道模型不适用于软电线，因此不应要求或遵守该模型。本文档确定了适用于软连线的所有与隧道相关的L2TPv2属性，并指定了这些属性的处理机制，以避免实现中的歧义。本文档还确定了特定于强制隧道模型的L2TPv2属性集，该属性集不适用于软线，并指定了在软线上下文中忽略或取消其效果的机制。
The SI and SC MUST follow the L2TPv2 operations described in [RFC2661] when performing Softwire establishment, teardown, and Operations, Administration, and Management (OAM). With L2TPv2, a Softwire consists of an L2TPv2 Control Connection (also referred to as Control Channel), a single L2TPv2 Session, and the PPP link negotiated over the Session. To establish the Softwire, the SI first initiates an L2TPv2 Control Channel to the SC, which accepts the request and terminates the Control Channel. L2TPv2 supports an optional mutual Control Channel authentication that allows both SI and SC to validate each other's identity at the initial phase of hand-shaking before proceeding with Control Channel establishment. After the L2TPv2 Control Channel is established between the SI and SC, the SI initiates an L2TPv2 Session to the SC. Then the PPP/IP link is negotiated over the L2TPv2 Session between the SI and SC. After the PPP/IP link is established, it acts as the Softwire between the SI and SC for tunneling IP traffic of one Address Family (AF) across the access network of another Address Family.
SI和SC在执行软线建立、拆卸以及操作、管理和管理（OAM）时，必须遵循[RFC2661]中描述的L2TPv2操作。对于L2TPv2，软线由L2TPv2控制连接（也称为控制通道）、单个L2TPv2会话和通过会话协商的PPP链路组成。为了建立软线，SI首先向SC发起L2TPv2控制信道，SC接受请求并终止控制信道。L2TPv2支持可选的相互控制信道认证，允许SI和SC在开始建立控制信道之前，在握手的初始阶段验证彼此的身份。在SI和SC之间建立L2TPv2控制信道后，SI向SC发起L2TPv2会话。然后在SI和SC之间的L2TPv2会话上协商PPP/IP链路。在建立PPP/IP链路后，它充当SI和SC之间的软线，用于一个地址族（AF）的隧道IP通信通过另一个地址族的访问网络。
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].
在软线的生命周期内，SI和SC都发送L2TPv2 keepalive HELLO消息，以监视软线和对等L2TP控制连接端点（LCCE）的运行状况，并可能刷新CPE或接入链路另一端的NAT/NAPT（网络地址转换/网络地址端口转换）条目。出于同样的目的，链路控制协议（LCP）回显消息也可以用作keepalive。在软件线的keepalive超时或管理性关闭的情况下，SI或SC可以按照[RFC2661]中的规定，通过断开L2TPv2控制信道和会话来断开软件线。
AF Address Family, IPv4 or IPv6.
AF地址系列，IPv4或IPv6。
CPE Customer Premises Equipment.
CPE客户场所设备。
LCCE L2TP Control Connection Endpoint, an L2TP node that exists at either end of an L2TP Control Connection. (See [RFC3931].)
LCCE L2TP控制连接端点，存在于L2TP控制连接两端的L2TP节点。（参见[RFC3931]。）
LNS L2TP Network Server, a node that acts as one side of an L2TP tunnel (Control Connection) endpoint. The LNS is the logical termination point of a PPP session that is being tunneled from the remote system by the peer LCCE. (See [RFC2661].)
LNS L2TP网络服务器，充当L2TP隧道（控制连接）端点一侧的节点。LNS是对等LCCE从远程系统通过隧道传输的PPP会话的逻辑终止点。（见[RFC2661]。）
SC Softwire Concentrator, the node terminating the Softwire in the service provider network. (See [RFC4925].)
SC软线集中器，在服务提供商网络中终止软线的节点。（参见[RFC4925]。）
SI Softwire Initiator, the node initiating the Softwire within the customer network. (See [RFC4925].)
SI Softwire Initiator，在客户网络内发起软线的节点。（参见[RFC4925]。）
SPH Softwire Payload Header, the IP headers being carried within a Softwire. (See [RFC4925].)
SPH软线有效负载报头，IP报头在软线中承载。（参见[RFC4925]。）
STH Softwire Transport Header, the outermost IP header of a Softwire. (See [RFC4925].)
STH软线传输头，软线的最外层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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Some sections of this document contain considerations that are not required for interoperability and correct operation of Softwire implementations. These sections' titles are marked beginning with "Considerations".
本文档的某些部分包含互操作性和软线实现的正确操作所不需要的注意事项。这些章节的标题以“注意事项”开头。
A list of Softwire "Hub and Spoke" requirements has been identified by the Softwire Problem Statement [RFC4925]. The following sub-sections describe how L2TPv2 fulfills each of them.
软线问题声明[RFC4925]确定了软线“中心辐射”需求列表。以下小节介绍L2TPv2如何实现每一项功能。
A "Hub and Spoke" Softwire must be able to traverse Network Address Translation (NAT) and Network Address Port Translation (NAPT, also referred to as Port Address Translation or PAT) devices [RFC3022] in case the scenario in question involves a non-upgradable, preexisting IPv4 home gateway performing NAT/NAPT or some carrier equipment at the other end of the access link performing NAT/NAPT. The L2TPv2 Softwire (i.e., Control Channel and Session) is capable of NAT/NAPT traversal since L2TPv2 can run over UDP.
“集线器和辐条式”软线必须能够遍历网络地址转换（NAT）和网络地址端口转换（NAPT，也称为端口地址转换或PAT）设备[RFC3022]，以防所讨论的场景涉及不可升级，先前存在的IPv4家庭网关执行NAT/NAPT，或访问链路另一端的某些运营商设备执行NAT/NAPT。L2TPv2软线（即控制信道和会话）能够进行NAT/NAPT遍历，因为L2TPv2可以通过UDP运行。
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的选项。无论NAT/NAPT是否存在，UDP封装都存在。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]第8.1节和[RFC3193]第4节所述，L2TP启动控制连接应答器（SCCRP）应答器（SC）可以选择与启动器启动控制连接请求（SCCRQ）（SI）不同的IP地址和/或UDP端口。这可能会也可能不会遍历NAT/NAPT，这取决于NAT/NAPT的过滤行为（参见[RFC4787]第5节）。具体来说，任何IP地址和端口组合都将与端点无关的过滤一起工作，但更改IP地址和端口将无法通过地址相关或地址和端口相关的过滤来工作。因此，不建议从不同的IP地址和/或UDP端口进行响应。
In the "Hub and Spoke" model, a carrier must be able to scale the solution to millions of Softwire Initiators by adding more hubs (i.e., Softwire Concentrators). L2TPv2 is a widely deployed protocol in broadband services, and its scalability has been proven in multiple large-scale IPv4 Virtual Private Network deployments, which scale up to millions of subscribers each.
在“集线器和辐条”模式中，运营商必须能够通过添加更多集线器（即软线集中器）将解决方案扩展到数百万个软线启动器。L2TPv2是宽带服务中广泛部署的协议，其可扩展性已在多个大规模IPv4虚拟专用网络部署中得到验证，每个部署可扩展到数百万用户。
There are no dynamic routing protocols between the SC and SI. A default route from the SI to the SC is used.
SC和SI之间没有动态路由协议。使用从SI到SC的默认路由。
Multicast protocols simply run transparently over L2TPv2 Softwires together with other regular IP traffic.
多播协议只是在L2TPv2软线上与其他常规IP通信一起透明地运行。
L2TPv2 supports optional mutual Control Channel authentication and leverages the optional mutual PPP per-session authentication. L2TPv2 is well integrated with AAA solutions (such as RADIUS) for both authentication and authorization. Most L2TPv2 implementations available in the market support the logging of authentication and authorization events.
L2TPv2支持可选的相互控制通道身份验证，并利用可选的每会话相互PPP身份验证。L2TPv2与AAA解决方案（如RADIUS）很好地集成，用于身份验证和授权。市场上大多数L2TPv2实现都支持身份验证和授权事件的日志记录。
L2TPv2 integration with RADIUS accounting (RADIUS Accounting extension for tunnel [RFC2867]) allows the collection and reporting of L2TPv2 Softwire usage statistics.
L2TPv2与RADIUS accounting（隧道RADIUS accounting extension[RFC2867]）的集成允许收集和报告L2TPv2软线使用统计数据。
Since L2TPv2 runs over IP/UDP in the Softwire context, IPsec Encapsulating Security Payload (ESP) can be used in conjunction to provide per-packet authentication, integrity, replay protection, and confidentiality for both L2TPv2 control and data traffic [RFC3193] and [RFC3948].
由于L2TPv2在软线上下文中通过IP/UDP运行，因此可以结合使用IPsec封装安全负载（ESP）为L2TPv2控制和数据通信[RFC3193]和[RFC3948]提供每包身份验证、完整性、重播保护和机密性。
For Softwire deployments in which full payload security is not required, the L2TPv2 built-in Control Channel authentication and the inherited PPP authentication and PPP Encryption Control Protocol can be considered.
对于不需要完全有效负载安全性的软线部署，可以考虑L2TPv2内置控制通道身份验证以及继承的PPP身份验证和PPP加密控制协议。
L2TPv2 supports an optional in-band keepalive mechanism that injects HELLO control messages after a specified period of time has elapsed since the last data or control message was received on a tunnel (see Section 5.5 of [RFC2661]). If the HELLO control message is not reliably delivered, then the Control Channel and its Session will be torn down. In the Softwire context, the L2TPv2 keepalive is used to monitor the connectivity status between the SI and SC and/or as a refresh mechanism for any NAT/NAPT translation entry along the access link.
L2TPv2支持可选的带内keepalive机制，该机制在隧道上接收到最后一个数据或控制消息后经过指定的时间段后注入HELLO控制消息（请参见[RFC2661]第5.5节）。如果HELLO控制消息没有可靠地传递，那么控制通道及其会话将被中断。在软线上下文中，L2TPv2 keepalive用于监视SI和SC之间的连接状态和/或作为沿接入链路的任何NAT/NAPT转换条目的刷新机制。
LCP ECHO offers a similar mechanism to monitor the connectivity status, as described in [RFC1661]. Softwire implementations SHOULD use L2TPv2 Hello keepalives, and in addition MAY use PPP LCP Echo messages to ensure Dead End Detection and/or to refresh NAT/NAPT translation entries. The combination of these two mechanisms can be used as an optimization.
LCP ECHO提供了类似的机制来监控连接状态，如[RFC1661]所述。软线实现应使用L2TPv2 Hello keepalives，此外，还可以使用PPP LCP回显消息来确保死端检测和/或刷新NAT/NAPT转换条目。这两种机制的组合可用作优化。
The L2TPv2 MIB [RFC3371] supports the complete suite of management operations such as configuration of Control Channel and Session, polling of Control Channel and Session status and their traffic statistics and notifications of Control Channel and Session UP/DOWN events.
L2TPv2 MIB[RFC3371]支持一整套管理操作，如控制通道和会话的配置、控制通道和会话状态的轮询及其流量统计以及控制通道和会话上/下事件的通知。
L2TPv2 supports the following encapsulations:
L2TPv2支持以下封装：
o IPv6/PPP/L2TPv2/UDP/IPv4
o IPv6/PPP/L2TPv2/UDP/IPv4
o IPv4/PPP/L2TPv2/UDP/IPv6
o IPv4/PPP/L2TPv2/UDP/IPv6
o IPv4/PPP/L2TPv2/UDP/IPv4
o IPv4/PPP/L2TPv2/UDP/IPv4
o IPv6/PPP/L2TPv2/UDP/IPv6
o IPv6/PPP/L2TPv2/UDP/IPv6
Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not support "autodetect" of NAT/NAPT.
请注意，L2TPv2不支持UDP旁路，因为L2TPv2不支持NAT/NAPT的“自动检测”。
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
对于“中心辐射”问题空间，已经确定了四种场景。在这四个场景中的每一个场景中，不同的家庭设备都扮演着软线启动器的角色。本节详细介绍了以L2TPv2作为软线协议和
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.
完成解决方案可能涉及的其他协议。本节将研究IPv6-over-IPv4（第3.1节）和IPv4-over-IPv6（第3.2节）封装的四种方案。
The following sub-sections cover IPv6 connectivity (SPH) across an IPv4-only access network (STH) using a 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.
软线启动器（SI）是主机CPE（直接连接到调制解调器），它是双堆栈。没有其他网关设备。IPv4流量不应穿过软线。参见图1。
IPv6 or dual-stack IPv4-only dual-stack
|------------------||-----------------||----------|
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
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
<------------------>
IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check
|------------------>/64 prefix
RA
|------------------>DNS, etc.
DHCPv6
|------------------>/64 prefix
RA
|------------------>DNS, etc.
DHCPv6
Figure 1: Host CPE as Softwire Initiator
图1：作为软线启动器的主机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）通过PPP协商IPv6，它还为ISP提供了将64位接口标识符分配给主机CPE或在两个PPP端对两个接口标识符执行唯一性验证的能力[RFC5072]。PPP上的IPv6启动后，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 over 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.
软线启动器（SI）是路由器CPE，它是一个双栈设备。IPv4流量不应穿过软线。参见图2。
IPv6 or dual-stack IPv4-only dual-stack
|------------------||-----------------||---------------------|
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
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
<------------------>
IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check
|------------------>/64 prefix
RA
|------------------>/48 prefix,
DHCPv6 DNS, etc.
|------------------>/64 prefix
RA
|------------------>/48 prefix,
DHCPv6 DNS, etc.
|------->/64 prefix
RA
|-------> DNS, etc.
DHCPv4/v6
|------->/64 prefix
RA
|-------> DNS, etc.
DHCPv4/v6
Figure 2: Router CPE as Softwire Initiator
图2：路由器CPE作为软线启动器
In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPV6CP negotiates IPv6-over-PPP, which also provides the capability for the ISP to assign the 64-bit
在这种情况下，L2TPv2控制信道和会话建立以及PPP LCP协商（以及可选的PPP身份验证）成功后，IPV6CP通过PPP协商IPv6，这也为ISP分配64位数据提供了能力
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端对两个接口标识符执行唯一性验证[RFC5072]。在IPv6 over PPP启动后，IPv6无状态地址自动配置/邻居发现通过IPv6 over PPP链路运行，LNS可以通过路由器公告（RA）通知路由器CPE用于无状态地址自动配置的前缀。DHCPv6可用于执行IPv6前缀委派（例如，委派将在家庭网络[RFC3633]内使用的前缀），并将其他非地址配置选项（例如DNS[RFC3646]）传送给路由器CPE。
The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack host (behind the IPv4-only CPE), which acts as an IPv6 host CPE. The IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 3.
CPE仅为IPv4。软线启动器（SI）是一个双栈主机（位于仅IPv4的CPE后面），充当IPv6主机CPE。IPv4流量不应穿过软线。参见图3。
IPv6 or dual-stack IPv4-only dual-stack
|------------------||----------------------------||----------|
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)
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
<------------------------------>
IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check
|------------------------------>/64 prefix
RA
|------------------------------>DNS, etc.
DHCPv6
|------------------------------>/64 prefix
RA
|------------------------------>DNS, etc.
DHCPv6
Figure 3: Host behind CPE as Softwire Initiator
图3: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通过PPP协商IPv6，这也为ISP分配64位数据提供了能力
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端的两个接口标识符执行唯一性验证[RFC5072]。IPv6 over PPP启动后，IPv6无状态地址自动配置/邻居发现通过IPv6 over 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。软线启动器（SI）是一个双栈设备（位于仅IPv4的CPE后面），在家庭网络中充当IPv6 CPE路由器。IPv4流量不应穿过软线。参见图4。
IPv6 or dual-stack IPv4-only dual-stack
|------------------||-------------------------||-------------|
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)
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
<--------------------------->
IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check
|--------------------------->/64 prefix
RA
|--------------------------->/48 prefix,
DHCPv6 DNS, etc.
|--------------------------->/64 prefix
RA
|--------------------------->/48 prefix,
DHCPv6 DNS, etc.
|----> /64
RA prefix
|----> DNS,
DHCPv6 etc.
|----> /64
RA prefix
|----> DNS,
DHCPv6 etc.
Figure 4: Router behind CPE as Softwire Initiator
图4: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
在此场景中，在L2TPv2控制信道和会话建立以及PPP LCP协商（以及可选的PPP身份验证）成功后，IPV6CP通过PPP协商IPv6，它还为ISP提供了将64位接口标识符分配给v4/v6路由器或在两个PPP端对两个接口标识符执行唯一性验证的能力[RFC5072]。IPv6 over PPP启动后，IPv6无状态地址自动配置/邻居发现将通过IPv6 over PPP链路运行，LNS可以通过路由器公告通知v4/v6路由器用于无状态地址自动配置的前缀
(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.
（RA）。DHCPv6可用于执行IPv6前缀委派（例如，委派将在家庭网络[RFC3633]内使用的前缀），并将其他非地址配置选项（例如DNS[RFC3646]）传送到v4/v6路由器。
The following sub-sections cover IPv4 connectivity (SPH) across an IPv6-only access network (STH) using a Softwire.
以下小节介绍使用软线通过仅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.
软线启动器（SI）是主机CPE（直接连接到调制解调器），它是双堆栈。没有其他网关设备。IPv6流量不应穿过软线。参见图5。
IPv4 or dual-stack IPv6-only dual-stack
|------------------||-----------------||----------|
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
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.
<------------------>
IPCP: capable of global IP assignment
and DNS, etc.
Figure 5: Host CPE as Softwire Initiator
图5：作为软线启动器的主机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）通过PPP协商IPv4，这也为ISP向主机CPE分配全局IPv4地址提供了能力。还可以通过DHCP分配全局IPv4地址。其他配置选项（例如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.
软线启动器（SI）是路由器CPE，它是一个双栈设备。IPv6流量不应穿过软线。参见图6。
IPv4 or dual-stack IPv6-only dual-stack Home
|------------------||-----------------||-------------------|
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
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.
<------------------>
IPCP: capable of global IP assignment
and DNS, etc.
|------------------>
DHCPv4: prefix, mask, PD
|------------------>
DHCPv4: prefix, mask, PD
private/
|------> global
DHCP IP, DNS,
etc.
private/
|------> global
DHCP IP, DNS,
etc.
Figure 6: Router CPE as Softwire Initiator
图6：路由器CPE作为软线启动器
In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPCP negotiates IPv4-over-PPP, which also provides the capability for the ISP to assign a global IPv4 address to the router CPE. A global IPv4 address can also be assigned via DHCP. Other configuration options (such as DNS) can be conveyed to the router CPE via IPCP [RFC1877] or DHCP [RFC2132]. For IPv4 Prefix Delegation for the home network, DHCP [SUBNET-ALL] can be used.
在此场景中，L2TPv2控制信道和会话建立以及PPP LCP协商（以及可选的PPP认证）成功后，IPCP通过PPP协商IPv4，这也为ISP向路由器CPE分配全局IPv4地址提供了能力。还可以通过DHCP分配全局IPv4地址。其他配置选项（例如DNS）可以通过IPCP[RFC1877]或DHCP[RFC2132]传送到路由器CPE。对于家庭网络的IPv4前缀委派，可以使用DHCP[SUBNET-ALL]。
The CPE is IPv6-only. The Softwire Initiator (SI) is a dual-stack host (behind the IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 7.
CPE仅为IPv6。软线启动器（SI）是一个双栈主机（位于IPv6 CPE后面），充当IPv4主机CPE。IPv6流量不应穿过软线。参见图7。
IPv4 or dual-stack IPv6-only dual-stack
|------------------||----------------------------||----------|
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)
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.
<------------------------------>
IPCP: capable of global IP assignment
and DNS, etc.
Figure 7: Host behind CPE as Softwire Initiator
图7: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通过PPP协商IPv4，这也为ISP向主机分配全局IPv4地址提供了能力。还可以通过DHCP分配全局IPv4地址。其他配置选项（例如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。软线启动器（SI）是一个双堆栈设备（仅在IPv6 CPE后面），在家庭网络中充当IPv4 CPE路由器。IPv6流量不应穿过软线。参见图8。
IPv4 or dual-stack IPv6-only dual-stack
|------------------||-------------------------||------------|
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)
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.
<--------------------------->
IPCP: assigns global IP address and DNS, etc.
|--------------------------->
DHCPv4: prefix, mask, PD
|--------------------------->
DHCPv4: prefix, mask, PD
private/
|----> global
DHCP IP, DNS,
etc.
private/
|----> global
DHCP IP, DNS,
etc.
Figure 8: Router behind CPE as Softwire Initiator
图8: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通过PPP协商IPv4，这也为ISP向v4/v6路由器分配全局IPv4地址提供了能力。还可以通过DHCP分配全局IPv4地址。其他配置选项（如DNS）可以通过IPCP[RFC1877]或DHCP[RFC2132]传送到v4/v6路由器。对于家庭网络的IPv4前缀委派，可以使用DHCP[SUBNET-ALL]。
This section lists and groups documents from the Internet standardization describing technologies used to design the framework of the Softwire "Hub and Spoke" solution. This emphasizes the motivation of Softwire to reuse as many existing standards as
本节列出并分组来自互联网标准化的文档，描述用于设计软线“中心辐射”解决方案框架的技术。这强调了Softwire尽可能多地重用现有标准的动机
possible. This list contains both Standards Track (Proposed Standard, Draft Standard, and Standard) and Informational documents. The list of documents and their status should only be only used for description purposes.
可能的此列表包含标准跟踪（建议标准、标准草案和标准）和信息性文档。文档列表及其状态只能用于描述目的。
RFC 2661 "Layer Two Tunneling Protocol 'L2TP'" [RFC2661].
RFC 2661“第二层隧道协议‘L2TP’”[RFC2661]。
* For both IPv4 and IPv6 payloads (SPH), support is complete.
* 对于IPv4和IPv6有效负载（SPH），支持已完成。
* For both IPv4 and IPv6 transports (STH), support is complete.
* 对于IPv4和IPv6传输（STH），支持已完成。
RFC 3193 "Securing L2TP using IPsec" [RFC3193].
RFC 3193“使用IPsec保护L2TP”[RFC3193]。
RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948].
RFC 3948“IPsec ESP数据包的UDP封装”[RFC3948]。
* IPsec supports both IPv4 and IPv6 transports.
* IPsec同时支持IPv4和IPv6传输。
RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" [RFC2865].
RFC 2865“远程身份验证拨入用户服务（RADIUS）”[RFC2865]。
* Updated by [RFC2868], [RFC3575], and [RFC5080].
* 由[RFC2868]、[RFC3575]和[RFC5080]更新。
RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol Support" [RFC2867].
RFC 2867“隧道协议支持的半径计算修改”[RFC2867]。
RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868].
RFC 2868“隧道协议支持的半径属性”[RFC2868]。
RFC 3162 "RADIUS and IPv6" [RFC3162].
RFC 3162“半径和IPv6”[RFC3162]。
RFC 1471 "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol" [RFC1471].
RFC 1471“点到点协议的链路控制协议的托管对象定义”[RFC1471]。
RFC 1473 "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol" [RFC1473].
RFC 1473“点到点协议的IP网络控制协议的托管对象定义”[RFC1473]。
RFC 3371 "Layer Two Tunneling Protocol "L2TP" Management Information Base" [RFC3371].
RFC 3371“第二层隧道协议”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“动态主机配置协议（DHCP）版本6的IPv6前缀选项”[RFC3633]。
RFC 3646 "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3646].
RFC 3646“IPv6（DHCPv6）动态主机配置协议的DNS配置选项”[RFC3646]。
RFC 3736 "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6" [RFC3736].
RFC 3736“IPv6的无状态动态主机配置协议（DHCP）服务”[RFC3736]。
RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)" [RFC1332].
RFC 1332“PPP互联网协议控制协议（IPCP）”[RFC1332]。
RFC 1661 "The Point-to-Point Protocol (PPP)" [RFC1661].
RFC 1661“点对点协议（PPP）”[RFC1661]。
RFC 1877 "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses" [RFC1877].
RFC 1877“名称服务器地址的PPP互联网协议控制协议扩展”[RFC1877]。
RFC 2131 "Dynamic Host Configuration Protocol" [RFC2131].
RFC 2131“动态主机配置协议”[RFC2131]。
RFC 2132 "DHCP Options and BOOTP Vendor Extensions" [RFC2132].
RFC 2132“DHCP选项和BOOTP供应商扩展”[RFC2132]。
DHCP Subnet Allocation "Subnet Allocation Option".
DHCP子网分配“子网分配选项”。
* Work in progress, see [SUBNET-ALL].
* 正在进行工作，请参阅[SUBNET-ALL]。
A Softwire is established in three distinct steps, potentially preceded by an optional IPsec-related step 0 (see Figure 9). First, an L2TPv2 tunnel with a single session is established from the SI to the SC. Second, a PPP session is established over the L2TPv2 session and the SI obtains an address. Third, the SI optionally gets other information through DHCP such as a delegated prefix and DNS servers.
Softwire通过三个不同的步骤建立，之前可能会有一个可选的IPsec相关步骤0（见图9）。首先，从SI到SC建立具有单个会话的L2TPv2隧道。其次，在L2TPv2会话上建立PPP会话，SI获得地址。第三，SI可以选择通过DHCP获取其他信息，如委派前缀和DNS服务器。
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)
SC SI
| |
|<-------------IKEv1------------->| Step 0
| | IPsec SA establishment
| | (optional)
| |
|<-------------L2TPv2------------>| Step 1
| | L2TPv2 Tunnel establishment
| |
|<--------------PPP-------------->| Step 2
|<-----Endpoint Configuration---->| PPP and Endpoint
| | configuration
| |
|<------Router Configuration----->| Step 3
| | Additional configuration
| | (optional)
Figure 9: Steps for the Establishment of a Softwire
图9：建立软线的步骤
Figure 10 depicts details of each of these steps required to establish a Softwire.
图10描述了建立软线所需的每个步骤的细节。
SC SI
| |
| | Step 0
|<------------IKEv1-------------->| = IKEv1 (Optional)
| |
| | Step 1
|<------------SCCRQ---------------| -
|-------------SCCRP-------------->| |
|<------------SCCCN---------------| |
|<------------ICRQ----------------| | L2TPv2
|-------------ICRP--------------->| |
|<------------ICCN----------------| -
| |
| | Step 2
|<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP
|--------Configuration-Ack------->| | LCP
|<-------Configuration-Ack--------| -
| |
|-----------Challenge------------>| - PPP Authentication
|<----------Response--------------| | (Optional - CHAP)
|------------Success------------->| -
| |
|<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP NCP
|--------Configuration-Ack------->| | (IPV6CP or IPCP)
|<-------Configuration-Ack--------| -
| |
|<------Router-Solicitation-------| - Neighbor Discovery
|-------Router-Advertisement----->| | (IPv6 only)
| | -
| |
| | Step3
| | DHCP (Optional)
|<-----------SOLICIT--------------| -
|-----------ADVERTISE------------>| | DHCPv6
|<---------- REQUEST--------------| | (IPv6 SW, Optional)
|-------------REPLY-------------->| -
| | or
|<---------DHCPDISCOVER-----------| -
|-----------DHCPOFFER------------>| | DHCPv4
|<---------DHCPREQUEST------------| | (IPv4 SW, Optional)
|------------DHCPACK------------->| -
SC SI
| |
| | Step 0
|<------------IKEv1-------------->| = IKEv1 (Optional)
| |
| | Step 1
|<------------SCCRQ---------------| -
|-------------SCCRP-------------->| |
|<------------SCCCN---------------| |
|<------------ICRQ----------------| | L2TPv2
|-------------ICRP--------------->| |
|<------------ICCN----------------| -
| |
| | Step 2
|<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP
|--------Configuration-Ack------->| | LCP
|<-------Configuration-Ack--------| -
| |
|-----------Challenge------------>| - PPP Authentication
|<----------Response--------------| | (Optional - CHAP)
|------------Success------------->| -
| |
|<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP NCP
|--------Configuration-Ack------->| | (IPV6CP or IPCP)
|<-------Configuration-Ack--------| -
| |
|<------Router-Solicitation-------| - Neighbor Discovery
|-------Router-Advertisement----->| | (IPv6 only)
| | -
| |
| | Step3
| | DHCP (Optional)
|<-----------SOLICIT--------------| -
|-----------ADVERTISE------------>| | DHCPv6
|<---------- REQUEST--------------| | (IPv6 SW, Optional)
|-------------REPLY-------------->| -
| | or
|<---------DHCPDISCOVER-----------| -
|-----------DHCPOFFER------------>| | DHCPv4
|<---------DHCPREQUEST------------| | (IPv4 SW, Optional)
|------------DHCPACK------------->| -
Figure 10: Detailed Steps in the Establishment of a Softwire
图10：建立软线的详细步骤
The IPsec-related negotiations in step 0 are optional. The L2TPv2 negotiations in step 1 are described in Section 5.1. The PPP Network Control Protocol (NCP) negotiations in step 2 use IPV6CP for IPv6- over-IPv4 Softwires, and IPCP for IPv4-over-IPv6 Softwires (see Section 5.2.4). The optional DHCP negotiations in step 3 use DHCPv6 for IPv6-over-IPv4 Softwires, and DHCPv4 for IPv4-over-IPv6 Softwires (see Section 5.4). Additionally, for IPv6-over-IPv4 Softwires, the DHCPv6 exchange for non-address configuration (such as DNS) can use Stateless DHCPv6, the two-message exchange with Information-Request and Reply messages (see Section 1.2 of [RFC3315] and [RFC3736]).
步骤0中与IPsec相关的协商是可选的。第5.1节介绍了步骤1中的L2TPv2协商。步骤2中的PPP网络控制协议（NCP）协商将IPV6CP用于IPv6-over-IPv4软线，将IPCP用于IPv4-over-IPv6软线（见第5.2.4节）。步骤3中的可选DHCP协商将DHCPv6用于IPv6-over-IPv4软线，将DHCPv4用于IPv4-over-IPv6软线（请参阅第5.4节）。此外，对于IPv6-over-IPv4软线，用于非地址配置（如DNS）的DHCPv6交换可以使用无状态DHCPv6，这两种消息交换具有信息请求和回复消息（请参见[RFC3315]和[RFC3736]的第1.2节）。
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.
在软线“中心辐射”模型中，软线启动器（SI）承担LAC客户端的角色，软线集中器（SC）承担LN的角色。
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.
在软线模型中，L2TPv2数据包必须通过UDP传输。IP协议的基础版本可能是IPv4或IPv6，具体取决于软线方案。
In the following sections, the term "Tunnel" follows the definition from Section 1.2 of [RFC2661], namely: "The Tunnel consists of a Control Connection and zero or more L2TP Sessions".
在以下章节中，术语“隧道”遵循[RFC2661]第1.2节的定义，即：“隧道由一个控制连接和零个或多个L2TP会话组成”。
Figure 11 describes the messages exchanged and Attribute Value Pairs (AVPs) used to establish a tunnel between an SI (LAC) and an SC (LNS). The messages and AVPs described here are only a subset of those defined in [RFC2661]. This is because Softwires use only a subset of the L2TPv2 functionality. The subset of L2TP Control Connection Management AVPs that is applicable to Softwires is grouped into Required AVPs and Optional AVPs on a per-control-message basis (see Figure 11). For each control message, Required AVPs include all the "MUST be present" AVPs from [RFC2661] for that control message, and Optional AVPs include the "MAY be present" AVPs from [RFC2661] that are used in the Softwire context on that control message. Note that in the Softwire environment, the SI always initiates the tunnel. L2TPv2 AVPs SHOULD NOT be hidden.
图11描述了用于在SI（LAC）和SC（LNS）之间建立隧道的消息交换和属性值对（AVP）。此处描述的消息和AVP只是[RFC2661]中定义的消息和AVP的子集。这是因为软线只使用L2TPv2功能的一个子集。适用于软线的L2TP控制连接管理AVP子集根据每个控制消息分为所需AVP和可选AVP（见图11）。对于每个控制消息，所需AVP包括来自该控制消息的[RFC2661]的所有“必须存在”AVP，可选AVP包括来自该控制消息的软线上下文中使用的[RFC2661]的“可能存在”AVP。请注意，在软线环境中，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
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
|---------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
|<--------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
在L2TPv2中，通常，LAC和LNS之间的隧道可以承载多个用户的数据。这些用户中的每一个都由隧道内的L2TPv2会话表示。在软线环境中，隧道承载单个用户的信息。因此，每个隧道只有一个L2TPv2会话。图12描述了交换的消息和用于在SI（LAC）和SC（LNS）之间建立会话的AVP。此处描述的消息和AVP只是[RFC2661]中定义的消息和AVP的子集。这是因为软线只使用L2TPv2功能的一个子集。适用于软线的L2TP呼叫管理（即，会话管理）AVP子集根据每个控制消息分组为所需AVP和可选AVP（见图12）。每人
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.
控制消息，所需AVP包括来自[RFC2661]的该控制消息的所有“必须存在”AVP，可选AVP包括来自[RFC2661]的在该控制消息的软线上下文中使用的“可能存在”AVP。请注意，在软线环境中，SI始终启动会话。软线L2TPv2会话设置仅使用传入呼叫模式。不允许传出或模拟呼叫（会话）。L2TPv2 AVP不应隐藏。
SC SI
|<--------ICRQ---------|
Required AVPs:
Message Type
Assigned Session ID
Call Serial Number
SC SI
|<--------ICRQ---------|
Required AVPs:
Message Type
Assigned Session ID
Call Serial Number
|---------ICRP-------->|
Required AVPs:
Message Type
Assigned Session ID
|---------ICRP-------->|
Required AVPs:
Message Type
Assigned Session ID
|<--------ICCN---------|
Required AVPs:
Message Type
(Tx) Connect Speed
Framing Type
|<--------ICCN---------|
Required AVPs:
Message Type
(Tx) Connect Speed
Framing Type
Figure 12: Session Establishment
图12：会话建立
The following sub-sections (5.1.1.1 through 5.1.1.3) describe in more detail the Control Connection and Session establishment AVPs (see message flows in Figures 11 and 12, respectively) that are required, optional and not relevant for the L2TPv2 Tunnel establishment of a Softwire. Specific L2TPv2 protocol messages and flows that are not explicitly described in these sections are handled as defined in [RFC2661].
以下小节（5.1.1.1至5.1.1.3）更详细地描述了控制连接和会话建立AVP（分别参见图11和图12中的消息流），这些AVP对于软线的L2TPv2隧道建立是必需的、可选的和不相关的。这些章节中未明确描述的特定L2TPv2协议消息和流按照[RFC2661]中的定义进行处理。
The mechanism for hiding AVP Attribute values is used, as described in Section 4.3 of [RFC2661], to hide sensitive control message data such as usernames, user passwords, or IDs, instead of sending the AVP contents in the clear. Since AVPs used in L2TP messages for the Softwire establishment do not transport such sensitive data, L2TPv2 AVPs SHOULD NOT be hidden.
如[RFC2661]第4.3节所述，隐藏AVP属性值的机制用于隐藏敏感控制消息数据，如用户名、用户密码或ID，而不是以明文形式发送AVP内容。由于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.
本节规定了[RFC2661]所要求的AVP的特定值，这些AVP需要出现在一个或多个用于软连线建立的消息中，因为它们在软连线上下文中使用。它结合了第5.1.1节中所有控制消息中的所有所需AVP，并提供了特定于软线的使用指南。
Host Name 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.
SCCRQ和SCCRP消息中需要此AVP。此AVP可用于验证用户，在这种情况下，它将包含用户标识。如果此AVP不用于对用户进行身份验证，则可用于日志记录目的。
Framing Capabilities AVP
成帧能力
Both the synchronous (S) and asynchronous (A) bits SHOULD be set to 1. This AVP SHOULD be ignored by the receiver.
同步（S）和异步（A）位都应设置为1。接收机应忽略此AVP。
Framing Type AVP
框架式AVP
The synchronous bit SHOULD be set to 1 and the asynchronous bit to 0. This AVP SHOULD be ignored by the receiver.
同步位应设置为1，异步位应设置为0。接收机应忽略此AVP。
(Tx) Connect Speed AVP
（Tx）连接速度AVP
(Tx) Connect Speed is a required AVP but is not meaningful in the Softwire context. Its value SHOULD be set to 0 and ignored by the receiver.
（Tx）连接速度是所需的AVP，但在软线环境中没有意义。其值应设置为0，并由接收器忽略。
Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call Serial Number AVP, and Assigned Session ID AVP
消息类型AVP、协议版本AVP、分配的隧道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]所要求的），但在软线环境中使用。它结合了第5.1.1节中所有控制信息中的所有可选AVP，并提供了特定于软线的使用指南。
Challenge AVP and Challenge Response AVP
挑战AVP和挑战响应AVP
These AVPs are not required, but are necessary to implement tunnel authentication. Since tunnel authentication happens at the beginning of L2TPv2 tunnel creation, it can be helpful in preventing denial-of-service (DoS) attacks. See Section 5.1.1 of [RFC2661].
这些AVP不是必需的，但对于实现隧道身份验证是必需的。由于隧道身份验证发生在L2TPv2隧道创建的开始，因此它有助于防止拒绝服务（DoS）攻击。见[RFC2661]第5.1.1节。
The usage of these AVPs in L2TP messages is OPTIONAL, but SHOULD be implemented in the SC.
在L2TP消息中使用这些AVP是可选的，但应在SC中实现。
Receive Window Size AVP, Firmware Revision AVP, and Vendor Name AVP
接收窗口大小AVP、固件版本AVP和供应商名称AVP
As defined in [RFC2661].
如[RFC2661]中所定义。
L2TPv2 specifies numerous AVPs that, while allowed for a given message, are irrelevant to Softwires. They can be irrelevant to Softwires because they do not apply to the Softwire establishment flow (e.g., they are only used in the Outgoing Call establishment message exchange, while Softwires only use the Incoming Call message flow), or because they are Optional AVPs that are not used. L2TPv2 AVPs that are relevant to Softwires were covered in Sections 5.1.1, 5.1.1.1, and 5.1.1.2. Softwire implementations SHOULD NOT send AVPs that are not relevant to Softwires. However, they SHOULD ignore them when they are received. This will simplify the creation of Softwire applications that build upon existing L2TPv2 implementations.
L2TPv2指定了许多AVP，这些AVP虽然允许用于给定的消息，但与软线无关。它们可能与软线无关，因为它们不适用于软线建立流（例如，它们仅用于传出呼叫建立消息交换，而软线仅使用传入呼叫消息流），或者因为它们是未使用的可选AVP。第5.1.1、5.1.1.1和5.1.1.2节介绍了与软电线相关的L2TPv2 AVP。软线实施不应发送与软线无关的AVP。然而，当他们收到这些信息时，他们应该忽略它们。这将简化基于现有L2TPv2实现的软线应用程序的创建。
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
[RFC2661]中为L2TPv2 HELLO消息指定的默认值可能导致83秒的死端检测时间。尽管这些重传定时器和计数器应可配置（见[RFC2661]第5.8节），但这些值可能不适用于所有情况，其中需要更快的死端检测，或者需要更频繁地刷新NAT/NAPT上下文。在这种情况下，SI/SC可结合L2TPv2 HELLO使用[RFC1661]中所述的LCP回显消息（回显请求和回显回复代码）。使用时，LCP回显消息的重新发射计时器应低于L2TPv2 HELLO消息的值。[RFC2661]第6.5节中建议的HELLO消息重传间隔的默认值为60秒。使用时，LCP回显信息的一组建议值（此处仅包含用于指导）
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.
请求间隔默认为30秒，最小为10秒，最大为配置的L2TPv2 HELLO重传间隔和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都可以中断会话和隧道。按照[RFC2661]第5.7节的规定，通过发送StopCCN控制消息来实现。在这种情况下，没有特定于软线的操作。
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).
在软线“中心辐射”框架中，L2TPv2作为IP-In-IP隧道的一部分分层在UDP之上；[RFC2661]的第8.1节描述了UDP/IP上的L2TP。因此，[RFC5405]中规定的UDP指南适用，因为它们涉及承载基于IP的流量的UDP隧道方案。[RFC5405]第3.1.3节规定，在这种情况下，隧道不需要特定的拥塞控制机制。此外，[RFC5405]第3.2节提供了封装（外部）数据报的消息大小指南，包括实施路径MTU发现（PMTUD）的建议。
This section describes the PPP negotiations between the SI and SC in the Softwire context.
本节描述了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报头的大小。在MTU等于1500字节的IPv4链路上，这通常意味着PPP MTU为1460字节。当链路由IPsec管理时，应降低此MTU以考虑ESP封装（请参见[SW-SEC]）。MTU的值也可根据L2TP报头的大小而变化，如L2TP消息报头的前导位所定义（参见[RFC2661]）。此外，有关碎片问题的详细讨论，请参见[RFC4623]。
Once the L2TPv2 session is established, the SI and SC initiate the PPP connection by negotiating LCP as described in [RFC1661]. The Address-and-Control-Field-Compression configuration option (ACFC) [RFC1661] MAY be rejected.
建立L2TPv2会话后，SI和SC通过协商LCP（如[RFC1661]中所述）启动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]身份验证必须由软线启动器和软线集中器支持。可能支持其他身份验证方法，如Microsoft CHAP版本1（MS-CHAPv1）[RFC2433]和可扩展身份验证协议（EAP）[RFC3748]。
A detailed discussion of Softwire security is contained in [SW-SEC].
[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.
在软线上下文中协商的唯一网络控制协议（NCP）是IPV6CP（见第5.2.4.1节），用于IPv6作为SPH，IPCP（见第5.2.4.2节）用于IPv4作为SPH。
In the IPv6-over-IPv4 scenarios (see Section 3.1), after the optional authentication phase, the Softwire Initiator MUST negotiate IPV6CP as defined in [RFC5072]. IPV6CP provides a way to negotiate a unique 64-bit Interface-Identifier to be used for the address autoconfiguration at the local end of the link.
在IPv6-over-IPv4方案中（参见第3.1节），在可选身份验证阶段之后，软线启动器必须协商[RFC5072]中定义的IPV6CP。IPV6CP提供了一种协商唯一64位接口标识符的方法，用于链路本地端的地址自动配置。
In the IPv4-over-IPv6 scenarios (see Section 3.2), a Softwire Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain an IPv4 address from the SC. IPCP MAY also be used to obtain DNS information as described in [RFC1877].
在IPv4-over-IPv6方案中（参见第3.2节），软线启动器必须协商IPCP[RFC1332]。SI使用IPCP从SC获取IPv4地址。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协商接口标识符自动配置的链路本地地址之外）。软线启动器使用IPV6CP协商接口标识符并使用无状态地址自动配置[RFC4862]，和/或使用无状态地址自动配置的隐私扩展[RFC4941]，（如[RFC5072]第5节所述）和/或使用DHCPv6[RFC3315]分配全局IPv6地址。
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软线的软线启动器必须向软线集中器发送路由器请求消息。软线集中器必须使用路由器广告进行应答。如果邻居发现用于配置软线端点的地址，则此消息必须包含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位。然后，软线启动器必须发送DHCPv6请求以配置软线端点的地址。
Duplicate Address Detection ([RFC4861]) MUST be performed on the Softwire in both cases.
在这两种情况下，必须在软线上执行重复地址检测（[RFC4861]）。
The Softwire Initiator MAY use DHCP to get additional information such as delegated prefix and DNS servers.
软线启动器可以使用DHCP来获取附加信息，例如委派前缀和DNS服务器。
In the scenarios in Section 3.1, if the SI supports DHCPv6, it SHOULD send a Solicit message to verify if more information is available.
在第3.1节中的场景中，如果SI支持DHCPv6，它应该发送请求消息以验证是否有更多信息可用。
If an SI establishing an IPv6 Softwire acts as a router (i.e., in the scenarios in Sections 3.1.2 and 3.1.4) it MUST include the Identity Association for Prefix Delegation (IA_PD) option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in order to request an IPv6 prefix.
如果建立IPv6软线的SI充当路由器（即，在第3.1.2节和第3.1.4节中的场景中），则必须在DHCPv6请求消息[RFC3315]中包含前缀委派身份关联（IA_PD）选项[RFC3633]，以请求IPv6前缀。
When delegating an IPv6 prefix to the SI by returning a DHCPv6 Advertise message with the IA_PD and IP_PD Prefix options [RFC3633], the SC SHOULD inject a route for this prefix in the IPv6 routing table in order to forward the traffic to the relevant Softwire.
当通过返回带有IA_PD和IP_PD前缀选项[RFC3633]的DHCPv6播发消息将IPv6前缀委托给SI时，SC应在IPv6路由表中插入该前缀的路由，以便将流量转发到相关软线。
Configuration of DNS MUST be done as specified in [RFC3646] and transmitted according to [RFC3315] and [RFC3736]. In general, all DHCPv6 options MUST be transmitted according to [RFC3315] and [RFC3736].
DNS的配置必须按照[RFC3646]中的规定进行，并根据[RFC3315]和[RFC3736]进行传输。通常，所有DHCPv6选项必须根据[RFC3315]和[RFC3736]传输。
An SI establishing an IPv4 Softwire MAY send a DHCP request containing the Subnet Allocation option [SUBNET-ALL]. This practice is not common, but it may be used to connect IPv4 subnets using Softwires, as defined in Sections 3.2.2 and 3.2.4.
建立IPv4软线的SI可以发送包含子网分配选项[Subnet-ALL]的DHCP请求。这种做法并不常见，但可用于使用第3.2.2节和第3.2.4节中定义的软线连接IPv4子网。
One Subnet-Request suboption MUST be configured with the 'h' bit set to '1', as the SI is expected to perform the DHCP server function. The 'i' bit of the Subnet-Request suboption SHOULD be set to '0' the first time a prefix is requested and to '1' on subsequent requests, if a prefix has been allocated. The Prefix length suboption SHOULD be 0 by default. If the SI is configured to support only specific prefix lengths, it SHOULD specify the longest (smallest) prefix length it supports.
一个子网请求子选项必须配置为将“h”位设置为“1”，因为SI需要执行DHCP服务器功能。子网请求子选项的“i”位应在第一次请求前缀时设置为“0”，如果已分配前缀，则在后续请求时应设置为“1”。默认情况下，“前缀长度”子选项应为0。如果SI配置为仅支持特定前缀长度，则应指定其支持的最长（最小）前缀长度。
If the SI was previously assigned a prefix from that same SC, it SHOULD include the Subnet-Information suboption with the prefix it was previously assigned. The 'c' and 's' bits of the suboption SHOULD be set to '0'.
如果SI先前从同一SC分配了前缀，则应包括子网信息子选项及其先前分配的前缀。子选项的“c”和“s”位应设置为“0”。
In the scenarios in Section 3.2, when delegating an IPv4 prefix to the SI, the SC SHOULD inject a route for this prefix in the IPv4 routing table in order to forward the traffic to the relevant Softwire.
在第3.2节中的场景中，当将IPv4前缀委托给SI时，SC应在IPv4路由表中为该前缀注入路由，以便将流量转发到相关的软线。
This section describes how a Softwire Concentrator may manage delegated addresses for Softwire endpoints and for subnets behind the Softwire Initiator. One common practice is to aggregate endpoints' addresses and delegated prefixes into one prefix routed to the SC. The main benefit is to ease the routing scheme by isolating on the SC succeeding route injections (when delegating new prefixes for SI).
本节描述软线集中器如何管理软线端点和软线启动器后面的子网的委派地址。一种常见做法是将端点的地址和委托前缀聚合为一个路由到SC的前缀。主要好处是通过在SC上隔离后续的路由注入（为SI委托新前缀时），简化路由方案。
A Softwire Concentrator should provide globally routable addresses to Softwire endpoints. Other types of addresses such as Unique Local Addresses (ULAs) [RFC4193] may be used to address Softwire endpoints in a private network with no global connectivity. A single /64 should be assigned to the Softwire to address both Softwire endpoints.
软线集中器应向软线端点提供全局可路由地址。诸如唯一本地地址（ULA）[RFC4193]之类的其他类型的地址可用于在没有全局连接的专用网络中寻址软线端点。应向软线分配一个/64以寻址两个软线端点。
Global addresses or ULAs must be assigned to endpoints when the scenario "Host CPE as Softwire Initiator" (described in Section 3.1.1) is considered to be deployed. For other scenarios, link-local addresses may also be used.
当考虑部署场景“主机CPE作为软线启动器”（如第3.1.1节所述）时，必须将全局地址或ULA分配给端点。对于其他场景，也可以使用链路本地地址。
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.
软线集中器可以提供全局可路由或专用IPv4地址。在端点上使用IPv4专用地址[RFC1918]时，不建议将IPv4专用前缀委托给SI，因为这可能导致嵌套NAT情况。
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 Internet时，不建议使用ULAs。在端点上使用IPv6 ULA时，委派的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 |
+------------------+-----------------------+------------------------+
+------------------+-----------------------+------------------------+
| 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) |
+-------------+-----------------+-----------------------------------+
+-------------+-----------------+-----------------------------------+
| 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.
软线可以提供稳定的地址，即使底层寻址方案发生变化，这与自动隧道相反。软线集中器应始终为重新连接的用户提供相同的地址和前缀。然而，如果软线服务的目标是为漫游用户提供临时地址，则可将其设置为仅提供临时地址。
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.
当重新连接到其他软线集中器时，地址和前缀可能会更改。然而，提供软线服务的组织可以跨不同的软线集中器提供相同的地址和前缀，代价是更分段的路由表。如果前缀聚合在拓扑上靠近SC的位置，则路由分段问题可能会受到限制。例如，如果为了负载平衡目的将多个SC并行放置，则会出现这种情况。
The Softwire Concentrator is expected to act as a client to a AAA server, for example, a RADIUS server. During the PPP authentication phase, the RADIUS server may return additional information in the form of attributes in the Access-Accept message.
预计软线集中器将充当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.
软线集中器可以在接入请求消息中包括隧道类型和隧道介质类型属性[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]，则软线集中器必须将其发送到其IPV6CP配置请求消息的接口标识符字段中的软线启动器。
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的路由器播发中使用该前缀。如果Framed-IPv6-Prefix不存在，但Framed-IPv6-Pool存在，则SC必须从该池中选择前缀以发送RAs。
If the Framed-IP-Address attribute [RFC2865] is present, the Softwire Concentrator must provide that address to the Softwire Initiator during IPCP address negotiation. That is, when the Softwire Initiator requests an IP address from the Softwire Concentrator, the address provided should be the Framed-IP-Address.
如果存在帧IP地址属性[RFC2865]，则软线集中器必须在IPCP地址协商期间向软线启动器提供该地址。也就是说，当软线启动器从软线集中器请求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.
如果RADIUS访问接受消息中存在Delegated-IPv6-Prefix[RFC4818]属性，则软线集中器必须将其用于IPv6前缀的委派。由于前缀委派由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]中提出的机制。在这种情况下，在软线身份验证阶段，PPP收集用户的RADIUS属性，例如Delegated-IPv6-Prefix。将特定的DHCPv6继电器分配给软线。在将DHCPv6请求转发到DHCPv6服务器之前，DHCPv6中继在中继代理RADIUS属性选项（RRAO）DHCPv6选项中填充这些属性。
RADIUS does not define an attribute for the delegated IPv4 Prefix. Attributes indicating an IPv4 prefix and its length (for instance the combination of the Framed-IP-Address and Framed-IP-Netmask attributes [RFC2865]) may be used by the Softwire Concentrator to delegate an IPv4 prefix to the Softwire Initiator. The Softwire Concentrator must add a corresponding route with the Softwire Initiator as next-hop.
RADIUS未为委派的IPv4前缀定义属性。软线集中器可以使用指示IPv4前缀及其长度的属性（例如帧IP地址和帧IP网络掩码属性[RFC2865]的组合）来将IPv4前缀委托给软线启动器。软线集中器必须将软线启动器作为下一跳添加相应的路由。
As this practice had been used, the inclusion of the Framed-IP-Netmask attribute along with the Framed-IP-Address attribute tells the Softwire Concentrator to delegate an IPv4 prefix to the Softwire Initiator (e.g., in the IPv4-over-IPv6 scenarios where the Softwire Initiator is a router, see Sections 3.2.2 and 3.2.4), as the SC should forward packets destined to any IPv4 address in the prefix to the SI.
由于使用了此实践，将框架IP网络掩码属性与框架IP地址属性一起包含会告诉软线集中器将IPv4前缀委托给软线启动器（例如，在软线启动器为路由器的IPv4-over-IPv6场景中，请参见第3.2.2节和第3.2.4节），因为SC应该将目的地为前缀中任何IPv4地址的数据包转发给SI。
Existing protocol mechanics for conveying adjunct or accessory information for logging purposes, including L2TPv2 and RADIUS methods, can include informational text that the behavior is according to the Softwire "Hub and Spoke" framework (following the implementation details specified in this document).
用于传输用于记录目的的附加或辅助信息的现有协议机制，包括L2TPv2和RADIUS方法，可以包括行为符合软线“中心辐射”框架的信息文本（遵循本文档中指定的实现细节）。
RADIUS Accounting for L2TP and PPP are documented (see Section 4.3).
记录L2TP和PPP的半径（见第4.3节）。
When deploying Softwire solutions, operators may experience difficulties to differentiate the address family of the traffic reported in accounting information from RADIUS. This problem and some potential solutions are described in [SW-ACCT].
在部署软线解决方案时，运营商可能会遇到区分会计信息中报告的通信量的地址系列与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]).
“集线器和轮辐”问题的一个设计目标是非常强烈地考虑已经部署的协议的重用（参见[RCF425]）。另一个设计目标是具有非常高的伸缩特性的解决方案。L2TPv2[RFC2661]是软线“中心辐射”解决方案空间中使用的第1阶段协议，L2TPv2安全注意事项适用于本文档（参见[RFC2661]第9节）。
The L2TPv2 Softwire solution adds the following considerations:
L2TPv2软线解决方案增加了以下注意事项：
o L2TP Tunnel Authentication (see Sections 5.1.1 and 9.1 of [RFC2661]) provides authentication at tunnel setup. It may be used to limit DoS attacks by authenticating the tunnel before L2TP and PPP resources are allocated.
o L2TP隧道认证（见[RFC2661]第5.1.1和9.1节）在隧道设置时提供认证。它可以通过在分配L2TP和PPP资源之前对隧道进行身份验证来限制DoS攻击。
o In a Softwire environment, L2TPv2 AVPs do not transport sensitive data, and thus the L2TPv2 AVP hiding mechanism is not used (see Section 5.1.1).
o 在软线环境中，L2TPv2 AVP不传输敏感数据，因此不使用L2TPv2 AVP隐藏机制（见第5.1.1节）。
o PPP CHAP [RFC1994] provides basic user authentication. Other authentication protocols may additionally be supported (see Section 5.2.3).
o PPP CHAP[RFC1994]提供基本用户身份验证。还可支持其他认证协议（见第5.2.3节）。
L2TPv2 can also be secured with IPsec to provide privacy, integrity, and replay protection. Currently, there are two different solutions for security L2TPv2 with IPsec:
L2TPv2还可以通过IPsec进行保护，以提供隐私、完整性和重播保护。目前，使用IPsec的安全L2TPv2有两种不同的解决方案：
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 [RFC3193]、[RFC3947]和[RFC3948]中规定了使用IPsec“版本2”（IKEv1）保护L2TPv2。当L2TPv2用于软线环境时，将应用自愿隧道模型。[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]还指定了一种新的（不兼容的）解决方案，用于使用IPsec“版本3”（IKEv2）保护L2TPv2。[SW-SEC]第3.5节描述了使用IKEv2的优势，在未来阶段需要考虑该解决方案。
Additional discussion of Softwire security is contained in [SW-SEC].
[SW-SEC]中包含了对软线安全性的更多讨论。
The authors would like to acknowledge the following contributors who provided helpful input on this document: Florent Parent, Jordi Palet Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, Francis Dupont, Ralph Droms, Hemant Singh, and Alain Durand.
作者要感谢以下为本文件提供有用信息的贡献者：Florent Parent、Jordi Palet Martinez、Ole Troan、Shin Miyakawa、Carl Williams、Mark Townsley、Francis Dupont、Ralph Droms、Hemant Singh和Alain Durand。
The authors would also like to acknowledge the participants in the Softwires interim meetings held in Hong Kong, China, and Barcelona, Spain. The minutes for the interim meeting at the China University - Hong Kong (February 23-24, 2006) are at <http://www.ietf.org/proceedings/06mar/isoftwire.html>. The minutes for the interim meeting at Polytechnic University of Catalonia - Barcelona (September 14-15, 2006) are reachable at <http://www.ietf.org/proceedings/06nov/isoftwire.html>. The Softwires auxiliary page at <http://bgp.nu/~dward/softwires/> contains additional meeting information.
作者还想感谢参加在香港、中国和西班牙巴塞罗那举行的临时会议的参加者。中国大学香港会议（二月23-24，2006）临时会议纪要http://www.ietf.org/proceedings/06mar/isoftwire.html>. 加泰罗尼亚巴塞罗那理工大学（九月14-15日、2006日）临时会议纪要可在<http://www.ietf.org/proceedings/06nov/isoftwire.html>. 位于的Softwires辅助页<http://bgp.nu/~dward/softwires/>包含其他会议信息。
During and after the IETF Last Call, useful comments and discussion were provided by Jari Arkko, David Black, Lars Eggert, Pasi Eronen, and Dan Romascanu.
在IETF上次通话期间和之后，Jari Arkko、David Black、Lars Eggert、Pasi Eronen和Dan Romascanu提供了有用的评论和讨论。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC1332，1992年5月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162]Aboba，B.，Zorn，G.和D.Mitton，“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]Patel，B.，Aboba，B.，Dixon，W.，Zorn，G.，和S.Booth，“使用IPsec保护L2TP”，RFC 3193，2001年11月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two Tunneling Protocol "L2TP" Management Information Base", RFC 3371, August 2002.
[RFC3371]Caves，E.，Calhoun，P.和R.Wheeler，“第二层隧道协议”L2TP“管理信息库”，RFC 3371，2002年8月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007.
[RFC4818]Salowey，J.和R.Droms，“RADIUS-IPv6-Prefix属性”，RFC 4818，2007年4月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC5072]S.Varada，Haskins，D.和E.Allen，“PPP上的IP版本6”，RFC 5072，2007年9月。
[RELAY-RAD] Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", Work in Progress, February 2006.
[RELAY-RAD]Lau，W.“DHCPv6中继代理半径属性选项”，正在进行的工作，2006年2月。
[RFC1471] Kastenholz, F., "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol", RFC 1471, June 1993.
[RFC1471]Kastenholz，F.，“点到点协议链路控制协议的托管对象定义”，RFC 14711993年6月。
[RFC1473] Kastenholz, F., "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol", RFC 1473, June 1993.
[RFC1473]Kastenholz，F.，“点到点协议的IP网络控制协议的托管对象定义”，RFC 1473，1993年6月。
[RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses", RFC 1877, December 1995.
[RFC1877]Cobb，S.和F.Baker，“名称服务器地址的PPP互联网协议控制协议扩展”，RFC 18771995年12月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
[RFC2433]Zorn，G.和S.Cobb，“微软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]Zorn，G.，Aboba，B.和D.Mitton，“隧道协议支持的半径计算修改”，RFC 28672000年6月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868]Zorn，G.，Leifer，D.，Rubens，A.，Shriver，J.，Holdrege，M.，和I.Goyret，“隧道协议支持的半径属性”，RFC 28682000年6月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC3575]Aboba，B.“RADIUS（远程认证拨入用户服务）的IANA注意事项”，RFC 3575，2003年7月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646]Droms，R.，“IPv6动态主机配置协议（DHCPv6）的DNS配置选项”，RFC 36462003年12月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]Lau，J.，Townsley，M.，和I.Goyret，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005.
[RFC4087]Thaler，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.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年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 46232006年8月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC4925]Li，X.，Dawkins，S.，Ward，D.，和A.Durand，“软线问题声明”，RFC 49252007年7月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080]Nelson，D.和A.DeKok，“通用远程身份验证拨入用户服务（RADIUS）实施问题和建议修复”，RFC 50802007年12月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
[SUBNET-ALL] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, "Subnet Allocation Option", Work in Progress, March 2009.
[SUBNET-ALL]Johnson，R.，Kumarasamy，J.，Kinnear，K.，和M.Stapp，“子网分配选项”，正在进行的工作，2009年3月。
[SW-ACCT] Stevant, B., Toutain, L., Dupont, F., and D. Binet, "Accounting on Softwires", Work in Progress, April 2009.
[SW-ACCT]Stevant，B.，Toutain，L.，Dupont，F.，和D.Binet，“软电线会计”，在建工程，2009年4月。
[SW-SEC] Yamamoto, S., Williams, C., Parent, F., and H. Yokota, "Softwire Security Analysis and Requirements", Work in Progress, May 2009.
[SW-SEC]Yamamoto，S.，Williams，C.，Parent，F.，和H.Yokota，“软线安全分析和需求”，正在进行的工作，2009年5月。
Authors' Addresses
作者地址
Bill Storer Cisco Systems 170 W Tasman Dr San Jose, CA 95134 USA
Bill Storer Cisco Systems 170 W Tasman Dr San Jose，加利福尼亚州95134美国
EMail: bstorer@cisco.com
EMail: bstorer@cisco.com
Carlos Pignataro (editor) Cisco Systems 7200 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA
Carlos Pignataro（编辑）思科系统7200 Kit Creek路邮政信箱14987美国北卡罗来纳州三角研究公园27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com
Maria Alice Dos Santos Cisco Systems 170 W Tasman Dr San Jose, CA 95134 USA
Maria Alice Dos Santos Cisco Systems 170 W Tasman Dr San Jose，加利福尼亚州，美国95134
EMail: mariados@cisco.com
EMail: mariados@cisco.com
Bruno Stevant (editor) TELECOM Bretagne 2 rue de la Chataigneraie CS17607 Cesson Sevigne, 35576 France
布鲁诺·斯特万特（编辑）法国塞森塞维涅Chataignarie街2号布列塔涅电信公司CS17607，邮编：35576
EMail: bruno.stevant@telecom-bretagne.eu
EMail: bruno.stevant@telecom-bretagne.eu
Laurent Toutain TELECOM Bretagne 2 rue de la Chataigneraie CS17607 Cesson Sevigne, 35576 France
法国塞森塞维涅市沙塔尼大街2号洛朗图丹电信公司CS17607，邮编：35576
EMail: laurent.toutain@telecom-bretagne.eu
EMail: laurent.toutain@telecom-bretagne.eu
Jean-Francois Tremblay Videotron Ltd. 612 Saint-Jacques Montreal, QC H3C 4M8 Canada
Jean-Francois Tremblay Videotron有限公司，加拿大QC H3C 4M8蒙特利尔圣雅克612号
EMail: jf@jftremblay.com
EMail: jf@jftremblay.com