Network Working Group B. Aboba
Request for Comments: 3575 Microsoft
Updates: 2865 July 2003
Category: Standard Track
Network Working Group B. Aboba
Request for Comments: 3575 Microsoft
Updates: 2865 July 2003
Category: Standard Track
IANA Considerations for RADIUS (Remote Authentication Dial In User Service)
RADIUS（远程身份验证拨入用户服务）的IANA注意事项
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS).
本文档描述了远程身份验证拨入用户服务（RADIUS）的IANA注意事项。
This document updates RFC 2865.
本文件更新了RFC 2865。
This document provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the Remote Authentication Dial In User Service (RADIUS), defined in [RFC2865], in accordance with BCP 26, [RFC2434]. It also reserves Packet Type Codes that are or have been in use on the Internet.
本文件根据BCP 26[RFC2434]的规定，就[RFC2865]中定义的远程认证拨入用户服务（RADIUS）相关值的注册向互联网分配号码管理局（IANA）提供指导。它还保留互联网上正在使用或已经使用的数据包类型代码。
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]中所述进行解释。
The following terms are used here with the meanings defined in BCP 26: "name space", "assigned value", "registration".
以下术语的含义见BCP 26：“名称空间”、“赋值”、“注册”。
The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IESG Approval", "IETF Consensus", "Standards Action".
以下政策的含义见BCP 26：“私人使用”、“先到先得”、“专家评审”、“要求规范”、“IESG批准”、“IETF共识”、“标准行动”。
There are three name spaces in RADIUS that require registration: Packet Type Codes, Attribute Types, and Attribute Values (for certain Attributes). This document creates no new IANA registries, since a RADIUS registry was created by [RFC2865].
RADIUS中有三个名称空间需要注册：数据包类型代码、属性类型和属性值（对于某些属性）。由于[RFC2865]创建了RADIUS注册表，因此本文档不创建新的IANA注册表。
RADIUS is not intended as a general-purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to Authentication, Authorization or Accounting.
RADIUS不是一个通用协议，分配不应用于与身份验证、授权或记帐无关的目的。
For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. The intention is that any allocation will be accompanied by a published RFC. However, the Designated Expert can approve allocations once it seems clear that an RFC will be published, allowing for the allocation of values prior to the document being approved for publication as an RFC. The Designated Expert will post a request to the AAA WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request, publish a notice of the decision to the AAA WG mailing list or its successor, and inform IANA of its decision. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable.
对于需要咨询指定专家的注册请求，IESG区域负责人应任命指定专家。其目的是，任何分配都将附带公布的RFC。但是，一旦确定RFC将被发布，指定专家可以批准分配，允许在文件被批准作为RFC发布之前分配值。指定专家将向AAA工作组邮件列表（或区域总监指定的继任者）发出请求，以征求意见和审查，包括互联网草案。在30天内，指定专家将批准或拒绝注册请求，向AAA WG邮件列表或其继任者发布决定通知，并将其决定通知IANA。拒绝通知必须有理由作出解释，并在可能的情况下，就如何修改请求以使其成为可接受的请求提出具体建议。
Packet Type Codes have a range from 1 to 253. RADIUS Type Codes 1-5 and 11-13 were allocated in [RFC2865], while Type Codes 40-45, 250-253 are allocated by this document. Type Codes 250-253 are allocated for Experimental Uses, and 254-255 are reserved. Packet Type Codes 6-10, 12-13, 21-34, 50-51 have no meaning defined by an IETF RFC, but are reserved until a specification is provided for them. This is being done to avoid interoperability problems with software that implements non-standard RADIUS extensions that are or
数据包类型代码的范围为1到253。[RFC2865]中分配了半径类型代码1-5和11-13，而本文件分配了类型代码40-45、250-253。类型代码250-253分配用于实验用途，254-255保留。包类型代码6-10、12-13、21-34、50-51没有IETF RFC定义的含义，但在为其提供规范之前保留。这样做是为了避免与实现非标准RADIUS扩展的软件的互操作性问题，这些扩展是或
have been in use on the Internet. Because a new Packet Type has considerable impact on interoperability, a new Packet Type Code requires IESG Approval. The intention is that any allocation will be accompanied by a published RFC. Type Codes 52-249 should be allocated first; when these are exhausted, Type Codes 14-20, 35-39, 46-49 may be allocated. For a list of Type Codes, see Appendix A.
已在互联网上使用。由于新的数据包类型对互操作性有相当大的影响，因此新的数据包类型代码需要IESG批准。其目的是，任何分配都将附带公布的RFC。应首先分配类型代码52-249；当这些设备耗尽时，可分配类型代码14-20、35-39、46-49。有关类型代码列表，请参见附录a。
Attribute Types have a range from 1 to 255, and are the scarcest resource in RADIUS, thus must be allocated with care. Attributes 1-53,55,60-88,90-91,94-100 have been allocated, with 17 and 21 available for re-use. Attributes 17, 21, 54, 56-59, 89, 101-191 may be allocated by IETF Consensus. It is recommended that attributes 17 and 21 be used only after all others are exhausted.
属性类型的范围为1到255，是RADIUS中最稀缺的资源，因此必须小心分配。属性1-53、55、60-88、90-91、94-100已分配，17和21可重复使用。属性17、21、54、56-59、89、101-191可由IETF协商一致分配。建议仅在耗尽所有其他属性后才使用属性17和21。
Note that RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. For functions specific only to one vendor's implementation of RADIUS, the use of that should be encouraged instead of the allocation of global attribute types.
注意，RADIUS为供应商特定的扩展（属性26）定义了一种机制，用于仅针对一个供应商的RADIUS实现的功能，在这种情况下，互操作性被认为是无用的。对于仅针对一个供应商的RADIUS实现的功能，应鼓励使用该功能，而不是分配全局属性类型。
As noted in [RFC2865]:
如[RFC2865]所述：
Attribute Type Values 192-223 are reserved for experimental use, values 224-240 are reserved for implementation-specific use, and values 241-255 are reserved and should not be used.
属性类型值192-223保留供实验使用，值224-240保留供实现特定使用，值241-255保留且不应使用。
Therefore Attribute Type values 192-240 are considered Private Use, and values 241-255 require Standards Action.
因此，属性类型值192-240被视为专用，而值241-255需要标准操作。
Certain attributes (for example, NAS-Port-Type) in RADIUS define a list of values to correspond with various meanings. There can be 4 billion (2^32) values for each attribute. Additional values can be allocated by the Designated Expert. The exception to this policy is the Service-Type attribute (6), whose values define new modes of operation for RADIUS. Values 1-16 of the Service-Type attribute have been allocated. Allocation of new Service-Type values are by IETF Consensus. The intention is that any allocation will be accompanied by a published RFC.
RADIUS中的某些属性（例如NAS端口类型）定义了一个值列表，以对应不同的含义。每个属性可以有40亿（2^32）个值。其他值可由指定专家分配。此策略的例外是服务类型属性（6），其值定义RADIUS的新操作模式。已分配服务类型属性的值1-16。新服务类型值的分配由IETF协商一致。其目的是，任何分配都将附带公布的RFC。
[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月。
[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月。
[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月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607]Aboba，B.和J.Vollbrecht，“漫游中的代理链接和策略实施”，RFC 2607，1999年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年6月。
[RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RFC2867]Zorn，G.，Aboba，B.和D.Mitton，“隧道协议支持的半径计算修改”，RFC 28672000年6月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868]Zorn，G.，Leifer，D.，Rubens，A.，Shriver，J.，Holdrege，M.和I.Goyret，“隧道协议支持的半径属性”，RFC 28682000年6月。
[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月。
[RFC2869bis] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Authentication Protocol (EAP)", Work in Progress.
[RFC2869bis]Aboba，B.和P.Calhoun，“可扩展身份验证协议（EAP）的RADIUS支持”，正在进行中。
[RFC2882] Mitton, D., "Network Access Servers Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
[RFC2882]Mitton，D.，“网络访问服务器要求：扩展RADIUS实践”，RFC 28822000年7月。
[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月。
[DynAuth] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
[DynAuth]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 35762003年7月。
The security considerations detailed in [RFC2434] are generally applicable to this document. Security considerations relating to the RADIUS protocol are discussed in [RFC2607], [RFC2865], [RFC3162], [DynAuth], and [RFC2869bis].
[RFC2434]中详述的安全注意事项通常适用于本文件。[RFC2607]、[RFC2865]、[RFC3162]、[DynAuth]和[RFC2869bis]中讨论了与RADIUS协议相关的安全注意事项。
Appendix A - RADIUS Packet Types
附录A-RADIUS数据包类型
A list of RADIUS Packet Type Codes is given below. This document instructs IANA to list them in the registry of Packet Type Codes. Note that Type Codes 40-45, defined in [DynAuth], are being formally allocated here. Codes 40-45 were listed in [RFC2882] and have been implemented and used. Given their current widespread usage, these assignments are not reclaimable in practice.
RADIUS数据包类型代码列表如下所示。本文档指示IANA在数据包类型代码注册表中列出它们。请注意，[DynAuth]中定义的类型代码40-45在此正式分配。[RFC2882]中列出了代码40-45，并已实施和使用。鉴于其目前的广泛使用，这些分配在实践中是不可回收的。
# Message Reference
---- ------------------------- ---------
1 Access-Request [RFC2865]
2 Access-Accept [RFC2865]
3 Access-Reject [RFC2865]
4 Accounting-Request [RFC2865]
5 Accounting-Response [RFC2865]
6 Accounting-Status [RFC2882]
(now Interim Accounting)
7 Password-Request [RFC2882]
8 Password-Ack [RFC2882]
9 Password-Reject [RFC2882]
10 Accounting-Message [RFC2882]
11 Access-Challenge [RFC2865]
12 Status-Server (experimental) [RFC2865]
13 Status-Client (experimental) [RFC2865]
21 Resource-Free-Request [RFC2882]
22 Resource-Free-Response [RFC2882]
23 Resource-Query-Request [RFC2882]
24 Resource-Query-Response [RFC2882]
25 Alternate-Resource-
Reclaim-Request [RFC2882]
26 NAS-Reboot-Request [RFC2882]
27 NAS-Reboot-Response [RFC2882]
28 Reserved
29 Next-Passcode [RFC2882]
# Message Reference
---- ------------------------- ---------
1 Access-Request [RFC2865]
2 Access-Accept [RFC2865]
3 Access-Reject [RFC2865]
4 Accounting-Request [RFC2865]
5 Accounting-Response [RFC2865]
6 Accounting-Status [RFC2882]
(now Interim Accounting)
7 Password-Request [RFC2882]
8 Password-Ack [RFC2882]
9 Password-Reject [RFC2882]
10 Accounting-Message [RFC2882]
11 Access-Challenge [RFC2865]
12 Status-Server (experimental) [RFC2865]
13 Status-Client (experimental) [RFC2865]
21 Resource-Free-Request [RFC2882]
22 Resource-Free-Response [RFC2882]
23 Resource-Query-Request [RFC2882]
24 Resource-Query-Response [RFC2882]
25 Alternate-Resource-
Reclaim-Request [RFC2882]
26 NAS-Reboot-Request [RFC2882]
27 NAS-Reboot-Response [RFC2882]
28 Reserved
29 Next-Passcode [RFC2882]
# Message Reference
---- ------------------------- ---------
30 New-Pin [RFC2882]
31 Terminate-Session [RFC2882]
32 Password-Expired [RFC2882]
33 Event-Request [RFC2882]
34 Event-Response [RFC2882]
40 Disconnect-Request [DynAuth]
41 Disconnect-ACK [DynAuth]
42 Disconnect-NAK [DynAuth]
43 CoA-Request [DynAuth]
44 CoA-ACK [DynAuth]
45 CoA-NAK [DynAuth]
50 IP-Address-Allocate [RFC2882]
51 IP-Address-Release [RFC2882]
250-253 Experimental Use
254 Reserved
255 Reserved [RFC2865]
# Message Reference
---- ------------------------- ---------
30 New-Pin [RFC2882]
31 Terminate-Session [RFC2882]
32 Password-Expired [RFC2882]
33 Event-Request [RFC2882]
34 Event-Response [RFC2882]
40 Disconnect-Request [DynAuth]
41 Disconnect-ACK [DynAuth]
42 Disconnect-NAK [DynAuth]
43 CoA-Request [DynAuth]
44 CoA-ACK [DynAuth]
45 CoA-NAK [DynAuth]
50 IP-Address-Allocate [RFC2882]
51 IP-Address-Release [RFC2882]
250-253 Experimental Use
254 Reserved
255 Reserved [RFC2865]
Intellectual Property Statement
知识产权声明
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执行董事。
Acknowledgments
致谢
Thanks to Ignacio Goyret of Lucent, Allison Mankin of Lucent Bell Labs, Thomas Narten of IBM, Glen Zorn and Harald Alvestrand of Cisco for discussions relating to this document.
感谢朗讯的Ignacio Goyret、朗讯贝尔实验室的Allison Mankin、IBM的Thomas Narten、Cisco的Glen Zorn和Harald Alvestrand就本文档进行的讨论。
Authors' Addresses
作者地址
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
Full Copyright Statement
完整版权声明
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编辑功能的资金目前由互联网协会提供。