Internet Engineering Task Force (IETF) R. Maglione
Request for Comments: 6519 Telecom Italia
Category: Standards Track A. Durand
ISSN: 2070-1721 Juniper Networks
February 2012
Internet Engineering Task Force (IETF) R. Maglione
Request for Comments: 6519 Telecom Italia
Category: Standards Track A. Durand
ISSN: 2070-1721 Juniper Networks
February 2012
RADIUS Extensions for Dual-Stack Lite
双栈Lite的半径扩展
Abstract
摘要
Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix. Dual-Stack Lite requires pre-configuration of the Dual-Stack Lite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element. In many networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic Host Configuration Protocol (DHCP). This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Dual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS server and the Network Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server.
双栈Lite是一种解决方案，可为仅使用IPv6前缀寻址的客户提供IPv4和IPv6连接。双栈Lite需要预先配置基本桥接宽带（B4）元件上的双栈Lite地址系列转换路由器（AFTR）通道信息。在许多网络中，客户配置文件信息可能存储在身份验证、授权和记帐（AAA）服务器中，而客户端配置主要通过动态主机配置协议（DHCP）提供。本文档指定了一个新的远程身份验证拨入用户服务（RADIUS）属性，以携带双栈Lite AFTR隧道名称；半径属性是基于等效的DHCPv6选项AFTR\u NAME选项定义的。此RADIUS属性用于RADIUS服务器和网络访问服务器（NAS）之间；它不打算直接用于B4元件和RADIUS服务器之间。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6519.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6519.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. DS-Lite Configuration with RADIUS and DHCPv6 ....................4
4. RADIUS Attribute ................................................7
4.1. DS-Lite-Tunnel-Name ........................................7
5. Table of Attributes .............................................9
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
1. Introduction ....................................................3
2. Terminology .....................................................4
3. DS-Lite Configuration with RADIUS and DHCPv6 ....................4
4. RADIUS Attribute ................................................7
4.1. DS-Lite-Tunnel-Name ........................................7
5. Table of Attributes .............................................9
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Dual-Stack Lite [RFC6333] is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix (no IPv4 address is assigned to the attachment device). One of its key components is an IPv4-over-IPv6 tunnel, but a Dual-Stack-Lite Basic Bridging BroadBand (B4) element will not know if the network to which it is attached offers Dual-Stack Lite support. Even if the B4 did know, it would not know the remote end of the tunnel to which it could establish a connection.
双栈Lite[RFC6333]是一种解决方案，可为仅使用IPv6前缀寻址的客户提供IPv4和IPv6连接（未向连接设备分配IPv4地址）。其关键组件之一是IPv4-over-IPv6隧道，但双栈Lite基本桥接宽带（B4）元件将不知道其所连接的网络是否提供双栈Lite支持。即使B4知道，它也不知道它可以建立连接的隧道的远端。
To inform the B4 element of the location of the Address Family Transition Router (AFTR), a Fully Qualified Domain Name (FQDN) may be used. Once this information is conveyed, the presence of the configuration indicating the AFTR's location also informs a host to initiate Dual-Stack Lite (DS-Lite) service and become a Softwire Initiator.
为了通知B4元素地址族转换路由器（AFTR）的位置，可以使用完全限定域名（FQDN）。一旦传递了该信息，指示AFTR位置的配置的存在也通知主机启动双栈Lite（DS Lite）服务并成为软线启动器。
[RFC6334] specifies a DHCPv6 option that is meant to be used by a DS-Lite client (B4 element) to discover its AFTR name. In order to be able to populate such an option, the DHCPv6 server must be pre-provisioned with the AFTR name.
[RFC6334]指定DS Lite客户端（B4元素）用来发现其AFTR名称的DHCPv6选项。为了能够填充这样的选项，DHCPv6服务器必须预先配置AFTR名称。
In broadband environments, a customer profile may be managed by Authentication, Authorization, and Accounting (AAA) servers, together with AAA for users. The Remote Authentication Dial-In User Service (RADIUS) protocol [RFC2865] is usually used by AAA servers to communicate with network elements. [RADIUS-IPv6] describes a typical broadband network scenario in which the Network Access Server (NAS) acts as the access gateway for the users (hosts or Customer Premises Equipment (CPE) devices) and also embeds a DHCPv6 server function that allows it to locally handle any DHCPv6 requests issued by the clients.
在宽带环境中，可以通过身份验证、授权和计费（AAA）服务器以及用户的AAA来管理客户配置文件。AAA服务器通常使用远程身份验证拨入用户服务（RADIUS）协议[RFC2865]与网元通信。[RADIUS-IPv6]描述了一种典型的宽带网络场景，其中网络访问服务器（NAS）充当用户（主机或客户场所设备（CPE）设备）的访问网关，还嵌入了DHCPv6服务器功能，允许其在本地处理客户机发出的任何DHCPv6请求。
Since the DS-Lite AFTR information can be stored in AAA servers and the client configuration is mainly provided through DHCP running between the NAS and the requesting clients, a new RADIUS attribute is needed to send AFTR information from the AAA server to the NAS.
由于DS Lite AFTR信息可以存储在AAA服务器中，并且客户端配置主要通过在NAS和请求客户端之间运行的DHCP提供，因此需要新的RADIUS属性将AFTR信息从AAA服务器发送到NAS。
This document defines a new RADIUS attribute to be used for carrying the DS-Lite Tunnel Name, based on the equivalent DHCPv6 option already specified in [RFC6334].
本文档基于[RFC6334]中已经指定的等效DHCPv6选项，定义了用于承载DS Lite隧道名称的新RADIUS属性。
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]中所述进行解释。
The terms DS-Lite Basic Bridging BroadBand element (B4) and the DS-Lite Address Family Transition Router element (AFTR) are defined in [RFC6333].
术语DS-Lite基本桥接宽带元件（B4）和DS-Lite地址系列转换路由器元件（AFTR）在[RFC6333]中定义。
Figure 1 illustrates how the RADIUS protocol and DHCPv6 work together to accomplish DS-Lite configuration on the B4 element when a PPP session is used to provide connectivity to the user.
图1说明了当使用PPP会话向用户提供连接时，RADIUS协议和DHCPv6如何协同工作以在B4元素上完成DS Lite配置。
The NAS operates as a client of RADIUS and as a DHCP Server. The NAS initially sends a RADIUS Access-Request message to the RADIUS server, requesting authentication. Once the RADIUS server receives the request, it validates the sending client, and if the request is approved, the AAA server replies with an Access-Accept message including a list of attribute-value pairs that describe the parameters to be used for this session. This list MAY also contain the AFTR tunnel name. When the NAS receives a DHCPv6 client request containing the DS-Lite tunnel option, the NAS SHALL use the name returned in the RADIUS DS-Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME option in the DHCPv6 reply message.
NAS作为RADIUS的客户端和DHCP服务器运行。NAS最初向RADIUS服务器发送RADIUS访问请求消息，请求身份验证。RADIUS服务器接收到请求后，将验证发送客户端，如果请求获得批准，AAA服务器将使用Access Accept消息（包括描述此会话所用参数的属性值对列表）进行答复。此列表还可能包含AFTR隧道名称。当NAS接收到包含DS Lite tunnel选项的DHCPv6客户端请求时，NAS应使用RADIUS DS Lite tunnel name属性中返回的名称来填充DHCPv6回复消息中的DHCPv6选项AFTR name选项。
B4 NAS AAA
| | Server
| | |
|----PPP LCP Config-Request------> | |
| | |
| |----Access-Request ---->|
| | |
| |<---- Access-Accept-----|
| | (DS-Lite-Tunnel-Name) |
|<-----PPP LCP Config-ACK ------- | |
| | |
| | |
|--- PPP IPv6CP Config-Request --->| |
| | |
|<----- PPP IPv6CP Config-ACK -----| |
| | |
|------- DHCPv6 Solicit -------->| |
| | |
|<-------DHCPv6 Advertisement -----| |
| (DHCPv6 OPTION_AFTR_NAME) | |
| | |
|------- DHCPv6 Request -------->| |
| | |
|<-------- DHCPv6 Reply ---------- | |
| (DHCPv6 OPTION_AFTR_NAME) | |
B4 NAS AAA
| | Server
| | |
|----PPP LCP Config-Request------> | |
| | |
| |----Access-Request ---->|
| | |
| |<---- Access-Accept-----|
| | (DS-Lite-Tunnel-Name) |
|<-----PPP LCP Config-ACK ------- | |
| | |
| | |
|--- PPP IPv6CP Config-Request --->| |
| | |
|<----- PPP IPv6CP Config-ACK -----| |
| | |
|------- DHCPv6 Solicit -------->| |
| | |
|<-------DHCPv6 Advertisement -----| |
| (DHCPv6 OPTION_AFTR_NAME) | |
| | |
|------- DHCPv6 Request -------->| |
| | |
|<-------- DHCPv6 Reply ---------- | |
| (DHCPv6 OPTION_AFTR_NAME) | |
DHCPv6 RADIUS
DHCPv6半径
Figure 1: RADIUS and DHCPv6 Message Flow for a PPP Session
图1:PPP会话的RADIUS和DHCPv6消息流
Figure 2 illustrates how the RADIUS protocol and DHCPv6 work together to accomplish DS-Lite configuration on the B4 element when an IP session is used to provide connectivity to the user.
图2说明了当使用IP会话向用户提供连接时，RADIUS协议和DHCPv6如何协同工作以在B4元素上完成DS Lite配置。
The only difference between this message flow and the previous one is that in this scenario, the interaction between the NAS and the AAA/ RADIUS server is triggered by the DHCPv6 Solicit message received by the NAS from the B4 acting as a DHCPv6 client, while in the case of a PPP session, the trigger is the PPP Link Control Protocol (LCP) Config-Request message received by the NAS.
此消息流与前一个消息流之间的唯一区别在于，在此场景中，NAS和AAA/RADIUS服务器之间的交互由NAS从充当DHCPv6客户端的B4接收的DHCPv6请求消息触发，而在PPP会话的情况下，触发是PPP链路控制协议（LCP）NAS接收到配置请求消息。
B4 NAS AAA
| | Server
|------ DHCPv6 Solicit ---------> | |
| | |
| |----Access-Request ---->|
| | |
| |<---Access-Accept-------|
| | (DS-Lite-Tunnel-Name) |
| | |
|<-------DHCPv6 Advertisement------| |
| (DHCPv6 OPTION_AFTR_NAME) | |
| | |
|------- DHCPv6 Request -------->| |
| | |
| | |
|<----- DHCPv6 Reply ------------- | |
| (DHCPv6 OPTION_AFTR_NAME) | |
B4 NAS AAA
| | Server
|------ DHCPv6 Solicit ---------> | |
| | |
| |----Access-Request ---->|
| | |
| |<---Access-Accept-------|
| | (DS-Lite-Tunnel-Name) |
| | |
|<-------DHCPv6 Advertisement------| |
| (DHCPv6 OPTION_AFTR_NAME) | |
| | |
|------- DHCPv6 Request -------->| |
| | |
| | |
|<----- DHCPv6 Reply ------------- | |
| (DHCPv6 OPTION_AFTR_NAME) | |
DHCPv6 RADIUS
DHCPv6半径
Figure 2: RADIUS and DHCPv6 Message Flow for an IP Session
图2:IP会话的RADIUS和DHCPv6消息流
In the scenario depicted in Figure 2, the Access-Request packet contains a Service-Type attribute with the value Authorize Only (17); thus, according to [RFC5080], the Access-Request packet MUST contain a State attribute.
在图2中描述的场景中，访问请求包包含一个值为Authorize Only（17）的服务类型属性；因此，根据[RFC5080]，访问请求数据包必须包含状态属性。
After receiving the DS-Lite-Tunnel-Name attribute in the initial Access-Accept packet, the NAS MUST store the received AFTR tunnel name locally. When the B4 sends a DHCPv6 Renew message to request an extension of the lifetimes for the assigned address or prefix, the NAS does not have to initiate a new Access-Request packet towards the AAA server to request the AFTR tunnel name. The NAS retrieves the previously stored AFTR tunnel name and uses it in its reply.
在接收到初始访问接受数据包中的DS Lite隧道名称属性后，NAS必须在本地存储接收到的AFTR隧道名称。当B4发送DHCPv6 Renew消息以请求延长分配地址或前缀的使用寿命时，NAS不必向AAA服务器发起新的访问请求数据包以请求AFTR隧道名称。NAS检索以前存储的AFTR隧道名称，并在其应答中使用它。
According to [RFC3315], if the DHCPv6 server to which the DHCPv6 Renew message was sent at time T1 has not responded, the DHCPv6 client initiates a Rebind/Reply message exchange with any available server. In this scenario, the NAS receiving the DHCPv6 Rebind message MUST initiate a new Access-Request message towards the AAA server. The NAS MAY include the DS-Lite-Tunnel-Name attribute in its Access-Request message.
根据[RFC3315]，如果在时间T1向其发送DHCPv6续订消息的DHCPv6服务器没有响应，则DHCPv6客户端将启动与任何可用服务器的重新绑定/回复消息交换。在这种情况下，接收DHCPv6重新绑定消息的NAS必须向AAA服务器发起新的访问请求消息。NAS可以在其访问请求消息中包含DS Lite隧道名称属性。
If the NAS does not receive the DS-Lite-Tunnel-Name attribute in the Access-Accept message, it MAY fall back to a pre-configured default tunnel name, if any. If the NAS does not have any pre-configured
如果NAS没有在Access Accept消息中接收到DS Lite Tunnel Name属性，它可能会退回到预先配置的默认隧道名称（如果有）。如果NAS没有任何预配置的
default tunnel name or if the NAS receives an Access-Reject message, the IPv4-over-IPv6 tunnel cannot be established; thus, the B4 element has only IPv6 connectivity.
默认隧道名称，或者如果NAS接收到访问拒绝消息，则无法建立IPv4-over-IPv6隧道；因此，B4元素只有IPv6连接。
This section specifies the format of the new RADIUS attribute.
本节指定新半径属性的格式。
The DS-Lite-Tunnel-Name RADIUS attribute contains an FQDN that refers to the AFTR to which the client is requested to establish a connection. The NAS SHALL use the name returned in the RADIUS DS-Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME option [RFC6334].
DS Lite Tunnel Name RADIUS属性包含一个FQDN，该FQDN引用客户端被请求建立连接的AFTR。NAS应使用RADIUS DS Lite Tunnel name属性中返回的名称填充DHCPv6选项[RFC6334]。
This attribute MAY be used in Access-Request packets as a hint to the RADIUS server; for example, if the NAS is pre-configured with a default tunnel name, this name MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the NAS, and it MAY assign a different AFTR tunnel name.
该属性可在访问请求包中用作对RADIUS服务器的提示；例如，如果NAS预先配置了默认的隧道名称，则可以在属性中插入此名称。RADIUS服务器可能会忽略NAS发送的提示，并且可能会分配不同的AFTR隧道名称。
If the NAS includes the DS-Lite-Tunnel-Name attribute, but the AAA server does not recognize it, this attribute MUST be ignored by the AAA server.
如果NAS包含DS Lite Tunnel Name属性，但AAA服务器无法识别该属性，则AAA服务器必须忽略该属性。
If the NAS does not receive the DS-Lite-Tunnel-Name attribute in the Access-Accept message, it MAY fall back to a pre-configured default tunnel name, if any. If the NAS does not have any pre-configured default tunnel name, the tunnel cannot be established.
如果NAS没有在Access Accept消息中接收到DS Lite Tunnel Name属性，它可能会退回到预先配置的默认隧道名称（如果有）。如果NAS没有任何预先配置的默认隧道名称，则无法建立隧道。
If the NAS is pre-provisioned with a default AFTR tunnel name and the AFTR tunnel name received in the Access-Accept message is different from the configured default, then the AFTR tunnel name received in the Access-Accept message MUST be used for the session.
如果NAS预先配置了默认AFTR隧道名称，并且在Access Accept消息中接收到的AFTR隧道名称与配置的默认名称不同，则在Access Accept消息中接收到的AFTR隧道名称必须用于会话。
If the NAS cannot support the received AFTR tunnel name for any reason, the tunnel SHOULD NOT be established.
如果NAS因任何原因无法支持收到的AFTR隧道名称，则不应建立隧道。
When the Access-Request message is triggered by a DHCPv6 Rebind message, if the AFTR tunnel name received in the Access-Accept message is different from the currently used one for that session, the NAS MUST force the B4 to re-establish the tunnel using the new AFTR name received in the Access-Accept message.
当DHCPv6重新绑定消息触发访问请求消息时，如果在访问接受消息中接收到的AFTR隧道名称与该会话当前使用的名称不同，NAS必须强制B4使用在访问接受消息中接收到的新AFTR名称重新建立隧道。
If an implementation includes Change-of-Authorization (CoA) messages [RFC5176], they could be used to modify the current established DS-Lite tunnel. When the NAS receives a CoA Request message
如果实现包括授权变更（CoA）消息[RFC5176]，则它们可用于修改当前建立的DS Lite隧道。NAS收到CoA请求消息时
containing the DS-Lite-Tunnel-Name attribute, the NAS MUST send a Reconfigure message to a B4 to inform the B4 that the NAS has new or updated configuration parameters and that the B4 is to initiate a Renew/Reply or Information-Request/Reply transaction with the NAS in order to receive the updated information.
包含DS Lite Tunnel Name属性的NAS必须向B4发送重新配置消息，以通知B4 NAS具有新的或更新的配置参数，并且B4将启动与NAS的续订/回复或信息请求/回复事务，以便接收更新的信息。
Upon receiving an AFTR tunnel name different from the currently used one, the B4 MUST terminate the current DS-Lite tunnel, and the B4 MUST establish a new DS-Lite tunnel with the specified AFTR.
收到与当前使用的AFTR隧道名称不同的AFTR隧道名称后，B4必须终止当前DS Lite隧道，并且B4必须使用指定的AFTR建立新的DS Lite隧道。
The DS-Lite-Tunnel-Name RADIUS attribute MAY be present in Accounting-Request records where the Acct-Status-Type is set to Start, Stop, or Interim-Update. The DS-Lite-Tunnel-Name RADIUS attribute MUST NOT appear more than once in a message.
帐户状态类型设置为开始、停止或临时更新的记帐请求记录中可能存在DS Lite Tunnel Name RADIUS属性。DS Lite Tunnel Name RADIUS属性在消息中不得出现多次。
A summary of the DS-Lite-Tunnel-Name RADIUS attribute format is shown below. The fields are transmitted from left to right.
DS Lite隧道名称半径属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | DS-Lite-Tunnel-Name (FQDN)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | DS-Lite-Tunnel-Name (FQDN)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
类型：
144 for DS-Lite-Tunnel-Name.
144表示DS Lite隧道名称。
Length:
长度：
This field indicates the total length in octets of this attribute including the Type and Length fields, and the length in octets of the DS-Lite-Tunnel-Name field.
此字段表示此属性的总长度（以八位字节为单位），包括类型和长度字段，以及DS Lite隧道名称字段的长度（以八位字节为单位）。
DS-Lite-Tunnel-Name:
DS Lite隧道名称：
This field contains a single FQDN of the remote tunnel endpoint, located at the DS-Lite AFTR.
此字段包含位于DS Lite AFTR的远程隧道端点的单个FQDN。
As the DS-Lite-Tunnel-Name attribute is used to populate the DHCPv6 OPTION_AFTR_NAME option, the DS-Lite-Tunnel-Name field is formatted as required in DHCPv6 (Section 8 of [RFC3315] -- "Representation and Use of Domain Names"). Briefly, the format described is using a single octet noting the length of one DNS label (limited to at most 63 octets), followed by the label contents. This repeats until all labels in the FQDN are exhausted, including a terminating zero-length label. Any updates to Section 8 of [RFC3315] also apply to the encoding of this field.
由于DS Lite Tunnel Name属性用于填充DHCPv6 OPTION\u AFTR\u Name选项，因此DS Lite Tunnel Name字段的格式符合DHCPv6中的要求（参见[RFC3315]-“域名的表示和使用”第8节）。简单地说，所描述的格式是使用一个八位字节记录一个DNS标签的长度（最多限制为63个八位字节），然后是标签内容。此操作将重复，直到FQDN中的所有标签（包括终止的零长度标签）都已用尽。[RFC3315]第8节的任何更新也适用于该字段的编码。
The data type of the DS-Lite-Tunnel-Name RADIUS attribute is a string with opaque encapsulation, according to Section 5 of [RFC2865].
根据[RFC2865]第5节，DS Lite Tunnel Name RADIUS属性的数据类型是不透明封装的字符串。
The following tables provide a guide to which attributes may be found in which kinds of packets, and in what quantity.
下表提供了在哪些类型的数据包中可以找到哪些属性以及数量的指南。
Access- Access- Access- Challenge Accounting # Attribute Request Accept Reject Request 0-1 0-1 0 0 0-1 144 DS-Lite-Tunnel-Name
访问-访问-访问-质询记帐#属性请求接受拒绝请求0-10-1 0-1 144 DS Lite隧道名称
CoA-Request CoA-ACK CoA-NACK # Attribute 0-1 0 0 144 DS-Lite-Tunnel-Name
CoA请求CoA确认CoA NACK#属性0-1 0 144 DS Lite隧道名称
The following table defines the meaning of the above table entries.
下表定义了上述表格条目的含义。
0 This attribute MUST NOT be present in the packet. 0+ Zero or more instances of this attribute MAY be present in the packet. 0-1 Zero or one instance of this attribute MAY be present in the packet.
0此属性不能出现在数据包中。数据包中可能存在0+零个或多个此属性的实例。0-1数据包中可能存在该属性的零个或一个实例。
This document has no additional security considerations beyond those already identified in [RFC2865] for the RADIUS protocol and in [RFC5176] for CoA messages.
除了[RFC2865]中针对RADIUS协议和[RFC5176]中针对CoA消息所确定的安全注意事项外，本文件没有其他安全注意事项。
[RFC6333] discusses security issues related to Dual-Stack Lite.
[RFC6333]讨论与双栈Lite相关的安全问题。
Per this document, IANA has allocated a new RADIUS attribute type from the IANA registry "Radius Attribute Types" located at http://www.iana.org/assignments/radius-types.
根据本文档，IANA已从位于的IANA注册表“RADIUS属性类型”中分配了新的RADIUS属性类型http://www.iana.org/assignments/radius-types.
DS-Lite-Tunnel-Name - 144
DS Lite隧道名称-144
[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月。
[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月。
[RFC3315] Droms, R., Ed., 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.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[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月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 63332011年8月。
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, August 2011.
[RFC6334]Hankins，D.和T.Mrugalski，“双栈Lite的IPv6动态主机配置协议（DHCPv6）选项”，RFC 63342011年8月。
[RADIUS-IPv6] Lourdelet, B., Dec, W., Ed., Sarikaya, B., Zorn, G., and D. Miles, "RADIUS attributes for IPv6 Access Networks", Work in Progress, November 2011.
[RADIUS-IPv6]Lourdelet，B.，Dec，W.，Ed.，Sarikaya，B.，Zorn，G.，和D.Miles，“IPv6接入网络的RADIUS属性”，正在进行的工作，2011年11月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5176]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 51762008年1月。
Authors' Addresses
作者地址
Roberta Maglione Telecom Italia Via Reiss Romoli 274 Torino 10148 Italy
罗伯塔·马格里奥尼意大利电信公司Via Reiss Romoli 274都灵10148意大利
EMail: roberta.maglione@telecomitalia.it
EMail: roberta.maglione@telecomitalia.it
Alain Durand Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089-1206 USA
美国加利福尼亚州桑尼维尔北马蒂尔达大道1194号阿兰·杜兰德·朱尼珀网络公司，邮编94089-1206
EMail: adurand@juniper.net
EMail: adurand@juniper.net