Network Working Group G. Zorn
Request for Comments: 2868 Cisco Systems, Inc.
Updates: RFC 2865 D. Leifer
Category: Informational A. Rubens
Ascend Communications
J. Shriver
Intel Corporation
M. Holdrege
ipVerse
I. Goyret
Lucent Technologies
June 2000
Network Working Group G. Zorn
Request for Comments: 2868 Cisco Systems, Inc.
Updates: RFC 2865 D. Leifer
Category: Informational A. Rubens
Ascend Communications
J. Shriver
Intel Corporation
M. Holdrege
ipVerse
I. Goyret
Lucent Technologies
June 2000
RADIUS Attributes for Tunnel Protocol Support
用于隧道协议支持的RADIUS属性
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks.
本文档定义了一组RADIUS属性，旨在支持在拨号网络中提供强制隧道。
Many applications of tunneling protocols such as L2TP involve dial-up network access. Some, such as the provision of access to corporate intranets via the Internet, are characterized by voluntary tunneling: the tunnel is created at the request of the user for a specific purpose. Other applications involve compulsory tunneling: the tunnel is created without any action from the user and without allowing the user any choice in the matter. In order to provide this functionality, new RADIUS attributes are needed to carry the tunneling information from the RADIUS server to the tunnel end points; this document defines those attributes. Specific recommendations for, and examples of, the application of these attributes for L2TP can be found in RFC 2809.
隧道协议（如L2TP）的许多应用都涉及拨号网络访问。有些，例如通过互联网提供对公司内部网的访问，其特点是自愿隧道：隧道是应用户的请求为特定目的而创建的。其他应用程序涉及强制隧道：创建隧道时用户没有任何操作，也不允许用户在该问题上进行任何选择。为了提供此功能，需要新的RADIUS属性将隧道信息从RADIUS服务器传送到隧道端点；本文档定义了这些属性。关于L2TP应用这些属性的具体建议和示例，请参见RFC 2809。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [14].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[14]所述。
Multiple instances of each of the attributes defined below may be included in a single RADIUS packet. In this case, the attributes to be applied to any given tunnel SHOULD all contain the same value in their respective Tag fields; otherwise, the Tag field SHOULD NOT be used.
以下定义的每个属性的多个实例可包括在单个RADIUS数据包中。在这种情况下，要应用于任何给定隧道的属性在其各自的标记字段中都应包含相同的值；否则，不应使用标记字段。
If the RADIUS server returns attributes describing multiple tunnels then the tunnels SHOULD be interpreted by the tunnel initiator as alternatives and the server SHOULD include an instance of the Tunnel-Preference Attribute in the set of Attributes pertaining to each alternative tunnel. Similarly, if the RADIUS client includes multiple sets of tunnel Attributes in an Access-Request packet, all the Attributes pertaining to a given tunnel SHOULD contain the same value in their respective Tag fields and each set SHOULD include an appropriately valued instance of the Tunnel-Preference Attribute.
如果RADIUS服务器返回描述多个隧道的属性，则隧道启动器应将隧道解释为备选方案，并且服务器应在与每个备选隧道相关的属性集中包含隧道首选项属性的实例。类似地，如果RADIUS客户端在访问请求分组中包括多组隧道属性，则与给定隧道相关的所有属性应在其各自的标记字段中包含相同的值，并且每组应包括隧道首选项属性的适当值实例。
Description
描述
This Attribute indicates the tunneling protocol(s) to be used (in the case of a tunnel initiator) or the the tunneling protocol in use (in the case of a tunnel terminator). It MAY be included in Access-Request, Access-Accept and Accounting-Request packets. If the Tunnel-Type Attribute is present in an Access-Request packet sent from a tunnel initiator, it SHOULD be taken as a hint to the RADIUS server as to the tunnelling protocols supported by the tunnel end-point; the RADIUS server MAY ignore the hint, however. A tunnel initiator is not required to implement any of these tunnel types; if a tunnel initiator receives an Access-Accept packet which contains only unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave as though an Access-Reject had been received instead.
此属性表示要使用的隧道协议（对于隧道启动器）或正在使用的隧道协议（对于隧道终止程序）。它可以包含在访问请求、访问接受和记帐请求包中。如果隧道类型属性存在于从隧道启动器发送的访问请求数据包中，则应将其作为对RADIUS服务器的隧道端点支持的隧道协议的提示；但是，RADIUS服务器可能会忽略该提示。实现这些隧道类型中的任何一种都不需要隧道启动器；如果隧道启动器接收到仅包含未知或不受支持的隧道类型的访问接受数据包，则隧道启动器的行为必须与接收到访问拒绝一样。
If the Tunnel-Type Attribute is present in an Access-Request packet sent from a tunnel terminator, it SHOULD be taken to signify the tunnelling protocol in use. In this case, if the RADIUS server determines that the use of the communicated protocol is not authorized, it MAY return an Access-Reject packet. If a tunnel terminator receives an Access-Accept packet which contains
如果隧道类型属性存在于从隧道终止器发送的访问请求数据包中，则应将其视为表示正在使用的隧道协议。在这种情况下，如果RADIUS服务器确定未授权使用所通信的协议，则其可返回访问拒绝分组。如果隧道终端接收到包含
one or more Tunnel-Type Attributes, none of which represent the tunneling protocol in use, the tunnel terminator SHOULD behave as though an Access-Reject had been received instead.
一个或多个隧道类型属性，其中没有一个表示正在使用的隧道协议，隧道终止符的行为应与接收到访问拒绝一样。
A summary of the Tunnel-Type Attribute format is shown below. The fields are transmitted from left to right.
隧道类型属性格式的摘要如下所示。字段从左向右传输。
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 | Tag | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Tag | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 64 for Tunnel-Type
64型适用于隧道型
Length Always 6.
长度始终为6。
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00).
标签标签字段的长度为一个八位字节，旨在提供一种方法，对引用同一隧道的同一数据包中的属性进行分组。此字段的有效值为0x01到0x1F，包括在内。如果标记字段未使用，则它必须为零（0x00）。
Value The Value field is three octets and contains one of the following values, indicating the type of tunnel to be started.
值值字段是三个八位字节，包含以下值之一，指示要启动的隧道类型。
1 Point-to-Point Tunneling Protocol (PPTP) [1]
2 Layer Two Forwarding (L2F) [2]
3 Layer Two Tunneling Protocol (L2TP) [3]
4 Ascend Tunnel Management Protocol (ATMP) [4]
5 Virtual Tunneling Protocol (VTP)
6 IP Authentication Header in the Tunnel-mode (AH) [5]
7 IP-in-IP Encapsulation (IP-IP) [6]
8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [7]
9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [8]
10 Generic Route Encapsulation (GRE) [9]
11 Bay Dial Virtual Services (DVS)
12 IP-in-IP Tunneling [10]
1 Point-to-Point Tunneling Protocol (PPTP) [1]
2 Layer Two Forwarding (L2F) [2]
3 Layer Two Tunneling Protocol (L2TP) [3]
4 Ascend Tunnel Management Protocol (ATMP) [4]
5 Virtual Tunneling Protocol (VTP)
6 IP Authentication Header in the Tunnel-mode (AH) [5]
7 IP-in-IP Encapsulation (IP-IP) [6]
8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [7]
9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [8]
10 Generic Route Encapsulation (GRE) [9]
11 Bay Dial Virtual Services (DVS)
12 IP-in-IP Tunneling [10]
Description
描述
The Tunnel-Medium-Type Attribute indicates which transport medium to use when creating a tunnel for those protocols (such as L2TP) that can operate over multiple transports. It MAY be included in both Access-Request and Access-Accept packets; if it is present in an Access-Request packet, it SHOULD be taken as a hint to the RADIUS server as to the tunnel media supported by the tunnel end-point. The RADIUS server MAY ignore the hint, however.
“隧道介质类型”属性指示在为那些可以在多个传输上运行的协议（如L2TP）创建隧道时要使用的传输介质。它可以包括在访问请求和访问接受分组中；如果它存在于访问请求数据包中，则应将其视为RADIUS服务器关于隧道端点支持的隧道介质的提示。但是，RADIUS服务器可能会忽略该提示。
A summary of the Tunnel-Medium-Type Attribute format is given below. The fields are transmitted left to right.
隧道介质类型属性格式概述如下。字段从左向右传输。
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 | Tag | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Tag | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65 for Tunnel-Medium-Type
65型适用于隧道中型
Length 6
长度6
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00).
标签标签字段的长度为一个八位字节，旨在提供一种方法，对引用同一隧道的同一数据包中的属性进行分组。此字段的有效值为0x01到0x1F，包括在内。如果标记字段未使用，则它必须为零（0x00）。
Value The Value field is three octets and contains one of the values listed under "Address Family Numbers" in [14]. For the sake of convenience, a relevant excerpt of this list is reproduced below.
值值字段为三个八位字节，包含[14]中“地址系列号”下列出的值之一。为方便起见，本清单的相关摘录转载如下。
1 IPv4 (IP version 4) 2 IPv6 (IP version 6) 3 NSAP 4 HDLC (8-bit multidrop) 5 BBN 1822 6 802 (includes all 802 media plus Ethernet "canonical format") 7 E.163 (POTS) 8 E.164 (SMDS, Frame Relay, ATM)
1 IPv4（IP版本4）2 IPv6（IP版本6）3 NSAP 4 HDLC（8位多点）5 BBN 1822 6 802（包括所有802媒体加以太网“标准格式”）7 E.163（POTS）8 E.164（SMDS、帧中继、ATM）
9 F.69 (Telex) 10 X.121 (X.25, Frame Relay) 11 IPX 12 Appletalk 13 Decnet IV 14 Banyan Vines 15 E.164 with NSAP format subaddress
9 F.69（电传）10 X.121（X.25，帧中继）11 IPX 12 Appletalk 13 Decnet IV 14 Banyan Vines 15 E.164，带NSAP格式子地址
Description
描述
This Attribute contains the address of the initiator end of the tunnel. It MAY be included in both Access-Request and Access-Accept packets to indicate the address from which a new tunnel is to be initiated. If the Tunnel-Client-Endpoint Attribute is included in an Access-Request packet, the RADIUS server should take the value as a hint; the server is not obligated to honor the hint, however. This Attribute SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop, in which case it indicates the address from which the tunnel was initiated. This Attribute, along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection-ID attributes, may be used to provide a globally unique means to identify a tunnel for accounting and auditing purposes.
此属性包含隧道的启动器端的地址。它可以包括在接入请求和接入接受分组中，以指示新隧道将从其发起的地址。如果隧道客户端端点属性包含在访问请求数据包中，RADIUS服务器应将该值作为提示；但是，服务器没有义务遵守提示。此属性应包含在记帐请求数据包中，该数据包包含值为Start或Stop的Acct Status Type属性，在这种情况下，该属性表示启动隧道的地址。此属性以及隧道服务器端点和Acct Tunnel Connection ID属性可用于提供全局唯一的方法来标识用于记帐和审核目的的隧道。
A summary of the Tunnel-Client-Endpoint Attribute format is shown below. The fields are transmitted from left to right.
隧道客户端端点属性格式的摘要如下所示。字段从左向右传输。
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 66 for Tunnel-Client-Endpoint.
隧道客户端终结点的类型66。
Length >= 3
长度>=3
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field.
标签标签字段的长度为一个八位字节，旨在提供一种方法，对引用同一隧道的同一数据包中的属性进行分组。如果标记字段的值大于0x00且小于或等于0x1F，则应将其解释为指示此属性属于哪个隧道（多个备选方案）。如果标记字段大于0x1F，则应将其解释为以下字符串字段的第一个字节。
String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute.
字符串字符串字段表示的地址格式取决于隧道介质类型属性的值。
If Tunnel-Medium-Type is IPv4 (1), then this string is either the fully qualified domain name (FQDN) of the tunnel client machine, or it is a "dotted-decimal" IP address. Conformant implementations MUST support the dotted-decimal format and SHOULD support the FQDN format for IP addresses.
如果隧道介质类型为IPv4（1），则此字符串要么是隧道客户端计算机的完全限定域名（FQDN），要么是“点十进制”IP地址。一致性实现必须支持点十进制格式，并且应该支持IP地址的FQDN格式。
If Tunnel-Medium-Type is IPv6 (2), then this string is either the FQDN of the tunnel client machine, or it is a text representation of the address in either the preferred or alternate form [17]. Conformant implementations MUST support the preferred form and SHOULD support both the alternate text form and the FQDN format for IPv6 addresses.
如果隧道介质类型为IPv6（2），则此字符串要么是隧道客户端计算机的FQDN，要么是首选或备用形式的地址文本表示形式[17]。一致性实现必须支持首选格式，并且应支持IPv6地址的备用文本格式和FQDN格式。
If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag referring to configuration data local to the RADIUS client that describes the interface and medium-specific address to use.
如果隧道介质类型既不是IPv4也不是IPv6，则此字符串是一个标记，表示RADIUS客户端本地的配置数据，该配置数据描述了要使用的接口和介质特定地址。
Description
描述
This Attribute indicates the address of the server end of the tunnel. The Tunnel-Server-Endpoint Attribute MAY be included (as a hint to the RADIUS server) in the Access-Request packet and MUST be included in the Access-Accept packet if the initiation of a tunnel is desired. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session. This Attribute, along with the Tunnel-Client-Endpoint and Acct-Tunnel-Connection-ID Attributes [11], may be used to provide a globally unique means to identify a tunnel for accounting and auditing purposes.
此属性表示隧道服务器端的地址。隧道服务器端点属性可以包括在访问请求数据包中（作为对RADIUS服务器的提示），如果需要启动隧道，则必须包括在访问接受数据包中。它应该包含在记帐请求数据包中，该数据包包含Acct Status Type属性，其值为Start或Stop，并且属于隧道会话。此属性以及隧道客户端端点和Acct Tunnel Connection ID属性[11]可用于提供一种全局唯一的方法来识别隧道，以便进行会计和审计。
A summary of the Tunnel-Server-Endpoint Attribute format is shown below. The fields are transmitted from left to right.
隧道服务器端点属性格式的摘要如下所示。字段从左向右传输。
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 67 for Tunnel-Server-Endpoint.
为隧道服务器终结点键入67。
Length >= 3
长度>=3
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field.
标签标签字段的长度为一个八位字节，旨在提供一种方法，对引用同一隧道的同一数据包中的属性进行分组。如果标记字段的值大于0x00且小于或等于0x1F，则应将其解释为指示此属性属于哪个隧道（多个备选方案）。如果标记字段大于0x1F，则应将其解释为以下字符串字段的第一个字节。
String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute.
字符串字符串字段表示的地址格式取决于隧道介质类型属性的值。
If Tunnel-Medium-Type is IPv4 (1), then this string is either the fully qualified domain name (FQDN) of the tunnel client machine, or it is a "dotted-decimal" IP address. Conformant implementations MUST support the dotted-decimal format and SHOULD support the FQDN format for IP addresses.
如果隧道介质类型为IPv4（1），则此字符串要么是隧道客户端计算机的完全限定域名（FQDN），要么是“点十进制”IP地址。一致性实现必须支持点十进制格式，并且应该支持IP地址的FQDN格式。
If Tunnel-Medium-Type is IPv6 (2), then this string is either the FQDN of the tunnel client machine, or it is a text representation of the address in either the preferred or alternate form [17]. Conformant implementations MUST support the preferred form and SHOULD support both the alternate text form and the FQDN format for IPv6 addresses.
如果隧道介质类型为IPv6（2），则此字符串要么是隧道客户端计算机的FQDN，要么是首选或备用形式的地址文本表示形式[17]。一致性实现必须支持首选格式，并且应支持IPv6地址的备用文本格式和FQDN格式。
If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag referring to configuration data local to the RADIUS client that describes the interface and medium-specific address to use.
如果隧道介质类型不是IPv4或IPv6，则此字符串是一个标记，表示RADIUS客户端本地的配置数据，该配置数据描述了要使用的接口和介质特定地址。
Description
描述
This Attribute may contain a password to be used to authenticate to a remote server. It may only be included in an Access-Accept packet.
此属性可能包含用于向远程服务器进行身份验证的密码。它只能包含在访问-接受数据包中。
A summary of the Tunnel-Password Attribute format is shown below. The fields are transmitted from left to right.
隧道密码属性格式的摘要如下所示。字段从左向右传输。
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 | Tag | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt (cont) | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Tag | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt (cont) | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 69 for Tunnel-Password
输入69作为隧道密码
Length >= 5
长度>=5
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains; otherwise, the Tag field SHOULD be ignored.
标签标签字段的长度为一个八位字节，旨在提供一种方法，对引用同一隧道的同一数据包中的属性进行分组。此字段的有效值为0x01到0x1F，包括在内。如果标记字段的值大于0x00且小于或等于0x1F，则应将其解释为指示该属性属于哪个隧道（多个备选方案）；否则，应忽略标记字段。
Salt The Salt field is two octets in length and is used to ensure the uniqueness of the encryption key used to encrypt each instance of the Tunnel-Password attribute occurring in a given Access-Accept packet. The most significant bit (leftmost) of the Salt field MUST be set (1). The contents of each Salt field in a given Access-Accept packet MUST be unique.
Salt Salt字段的长度为两个八位字节，用于确保加密密钥的唯一性，该密钥用于加密给定访问接受数据包中出现的隧道密码属性的每个实例。必须设置盐场的最高有效位（最左侧）（1）。给定访问接受数据包中每个盐域的内容必须是唯一的。
String The plaintext String field consists of three logical sub-fields: the Data-Length and Password sub-fields (both of which are required), and the optional Padding sub-field. The Data-Length sub-field is one octet in length and contains the length of the unencrypted Password sub-field. The Password sub-field contains
字符串纯文本字符串字段由三个逻辑子字段组成：数据长度和密码子字段（两者都是必需的），以及可选的填充子字段。数据长度子字段的长度为一个八位字节，包含未加密密码子字段的长度。密码子字段包含
the actual tunnel password. If the combined length (in octets) of the unencrypted Data-Length and Password sub-fields is not an even multiple of 16, then the Padding sub-field MUST be present. If it is present, the length of the Padding sub-field is variable, between 1 and 15 octets. The String field MUST be encrypted as follows, prior to transmission:
实际的隧道密码。如果未加密数据长度和密码子字段的组合长度（以八位字节为单位）不是16的偶数倍，则必须存在填充子字段。如果存在，则填充子字段的长度是可变的，介于1到15个八位字节之间。在传输之前，必须按照以下方式对字符串字段进行加密：
Construct a plaintext version of the String field by concatenating the Data-Length and Password sub-fields. If necessary, pad the resulting string until its length (in octets) is an even multiple of 16. It is recommended that zero octets (0x00) be used for padding. Call this plaintext P.
通过连接数据长度和密码子字段，构造字符串字段的纯文本版本。如有必要，填充生成的字符串，直到其长度（以八位字节为单位）为16的偶数倍。建议将零个八位字节（0x00）用于填充。把这称为明文P。
Call the shared secret S, the pseudo-random 128-bit Request Authenticator (from the corresponding Access-Request packet) R, and the contents of the Salt field A. Break P into 16 octet chunks p(1), p(2)...p(i), where i = len(P)/16. Call the ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. Intermediate values b(1), b(2)...c(i) are required. Encryption is performed in the following manner ('+' indicates concatenation):
调用共享秘密S、伪随机128位请求验证器（来自相应的访问请求分组）R和盐域A的内容。将P分成16个八位组块P（1），P（2）…P（i），其中i＝len（P）/16。调用密文块c（1）、c（2）…c（i）和最终密文c。需要中间值b（1）、b（2）…c（i）。加密以以下方式执行（“+”表示串联）：
b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)
b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)
. .
. .
. .
b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)
b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)
b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)
. .
. .
. .
b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)
The resulting encrypted String field will contain c(1)+c(2)+...+c(i).
生成的加密字符串字段将包含c（1）+c（2）+…+c（i）。
On receipt, the process is reversed to yield the plaintext String.
接收时，该过程被反转以生成纯文本字符串。
Description
描述
This Attribute indicates the group ID for a particular tunneled session. The Tunnel-Private-Group-ID Attribute MAY be included in the Access-Request packet if the tunnel initiator can pre-determine the group resulting from a particular connection and SHOULD be included in the Access-Accept packet if this tunnel session is to be treated as belonging to a particular private group. Private groups may be used to associate a tunneled session with a particular group of users. For example, it may be used to facilitate routing of unregistered IP addresses through a
此属性表示特定隧道会话的组ID。如果隧道发起方可以预先确定由特定连接产生的组，则隧道专用组ID属性可以包括在访问请求分组中，并且如果该隧道会话将被视为属于特定专用组，则应该包括在访问接受分组中。私有组可用于将隧道会话与特定用户组相关联。例如，它可用于促进通过网络路由未注册的IP地址
particular interface. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session.
特定接口。它应该包含在记帐请求数据包中，该数据包包含Acct Status Type属性，其值为Start或Stop，并且属于隧道会话。
A summary of the Tunnel-Private-Group-ID Attribute format is shown below. The fields are transmitted from left to right.
隧道专用组ID属性格式的摘要如下所示。字段从左向右传输。
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 81 for Tunnel-Private-Group-ID.
81型用于隧道专用组ID。
Length >= 3
长度>=3
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field.
标签标签字段的长度为一个八位字节，旨在提供一种方法，对引用同一隧道的同一数据包中的属性进行分组。如果标记字段的值大于0x00且小于或等于0x1F，则应将其解释为指示此属性属于哪个隧道（多个备选方案）。如果标记字段大于0x1F，则应将其解释为以下字符串字段的第一个字节。
String This field must be present. The group is represented by the String field. There is no restriction on the format of group IDs.
字符串此字段必须存在。该组由字符串字段表示。对组ID的格式没有限制。
Description
描述
This Attribute is used to indicate to the tunnel initiator the particular tunnel to which a session is to be assigned. Some tunneling protocols, such as PPTP and L2TP, allow for sessions between the same two tunnel endpoints to be multiplexed over the same tunnel and also for a given session to utilize its own dedicated tunnel. This attribute provides a mechanism for RADIUS to be used to inform the tunnel initiator (e.g. PAC, LAC) whether to assign the session to a multiplexed tunnel or to a separate tunnel. Furthermore, it allows for sessions sharing multiplexed tunnels to be assigned to different multiplexed tunnels.
此属性用于向隧道启动器指示要向其分配会话的特定隧道。一些隧道协议，例如PPTP和L2TP，允许相同的两个隧道端点之间的会话在相同的隧道上多路复用，并且允许给定会话利用其自己的专用隧道。此属性为RADIUS提供了一种机制，用于通知隧道启动器（例如PAC、LAC）是将会话分配给多路复用隧道还是单独的隧道。此外，它允许将共享多路复用隧道的会话分配给不同的多路复用隧道。
A particular tunneling implementation may assign differing characteristics to particular tunnels. For example, different tunnels may be assigned different QOS parameters. Such tunnels may be used to carry either individual or multiple sessions. The Tunnel-Assignment-ID attribute thus allows the RADIUS server to indicate that a particular session is to be assigned to a tunnel that provides an appropriate level of service. It is expected that any QOS-related RADIUS tunneling attributes defined in the future that accompany this attribute will be associated by the tunnel initiator with the ID given by this attribute. In the meantime, any semantic given to a particular ID string is a matter left to local configuration in the tunnel initiator.
特定隧道实现可将不同的特性分配给特定隧道。例如，可以为不同的隧道分配不同的QOS参数。此类隧道可用于承载单个或多个会话。因此，“隧道分配ID”属性允许RADIUS服务器指示将特定会话分配给提供适当服务级别的隧道。预期将来随此属性定义的任何与QOS相关的RADIUS隧道属性将由隧道启动器与此属性给定的ID相关联。同时，给定给特定ID字符串的任何语义都由隧道启动器中的本地配置决定。
The Tunnel-Assignment-ID attribute is of significance only to RADIUS and the tunnel initiator. The ID it specifies is intended to be of only local use to RADIUS and the tunnel initiator. The ID assigned by the tunnel initiator is not conveyed to the tunnel peer.
隧道分配ID属性仅对RADIUS和隧道启动器具有重要意义。它指定的ID仅用于RADIUS和隧道启动器的本地使用。隧道启动器分配的ID不会传送到隧道对等方。
This attribute MAY be included in the Access-Accept. The tunnel initiator receiving this attribute MAY choose to ignore it and assign the session to an arbitrary multiplexed or non-multiplexed tunnel between the desired endpoints. This attribute SHOULD also be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session.
此属性可能包含在Access Accept中。接收此属性的隧道启动器可以选择忽略它，并将会话分配给所需端点之间的任意多路复用或非多路复用隧道。该属性还应包含在记帐请求数据包中，该数据包包含值为Start或Stop的Acct Status Type属性，该属性属于隧道会话。
If a tunnel initiator supports the Tunnel-Assignment-ID Attribute, then it should assign a session to a tunnel in the following manner:
如果隧道启动器支持隧道分配ID属性，则应按以下方式将会话分配给隧道：
If this attribute is present and a tunnel exists between the specified endpoints with the specified ID, then the session should be assigned to that tunnel.
如果此属性存在，并且在具有指定ID的指定端点之间存在隧道，则应将会话分配给该隧道。
If this attribute is present and no tunnel exists between the specified endpoints with the specified ID, then a new tunnel should be established for the session and the specified ID should be associated with the new tunnel.
如果此属性存在，且具有指定ID的指定端点之间不存在隧道，则应为会话建立新隧道，并且指定ID应与新隧道关联。
If this attribute is not present, then the session is assigned to an unnamed tunnel. If an unnamed tunnel does not yet exist between the specified endpoints then it is established and used for this and subsequent sessions established without the Tunnel-Assignment-ID attribute. A tunnel initiator MUST NOT assign a session for which a Tunnel-Assignment-ID Attribute was not specified to a named tunnel (i.e. one that was initiated by a session specifying this attribute).
如果此属性不存在，则将会话分配给未命名的隧道。如果指定端点之间尚不存在未命名的隧道，则将建立该隧道，并将其用于在不使用隧道分配ID属性的情况下建立的此会话和后续会话。隧道启动器不得将未指定隧道分配ID属性的会话分配给命名隧道（即由指定此属性的会话启动的会话）。
Note that the same ID may be used to name different tunnels if such tunnels are between different endpoints.
请注意，如果不同的隧道位于不同的端点之间，则可以使用相同的ID来命名不同的隧道。
A summary of the Tunnel-Assignment-ID Attribute format is shown below. The fields are transmitted from left to right.
隧道分配ID属性格式的摘要如下所示。字段从左向右传输。
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 82 for Tunnel-Assignment-ID.
82型，用于隧道分配ID。
Length >= 3
长度>=3
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field.
标签标签字段的长度为一个八位字节，旨在提供一种方法，对引用同一隧道的同一数据包中的属性进行分组。如果标记字段的值大于0x00且小于或等于0x1F，则应将其解释为指示此属性属于哪个隧道（多个备选方案）。如果标记字段大于0x1F，则应将其解释为以下字符串字段的第一个字节。
String This field must be present. The tunnel ID is represented by the String field. There is no restriction on the format of the ID.
字符串此字段必须存在。隧道ID由字符串字段表示。ID的格式没有限制。
Description
描述
If more than one set of tunneling attributes is returned by the RADIUS server to the tunnel initiator, this Attribute SHOULD be included in each set to indicate the relative preference assigned to each tunnel. For example, suppose that Attributes describing two tunnels are returned by the server, one with a Tunnel-Type of PPTP and the other with a Tunnel-Type of L2TP. If the tunnel initiator supports only one of the Tunnel-Types returned, it will initiate a tunnel of that type. If, however, it supports both tunnel protocols, it SHOULD use the value of the Tunnel-Preference Attribute to decide which tunnel should be started. The tunnel having the numerically lowest value in the Value field of this Attribute SHOULD be given the highest preference. The values assigned to two or more instances of the Tunnel-Preference
如果RADIUS服务器将多组隧道属性返回给隧道启动器，则应在每组中包含此属性，以指示分配给每个隧道的相对首选项。例如，假设服务器返回描述两个隧道的属性，一个隧道类型为PPTP，另一个隧道类型为L2TP。如果隧道启动器仅支持返回的一种隧道类型，它将启动该类型的隧道。但是，如果它同时支持两种隧道协议，则应该使用隧道首选项属性的值来决定应该启动哪个隧道。在该属性的值字段中具有数值最低值的隧道应被赋予最高优先级。指定给隧道首选项的两个或多个实例的值
Attribute within a given Access-Accept packet MAY be identical. In this case, the tunnel initiator SHOULD use locally configured metrics to decide which set of attributes to use. This Attribute MAY be included (as a hint to the server) in Access-Request packets, but the RADIUS server is not required to honor this hint.
给定访问接受数据包中的属性可能相同。在这种情况下，隧道启动器应该使用本地配置的度量来决定使用哪一组属性。此属性可能包含在访问请求数据包中（作为对服务器的提示），但RADIUS服务器不需要遵守此提示。
A summary of the Tunnel-Preference Attribute format is shown below. The fields are transmitted from left to right.
隧道首选项属性格式的摘要如下所示。字段从左向右传输。
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 | Tag | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Tag | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 83 for Tunnel-Preference
隧道首选83型
Length Always 6.
长度始终为6。
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00).
标签标签字段的长度为一个八位字节，旨在提供一种方法，对引用同一隧道的同一数据包中的属性进行分组。此字段的有效值为0x01到0x1F，包括在内。如果标记字段未使用，则它必须为零（0x00）。
Value The Value field is three octets in length and indicates the preference to be given to the tunnel to which it refers; higher preference is given to lower values, with 0x000000 being most preferred and 0xFFFFFF least preferred.
值值字段的长度为三个八位字节，表示要优先选择它所指的隧道；较低的值优先选择较高的值，0x000000是最优先选择的值，0xFFFFFF是最不优先选择的值。
Description
描述
This Attribute specifies the name used by the tunnel initiator during the authentication phase of tunnel establishment. The Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the RADIUS server) in the Access-Request packet, and MUST be included in the Access-Accept packet if an authentication name other than the default is desired. This Attribute SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session.
此属性指定隧道启动器在隧道建立的身份验证阶段使用的名称。隧道客户端身份验证ID属性可能包含在访问请求数据包中（作为对RADIUS服务器的提示），如果需要默认名称以外的身份验证名称，则必须包含在访问接受数据包中。此属性应包含在记帐请求数据包中，该数据包包含值为Start或Stop的Acct Status Type属性，该属性属于隧道会话。
A summary of the Tunnel-Client-Auth-ID Attribute format is shown below. The fields are transmitted from left to right.
隧道客户端身份验证ID属性格式的摘要如下所示。字段从左向右传输。
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 90 for Tunnel-Client-Auth-ID.
对于Tunnel-Client-Auth-ID，键入90。
Length >= 3
长度>=3
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field.
标签标签字段的长度为一个八位字节，旨在提供一种方法，对引用同一隧道的同一数据包中的属性进行分组。如果标记字段的值大于0x00且小于或等于0x1F，则应将其解释为指示此属性属于哪个隧道（多个备选方案）。如果标记字段大于0x1F，则应将其解释为以下字符串字段的第一个字节。
String This field must be present. The String field contains the authentication name of the tunnel initiator. The authentication name SHOULD be represented in the UTF-8 charset.
字符串此字段必须存在。字符串字段包含隧道启动器的身份验证名称。身份验证名称应以UTF-8字符集表示。
Description
描述
This Attribute specifies the name used by the tunnel terminator during the authentication phase of tunnel establishment. The Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the RADIUS server) in the Access-Request packet, and MUST be included in the Access-Accept packet if an authentication name other than the default is desired. This Attribute SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session.
此属性指定隧道终止程序在隧道建立的身份验证阶段使用的名称。隧道客户端身份验证ID属性可能包含在访问请求数据包中（作为对RADIUS服务器的提示），如果需要默认名称以外的身份验证名称，则必须包含在访问接受数据包中。此属性应包含在记帐请求数据包中，该数据包包含值为Start或Stop的Acct Status Type属性，该属性属于隧道会话。
A summary of the Tunnel-Server-Auth-ID Attribute format is shown below. The fields are transmitted from left to right.
隧道服务器身份验证ID属性格式的摘要如下所示。字段从左向右传输。
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 91 for Tunnel-Server-Auth-ID.
对于Tunnel-Server-Auth-ID，键入91。
Length >= 3
长度>=3
Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field.
标签标签字段的长度为一个八位字节，旨在提供一种方法，对引用同一隧道的同一数据包中的属性进行分组。如果标记字段的值大于0x00且小于或等于0x1F，则应将其解释为指示此属性属于哪个隧道（多个备选方案）。如果标记字段大于0x1F，则应将其解释为以下字符串字段的第一个字节。
String This field must be present. The String field contains the authentication name of the tunnel terminator. The authentication name SHOULD be represented in the UTF-8 charset.
字符串此字段必须存在。字符串字段包含隧道终止符的身份验证名称。身份验证名称应以UTF-8字符集表示。
The following table provides a guide to which of the above attributes may be found in which kinds of packets, and in what quantity.
下表提供了在哪种类型的数据包中可以找到上述哪些属性以及数量的指南。
Request Accept Reject Challenge Acct-Request # Attribute
0+ 0+ 0 0 0-1 64 Tunnel-Type
0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type
0+ 0+ 0 0 0-1 66 Tunnel-Client-Endpoint
0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint
0 0+ 0 0 0 69 Tunnel-Password
0+ 0+ 0 0 0-1 81 Tunnel-Private-Group-ID
0 0+ 0 0 0-1 82 Tunnel-Assignment-ID
0+ 0+ 0 0 0 83 Tunnel-Preference
0+ 0+ 0 0 0-1 90 Tunnel-Client-Auth-ID
0+ 0+ 0 0 0-1 91 Tunnel-Server-Auth-ID
Request Accept Reject Challenge Acct-Request # Attribute
0+ 0+ 0 0 0-1 64 Tunnel-Type
0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type
0+ 0+ 0 0 0-1 66 Tunnel-Client-Endpoint
0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint
0 0+ 0 0 0 69 Tunnel-Password
0+ 0+ 0 0 0-1 81 Tunnel-Private-Group-ID
0 0+ 0 0 0-1 82 Tunnel-Assignment-ID
0+ 0+ 0 0 0 83 Tunnel-Preference
0+ 0+ 0 0 0-1 90 Tunnel-Client-Auth-ID
0+ 0+ 0 0 0-1 91 Tunnel-Server-Auth-ID
The following table defines the meaning of the above table entries.
下表定义了上述表格条目的含义。
0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet.
0此属性不能出现在数据包中。数据包中可能存在0+零个或多个此属性的实例。0-1数据包中可能存在该属性的零个或一个实例。
The Tunnel-Password Attribute may contain information which should only be known to a tunnel endpoint. However, the method used to hide the value of the attribute is such that intervening RADIUS proxies will have knowledge of the contents. For this reason, the Tunnel-Password Attribute SHOULD NOT be included in Access-Accept packets which may pass through (relatively) untrusted RADIUS proxies. In addition, the Tunnel-Password Attribute SHOULD NOT be returned to an unauthenticated client; if the corresponding Access-Request packet did not contain a verified instance of the Signature Attribute [15], the Access-Accept packet SHOULD NOT contain an instance of the Tunnel-Password Attribute.
隧道密码属性可能包含只有隧道端点才知道的信息。但是，用于隐藏属性值的方法是，中间的半径代理将知道内容。因此，隧道密码属性不应包含在可能通过（相对）不受信任的RADIUS代理的访问接受数据包中。此外，隧道密码属性不应返回给未经验证的客户端；如果相应的访问请求数据包不包含签名属性[15]的已验证实例，则访问接受数据包不应包含隧道密码属性的实例。
Tunnel protocols offer various levels of security, from none (e.g., PPTP) to strong (e.g., IPSec). Note, however, that in the compulsory tunneling case any security measures in place only apply to traffic between the tunnel endpoints. In particular, end-users SHOULD NOT rely upon the security of the tunnel to protect their data; encryption and/or integrity protection of tunneled traffic MUST NOT be considered as a replacement for end-to-end security.
隧道协议提供各种级别的安全性，从无（如PPTP）到强（如IPSec）。但是，请注意，在强制隧道情况下，任何安全措施仅适用于隧道端点之间的交通。特别是，终端用户不应依赖隧道的安全性来保护其数据；不得将隧道传输的加密和/或完整性保护视为端到端安全的替代。
This document defines a number of "magic" numbers to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists. The following subsections describe the assignment policy for the namespaces defined elsewhere in this document.
本文件定义了IANA需要维护的一些“神奇”数字。本节解释IANA在每个列表中分配额外编号时使用的标准。以下小节描述了本文档其他地方定义的命名空间的分配策略。
Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1; the remaining values are available for assignment by the IANA with IETF Consensus [16].
隧道类型属性的值1-12在第5.1节中定义；剩余值可由IANA与IETF协商一致分配[16]。
Values 1-15 of the Tunnel-Medium-Type Attribute are defined in Section 5.2; the remaining values are available for assignment by the IANA with IETF Consensus [16].
隧道介质类型属性的值1-15在第5.2节中定义；剩余值可由IANA与IETF协商一致分配[16]。
[1] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[1] Hamzeh，K.，Pall，G.，Verthein，W.，Taarud，J.，Little，W.和G.Zorn，“点对点隧道协议（PPTP）”，RFC 2637，1999年7月。
[2] Valencia, A., Littlewood, M. and T. Kolar, T., "Cisco Layer Two Forwarding (Protocol) 'L2F'", RFC 2341, May 1998.
[2] Valencia，A.，Littlewood，M.和T.Kolar，T.，“思科第二层转发（协议）‘L2F’”，RFC 23411998年5月。
[3] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunnelling Protocol (L2TP)", RFC 2661, August 1999.
[3] 汤斯利，W.，巴伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.和B.帕尔特，“第二层隧道协议（L2TP）”，RFC 26611999年8月。
[4] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, February 1997.
[4] Hamzeh，K.，“上升隧道管理协议-ATMP”，RFC 2107，1997年2月。
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[6] Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[7] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[7] Perkins，C.，“IP内的最小封装”，RFC 2004，1996年10月。
[8] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.
[8] 阿特金森，R.，“IP封装安全有效载荷（ESP）”，RFC 1827，1995年8月。
[9] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[9] Hanks，S.，Li，T.，Farinaci，D.和P.Traina，“通用路由封装（GRE）”，RFC 17011994年10月。
[10] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[10] 辛普森，W.，“IP隧道中的IP”，RFC 1853，1995年10月。
[11] Zorn, G. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[11] Zorn，G.和D.Mitton，“隧道协议支持的半径计算修改”，RFC 28672000年6月。
[12] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial in User Service (RADIUS)", RFC 2865, June 2000.
[12] Rigney，C.，Willens，S.，Rubens，A.和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[13] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[14] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[14] Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[15] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[15] 里格尼，C.，威拉斯，W.和P.卡尔霍恩，“半径延伸”，RFC 28692000年6月。
[16] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[16] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[17] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[17] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
Thanks to Dave Mitton for pointing out a nasty circular dependency in the original Tunnel-Password attribute definition and (in no particular order) to Kory Hamzeh, Bertrand Buclin, Andy Valencia, Bill Westfield, Kris Michielsen, Gurdeep Singh Pall, Ran Atkinson, Aydin Edguer, and Bernard Aboba for useful input and review.
感谢Dave Mitton指出原始隧道密码属性定义中存在令人讨厌的循环依赖，并感谢Kory Hamzeh、Bertrand Buclin、Andy Valencia、Bill Westfield、Kris Michielsen、Gurdeep Singh Pall、Atkinson、Aydin Edguer和Bernard Aboba（无特殊顺序）提供有用的输入和评论。
The RADIUS Working Group can be contacted via the current chair:
可通过现任主席联系RADIUS工作组：
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
加利福尼亚州普莱森顿市柳树路4464号卡尔·里格尼·利文斯顿企业，邮编94588
Phone: +1 510 426 0770
EMail: cdr@livingston.com
Phone: +1 510 426 0770
EMail: cdr@livingston.com
Questions about this memo can also be directed to:
有关本备忘录的问题，请联系：
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, Washington 98004 USA
格伦佐恩思科系统有限公司，地址：美国华盛顿州贝尔维尤第108大道500号500室，邮编：98004
Phone: +1 425 438 8218
FAX: +1 425 438 1848
EMail: gwz@cisco.com
Phone: +1 425 438 8218
FAX: +1 425 438 1848
EMail: gwz@cisco.com
Dory Leifer Ascend Communications 1678 Broadway Ann Arbor, MI 48105
多莉·莱弗·阿森通讯1678百老汇安娜堡，密歇根州48105
Phone: +1 734 747 6152
EMail: leifer@del.com
Phone: +1 734 747 6152
EMail: leifer@del.com
John Shriver Intel Corporation 28 Crosby Drive Bedford, MA 01730
约翰·施莱弗英特尔公司马萨诸塞州贝德福德克罗斯比大道28号01730
Phone: +1 781 687 1329
EMail: John.Shriver@intel.com
Phone: +1 781 687 1329
EMail: John.Shriver@intel.com
Allan Rubens Ascend Communications 1678 Broadway Ann Arbor, MI 48105
艾伦·鲁本斯·阿森通讯1678百老汇安娜堡，密歇根州48105
Phone: +1 313 761 6025
EMail: acr@del.com
Phone: +1 313 761 6025
EMail: acr@del.com
Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
Matt Holdrege ipVerse加利福尼亚州长滩西门诺大道223号，邮编90803
EMail: matt@ipverse.com
EMail: matt@ipverse.com
Ignacio Goyret Lucent Technologies One Ascend Plaza 1701 Harbor Bay Parkway Alameda, CA 94502
伊格纳西奥·戈雷特·朗讯科技一期Ascend广场1701号加利福尼亚州阿拉米达港湾公园路94502
Phone: +1 510 769 6001
EMail: igoyret@lucent.com
Phone: +1 510 769 6001
EMail: igoyret@lucent.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。