Network Working Group M. Chiba
Request for Comments: 3576 G. Dommety
Category: Informational M. Eklund
Cisco Systems, Inc.
D. Mitton
Circular Logic, UnLtd.
B. Aboba
Microsoft Corporation
July 2003
Network Working Group M. Chiba
Request for Comments: 3576 G. Dommety
Category: Informational M. Eklund
Cisco Systems, Inc.
D. Mitton
Circular Logic, UnLtd.
B. Aboba
Microsoft Corporation
July 2003
Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
远程身份验证拨入用户服务（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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session.
本文档描述了当前部署的远程身份验证拨入用户服务（RADIUS）协议的扩展，它允许动态更改用户会话，如网络访问服务器产品所实现的那样。这包括支持断开用户连接和更改适用于用户会话的授权。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . 5
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Disconnect Messages (DM) . . . . . . . . . . . . . . . . 5
2.2. Change-of-Authorization Messages (CoA) . . . . . . . . . 6
2.3. Packet Format. . . . . . . . . . . . . . . . . . . . . . 7
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Error-Cause. . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Table of Attributes. . . . . . . . . . . . . . . . . . . 16
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 21
5.1. Authorization Issues . . . . . . . . . . . . . . . . . . 21
5.2. Impersonation. . . . . . . . . . . . . . . . . . . . . . 22
5.3. IPsec Usage Guidelines . . . . . . . . . . . . . . . . . 22
5.4. Replay Protection. . . . . . . . . . . . . . . . . . . . 25
6. Example Traces . . . . . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . 27
8. Intellectual Property Statement. . . . . . . . . . . . . . . . 28
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 28
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . 5
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Disconnect Messages (DM) . . . . . . . . . . . . . . . . 5
2.2. Change-of-Authorization Messages (CoA) . . . . . . . . . 6
2.3. Packet Format. . . . . . . . . . . . . . . . . . . . . . 7
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Error-Cause. . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Table of Attributes. . . . . . . . . . . . . . . . . . . 16
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 21
5.1. Authorization Issues . . . . . . . . . . . . . . . . . . 21
5.2. Impersonation. . . . . . . . . . . . . . . . . . . . . . 22
5.3. IPsec Usage Guidelines . . . . . . . . . . . . . . . . . 22
5.4. Replay Protection. . . . . . . . . . . . . . . . . . . . 25
6. Example Traces . . . . . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . 27
8. Intellectual Property Statement. . . . . . . . . . . . . . . . 28
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 28
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
The RADIUS protocol, defined in [RFC2865], does not support unsolicited messages sent from the RADIUS server to the Network Access Server (NAS).
[RFC2865]中定义的RADIUS协议不支持从RADIUS服务器发送到网络访问服务器（NAS）的未经请求的消息。
However, there are many instances in which it is desirable for changes to be made to session characteristics, without requiring the NAS to initiate the exchange. For example, it may be desirable for administrators to be able to terminate a user session in progress. Alternatively, if the user changes authorization level, this may require that authorization attributes be added/deleted from a user session.
但是，在许多情况下，需要对会话特性进行更改，而不需要NAS启动交换。例如，管理员可能希望能够终止正在进行的用户会话。或者，如果用户更改授权级别，这可能需要在用户会话中添加/删除授权属性。
To overcome these limitations, several vendors have implemented additional RADIUS commands in order to be able to support unsolicited messages sent from the RADIUS server to the NAS. These extended commands provide support for Disconnect and Change-of-Authorization (CoA) messages. Disconnect messages cause a user session to be terminated immediately, whereas CoA messages modify session authorization attributes such as data filters.
为了克服这些限制，一些供应商实施了额外的RADIUS命令，以便能够支持从RADIUS服务器发送到NAS的未经请求的消息。这些扩展命令支持断开和更改授权（CoA）消息。断开连接消息会导致用户会话立即终止，而CoA消息会修改会话授权属性，如数据筛选器。
This protocol is being recommended for publication as an Informational RFC rather than as a standards-track RFC because of problems that cannot be fixed without creating incompatibilities with deployed implementations. This includes security vulnerabilities, as well as semantic ambiguities resulting from the design of the Change-of-Authorization (CoA) commands. While fixes are recommended, they cannot be made mandatory since this would be incompatible with existing implementations.
建议将此协议作为信息RFC而不是标准跟踪RFC发布，因为如果不创建与已部署实现的不兼容性，就无法修复这些问题。这包括安全漏洞，以及由于设计授权变更（CoA）命令而导致的语义歧义。虽然建议进行修复，但不能强制进行修复，因为这与现有实现不兼容。
Existing implementations of this protocol do not support authorization checks, so that an ISP sharing a NAS with another ISP could disconnect or change authorizations for another ISP's users. In order to remedy this problem, a "Reverse Path Forwarding" check is recommended. See Section 5.1. for details.
此协议的现有实现不支持授权检查，因此与其他ISP共享NAS的ISP可以断开或更改其他ISP用户的授权。为了解决此问题，建议进行“反向路径转发”检查。见第5.1节。详情请参阅。
Existing implementations utilize per-packet authentication and integrity protection algorithms with known weaknesses [MD5Attack]. To provide stronger per-packet authentication and integrity protection, the use of IPsec is recommended. See Section 5.3. for details.
现有的实现利用每个包的身份验证和完整性保护算法，这些算法具有已知的弱点[MD5Attack]。为了提供更强的每包身份验证和完整性保护，建议使用IPsec。见第5.3节。详情请参阅。
Existing implementations lack replay protection. In order to support replay detection, it is recommended that the Event-Timestamp Attribute be added to all messages in situations where IPsec replay protection is not employed. Implementations should be configurable to silently discard messages lacking the Event-Timestamp Attribute. See Section 5.4. for details.
现有的实现缺乏重播保护。为了支持重播检测，建议在未采用IPsec重播保护的情况下，将事件时间戳属性添加到所有消息中。实现应该可以配置为以静默方式丢弃缺少事件时间戳属性的消息。见第5.4节。详情请参阅。
The approach taken with CoA commands in existing implementations results in a semantic ambiguity. Existing implementations of the CoA-Request identify the affected session, as well as supply the authorization changes. Since RADIUS Attributes included within existing implementations of the CoA-Request can be used for session identification or authorization change, it may not be clear which function a given attribute is serving.
现有实现中使用CoA命令的方法会导致语义歧义。CoA请求的现有实现识别受影响的会话，并提供授权更改。由于CoA请求的现有实现中包含的RADIUS属性可用于会话标识或授权更改，因此可能不清楚给定属性服务于哪个功能。
The problem does not exist within [Diameter], in which authorization change is requested by a command using Attribute Value Pairs (AVPs) solely for identification, resulting in initiation of a standard Request/Response sequence where authorization changes are supplied. As a result, in no command can Diameter AVPs have multiple potential meanings.
在[Diameter]中不存在此问题，在[Diameter]中，授权更改是由仅用于标识的属性值对（AVP）命令请求的，导致在提供授权更改的情况下启动标准请求/响应序列。因此，在任何命令中，Diameter AVP都不能具有多个潜在含义。
Due to differences in handling change-of-authorization requests in RADIUS and Diameter, it may be difficult or impossible for a Diameter/RADIUS gateway to successfully translate existing implementations of this specification to equivalent messages in Diameter. For example, a Diameter command changing any attribute used for identification within existing CoA-Request implementations cannot be translated, since such an authorization change is impossible to carry out in existing implementations. Similarly, translation between existing implementations of Disconnect-Request or CoA-Request messages and Diameter is tricky because a Disconnect-Request or CoA-Request message will need to be translated to multiple Diameter commands.
由于在处理RADIUS和Diameter中的授权请求更改方面存在差异，Diameter/RADIUS网关可能难以或不可能成功地将本规范的现有实现转换为Diameter中的等效消息。例如，在现有CoA请求实现中更改用于标识的任何属性的Diameter命令无法转换，因为在现有实现中不可能执行此类授权更改。类似地，断开连接请求或CoA请求消息的现有实现与Diameter之间的转换非常复杂，因为断开连接请求或CoA请求消息需要转换为多个Diameter命令。
To simplify translation between RADIUS and Diameter, a Service-Type Attribute with value "Authorize Only" can (optionally) be included within a Disconnect-Request or CoA-Request. Such a Request contains only identification attributes. A NAS supporting the "Authorize Only" Service-Type within a Disconnect-Request or CoA-Request responds with a NAK containing a Service-Type Attribute with value "Authorize Only" and an Error-Cause Attribute with value "Request Initiated". The NAS will then send an Access-Request containing a Service-Type Attribute with a value of "Authorize Only". This usage sequence is akin to what occurs in Diameter and so is more easily translated by a Diameter/RADIUS gateway.
为了简化半径和直径之间的转换，可以（可选地）在断开连接请求或CoA请求中包含值为“仅授权”的服务类型属性。这样的请求只包含标识属性。在断开连接请求或CoA请求中支持“仅授权”服务类型的NAS使用NAK进行响应，NAK包含值为“仅授权”的服务类型属性和值为“请求已启动”的错误原因属性。NAS随后将发送一个访问请求，该请求包含一个值为“仅授权”的服务类型属性。此使用顺序与Diameter中的使用顺序相似，因此更容易通过Diameter/RADIUS网关进行转换。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]中所述进行解释。
This document frequently uses the following terms:
本文件经常使用以下术语：
Network Access Server (NAS): The device providing access to the network.
网络访问服务器（NAS）：提供网络访问的设备。
service: The NAS provides a service to the user, such as IEEE 802 or PPP.
服务：NAS向用户提供服务，如IEEE 802或PPP。
session: Each service provided by the NAS to a user constitutes a session, with the beginning of the session defined as the point where service is first provided and the end of the session defined as the point where service is ended. A user may have multiple sessions in parallel or series if the NAS supports that.
会话：NAS向用户提供的每个服务都构成一个会话，会话的开始定义为首次提供服务的点，会话的结束定义为服务的结束点。如果NAS支持，则用户可以并行或串联多个会话。
silently discard: This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.
静默丢弃：这意味着实现在不进行进一步处理的情况下丢弃数据包。实现应该提供记录错误的能力，包括静默丢弃的数据包的内容，并且应该在统计计数器中记录事件。
This section describes the most commonly implemented features of Disconnect and Change-of-Authorization messages.
本节介绍断开连接和更改授权消息的最常用功能。
A Disconnect-Request packet is sent by the RADIUS server in order to terminate a user session on a NAS and discard all associated session context. The Disconnect-Request packet is sent to UDP port 3799, and identifies the NAS as well as the user session to be terminated by inclusion of the identification attributes described in Section 3.
RADIUS服务器发送断开连接请求数据包，以终止NAS上的用户会话并丢弃所有相关会话上下文。断开连接请求数据包被发送到UDP端口3799，并通过包含第3节中描述的标识属性来标识NAS以及要终止的用户会话。
+----------+ Disconnect-Request +----------+
| | <-------------------- | |
| NAS | | RADIUS |
| | Disconnect-Response | Server |
| | ---------------------> | |
+----------+ +----------+
+----------+ Disconnect-Request +----------+
| | <-------------------- | |
| NAS | | RADIUS |
| | Disconnect-Response | Server |
| | ---------------------> | |
+----------+ +----------+
The NAS responds to a Disconnect-Request packet sent by a RADIUS server with a Disconnect-ACK if all associated session context is discarded and the user session is no longer connected, or a Disconnect-NAK, if the NAS was unable to disconnect the session and discard all associated session context. A NAS MUST respond to a Disconnect-Request including a Service-Type Attribute with value "Authorize Only" with a Disconnect-NAK; a Disconnect-ACK MUST NOT be sent. A NAS MUST respond to a Disconnect-Request including a Service-Type Attribute with an unsupported value with a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be included. A Disconnect-ACK MAY contain the Attribute Acct-Terminate-Cause (49) [RFC2866] with the value set to 6 for Admin-Reset.
如果放弃所有相关会话上下文且用户会话不再连接，NAS将使用断开确认响应RADIUS服务器发送的断开连接请求数据包；如果NAS无法断开会话并放弃所有相关会话上下文，NAS将使用断开连接NAK响应断开连接请求数据包。NAS必须使用断开连接NAK响应包括值为“仅授权”的服务类型属性的断开连接请求；不得发送断开连接确认。NAS必须使用Disconnect NAK响应断开连接请求，该请求包括具有不支持值的服务类型属性；可能包含值为“Unsupported Service”的错误原因属性。断开连接确认可能包含属性Acct Terminate Cause（49）[RFC2866]，其值设置为6以进行管理重置。
CoA-Request packets contain information for dynamically changing session authorizations. This is typically used to change data filters. The data filters can be of either the ingress or egress kind, and are sent in addition to the identification attributes as described in section 3. The port used, and packet format (described in Section 2.3.), are the same as that for Disconnect-Request Messages.
CoA请求数据包包含动态更改会话授权的信息。这通常用于更改数据过滤器。数据过滤器可以是入口或出口类型，并且除了第3节中描述的标识属性之外，还发送数据过滤器。所使用的端口和数据包格式（如第2.3节所述）与断开连接请求消息的端口和数据包格式相同。
The following attribute MAY be sent in a CoA-Request:
以下属性可在CoA请求中发送：
Filter-ID (11) - Indicates the name of a data filter list to be applied for the session that the identification attributes map to.
筛选器ID（11）-表示要应用于标识属性映射到的会话的数据筛选器列表的名称。
+----------+ CoA-Request +----------+
| | <-------------------- | |
| NAS | | RADIUS |
| | CoA-Response | Server |
| | ---------------------> | |
+----------+ +----------+
+----------+ CoA-Request +----------+
| | <-------------------- | |
| NAS | | RADIUS |
| | CoA-Response | Server |
| | ---------------------> | |
+----------+ +----------+
The NAS responds to a CoA-Request sent by a RADIUS server with a CoA-ACK if the NAS is able to successfully change the authorizations for the user session, or a CoA-NAK if the Request is unsuccessful. A NAS MUST respond to a CoA-Request including a Service-Type Attribute
如果NAS能够成功更改用户会话的授权，NAS将使用CoA ACK响应RADIUS服务器发送的CoA请求；如果请求失败，NAS将使用CoA NAK响应。NAS必须响应包含服务类型属性的CoA请求
with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be sent. A NAS MUST respond to a CoA-Request including a Service-Type Attribute with an unsupported value with a CoA-NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be included.
带有CoA NAK的值“仅授权”；不得发送CoA确认。NAS必须使用CoA NAK响应CoA请求，该请求包括具有不支持值的服务类型属性；可能包含值为“Unsupported Service”的错误原因属性。
For either Disconnect-Request or CoA-Request messages UDP port 3799 is used as the destination port. For responses, the source and destination ports are reversed. Exactly one RADIUS packet is encapsulated in the UDP Data field.
对于断开连接请求或CoA请求消息，UDP端口3799用作目标端口。对于响应，源端口和目标端口是反向的。UDP数据字段中只封装了一个RADIUS数据包。
A summary of the data format is shown below. The fields are transmitted from left to right.
数据格式摘要如下所示。字段从左向右传输。
The packet format consists of the fields: Code, Identifier, Length, Authenticator, and Attributes in Type:Length:Value (TLV) format. All fields hold the same meaning as those described in RADIUS [RFC2865]. The Authenticator field MUST be calculated in the same way as is specified for an Accounting-Request in [RFC2866].
数据包格式由以下字段组成：代码、标识符、长度、验证器和类型为：长度：值（TLV）格式的属性。所有字段的含义与RADIUS[RFC2865]中所述的相同。验证器字段的计算方法必须与[RFC2866]中为记帐请求指定的方法相同。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
密码
The Code field is one octet, and identifies the type of RADIUS packet. Packets received with an invalid Code field MUST be silently discarded. RADIUS codes (decimal) for this extension are assigned as follows:
代码字段是一个八位字节，用于标识RADIUS数据包的类型。接收到的带有无效代码字段的数据包必须以静默方式丢弃。此扩展的半径代码（十进制）分配如下：
40 - Disconnect-Request [RFC2882]
41 - Disconnect-ACK [RFC2882]
42 - Disconnect-NAK [RFC2882]
43 - CoA-Request [RFC2882]
44 - CoA-ACK [RFC2882]
45 - CoA-NAK [RFC2882]
40 - Disconnect-Request [RFC2882]
41 - Disconnect-ACK [RFC2882]
42 - Disconnect-NAK [RFC2882]
43 - CoA-Request [RFC2882]
44 - CoA-ACK [RFC2882]
45 - CoA-NAK [RFC2882]
Identifier
标识符
The Identifier field is one octet, and aids in matching requests and replies. The RADIUS client can detect a duplicate request if it has the same server source IP address and source UDP port and Identifier within a short span of time.
标识符字段是一个八位字节，有助于匹配请求和响应。如果RADIUS客户端在短时间内具有相同的服务器源IP地址、源UDP端口和标识符，则它可以检测到重复请求。
Unlike RADIUS as defined in [RFC2865], the responsibility for retransmission of Disconnect-Request and CoA-Request messages lies with the RADIUS server. If after sending these messages, the RADIUS server does not receive a response, it will retransmit.
与[RFC2865]中定义的RADIUS不同，断开连接请求和CoA请求消息的重新传输由RADIUS服务器负责。如果在发送这些消息后，RADIUS服务器没有收到响应，它将重新传输。
The Identifier field MUST be changed whenever the content of the Attributes field changes, or whenever a valid reply has been received for a previous request. For retransmissions where the contents are identical, the Identifier MUST remain unchanged.
每当Attributes字段的内容更改时，或者每当收到前一个请求的有效答复时，都必须更改Identifier字段。对于内容相同的重传，标识符必须保持不变。
If the RADIUS server is retransmitting a Disconnect-Request or CoA-Request to the same client as before, and the Attributes have not changed, the same Request Authenticator, Identifier and source port MUST be used. If any Attributes have changed, a new Authenticator and Identifier MUST be used.
如果RADIUS服务器与以前一样将断开连接请求或CoA请求重新传输到同一客户端，并且属性没有更改，则必须使用相同的请求验证器、标识符和源端口。如果任何属性已更改，则必须使用新的验证器和标识符。
Note that if the Event-Timestamp Attribute is included, it will be updated when the packet is retransmitted, changing the content of the Attributes field and requiring a new Identifier and Request Authenticator.
请注意，如果包含事件时间戳属性，则在重新传输数据包时将更新该属性，从而更改属性字段的内容，并需要新的标识符和请求验证器。
If the Request to a primary proxy fails, a secondary proxy must be queried, if available. Issues relating to failover algorithms are described in [AAATransport]. Since this represents a new request, a new Request Authenticator and Identifier MUST be used. However, where the RADIUS server is sending directly to the client, failover typically does not make sense, since Disconnect or CoA messages need to be delivered to the NAS where the session resides.
如果对主代理的请求失败，则必须查询辅助代理（如果可用）。[AAATransport]中描述了与故障转移算法相关的问题。因为这表示一个新的请求，所以必须使用一个新的请求验证器和标识符。但是，在RADIUS服务器直接发送到客户端的情况下，故障切换通常没有意义，因为需要将断开连接或CoA消息传递到会话所在的NAS。
Length
长
The Length field is two octets. It indicates the length of the packet including the Code, Identifier, Length, Authenticator and Attribute fields. Octets outside the range of the Length field MUST be treated as padding and ignored on reception. If the packet is shorter than the Length field indicates, it MUST be silently discarded. The minimum length is 20 and the maximum length is 4096.
长度字段是两个八位字节。它指示数据包的长度，包括代码、标识符、长度、验证器和属性字段。长度字段范围之外的八位字节必须视为填充，并在接收时忽略。如果数据包短于长度字段指示的长度，则必须以静默方式将其丢弃。最小长度为20，最大长度为4096。
Authenticator
验证者
The Authenticator field is sixteen (16) octets. The most significant octet is transmitted first. This value is used to authenticate the messages between the RADIUS server and client.
验证器字段为十六（16）个八位字节。最重要的八位字节首先传输。此值用于验证RADIUS服务器和客户端之间的消息。
Request Authenticator
请求验证器
In Request packets, the Authenticator value is a 16 octet MD5 [RFC1321] checksum, called the Request Authenticator. The Request Authenticator is calculated the same way as for an Accounting-Request, specified in [RFC2866].
在请求数据包中，验证器值是16个八位MD5[RFC1321]校验和，称为请求验证器。请求验证器的计算方法与[RFC2866]中规定的记帐请求的计算方法相同。
Note that the Request Authenticator of a Disconnect or CoA-Request cannot be done the same way as the Request Authenticator of a RADIUS Access-Request, because there is no User-Password Attribute in a Disconnect-Request or CoA-Request.
请注意，断开连接或CoA请求的请求验证器不能与RADIUS访问请求的请求验证器相同，因为断开连接请求或CoA请求中没有用户密码属性。
Response Authenticator
响应验证器
The Authenticator field in a Response packet (e.g. Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response Authenticator, and contains a one-way MD5 hash calculated over a stream of octets consisting of the Code, Identifier, Length, the Request Authenticator field from the packet being replied to, and the response Attributes if any, followed by the shared secret. The resulting 16 octet MD5 hash value is stored in the Authenticator field of the Response packet.
响应包（例如，断开ACK、断开NAK、CoA ACK或CoA NAK）中的认证器字段称为响应认证器，并包含在八位字节流上计算的单向MD5哈希，八位字节流包括代码、标识符、长度、来自被响应包的请求认证器字段，以及响应属性（如果有），后跟共享机密。得到的16个八位组MD5散列值存储在响应数据包的验证器字段中。
Administrative note: As noted in [RFC2865] Section 3, the secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well-chosen password. RADIUS clients MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that requests can be proxied.
管理说明：如[RFC2865]第3节所述，密码（客户端和RADIUS服务器之间共享的密码）应至少与精心选择的密码一样大且不可用。RADIUS客户端必须使用RADIUS UDP数据包的源IP地址来决定使用哪个共享密钥，以便可以代理请求。
Attributes
属性
In Disconnect and CoA-Request messages, all Attributes are treated as mandatory. A NAS MUST respond to a CoA-Request containing one or more unsupported Attributes or Attribute values with a CoA-NAK; a Disconnect-Request containing one or more unsupported Attributes or Attribute values MUST be answered with a Disconnect-NAK. State changes resulting from a CoA-Request MUST be atomic: if the Request is successful, a CoA-ACK is sent, and all requested authorization changes MUST be made. If the CoA-Request is unsuccessful, a CoA-NAK MUST be sent, and the requested
在Disconnect和CoA请求消息中，所有属性都被视为强制属性。NAS必须使用CoA NAK响应包含一个或多个不受支持的属性或属性值的CoA请求；包含一个或多个不受支持的属性或属性值的断开连接请求必须使用断开连接NAK进行响应。CoA请求导致的状态更改必须是原子的：如果请求成功，则发送CoA ACK，并且必须进行所有请求的授权更改。如果CoA请求不成功，则必须发送CoA NAK，并且请求的
authorization changes MUST NOT be made. Similarly, a state change MUST NOT occur as a result of an unsuccessful Disconnect-Request; here a Disconnect-NAK MUST be sent.
不得进行授权更改。类似地，状态更改不得因断开连接请求失败而发生；这里必须发送断开连接NAK。
Since within this specification attributes may be used for identification, authorization or other purposes, even if a NAS implements an attribute for use with RADIUS authentication and accounting, it may not support inclusion of that attribute within Disconnect-Request or CoA-Request messages, given the difference in attribute semantics. This is true even for attributes specified within [RFC2865], [RFC2868], [RFC2869] or [RFC3162] as allowable within Access-Accept messages.
由于在本规范中，属性可用于标识、授权或其他目的，即使NAS实现了用于RADIUS身份验证和记帐的属性，鉴于属性语义的差异，它可能不支持在断开连接请求或CoA请求消息中包含该属性。即使对于[RFC2865]、[RFC2868]、[RFC2869]或[RFC3162]中指定的访问接受消息中允许的属性，也是如此。
As a result, attributes beyond those specified in Section 3.2. SHOULD NOT be included within Disconnect or CoA messages since this could produce unpredictable results.
因此，超出第3.2节规定的属性。不应包含在断开连接或CoA消息中，因为这可能会产生不可预测的结果。
When using a forwarding proxy, the proxy must be able to alter the packet as it passes through in each direction. When the proxy forwards a Disconnect or CoA-Request, it MAY add a Proxy-State Attribute, and when the proxy forwards a response, it MUST remove its Proxy-State Attribute if it added one. Proxy-State is always added or removed after any other Proxy-States, but no other assumptions regarding its location within the list of Attributes can be made. Since Disconnect and CoA responses are authenticated on the entire packet contents, the stripping of the Proxy-State Attribute invalidates the integrity check - so the proxy needs to recompute it. A forwarding proxy MUST NOT modify existing Proxy-State, State, or Class Attributes present in the packet.
当使用转发代理时，代理必须能够在数据包沿每个方向通过时更改数据包。当代理转发断开连接或CoA请求时，它可能会添加代理状态属性；当代理转发响应时，如果添加了代理状态属性，则必须删除其代理状态属性。代理状态总是在任何其他代理状态之后添加或删除，但不能对其在属性列表中的位置进行其他假设。由于Disconnect和CoA响应是在整个数据包内容上进行身份验证的，代理状态属性的剥离会使完整性检查无效-因此代理需要重新计算它。转发代理不能修改数据包中现有的代理状态、状态或类属性。
If there are any Proxy-State Attributes in a Disconnect-Request or CoA-Request received from the server, the forwarding proxy MUST include those Proxy-State Attributes in its response to the server. The forwarding proxy MAY include the Proxy-State Attributes in the Disconnect-Request or CoA-Request when it forwards the request, or it MAY omit them in the forwarded request. If the forwarding proxy omits the Proxy-State Attributes in the request, it MUST attach them to the response before sending it to the server.
如果从服务器接收的断开连接请求或CoA请求中存在任何代理状态属性，则转发代理必须在其对服务器的响应中包含这些代理状态属性。转发代理可以在转发请求时在断开连接请求或CoA请求中包括代理状态属性，或者在转发请求中省略它们。如果转发代理在请求中忽略了代理状态属性，则必须在将其发送到服务器之前将其附加到响应。
In Disconnect-Request and CoA-Request packets, certain attributes are used to uniquely identify the NAS as well as a user session on the NAS. All NAS identification attributes included in a Request message MUST match in order for a Disconnect-Request or CoA-Request to be successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent. For session identification attributes, the User-Name and Acct-Session-Id Attributes, if included, MUST match in order for a Disconnect-Request or CoA-Request to be successful; other session identification attributes SHOULD match. Where a mismatch of session identification attributes is detected, a Disconnect-NAK or CoA-NAK SHOULD be sent. The ability to use NAS or session identification attributes to map to unique/multiple sessions is beyond the scope of this document. Identification attributes include NAS and session identification attributes, as described below.
在断开连接请求和CoA请求数据包中，某些属性用于唯一标识NAS以及NAS上的用户会话。请求消息中包含的所有NAS标识属性必须匹配，以便断开连接请求或CoA请求成功；否则，应发送断开NAK或CoA NAK。对于会话标识属性，用户名和Acct会话Id属性（如果包括）必须匹配，以便断开连接请求或CoA请求成功；其他会话标识属性应匹配。如果检测到会话标识属性不匹配，则应发送断开NAK或CoA NAK。使用NAS或会话标识属性映射到唯一/多个会话的能力超出了本文档的范围。标识属性包括NAS和会话标识属性，如下所述。
NAS identification attributes
NAS标识属性
Attribute # Reference Description
--------- --- --------- -----------
NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS.
NAS-Identifier 32 [RFC2865] String identifying the NAS.
NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.
Attribute # Reference Description
--------- --- --------- -----------
NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS.
NAS-Identifier 32 [RFC2865] String identifying the NAS.
NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.
Session identification attributes
会话标识属性
Attribute # Reference Description
--------- --- --------- -----------
User-Name 1 [RFC2865] The name of the user
associated with the session.
NAS-Port 5 [RFC2865] The port on which the
session is terminated.
Framed-IP-Address 8 [RFC2865] The IPv4 address associated
with the session.
Called-Station-Id 30 [RFC2865] The link address to which
the session is connected.
Calling-Station-Id 31 [RFC2865] The link address from which
the session is connected.
Acct-Session-Id 44 [RFC2866] The identifier uniquely
identifying the session
on the NAS.
Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
identifying related sessions.
NAS-Port-Type 61 [RFC2865] The type of port used.
NAS-Port-Id 87 [RFC2869] String identifying the port
where the session is.
Originating-Line-Info 94 [NASREQ] Provides information on the
characteristics of the line
from which a session
originated.
Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier
associated with the session;
always sent with
Framed-IPv6-Prefix.
Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated
with the session, always sent
with Framed-Interface-Id.
Attribute # Reference Description
--------- --- --------- -----------
User-Name 1 [RFC2865] The name of the user
associated with the session.
NAS-Port 5 [RFC2865] The port on which the
session is terminated.
Framed-IP-Address 8 [RFC2865] The IPv4 address associated
with the session.
Called-Station-Id 30 [RFC2865] The link address to which
the session is connected.
Calling-Station-Id 31 [RFC2865] The link address from which
the session is connected.
Acct-Session-Id 44 [RFC2866] The identifier uniquely
identifying the session
on the NAS.
Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
identifying related sessions.
NAS-Port-Type 61 [RFC2865] The type of port used.
NAS-Port-Id 87 [RFC2869] String identifying the port
where the session is.
Originating-Line-Info 94 [NASREQ] Provides information on the
characteristics of the line
from which a session
originated.
Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier
associated with the session;
always sent with
Framed-IPv6-Prefix.
Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated
with the session, always sent
with Framed-Interface-Id.
To address security concerns described in Section 5.1., the User-Name Attribute SHOULD be present in Disconnect-Request or CoA-Request packets; one or more additional session identification attributes MAY also be present. To address security concerns described in Section 5.2., one or more of the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present in Disconnect-Request or CoA-Request packets; the NAS-Identifier Attribute MAY be present in addition.
为了解决第5.1节中描述的安全问题，用户名属性应出现在断开连接请求或CoA请求数据包中；还可以存在一个或多个附加会话标识属性。为解决第5.2节所述的安全问题，断开连接请求或CoA请求数据包中应存在一个或多个NAS IP地址或NAS-IPv6-address属性；此外，还可能存在NAS标识符属性。
If one or more authorization changes specified in a CoA-Request cannot be carried out, or if one or more attributes or attribute-values is unsupported, a CoA-NAK MUST be sent. Similarly, if there are one or more unsupported attributes or attribute values in a Disconnect-Request, a Disconnect-NAK MUST be sent.
如果无法执行CoA请求中指定的一个或多个授权更改，或者如果一个或多个属性或属性值不受支持，则必须发送CoA NAK。类似地，如果断开连接请求中存在一个或多个不受支持的属性或属性值，则必须发送断开连接NAK。
Where a Service-Type Attribute with value "Authorize Only" is included within a CoA-Request or Disconnect-Request, attributes representing an authorization change MUST NOT be included; only identification attributes are permitted. If attributes other than NAS or session identification attributes are included in such a CoA-Request, implementations MUST send a CoA-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included. Similarly, if attributes other than NAS or session identification attributes are included in such a Disconnect-Request, implementations MUST send a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included.
如果CoA请求或断开连接请求中包含值为“仅授权”的服务类型属性，则表示授权更改的属性不得包括在内；仅允许标识属性。如果此类CoA请求中包括NAS或会话标识属性以外的属性，则实现必须发送CoA NAK；可能包含值为“Unsupported Attribute”的错误原因属性。类似地，如果在这种断开连接请求中包括除NAS或会话标识属性以外的属性，则实现必须发送断开连接NAK；可能包含值为“Unsupported Attribute”的错误原因属性。
Description
描述
It is possible that the NAS cannot honor Disconnect-Request or CoA-Request messages for some reason. The Error-Cause Attribute provides more detail on the cause of the problem. It MAY be included within Disconnect-ACK, Disconnect-NAK and CoA-NAK messages.
由于某种原因，NAS可能无法执行断开连接请求或CoA请求消息。“错误原因”属性提供了有关问题原因的更多详细信息。它可能包含在断开ACK、断开NAK和CoA NAK消息中。
A summary of the Error-Cause 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 | 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
101 for Error-Cause
101错误原因
Length
长
6
6.
Value
价值
The Value field is four octets, containing an integer specifying the cause of the error. Values 0-199 and 300-399 are reserved. Values 200-299 represent successful completion, so that these values may only be sent within Disconnect-ACK or CoA-ACK message and MUST NOT be sent within a Disconnect-NAK or CoA-NAK. Values
值字段是四个八位字节，包含一个指定错误原因的整数。保留值0-199和300-399。值200-299表示成功完成，因此这些值只能在断开连接ACK或CoA ACK消息内发送，不得在断开连接NAK或CoA NAK内发送。价值观
400-499 represent fatal errors committed by the RADIUS server, so that they MAY be sent within CoA-NAK or Disconnect-NAK messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. Values 500-599 represent fatal errors occurring on a NAS or RADIUS proxy, so that they MAY be sent within CoA-NAK and Disconnect-NAK messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. Error-Cause values SHOULD be logged by the RADIUS server. Error-Code values (expressed in decimal) include:
400-499表示RADIUS服务器犯下的致命错误，因此这些错误可以在CoA NAK或断开NAK消息中发送，而不能在CoA ACK或断开ACK消息中发送。值500-599表示NAS或RADIUS代理上发生的致命错误，因此它们可以在CoA NAK和DISCONT NAK消息中发送，而不能在CoA ACK或DISCONT ACK消息中发送。RADIUS服务器应记录错误原因值。错误代码值（以十进制表示）包括：
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
507 Request Initiated
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
507 Request Initiated
"Residual Session Context Removed" is sent in response to a Disconnect-Request if the user session is no longer active, but residual session context was found and successfully removed. This value is only sent within a Disconnect-ACK and MUST NOT be sent within a CoA-ACK, Disconnect-NAK or CoA-NAK.
如果用户会话不再处于活动状态，但找到并成功删除了剩余会话上下文，则发送“已删除剩余会话上下文”以响应断开连接请求。该值仅在断开连接确认内发送，不得在CoA确认、断开连接NAK或CoA NAK内发送。
"Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be sent by implementations of this specification.
“无效EAP数据包（忽略）”是一个非致命错误，本规范的实现不能发送该错误。
"Unsupported Attribute" is a fatal error sent if a Request contains an attribute (such as a Vendor-Specific or EAP-Message Attribute) that is not supported.
如果请求包含不受支持的属性（例如特定于供应商的属性或EAP消息属性），则“Unsupported Attribute”（不支持的属性）是发送的致命错误。
"Missing Attribute" is a fatal error sent if critical attributes (such as NAS or session identification attributes) are missing from a Request.
如果请求中缺少关键属性（如NAS或会话标识属性），则“缺少属性”是发送的致命错误。
"NAS Identification Mismatch" is a fatal error sent if one or more NAS identification attributes (see Section 3.) do not match the identity of the NAS receiving the Request.
如果一个或多个NAS标识属性（参见第3节）与接收请求的NAS的标识不匹配，“NAS标识不匹配”是一个致命错误。
"Invalid Request" is a fatal error sent if some other aspect of the Request is invalid, such as if one or more attributes (such as EAP-Message Attribute(s)) are not formatted properly.
如果请求的某些其他方面无效，例如一个或多个属性（如EAP消息属性）未正确格式化，则“无效请求”是发送的致命错误。
"Unsupported Service" is a fatal error sent if a Service-Type Attribute included with the Request is sent with an invalid or unsupported value.
如果使用无效或不支持的值发送请求中包含的服务类型属性，则“不支持的服务”是发送的致命错误。
"Unsupported Extension" is a fatal error sent due to lack of support for an extension such as Disconnect and/or CoA messages. This will typically be sent by a proxy receiving an ICMP port unreachable message after attempting to forward a Request to the NAS.
“Unsupported Extension”（不支持扩展）是由于缺少对扩展（如断开连接和/或CoA消息）的支持而发送的致命错误。这通常由代理发送，代理在尝试将请求转发到NAS后接收ICMP端口不可访问消息。
"Administratively Prohibited" is a fatal error sent if the NAS is configured to prohibit honoring of Request messages for the specified session.
如果NAS配置为禁止接受指定会话的请求消息，“管理禁止”是发送的致命错误。
"Request Not Routable" is a fatal error which MAY be sent by a RADIUS proxy and MUST NOT be sent by a NAS. It indicates that the RADIUS proxy was unable to determine how to route the Request to the NAS. For example, this can occur if the required entries are not present in the proxy's realm routing table.
“请求不可路由”是一个致命错误，可由RADIUS代理发送，不得由NAS发送。它表示RADIUS代理无法确定如何将请求路由到NAS。例如，如果代理的领域路由表中不存在所需的条目，则可能发生这种情况。
"Session Context Not Found" is a fatal error sent if the session context identified in the Request does not exist on the NAS.
如果NAS上不存在请求中标识的会话上下文，“找不到会话上下文”是发送的致命错误。
"Session Context Not Removable" is a fatal error sent in response to a Disconnect-Request if the NAS was able to locate the session context, but could not remove it for some reason. It MUST NOT be sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a Disconnect-NAK.
如果NAS能够找到会话上下文，但由于某种原因无法将其删除，则“会话上下文不可删除”是响应断开连接请求而发送的致命错误。它不能在CoA ACK、CoA NAK或DISCONT ACK内发送，只能在DISCONT NAK内发送。
"Other Proxy Processing Error" is a fatal error sent in response to a Request that could not be processed by a proxy, for reasons other than routing.
“其他代理处理错误”是响应代理无法处理的请求而发送的致命错误，原因不是路由。
"Resources Unavailable" is a fatal error sent when a Request could not be honored due to lack of available NAS resources (memory, non-volatile storage, etc.).
“资源不可用”是由于缺少可用NAS资源（内存、非易失性存储等）而无法满足请求时发送的致命错误。
"Request Initiated" is a fatal error sent in response to a Request including a Service-Type Attribute with a value of "Authorize Only". It indicates that the Disconnect-Request or CoA-Request has not been honored, but that a RADIUS Access-Request including a Service-Type Attribute with value "Authorize Only" is being sent to the RADIUS server.
“Request Initiated”是响应请求时发送的致命错误，该请求包含值为“Authorize Only”的服务类型属性。它表示未执行断开连接请求或CoA请求，但RADIUS访问请求（包括值为“仅授权”的服务类型属性）正在发送到RADIUS服务器。
The following table provides a guide to which attributes may be found in which packets, and in what quantity.
下表提供了在哪些数据包中可以找到哪些属性以及数量的指南。
Change-of-Authorization Messages
更改授权信息
Request ACK NAK # Attribute
0-1 0 0 1 User-Name [Note 1]
0-1 0 0 4 NAS-IP-Address [Note 1]
0-1 0 0 5 NAS-Port [Note 1]
0-1 0 0-1 6 Service-Type [Note 6]
0-1 0 0 7 Framed-Protocol [Note 3]
0-1 0 0 8 Framed-IP-Address [Note 1]
0-1 0 0 9 Framed-IP-Netmask [Note 3]
0-1 0 0 10 Framed-Routing [Note 3]
0+ 0 0 11 Filter-ID [Note 3]
0-1 0 0 12 Framed-MTU [Note 3]
0+ 0 0 13 Framed-Compression [Note 3]
0+ 0 0 14 Login-IP-Host [Note 3]
0-1 0 0 15 Login-Service [Note 3]
0-1 0 0 16 Login-TCP-Port [Note 3]
0+ 0 0 18 Reply-Message [Note 2]
0-1 0 0 19 Callback-Number [Note 3]
0-1 0 0 20 Callback-Id [Note 3]
0+ 0 0 22 Framed-Route [Note 3]
0-1 0 0 23 Framed-IPX-Network [Note 3]
0-1 0-1 0-1 24 State [Note 7]
0+ 0 0 25 Class [Note 3]
0+ 0 0 26 Vendor-Specific [Note 3]
0-1 0 0 27 Session-Timeout [Note 3]
0-1 0 0 28 Idle-Timeout [Note 3]
0-1 0 0 29 Termination-Action [Note 3]
0-1 0 0 30 Called-Station-Id [Note 1]
0-1 0 0 31 Calling-Station-Id [Note 1]
0-1 0 0 32 NAS-Identifier [Note 1]
0+ 0+ 0+ 33 Proxy-State
0-1 0 0 34 Login-LAT-Service [Note 3]
0-1 0 0 35 Login-LAT-Node [Note 3]
0-1 0 0 36 Login-LAT-Group [Note 3]
0-1 0 0 37 Framed-AppleTalk-Link [Note 3]
0+ 0 0 38 Framed-AppleTalk-Network [Note 3]
0-1 0 0 39 Framed-AppleTalk-Zone [Note 3]
0-1 0 0 44 Acct-Session-Id [Note 1]
0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
0-1 0-1 0-1 55 Event-Timestamp
0-1 0 0 61 NAS-Port-Type [Note 1]
Request ACK NAK # Attribute
Request ACK NAK # Attribute
0-1 0 0 1 User-Name [Note 1]
0-1 0 0 4 NAS-IP-Address [Note 1]
0-1 0 0 5 NAS-Port [Note 1]
0-1 0 0-1 6 Service-Type [Note 6]
0-1 0 0 7 Framed-Protocol [Note 3]
0-1 0 0 8 Framed-IP-Address [Note 1]
0-1 0 0 9 Framed-IP-Netmask [Note 3]
0-1 0 0 10 Framed-Routing [Note 3]
0+ 0 0 11 Filter-ID [Note 3]
0-1 0 0 12 Framed-MTU [Note 3]
0+ 0 0 13 Framed-Compression [Note 3]
0+ 0 0 14 Login-IP-Host [Note 3]
0-1 0 0 15 Login-Service [Note 3]
0-1 0 0 16 Login-TCP-Port [Note 3]
0+ 0 0 18 Reply-Message [Note 2]
0-1 0 0 19 Callback-Number [Note 3]
0-1 0 0 20 Callback-Id [Note 3]
0+ 0 0 22 Framed-Route [Note 3]
0-1 0 0 23 Framed-IPX-Network [Note 3]
0-1 0-1 0-1 24 State [Note 7]
0+ 0 0 25 Class [Note 3]
0+ 0 0 26 Vendor-Specific [Note 3]
0-1 0 0 27 Session-Timeout [Note 3]
0-1 0 0 28 Idle-Timeout [Note 3]
0-1 0 0 29 Termination-Action [Note 3]
0-1 0 0 30 Called-Station-Id [Note 1]
0-1 0 0 31 Calling-Station-Id [Note 1]
0-1 0 0 32 NAS-Identifier [Note 1]
0+ 0+ 0+ 33 Proxy-State
0-1 0 0 34 Login-LAT-Service [Note 3]
0-1 0 0 35 Login-LAT-Node [Note 3]
0-1 0 0 36 Login-LAT-Group [Note 3]
0-1 0 0 37 Framed-AppleTalk-Link [Note 3]
0+ 0 0 38 Framed-AppleTalk-Network [Note 3]
0-1 0 0 39 Framed-AppleTalk-Zone [Note 3]
0-1 0 0 44 Acct-Session-Id [Note 1]
0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
0-1 0-1 0-1 55 Event-Timestamp
0-1 0 0 61 NAS-Port-Type [Note 1]
Request ACK NAK # Attribute
Request ACK NAK # Attribute
0-1 0 0 62 Port-Limit [Note 3]
0-1 0 0 63 Login-LAT-Port [Note 3]
0+ 0 0 64 Tunnel-Type [Note 5]
0+ 0 0 65 Tunnel-Medium-Type [Note 5]
0+ 0 0 66 Tunnel-Client-Endpoint [Note 5]
0+ 0 0 67 Tunnel-Server-Endpoint [Note 5]
0+ 0 0 69 Tunnel-Password [Note 5]
0-1 0 0 71 ARAP-Features [Note 3]
0-1 0 0 72 ARAP-Zone-Access [Note 3]
0+ 0 0 78 Configuration-Token [Note 3]
0+ 0-1 0 79 EAP-Message [Note 2]
0-1 0-1 0-1 80 Message-Authenticator
0+ 0 0 81 Tunnel-Private-Group-ID [Note 5]
0+ 0 0 82 Tunnel-Assignment-ID [Note 5]
0+ 0 0 83 Tunnel-Preference [Note 5]
0-1 0 0 85 Acct-Interim-Interval [Note 3]
0-1 0 0 87 NAS-Port-Id [Note 1]
0-1 0 0 88 Framed-Pool [Note 3]
0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5]
0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5]
0-1 0 0 94 Originating-Line-Info [Note 1]
0-1 0 0 95 NAS-IPv6-Address [Note 1]
0-1 0 0 96 Framed-Interface-Id [Note 1]
0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
0+ 0 0 98 Login-IPv6-Host [Note 3]
0+ 0 0 99 Framed-IPv6-Route [Note 3]
0-1 0 0 100 Framed-IPv6-Pool [Note 3]
0 0 0+ 101 Error-Cause
Request ACK NAK # Attribute
Request ACK NAK # Attribute
0-1 0 0 62 Port-Limit [Note 3]
0-1 0 0 63 Login-LAT-Port [Note 3]
0+ 0 0 64 Tunnel-Type [Note 5]
0+ 0 0 65 Tunnel-Medium-Type [Note 5]
0+ 0 0 66 Tunnel-Client-Endpoint [Note 5]
0+ 0 0 67 Tunnel-Server-Endpoint [Note 5]
0+ 0 0 69 Tunnel-Password [Note 5]
0-1 0 0 71 ARAP-Features [Note 3]
0-1 0 0 72 ARAP-Zone-Access [Note 3]
0+ 0 0 78 Configuration-Token [Note 3]
0+ 0-1 0 79 EAP-Message [Note 2]
0-1 0-1 0-1 80 Message-Authenticator
0+ 0 0 81 Tunnel-Private-Group-ID [Note 5]
0+ 0 0 82 Tunnel-Assignment-ID [Note 5]
0+ 0 0 83 Tunnel-Preference [Note 5]
0-1 0 0 85 Acct-Interim-Interval [Note 3]
0-1 0 0 87 NAS-Port-Id [Note 1]
0-1 0 0 88 Framed-Pool [Note 3]
0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5]
0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5]
0-1 0 0 94 Originating-Line-Info [Note 1]
0-1 0 0 95 NAS-IPv6-Address [Note 1]
0-1 0 0 96 Framed-Interface-Id [Note 1]
0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
0+ 0 0 98 Login-IPv6-Host [Note 3]
0+ 0 0 99 Framed-IPv6-Route [Note 3]
0-1 0 0 100 Framed-IPv6-Pool [Note 3]
0 0 0+ 101 Error-Cause
Request ACK NAK # Attribute
Disconnect Messages
断开消息连接
Request ACK NAK # Attribute
0-1 0 0 1 User-Name [Note 1]
0-1 0 0 4 NAS-IP-Address [Note 1]
0-1 0 0 5 NAS-Port [Note 1]
0-1 0 0-1 6 Service-Type [Note 6]
0-1 0 0 8 Framed-IP-Address [Note 1]
0+ 0 0 18 Reply-Message [Note 2]
0-1 0-1 0-1 24 State [Note 7]
0+ 0 0 25 Class [Note 4]
0+ 0 0 26 Vendor-Specific
0-1 0 0 30 Called-Station-Id [Note 1]
0-1 0 0 31 Calling-Station-Id [Note 1]
0-1 0 0 32 NAS-Identifier [Note 1]
0+ 0+ 0+ 33 Proxy-State
Request ACK NAK # Attribute
Request ACK NAK # Attribute
0-1 0 0 1 User-Name [Note 1]
0-1 0 0 4 NAS-IP-Address [Note 1]
0-1 0 0 5 NAS-Port [Note 1]
0-1 0 0-1 6 Service-Type [Note 6]
0-1 0 0 8 Framed-IP-Address [Note 1]
0+ 0 0 18 Reply-Message [Note 2]
0-1 0-1 0-1 24 State [Note 7]
0+ 0 0 25 Class [Note 4]
0+ 0 0 26 Vendor-Specific
0-1 0 0 30 Called-Station-Id [Note 1]
0-1 0 0 31 Calling-Station-Id [Note 1]
0-1 0 0 32 NAS-Identifier [Note 1]
0+ 0+ 0+ 33 Proxy-State
Request ACK NAK # Attribute
Request ACK NAK # Attribute
0-1 0 0 44 Acct-Session-Id [Note 1]
0-1 0-1 0 49 Acct-Terminate-Cause
0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
0-1 0-1 0-1 55 Event-Timestamp
0-1 0 0 61 NAS-Port-Type [Note 1]
0+ 0-1 0 79 EAP-Message [Note 2]
0-1 0-1 0-1 80 Message-Authenticator
0-1 0 0 87 NAS-Port-Id [Note 1]
0-1 0 0 94 Originating-Line-Info [Note 1]
0-1 0 0 95 NAS-IPv6-Address [Note 1]
0-1 0 0 96 Framed-Interface-Id [Note 1]
0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
0 0+ 0+ 101 Error-Cause
Request ACK NAK # Attribute
Request ACK NAK # Attribute
0-1 0 0 44 Acct-Session-Id [Note 1]
0-1 0-1 0 49 Acct-Terminate-Cause
0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
0-1 0-1 0-1 55 Event-Timestamp
0-1 0 0 61 NAS-Port-Type [Note 1]
0+ 0-1 0 79 EAP-Message [Note 2]
0-1 0-1 0-1 80 Message-Authenticator
0-1 0 0 87 NAS-Port-Id [Note 1]
0-1 0 0 94 Originating-Line-Info [Note 1]
0-1 0 0 95 NAS-IPv6-Address [Note 1]
0-1 0 0 96 Framed-Interface-Id [Note 1]
0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
0 0+ 0+ 101 Error-Cause
Request ACK NAK # Attribute
[Note 1] Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request messages, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g. within CoA-Request messages to request authorization changes).
[注1]如果NAS或会话标识属性包含在断开连接请求或CoA请求消息中，则它们仅用于标识目的。这些属性不得用于识别以外的目的（例如，在CoA请求消息中请求授权变更）。
[Note 2] The Reply-Message Attribute is used to present a displayable message to the user. The message is only displayed as a result of a successful Disconnect-Request or CoA-Request (where a Disconnect-ACK or CoA-ACK is subsequently sent). Where EAP is used for authentication, an EAP-Message/Notification-Request Attribute is sent instead, and Disconnect-ACK or CoA-ACK messages contain an EAP-Message/Notification-Response Attribute.
[注意2]回复消息属性用于向用户显示可显示的消息。该消息仅在成功断开连接请求或CoA请求（随后发送断开连接确认或CoA确认）后显示。当EAP用于身份验证时，将改为发送EAP消息/通知请求属性，并且断开ACK或CoA ACK消息包含EAP消息/通知响应属性。
[Note 3] When included within a CoA-Request, these attributes represent an authorization change request. When one of these attributes is omitted from a CoA-Request, the NAS assumes that the attribute value is to remain unchanged. Attributes included in a CoA-Request replace all existing value(s) of the same attribute(s).
[注3]当包含在CoA请求中时，这些属性表示授权变更请求。当CoA请求中省略了其中一个属性时，NAS会假定该属性值保持不变。CoA请求中包含的属性将替换同一属性的所有现有值。
[Note 4] When included within a successful Disconnect-Request (where a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be sent unmodified by the client to the accounting server in the Accounting Stop packet. If the Disconnect-Request is unsuccessful, then the Class Attribute is not processed.
[注意4]当包含在成功的断开连接请求中（随后发送断开连接确认）时，客户机应在不修改的情况下将类属性发送到记帐停止数据包中的记帐服务器。如果断开连接请求失败，则不会处理Class属性。
[Note 5] When included within a CoA-Request, these attributes represent an authorization change request. Where tunnel attribute(s) are sent within a successful CoA-Request, all existing tunnel attributes are removed and replaced by the new attribute(s).
[注5]当包含在CoA请求中时，这些属性表示授权变更请求。如果在成功的CoA请求中发送隧道属性，则所有现有隧道属性将被删除并替换为新属性。
[Note 6] When included within a Disconnect-Request or CoA-Request, a Service-Type Attribute with value "Authorize Only" indicates that the Request only contains NAS and session identification attributes, and that the NAS should attempt reauthorization by sending an Access-Request with a Service-Type Attribute with value "Authorize Only". This enables a usage model akin to that supported in Diameter, thus easing translation between the two protocols. Support for the Service-Type Attribute is optional within CoA-Request and Disconnect-Request messages; where it is not included, the Request message may contain both identification and authorization attributes. A NAS that does not support the Service-Type Attribute with the value "Authorize Only" within a Disconnect-Request MUST respond with a Disconnect-NAK including no Service-Type Attribute; an Error-Cause Attribute with value "Unsupported Service" MAY be included. A NAS that does not support the Service-Type Attribute with the value "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK including no Service-Type Attribute; an Error-Cause Attribute with value "Unsupported Service" MAY be included.
[注意6]当包含在断开连接请求或CoA请求中时，值为“仅授权”的服务类型属性表示请求仅包含NAS和会话标识属性，NAS应通过发送值为“仅授权”的服务类型属性的访问请求来尝试重新授权。这使得使用模型与Diameter中支持的使用模型类似，从而简化了两个协议之间的转换。在CoA请求和断开连接请求消息中，对服务类型属性的支持是可选的；在未包括的情况下，请求消息可能同时包含标识和授权属性。在断开连接请求中不支持值为“仅授权”的服务类型属性的NAS必须使用不包括服务类型属性的断开连接NAK进行响应；可能包含值为“Unsupported Service”的错误原因属性。在CoA请求中不支持值为“仅授权”的服务类型属性的NAS必须使用不包括服务类型属性的CoA NAK进行响应；可能包含值为“Unsupported Service”的错误原因属性。
A NAS supporting the "Authorize Only" Service-Type value within Disconnect-Request or CoA-Request messages MUST respond with a Disconnect-NAK or CoA-NAK respectively, containing a Service-Type Attribute with value "Authorize Only", and an Error-Cause Attribute with value "Request Initiated". The NAS then sends an Access-Request to the RADIUS server with a Service-Type Attribute with value "Authorize Only". This Access-Request SHOULD contain the NAS attributes from the Disconnect or CoA-Request, as well as the session attributes from the Request legal for inclusion in an Access-Request as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As noted in [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be included in an Access-Request that does not contain a User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. The RADIUS server should send back an Access-Accept to (re-)authorize the session or an Access-Reject to refuse to (re-)authorize it.
在断开连接请求或CoA请求消息中支持“仅授权”服务类型值的NAS必须分别使用断开连接NAK或CoA NAK进行响应，其中包含值为“仅授权”的服务类型属性和值为“请求已启动”的错误原因属性。然后NAS向RADIUS服务器发送一个访问请求，该请求的服务类型属性值为“仅授权”。此访问请求应包含断开连接或CoA请求的NAS属性，以及[RFC2865]、[RFC2868]、[RFC2869]和[RFC3162]中规定的合法请求中包含的会话属性。如[RFC2869]第5.19节所述，访问请求中应包含消息验证器属性，该属性不包含用户密码、CHAP密码、ARAP密码或EAP消息属性。RADIUS服务器应发回一个访问接受（重新）授权会话或一个访问拒绝（重新）授权会话。
[Note 7] The State Attribute is available to be sent by the RADIUS server to the NAS in a Disconnect-Request or CoA-Request message and MUST be sent unmodified from the NAS to the RADIUS server in a subsequent ACK or NAK message. If a Service-Type Attribute with value "Authorize Only" is included in a Disconnect-Request or CoA-Request along with a State Attribute, then the State Attribute MUST be sent unmodified from the NAS to the RADIUS server in the resulting Access-Request sent to the RADIUS server, if any. The State Attribute is also available to be sent by the RADIUS server to the NAS in a CoA-Request that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the client performs the Termination-Action by sending a new Access-Request upon termination of the current session, it MUST include the State
[注意7]状态属性可由RADIUS服务器在断开连接请求或CoA请求消息中发送到NAS，并且必须在后续ACK或NAK消息中未经修改地从NAS发送到RADIUS服务器。如果值为“仅授权”的服务类型属性与状态属性一起包含在断开连接请求或CoA请求中，则状态属性必须在发送到RADIUS服务器（如果有）的最终访问请求中未经修改地从NAS发送到RADIUS服务器。状态属性也可由RADIUS服务器在CoA请求中发送到NAS，该CoA请求还包括具有RADIUS请求值的终止操作属性。如果客户端通过在当前会话终止时发送新的访问请求来执行终止操作，则它必须包括状态
Attribute unchanged in that Access-Request. In either usage, the client MUST NOT interpret the Attribute locally. A Disconnect-Request or CoA-Request packet must have only zero or one State Attribute. Usage of the State Attribute is implementation dependent. If the RADIUS server does not recognize the State Attribute in the Access-Request, then it MUST send an Access-Reject.
属性在该访问请求中保持不变。在这两种用法中，客户端都不能在本地解释该属性。断开连接请求或CoA请求数据包必须只有零或一个状态属性。State属性的使用取决于实现。如果RADIUS服务器无法识别访问请求中的State属性，则必须发送访问拒绝。
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. 1 Exactly one instance of this attribute MUST be present in packet.
0此属性不能出现在数据包中。数据包中可能存在0+零个或多个此属性的实例。0-1数据包中可能存在该属性的零个或一个实例。1数据包中必须正好存在此属性的一个实例。
This document uses the RADIUS [RFC2865] namespace, see <http://www.iana.org/assignments/radius-types>. There are six updates for the section: RADIUS Packet Type Codes. These Packet Types are allocated in [RADIANA]:
本文档使用RADIUS[RFC2865]名称空间，请参阅<http://www.iana.org/assignments/radius-types>. 该部分有六个更新：RADIUS数据包类型代码。这些数据包类型在[RADIANA]中分配：
40 - Disconnect-Request 41 - Disconnect-ACK 42 - Disconnect-NAK 43 - CoA-Request 44 - CoA-ACK 45 - CoA-NAK
40-断开请求41-断开确认42-断开NAK 43-CoA请求44-CoA确认45-CoA NAK
Allocation of a new Service-Type value for "Authorize Only" is requested. This document also uses the UDP [RFC768] namespace, see <http://www.iana.org/assignments/port-numbers>. The authors request a port assignment from the Registered ports range. Finally, this specification allocates the Error-Cause Attribute (101) with the following decimal values:
请求为“仅授权”分配新的服务类型值。本文档还使用UDP[RFC768]命名空间，请参阅<http://www.iana.org/assignments/port-numbers>. 作者从注册端口范围请求端口分配。最后，本规范使用以下十进制值分配错误原因属性（101）：
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found 504 Session Context Not Removable 505 Other Proxy Processing Error 506 Resources Unavailable 507 Request Initiated
503找不到会话上下文504会话上下文不可移动505其他代理处理错误506资源不可用507请求已启动
Where a NAS is shared by multiple providers, it is undesirable for one provider to be able to send Disconnect-Request or CoA-Requests affecting the sessions of another provider.
如果NAS由多个提供商共享，则一个提供商不希望能够发送影响另一个提供商会话的断开连接请求或CoA请求。
A NAS or RADIUS proxy MUST silently discard Disconnect-Request or CoA-Request messages from untrusted sources. By default, a RADIUS proxy SHOULD perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request originates from an authorized RADIUS server. In addition, it SHOULD be possible to explicitly authorize additional sources of Disconnect-Request or CoA-Request packets relating to certain classes of sessions. For example, a particular source can be explicitly authorized to send CoA-Request messages relating to users within a set of realms.
NAS或RADIUS代理必须以静默方式放弃来自不受信任源的断开连接请求或CoA请求消息。默认情况下，RADIUS代理应执行“反向路径转发”（RPF）检查，以验证断开连接请求或CoA请求是否源自授权的RADIUS服务器。此外，应该可以明确授权与特定会话类别相关的断开连接请求或CoA请求数据包的其他来源。例如，可以明确授权特定源发送与一组领域内的用户相关的CoA请求消息。
To perform the RPF check, the proxy uses the session identification attributes included in Disconnect-Request or CoA-Request messages, in order to determine the RADIUS server(s) to which an equivalent Access-Request could be routed. If the source address of the Disconnect-Request or CoA-Request is within this set, then the Request is forwarded; otherwise it MUST be silently discarded.
为了执行RPF检查，代理使用断开连接请求或CoA请求消息中包含的会话标识属性，以确定等效访问请求可以路由到的RADIUS服务器。如果断开连接请求或CoA请求的源地址在该集合内，则请求被转发；否则，它必须被默默地丢弃。
Typically the proxy will extract the realm from the Network Access Identifier [RFC2486] included within the User-Name Attribute, and determine the corresponding RADIUS servers in the proxy routing tables. The RADIUS servers for that realm are then compared against the source address of the packet. Where no RADIUS proxy is present, the RPF check will need to be performed by the NAS itself.
通常，代理将从用户名属性中包含的网络访问标识符[RFC2486]中提取域，并在代理路由表中确定相应的RADIUS服务器。然后将该领域的RADIUS服务器与数据包的源地址进行比较。如果不存在RADIUS代理，则需要由NAS本身执行RPF检查。
Since authorization to send a Disconnect-Request or CoA-Request is determined based on the source address and the corresponding shared secret, the NASes or proxies SHOULD configure a different shared secret for each RADIUS server.
由于发送断开连接请求或CoA请求的授权是根据源地址和相应的共享机密确定的，因此NASE或代理应为每个RADIUS服务器配置不同的共享机密。
[RFC2865] Section 3 states:
[RFC2865]第3节规定：
A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied.
RADIUS服务器必须使用RADIUS UDP数据包的源IP地址来决定使用哪个共享密钥，以便可以代理RADIUS请求。
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or NAS-IPv6-Address Attributes will typically not match the source address observed by the RADIUS server. Since the NAS-Identifier Attribute need not contain an FQDN, this attribute may not be resolvable to the source address observed by the RADIUS server, even when no proxy is present.
当RADIUS请求由代理转发时，NAS IP地址或NAS-IPv6-Address属性通常与RADIUS服务器观察到的源地址不匹配。由于NAS标识符属性不需要包含FQDN，因此此属性可能无法解析为RADIUS服务器观察到的源地址，即使不存在代理。
As a result, the authenticity check performed by a RADIUS server or proxy does not verify the correctness of NAS identification attributes. This makes it possible for a rogue NAS to forge NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier Attributes within a RADIUS Access-Request in order to impersonate another NAS. It is also possible for a rogue NAS to forge session identification attributes such as the Called-Station-Id, Calling-Station-Id, or Originating-Line-Info [NASREQ]. This could fool the RADIUS server into sending Disconnect-Request or CoA-Request messages containing forged session identification attributes to a NAS targeted by an attacker.
因此，RADIUS服务器或代理执行的真实性检查不会验证NAS标识属性的正确性。这使得流氓NAS可以在RADIUS访问请求中伪造NAS IP地址、NAS-IPv6-Address或NAS标识符属性，以模拟另一个NAS。恶意NAS也可能伪造会话标识属性，如被叫站Id、主叫站Id或始发线路信息[NASREQ]。这可能会欺骗RADIUS服务器将包含伪造会话标识属性的断开连接请求或CoA请求消息发送到攻击者所针对的NAS。
To address these vulnerabilities RADIUS proxies SHOULD check whether NAS identification attributes (see Section 3.) match the source address of packets originating from the NAS. Where one or more attributes do not match, Disconnect-Request or CoA-Request messages SHOULD be silently discarded.
为解决这些漏洞，RADIUS代理应检查NAS标识属性（见第3节）是否与源自NAS的数据包的源地址匹配。在一个或多个属性不匹配的情况下，断开连接请求或CoA请求消息应以静默方式丢弃。
Such a check may not always be possible. Since the NAS-Identifier Attribute need not correspond to an FQDN, it may not be resolvable to an IP address to be matched against the source address. Also, where a NAT exists between the RADIUS client and proxy, checking the NAS-IP-Address or NAS-IPv6-Address Attributes may not be feasible.
这种检查可能并不总是可行的。由于NAS标识符属性不需要对应于FQDN，因此它可能无法解析为要与源地址匹配的IP地址。此外，如果RADIUS客户端和代理之间存在NAT，则检查NAS IP地址或NAS-IPv6-Address属性可能不可行。
In addition to security vulnerabilities unique to Disconnect or CoA messages, the protocol exchanges described in this document are susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is RECOMMENDED that IPsec be employed to afford better security.
除了断开连接或CoA消息特有的安全漏洞外，本文档中描述的协议交换易受RADIUS[RFC2865]相同漏洞的影响。建议采用IPsec以提供更好的安全性。
Implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with a non-null transform SHOULD be supported, and IPsec ESP with a non-null encryption transform and authentication support SHOULD be used to provide per-packet confidentiality, authentication, integrity and replay protection. IKE SHOULD be used for key management.
本规范的实现应支持IPsec[RFC2401]和IKE[RFC2409]进行密钥管理。应支持具有非空转换的IPsec ESP[RFC2406]，并且应使用具有非空加密转换和身份验证支持的IPsec ESP来提供每个数据包的机密性、身份验证、完整性和重播保护。IKE应该用于密钥管理。
Within RADIUS [RFC2865], a shared secret is used for hiding Attributes such as User-Password, as well as used in computation of the Response Authenticator. In RADIUS accounting [RFC2866], the shared secret is used in computation of both the Request Authenticator and the Response Authenticator.
在RADIUS[RFC2865]中，共享秘密用于隐藏用户密码等属性，以及用于计算响应验证器。在RADIUS accounting[RFC2866]中，共享密钥用于计算请求认证器和响应认证器。
Since in RADIUS a shared secret is used to provide confidentiality as well as integrity protection and authentication, only use of IPsec ESP with a non-null transform can provide security services sufficient to substitute for RADIUS application-layer security. Therefore, where IPsec AH or ESP null is used, it will typically still be necessary to configure a RADIUS shared secret.
由于在RADIUS中，共享秘密用于提供机密性以及完整性保护和身份验证，因此只有使用具有非空转换的IPsec ESP才能提供足以替代RADIUS应用层安全性的安全服务。因此，在使用IPsec AH或ESP null的情况下，通常仍需要配置RADIUS共享机密。
Where RADIUS is run over IPsec ESP with a non-null transform, the secret shared between the NAS and the RADIUS server MAY NOT be configured. In this case, a shared secret of zero length MUST be assumed. However, a RADIUS server that cannot know whether incoming traffic is IPsec-protected MUST be configured with a non-null RADIUS shared secret.
如果RADIUS通过IPsec ESP以非空转换运行，则可能无法配置NAS和RADIUS服务器之间共享的机密。在这种情况下，必须假定一个长度为零的共享秘密。但是，无法知道传入通信是否受IPsec保护的RADIUS服务器必须配置非空RADIUS共享机密。
When IPsec ESP is used with RADIUS, per-packet authentication, integrity and replay protection MUST be used. 3DES-CBC MUST be supported as an encryption transform and AES-CBC SHOULD be supported. AES-CBC SHOULD be offered as a preferred encryption transform if supported. HMAC-SHA1-96 MUST be supported as an authentication transform. DES-CBC SHOULD NOT be used as the encryption transform.
当IPsec ESP与RADIUS一起使用时，必须使用每包身份验证、完整性和重播保护。必须支持3DES-CBC作为加密转换，并且应支持AES-CBC。如果支持，AES-CBC应作为首选加密转换提供。必须支持HMAC-SHA1-96作为身份验证转换。DES-CBC不应用作加密转换。
A typical IPsec policy for an IPsec-capable RADIUS client is "Initiate IPsec, from me to any destination port UDP 1812". This IPsec policy causes an IPsec SA to be set up by the RADIUS client prior to sending RADIUS traffic. If some RADIUS servers contacted by the client do not support IPsec, then a more granular policy will be required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 1812."
支持IPsec的RADIUS客户端的典型IPsec策略是“启动IPsec，从me到任何目标端口UDP 1812”。此IPsec策略导致RADIUS客户端在发送RADIUS流量之前设置IPsec SA。如果客户端联系的某些RADIUS服务器不支持IPsec，则需要更精细的策略：“启动IPsec，从me到支持IPsec的RADIUS服务器，目标端口UDP 1812。”
For a client implementing this specification, the policy would be "Accept IPsec, from any to me, destination port UDP 3799". This causes the RADIUS client to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS servers connecting to an IPsec-enabled RADIUS client, since some RADIUS servers may not support IPsec.
对于实现此规范的客户机，策略将是“接受IPsec，从任何到我，目标端口UDP 3799”。这会导致RADIUS客户端接受（但不要求）使用IPsec。对于连接到启用IPsec的RADIUS客户端的所有RADIUS服务器，可能不适合要求IPsec，因为某些RADIUS服务器可能不支持IPsec。
For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept IPsec, from any to me, destination port 1812". This causes the RADIUS server to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS clients connecting to an IPsec-enabled RADIUS server, since some RADIUS clients may not support IPsec.
对于支持IPsec的RADIUS服务器，典型的IPsec策略是“接受IPsec，从任何到我，目标端口1812”。这会导致RADIUS服务器接受（但不要求）使用IPsec。对于连接到启用IPsec的RADIUS服务器的所有RADIUS客户端，可能不适合要求IPsec，因为某些RADIUS客户端可能不支持IPsec。
For servers implementing this specification, the policy would be "Initiate IPsec, from me to any, destination port UDP 3799". This causes the RADIUS server to initiate IPsec when sending RADIUS extension traffic to any RADIUS client. If some RADIUS clients contacted by the server do not support IPsec, then a more granular policy will be required, such as "Initiate IPsec, from me to IPsec-capable-RADIUS-client, destination port UDP 3799".
对于实现此规范的服务器，策略将是“启动IPsec，从me到任意目标端口UDP 3799”。这会导致RADIUS服务器在向任何RADIUS客户端发送RADIUS扩展通信时启动IPsec。如果服务器联系的某些RADIUS客户端不支持IPsec，则需要更精细的策略，例如“启动IPsec，从me到支持IPsec的RADIUS客户端，目标端口UDP 3799”。
Where IPsec is used for security, and no RADIUS shared secret is configured, it is important that the RADIUS client and server perform an authorization check. Before enabling a host to act as a RADIUS client, the RADIUS server SHOULD check whether the host is authorized to provide network access. Similarly, before enabling a host to act as a RADIUS server, the RADIUS client SHOULD check whether the host is authorized for that role.
如果IPsec用于安全，并且未配置RADIUS共享机密，则RADIUS客户端和服务器执行授权检查非常重要。在启用主机作为RADIUS客户端之前，RADIUS服务器应检查主机是否有权提供网络访问。类似地，在启用主机作为RADIUS服务器之前，RADIUS客户端应检查主机是否被授权担任该角色。
RADIUS servers can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS clients. Alternatively, if a separate Certification Authority (CA) exists for RADIUS clients, then the RADIUS server can configure this CA as a trust anchor [RFC3280] for use with IPsec.
RADIUS服务器可以配置RADIUS客户端的IP地址（用于带有预共享密钥的IKE攻击模式）或FQDN（用于证书身份验证）。或者，如果RADIUS客户端存在单独的证书颁发机构（CA），则RADIUS服务器可以将此CA配置为用于IPsec的信任锚[RFC3280]。
Similarly, RADIUS clients can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS servers. Alternatively, if a separate CA exists for RADIUS servers, then the RADIUS client can configure this CA as a trust anchor for use with IPsec.
类似地，RADIUS客户端可以配置RADIUS服务器的IP地址（对于具有预共享密钥的IKE攻击模式）或FQDN（用于证书身份验证）。或者，如果RADIUS服务器存在单独的CA，则RADIUS客户端可以将此CA配置为用于IPsec的信任锚。
Since unlike SSL/TLS, IKE does not permit certificate policies to be set on a per-port basis, certificate policies need to apply to all uses of IPsec on RADIUS clients and servers. In IPsec deployment supporting only certificate authentication, a management station initiating an IPsec-protected telnet session to the RADIUS server would need to obtain a certificate chaining to the RADIUS client CA. Issuing such a certificate might not be appropriate if the management station was not authorized as a RADIUS client.
由于与SSL/TLS不同，IKE不允许基于每个端口设置证书策略，因此证书策略需要应用于RADIUS客户端和服务器上IPsec的所有使用。在仅支持证书身份验证的IPsec部署中，管理站启动到RADIUS服务器的受IPsec保护的telnet会话将需要获得到RADIUS客户端CA的证书链接。如果管理站未被授权为RADIUS客户端，则颁发此类证书可能不合适。
Where RADIUS clients may obtain their IP address dynamically (such as an Access Point supporting DHCP), Main Mode with pre-shared keys [RFC2409] SHOULD NOT be used, since this requires use of a group
如果RADIUS客户端可以动态获取其IP地址（例如支持DHCP的接入点），则不应使用带有预共享密钥[RFC2409]的主模式，因为这需要使用组
pre-shared key; instead, Aggressive Mode SHOULD be used. Where RADIUS client addresses are statically assigned, either Aggressive Mode or Main Mode MAY be used. With certificate authentication, Main Mode SHOULD be used.
预共享密钥；相反，应该使用攻击性模式。在静态分配RADIUS客户端地址的情况下，可以使用主动模式或主模式。对于证书身份验证，应使用主模式。
Care needs to be taken with IKE Phase 1 Identity Payload selection in order to enable mapping of identities to pre-shared keys, even with Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and addresses are dynamically assigned, mapping of identities to keys is not possible, so that group pre-shared keys are still a practical necessity. As a result, the ID_FQDN identity payload SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned. This approach also has other advantages, since it allows the RADIUS server and client to configure themselves based on the fully qualified domain name of their peers.
需要注意IKE阶段1身份有效负载选择，以便能够将身份映射到预共享密钥，即使在攻击模式下也是如此。在使用ID_IPV4_ADDR或ID_IPV6_ADDR标识有效载荷并动态分配地址的情况下，不可能将标识映射到密钥，因此组预共享密钥仍然是实际需要的。因此，ID_FQDN标识有效负载应在主动模式与预共享密钥一起使用，并且动态分配IP地址的情况下使用。这种方法还有其他优点，因为它允许RADIUS服务器和客户端根据其对等方的完全限定域名进行自我配置。
Note that with IPsec, security services are negotiated at the granularity of an IPsec SA, so that RADIUS exchanges requiring a set of security services different from those negotiated with existing IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also advisable where quality of service considerations dictate different handling RADIUS conversations. Attempting to apply different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For a discussion of the issues, see [RFC2983].
请注意，对于IPsec，安全服务是在IPsec SA的粒度上协商的，因此需要一组不同于与现有IPsec SA协商的安全服务的RADIUS交换将需要协商一个新的IPsec SA。如果服务质量考虑因素要求不同的处理方式，也建议使用单独的IPsec SA。试图对同一IPsec SA处理的连接应用不同的服务质量可能会导致重新排序，并超出重播窗口。有关这些问题的讨论，请参见[RFC2983]。
Where IPsec replay protection is not used, the Event-Timestamp (55) Attribute [RFC2869] SHOULD be included within all messages. When this attribute is present, both the NAS and the RADIUS server MUST check that the Event-Timestamp Attribute is current within an acceptable time window. If the Event-Timestamp Attribute is not current, then the message MUST be silently discarded. This implies the need for time synchronization within the network, which can be achieved by a variety of means, including secure NTP, as described in [NTPAUTH].
如果未使用IPsec重播保护，则所有消息中都应包含事件时间戳（55）属性[RFC2869]。当此属性存在时，NAS和RADIUS服务器必须检查事件时间戳属性是否在可接受的时间窗口内为当前属性。如果事件时间戳属性不是当前的，则必须以静默方式丢弃消息。这意味着需要在网络内进行时间同步，这可以通过多种方式实现，包括[NTPAUTH]中所述的安全NTP。
Both the NAS and the RADIUS server SHOULD be configurable to silently discard messages lacking an Event-Timestamp Attribute. A default time window of 300 seconds is recommended.
NAS和RADIUS服务器都应配置为以静默方式丢弃缺少事件时间戳属性的消息。建议使用300秒的默认时间窗口。
Disconnect Request with User-Name:
断开具有用户名的请求：
0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
32: 6d63 6869 6261
0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
32: 6d63 6869 6261
Disconnect Request with Acct-Session-ID:
断开帐户会话ID为的请求：
0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
32: 3930 3233 3435 3637 90234567
0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
32: 3930 3233 3435 3637 90234567
Disconnect Request with Framed-IP-Address:
断开具有框架IP地址的请求：
0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(.....
16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ...
32: 0a00 0203
0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(.....
16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ...
32: 0a00 0203
[RFC1305] Mills, D., "Network Time Protocol (version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC1305，1992年3月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[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月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486]Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[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月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年6月。
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869]Rigney，C.，Willats，W.和P.Calhoun，“半径延伸”，RFC 2869，2000年6月。
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162]Aboba，B.，Zorn，G.和D.Mitton，“RADIUS和IPv6”，RFC 3162，2001年8月。
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[RADIANA] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RADIANA]Aboba，B.“RADIUS（远程认证拨入用户服务）的IANA注意事项”，RFC 35752003年7月。
[RFC2882] Mitton, D., "Network Access Server Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
[RFC2882]Mitton，D.，“网络访问服务器要求：扩展RADIUS实践”，RFC 28822000年7月。
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.“差异化服务和隧道”，RFC 29832000年10月。
[AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[AAATransport]Aboba，B.和J.Wood，“认证、授权和会计（AAA）运输概况”，RFC 3539，2003年6月。
[Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in Progress.
[Diameter]Calhoun，P.等人，“Diameter基础协议”，正在进行的工作。
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[MD5Attack]Dobbertin，H.，“最近一次攻击后MD5的状态”，CryptoBytes第2卷第2期，1996年夏季。
[NASREQ] Calhoun, P., et al., "Diameter Network Access Server Application", Work in Progress.
[NASREQ]Calhoun，P.等人，“Diameter网络访问服务器应用程序”，正在进行中。
[NTPAUTH] Mills, D., "Public Key Cryptography for the Network Time Protocol", Work in Progress.
[NTPAUTH]Mills，D.，“网络时间协议的公钥加密”，正在进行中。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
This protocol was first developed and distributed by Ascend Communications. Example code was distributed in their free server kit.
该协议首先由Ascend Communications开发和发布。示例代码在他们的免费服务器套件中分发。
The authors would like to acknowledge the valuable suggestions and feedback from the following people:
作者希望感谢以下人士提出的宝贵建议和反馈：
Avi Lior <avi@bridgewatersystems.com>,
Randy Bush <randy@psg.net>,
Steve Bellovin <smb@research.att.com>
Glen Zorn <gwz@cisco.com>,
Mark Jones <mjones@bridgewatersystems.com>,
Claudio Lapidus <clapidus@hotmail.com>,
Anurag Batta <Anurag_Batta@3com.com>,
Kuntal Chowdhury <chowdury@nortelnetworks.com>, and
Tim Moore <timmoore@microsoft.com>.
Russ Housley <housley@vigilsec.com>
Avi Lior <avi@bridgewatersystems.com>,
Randy Bush <randy@psg.net>,
Steve Bellovin <smb@research.att.com>
Glen Zorn <gwz@cisco.com>,
Mark Jones <mjones@bridgewatersystems.com>,
Claudio Lapidus <clapidus@hotmail.com>,
Anurag Batta <Anurag_Batta@3com.com>,
Kuntal Chowdhury <chowdury@nortelnetworks.com>, and
Tim Moore <timmoore@microsoft.com>.
Russ Housley <housley@vigilsec.com>
Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134
Murtaza Chiba Cisco Systems，Inc.170西塔斯曼加州圣何塞博士，95134
EMail: mchiba@cisco.com
Phone: +1 408 525 7198
EMail: mchiba@cisco.com
Phone: +1 408 525 7198
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134
Gopal Dommety思科系统公司，170西塔斯曼博士，加利福尼亚州圣何塞市，邮编95134
EMail: gdommety@cisco.com
Phone: +1 408 525 1404
EMail: gdommety@cisco.com
Phone: +1 408 525 1404
Mark Eklund Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134
Mark Eklund Cisco Systems，Inc.170西塔斯曼博士，加利福尼亚州圣何塞市，邮编95134
EMail: meklund@cisco.com
Phone: +1 865 671 6255
EMail: meklund@cisco.com
Phone: +1 865 671 6255
David Mitton Circular Logic UnLtd. 733 Turnpike Street #154 North Andover, MA 01845
大卫·米顿循环逻辑UnLtd。马萨诸塞州安多弗北部154号收费公路街733号，邮编01845
EMail: david@mitton.com
Phone: +1 978 683 1814
EMail: david@mitton.com
Phone: +1 978 683 1814
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。