Internet Engineering Task Force (IETF) A. DeKok, Ed.
Request for Comments: 6158 FreeRADIUS
BCP: 158 G. Weber
Category: Best Current Practice Individual Contributor
ISSN: 2070-1721 March 2011
Internet Engineering Task Force (IETF) A. DeKok, Ed.
Request for Comments: 6158 FreeRADIUS
BCP: 158 G. Weber
Category: Best Current Practice Individual Contributor
ISSN: 2070-1721 March 2011
RADIUS Design Guidelines
半径设计指南
Abstract
摘要
This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs).
本文档提供了远程身份验证拨入用户服务（RADIUS）协议所用属性的设计指南。预计这些指南将被证明对IETF以及其他标准开发组织（SDO）内未来RADIUS属性规范的作者和评审人员有用。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6158.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6158.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................4
1.3. Applicability ..............................................5
1.3.1. Reviews .............................................5
2. Guidelines ......................................................6
2.1. Data Types .................................................8
2.2. Vendor Space ...............................................9
2.3. Service Definitions and RADIUS .............................9
2.4. Translation of Vendor Specifications ......................10
3. Rationale ......................................................11
3.1. RADIUS Operational Model ..................................11
3.2. Data Model Issues .........................................14
3.2.1. Issues with Definitions of Types ...................15
3.2.2. Tagging Mechanism ..................................16
3.2.3. Complex Data Types .................................16
3.2.4. Complex Data Type Exceptions .......................18
3.3. Vendor Space ..............................................19
3.3.1. Interoperability Considerations ....................20
3.3.2. Vendor Allocations .................................20
3.3.3. SDO Allocations ....................................20
3.4. Polymorphic Attributes ....................................21
4. IANA Considerations ............................................22
5. Security Considerations ........................................22
5.1. New Data Types and Complex Attributes .....................23
6. References .....................................................24
6.1. Normative References ......................................24
6.2. Informative References ....................................24
Appendix A. Design Guidelines Checklist ..........................27
A.1. Types Matching the RADIUS Data Model ......................27
A.1.1. Transport of Basic Data Types ........................27
A.1.2. Transport of Authentication and Security Data ........27
A.1.3. Opaque Data Types ....................................27
A.1.4. Pre-existing Data Types ..............................28
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................4
1.3. Applicability ..............................................5
1.3.1. Reviews .............................................5
2. Guidelines ......................................................6
2.1. Data Types .................................................8
2.2. Vendor Space ...............................................9
2.3. Service Definitions and RADIUS .............................9
2.4. Translation of Vendor Specifications ......................10
3. Rationale ......................................................11
3.1. RADIUS Operational Model ..................................11
3.2. Data Model Issues .........................................14
3.2.1. Issues with Definitions of Types ...................15
3.2.2. Tagging Mechanism ..................................16
3.2.3. Complex Data Types .................................16
3.2.4. Complex Data Type Exceptions .......................18
3.3. Vendor Space ..............................................19
3.3.1. Interoperability Considerations ....................20
3.3.2. Vendor Allocations .................................20
3.3.3. SDO Allocations ....................................20
3.4. Polymorphic Attributes ....................................21
4. IANA Considerations ............................................22
5. Security Considerations ........................................22
5.1. New Data Types and Complex Attributes .....................23
6. References .....................................................24
6.1. Normative References ......................................24
6.2. Informative References ....................................24
Appendix A. Design Guidelines Checklist ..........................27
A.1. Types Matching the RADIUS Data Model ......................27
A.1.1. Transport of Basic Data Types ........................27
A.1.2. Transport of Authentication and Security Data ........27
A.1.3. Opaque Data Types ....................................27
A.1.4. Pre-existing Data Types ..............................28
A.2. Improper Data Types .......................................28
A.2.1. Simple Data Types ....................................28
A.2.2. More Complex Data Types ..............................29
A.3. Vendor-Specific Formats ...................................29
A.4. Changes to the RADIUS Operational Model ...................30
A.5. Allocation of Attributes ..................................31
Appendix B. Complex Attributes ...................................32
B.1. CHAP-Password .............................................32
B.2. CHAP-Challenge ............................................32
B.3. Tunnel-Password ...........................................33
B.4. ARAP-Password .............................................33
B.5. ARAP-Features .............................................34
B.6. Connect-Info ..............................................34
B.7. Framed-IPv6-Prefix ........................................35
B.8. Egress-VLANID .............................................36
B.9. Egress-VLAN-Name ..........................................37
B.10. Digest-* .................................................37
Acknowledgments ...................................................37
A.2. Improper Data Types .......................................28
A.2.1. Simple Data Types ....................................28
A.2.2. More Complex Data Types ..............................29
A.3. Vendor-Specific Formats ...................................29
A.4. Changes to the RADIUS Operational Model ...................30
A.5. Allocation of Attributes ..................................31
Appendix B. Complex Attributes ...................................32
B.1. CHAP-Password .............................................32
B.2. CHAP-Challenge ............................................32
B.3. Tunnel-Password ...........................................33
B.4. ARAP-Password .............................................33
B.5. ARAP-Features .............................................34
B.6. Connect-Info ..............................................34
B.7. Framed-IPv6-Prefix ........................................35
B.8. Egress-VLANID .............................................36
B.9. Egress-VLAN-Name ..........................................37
B.10. Digest-* .................................................37
Acknowledgments ...................................................37
This document provides guidelines for the design of Remote Authentication Dial In User Service (RADIUS) attributes within the IETF as well as within other Standards Development Organizations (SDOs). By articulating RADIUS design guidelines, it is hoped that this document will encourage the development and publication of high-quality RADIUS attribute specifications.
本文件提供了IETF内以及其他标准开发组织（SDO）内远程认证拨入用户服务（RADIUS）属性的设计指南。通过阐述RADIUS设计指南，希望本文件将鼓励开发和发布高质量的RADIUS属性规范。
However, the advice in this document will not be helpful unless it is put to use. As with "Guidelines for Authors and Reviewers of MIB Documents" [RFC4181], it is expected that authors will check their document against the guidelines in this document prior to publication or requesting review (such as an "Expert Review" described in [RFC3575]). Similarly, it is expected that this document will be used by reviewers (such as WG participants or the Authentication, Authorization, and Accounting (AAA) Doctors [DOCTORS]), resulting in an improvement in the consistency of reviews.
然而，本文件中的建议除非付诸使用，否则将毫无帮助。与“MIB文件的作者和审阅者指南”[RFC4181]一样，预计作者将在出版或请求审阅之前对照本文件中的指南检查其文件（如[RFC3575]中所述的“专家审阅”）。同样，预计本文件将被审查人员（如工作组参与者或认证、授权和会计（AAA）医生[医生]）使用，从而提高审查的一致性。
In order to meet these objectives, this document needs to cover not only the science of attribute design but also the art. Therefore, in addition to covering the most frequently encountered issues, this document explains some of the considerations motivating the guidelines. These considerations include complexity trade-offs that make it difficult to provide "hard and fast" rules for attribute design. This document explains those trade-offs through reviews of current attribute usage.
为了实现这些目标，本文件不仅需要涵盖属性设计科学，还需要涵盖艺术。因此，除了涵盖最常遇到的问题外，本文件还解释了推动指南的一些考虑因素。这些考虑因素包括复杂性权衡，这使得难以为属性设计提供“硬性和快速性”规则。本文档通过对当前属性使用情况的回顾来解释这些权衡。
The rest of the document is organized as follows. Section 1 discusses the applicability of the guidelines and defines a recommended review process for RADIUS specifications. Section 2 defines the design guidelines in terms of what is "RECOMMENDED" and "NOT RECOMMENDED". Section 3 gives a longer explanation of the rationale behind the guidelines given in the previous section. Appendix A repeats the guidelines in a "checklist" format. Appendix B discusses previously defined attributes that do not follow the guidelines.
文件的其余部分组织如下。第1节讨论了指南的适用性，并定义了建议的RADIUS规范审查流程。第2节根据“推荐”和“不推荐”定义了设计指南。第3节对上一节中给出的指南背后的基本原理进行了较长的解释。附录A以“检查表”格式重复了指南。附录B讨论了之前定义的不符合指南的属性。
Authors of new RADIUS specifications can be compliant with the design guidelines by working through the checklists given in Appendix A. Reviewers of RADIUS specifications are expected to be familiar with the entire document.
新RADIUS规范的作者可以通过使用附录A中给出的检查表来遵守设计指南。RADIUS规范的审查人员应熟悉整个文件。
This document uses the following terms:
本文件使用以下术语：
Network Access Server (NAS) A device that provides an access service for a user to a network.
网络访问服务器（NAS）为用户提供网络访问服务的设备。
RADIUS server A RADIUS authentication, authorization, and accounting (AAA) server is an entity that provides one or more AAA services to a NAS.
RADIUS服务器RADIUS身份验证、授权和记帐（AAA）服务器是向NAS提供一个或多个AAA服务的实体。
Standard space Codes in the RADIUS Attribute Type Space that are allocated by IANA and that follow the format defined in Section 5 of RFC 2865 [RFC2865].
IANA分配的RADIUS属性类型空间中的标准空间代码，遵循RFC 2865[RFC2865]第5节中定义的格式。
Vendor space The contents of the Vendor-Specific Attribute (VSA), as defined in [RFC2865], Section 5.26. These attributes provide a unique attribute type space in the "String" field for each vendor (identified by the Vendor-Type field), which they can self-allocate.
供应商空间-供应商特定属性（VSA）的内容，如[RFC2865]第5.26节所定义。这些属性在“字符串”字段中为每个供应商（由“供应商类型”字段标识）提供唯一的属性类型空间，它们可以自行分配。
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 advice in this document applies to RADIUS attributes used to encode service-provisioning, authentication, or accounting data based on the attribute encodings and data formats defined in RFC 2865 [RFC2865], RFC 2866 [RFC2866], and subsequent RADIUS RFCs.
本文档中的建议适用于用于根据RFC 2865[RFC2865]、RFC 2866[RFC2866]和后续RADIUS RFC中定义的属性编码和数据格式对服务供应、认证或记帐数据进行编码的RADIUS属性。
Since this document represents a Best Current Practice, it does not update or deprecate existing standards. As a result, uses of the terms "MUST" and "MUST NOT" are limited to requirements already present in existing documents.
由于本文档代表了当前最佳实践，因此不会更新或弃用现有标准。因此，术语“必须”和“不得”的使用仅限于现有文件中已有的要求。
It is RECOMMENDED that these guidelines be followed for all new RADIUS specifications, whether they originate from a vendor, an SDO, or the IETF. Doing so will ensure the widest possible applicability and interoperability of the specifications, while requiring minimal changes to existing systems. In particular, it is expected that RADIUS specifications requesting allocation within the standard space will follow these guidelines and will explain why this is not possible if they cannot.
建议所有新的RADIUS规范都遵循这些指南，无论它们是来自供应商、SDO还是IETF。这样做将确保规范尽可能广泛的适用性和互操作性，同时要求对现有系统进行最小的更改。特别是，预计要求在标准空间内分配的半径规格将遵循这些指导原则，并将解释如果不能做到这一点，为什么这是不可能的。
However, there are situations in which vendors or SDOs can choose not to follow these guidelines without major consequences. As noted in Section 5.26 of [RFC2865], Vendor-Specific Attributes (VSAs) are "available to allow vendors to support their own extended Attributes not suitable for general usage". Where vendors or SDOs develop specifications "not suitable for general usage", limited interoperability and inability to use existing implementations may be acceptable, and, in these situations, vendors and SDOs MAY choose not to conform to these guidelines.
然而，在某些情况下，供应商或SDO可以选择不遵守这些准则，而不会产生重大后果。如[RFC2865]第5.26节所述，供应商特定属性（VSA）“可用于允许供应商支持其自身不适合一般用途的扩展属性”。如果供应商或SDO制定的规范“不适用于一般用途”，有限的互操作性和无法使用现有实现可能是可以接受的，在这些情况下，供应商和SDO可能选择不遵守这些指南。
Note that the RADEXT WG is currently (as of 2011) involved in developing updates to RADIUS. Those updates will provide their own usage guidelines that may modify some of the guidelines defined here, such as defining new data types, practices, etc.
请注意，RADEXT工作组目前（截至2011年）正在开发RADIUS的更新。这些更新将提供自己的使用指南，这些指南可能会修改此处定义的一些指南，例如定义新的数据类型、实践等。
RADIUS protocol changes, or specification of attributes (such as Service-Type), that can, in effect, provide new RADIUS commands require greater expertise and deeper review, as do changes to the RADIUS operational model. As a result, such changes are outside the scope of this document and MUST NOT be undertaken outside the IETF.
RADIUS协议更改或属性规范（如服务类型）实际上可以提供新的RADIUS命令，这需要更多的专业知识和更深入的审查，RADIUS操作模型的更改也是如此。因此，此类变更不在本文件范围内，不得在IETF范围外进行。
For specifications utilizing attributes within the standard space, conformance with the design guidelines in this document is expected unless a good case can be made for an exception. Reviewers SHOULD use the design guidelines as a review checklist.
对于在标准空间内使用属性的规范，除非有充分的例外情况，否则应符合本文件中的设计指南。评审员应使用设计指南作为评审清单。
While not required, IETF review may also be beneficial for specifications utilizing the vendor space. Experience has shown that attributes not originally designed for general usage can subsequently garner wide-spread deployment. An example is the Vendor-Specific Attributes defined in [RFC2548], which have been widely implemented within IEEE 802.11 Access Points.
虽然不需要，但IETF审查也可能有助于规范利用供应商空间。经验表明，最初不是为一般用途而设计的属性随后可以获得广泛的部署。一个例子是[RFC2548]中定义的特定于供应商的属性，这些属性已在IEEE 802.11接入点中广泛实现。
In order to assist in the development of specifications conforming to these guidelines, authors can request review by sending an email to the AAA Doctors [DOCTORS] or equivalent mailing list. The IETF Operations & Management Area Directors will then arrange for the review to be completed and posted to the AAA Doctors mailing list [DOCTORS], RADEXT WG mailing list, or other IETF mailing lists. Since reviews are handled by volunteers, responses are provided on a best-effort basis, with no service-level guarantees. Authors are encouraged to seek review as early as possible, so as to avoid potential delays.
为了帮助制定符合这些指南的规范，作者可以通过向AAA医生[医生]或同等邮件列表发送电子邮件请求审查。然后，IETF运营和管理区域总监将安排完成审查，并将其发布到AAA医生邮件列表[医生]、RADEXT WG邮件列表或其他IETF邮件列表中。由于审查由志愿者处理，因此在没有服务水平保证的情况下尽最大努力提供答复。鼓励作者尽早寻求审查，以避免潜在的延误。
As reviewers require access to the specification, vendors and SDOs are encouraged to make it publicly available. Where the RADIUS specification is embedded within a larger document that cannot be made public, the RADIUS attribute and value definitions can be made available on a public web site or can be published as an Informational RFC, as with [RFC4679].
由于审查人员需要访问规范，因此鼓励供应商和SDO将其公开。如果RADIUS规范嵌入在无法公开的较大文档中，则可以在公共网站上提供RADIUS属性和值定义，或作为信息RFC发布，如[RFC4679]。
The review process requires neither allocation of attributes within the standard space nor publication of an RFC. Requiring SDOs or vendors to rehost VSAs into the standard space solely for the purpose of obtaining review would put pressure on the standard space and may be harmful to interoperability since it would create two ways to provision the same service. Rehosting may also require changes to the RADIUS data model, which will affect implementations that do not intend to support the SDO or vendor specifications.
审查过程既不需要在标准空间内分配属性，也不需要发布RFC。要求SDO或供应商仅为了获得审查而将VSA重新部署到标准空间，这将给标准空间带来压力，并可能有害于互操作性，因为这将创建提供相同服务的两种方式。重新宿主可能还需要更改RADIUS数据模型，这将影响不打算支持SDO或供应商规范的实现。
Similarly, vendors are encouraged to make their specifications publicly available, for maximum interoperability. However, it is not necessary for a vendor to request publication of a VSA specification as an RFC.
同样，鼓励供应商公开其规范，以实现最大的互操作性。但是，供应商无需请求将VSA规范发布为RFC。
The RADIUS protocol as defined in [RFC2865] and [RFC2866] uses elements known as attributes in order to represent authentication, authorization, and accounting data.
[RFC2865]和[RFC2866]中定义的RADIUS协议使用称为属性的元素来表示身份验证、授权和记帐数据。
Unlike Simple Network Management Protocol (SNMP), first defined in [RFC1157] and [RFC1155], RADIUS does not define a formal data definition language. The data type of RADIUS attributes is not transported on the wire. Rather, the data type of a RADIUS attribute is fixed when an attribute is defined. Based on the RADIUS attribute type code, RADIUS clients and servers can determine the data type based on pre-configured entries within a data dictionary.
与[RFC1157]和[RFC1155]中首次定义的简单网络管理协议（SNMP）不同，RADIUS没有定义正式的数据定义语言。半径属性的数据类型不会在导线上传输。相反，定义属性时，半径属性的数据类型是固定的。基于RADIUS属性类型代码，RADIUS客户端和服务器可以根据数据字典中预先配置的条目确定数据类型。
To explain the implications of this early RADIUS design decision, we distinguish two kinds of data types, namely "basic" and "complex". Basic data types use one of the existing RADIUS data types as defined in Section 2.1, encapsulated in a [RFC2865] RADIUS attribute or in a [RFC2865] RADIUS VSA. All other data formats are "complex types".
为了解释早期RADIUS设计决策的含义，我们区分了两种数据类型，即“基本”和“复杂”。基本数据类型使用第2.1节中定义的现有RADIUS数据类型之一，封装在[RFC2865]RADIUS属性或[RFC2865]RADIUS VSA中。所有其他数据格式都是“复杂类型”。
RADIUS attributes can be classified into one of three broad categories:
半径属性可分为三大类之一：
* Attributes that are of interest to a single vendor, e.g., for a product or product line. Minimal cross-vendor interoperability is needed.
* 单个供应商感兴趣的属性，例如产品或产品线的属性。需要最低限度的跨供应商互操作性。
Vendor-Specific Attributes (VSAs) are appropriate for use in this situation. Code-point allocation is managed by the vendor with the vendor space defined by their Private Enterprise Number (PEN), as given in the Vendor-Id field.
供应商特定属性（VSA）适用于这种情况。代码点分配由供应商管理，供应商空间由其私有企业编号（PEN）定义，如供应商Id字段中所示。
* Attributes that are of interest to an industry segment, where an SDO defines the attributes for that industry. Multi-vendor interoperability within an industry segment is expected.
* 与行业细分相关的属性，其中SDO定义了该行业的属性。预计行业内的多供应商互操作性。
Vendor-Specific Attributes (VSAs) MUST be used. Code-point allocation is managed by the SDO with the vendor space defined by the SDO's PEN rather than the PEN of an individual vendor.
必须使用特定于供应商的属性（VSA）。代码点分配由SDO管理，供应商空间由SDO的PEN而不是单个供应商的PEN定义。
* Attributes that are of broad interest to the Internet community. Multi-vendor interoperability is expected.
* 互联网社区广泛感兴趣的属性。多供应商互操作性是预期的。
Attributes within the standard space are appropriate for this purpose and are allocated via IANA as described in [RFC3575]. Since the standard space represents a finite resource, and is the only attribute space available for use by IETF working groups, vendors, and SDOs are encouraged to utilize the vendor space rather than request allocation of attributes from the standard space. Usage of attribute type codes reserved for standard attributes is considered antisocial behavior and is strongly discouraged.
标准空间内的属性适用于此目的，并通过IANA进行分配，如[RFC3575]所述。由于标准空间代表有限的资源，是IETF工作组可用的唯一属性空间，因此鼓励供应商和SDO利用供应商空间，而不是从标准空间请求属性分配。使用为标准属性保留的属性类型代码被视为反社会行为，强烈反对。
RADIUS defines a limited set of data types, defined as "basic data types". The following data qualifies as "basic data types":
RADIUS定义了一组有限的数据类型，定义为“基本数据类型”。以下数据符合“基本数据类型”的条件：
* 32-bit unsigned integer in network byte order.
* 网络字节顺序的32位无符号整数。
* Enumerated data types, represented as a 32-bit unsigned integer with a list of name to value mappings (e.g., Service-Type).
* 枚举数据类型，表示为32位无符号整数，带有名称到值映射列表（例如，服务类型）。
* IPv4 address in network byte order.
* 按网络字节顺序排列的IPv4地址。
* Time as a 32-bit unsigned value in network byte order and in seconds since 00:00:00 UTC, January 1, 1970.
* 自1970年1月1日UTC 00:00:00以来，以网络字节顺序和秒为单位的32位无符号值的时间。
* IPv6 address in network byte order.
* 按网络字节顺序排列的IPv6地址。
* Interface-Id (8-octet string in network byte order).
* 接口Id（以网络字节顺序排列的8位字节字符串）。
* IPv6 prefix.
* IPv6前缀。
* String (i.e., binary data), totaling 253 octets or less in length. This includes the opaque encapsulation of data structures defined outside of RADIUS. See also Appendix A.1.3 for additional discussion.
* 字符串（即二进制数据），总长度不超过253个八位字节。这包括在RADIUS之外定义的数据结构的不透明封装。更多讨论请参见附录A.1.3。
* UTF-8 text [RFC3629], totaling 253 octets or less in length.
* UTF-8文本[RFC3629]，总长度不超过253个八位字节。
Note that the length limitations for VSAs of type String and Text are less than 253 octets, due to the additional overhead of the Vendor-Specific encoding.
请注意，由于供应商特定编码的额外开销，字符串和文本类型的VSA的长度限制小于253个八位字节。
The following data also qualifies as "basic data types":
以下数据也可称为“基本数据类型”：
* Attributes grouped into a logical container using the [RFC2868] tagging mechanism. This approach is NOT RECOMMENDED (see Section 3.2.2) but is permissible where the alternatives are worse.
* 使用[RFC2868]标记机制将属性分组到逻辑容器中。不建议采用这种方法（见第3.2.2节），但在备选方案更差的情况下允许采用这种方法。
* Attributes requiring the transport of more than 253 octets of Text or String data. This includes the opaque encapsulation of data structures defined outside of RADIUS, e.g., EAP-Message.
* 需要传输超过253个八位字节的文本或字符串数据的属性。这包括在RADIUS之外定义的数据结构的不透明封装，例如EAP消息。
All other data formats (including nested attributes) are defined to be "complex data types" and are NOT RECOMMENDED for normal use. Complex data types MAY be used in situations where they reduce complexity in non-RADIUS systems or where using the basic data types would be awkward (such as where grouping would be required in order
所有其他数据格式（包括嵌套属性）都定义为“复杂数据类型”，不建议正常使用。复杂数据类型可用于降低非RADIUS系统复杂性的情况，或使用基本数据类型会比较麻烦的情况（例如需要按顺序分组的情况）
to link related attributes). Since there are no "hard and fast" rules for where complexity is best located, each situation has to be decided on a case-by-case basis. Examples of this trade-off are discussed in Appendix B. Where a complex data type is selected, an explanation SHOULD be offered as to why this was necessary.
链接相关属性）。由于没有“硬性”规则来确定复杂性的最佳位置，因此必须根据具体情况来决定每种情况。附录B中讨论了这种权衡的示例。如果选择了复杂的数据类型，则应解释为什么需要这样做。
The Vendor space is defined to be the contents of the Vendor-Specific Attribute ([RFC2865], Section 5.26) where the Vendor-Id defines the space for a particular vendor, and the contents of the "String" field define a unique attribute type space for that vendor. As discussed there, it is intended for vendors and SDOs to support their own attributes not suitable for general use.
供应商空间定义为供应商特定属性的内容（[RFC2865]，第5.26节），其中供应商Id定义了特定供应商的空间，“字符串”字段的内容定义了该供应商的唯一属性类型空间。正如这里所讨论的，它旨在让供应商和SDO支持他们自己的不适合一般用途的属性。
While the encoding of attributes within the vendor space is under the control of vendors and SDOs, following the guidelines described here is advantageous since it enables maximum interoperability with minimal changes to existing systems.
虽然供应商空间中的属性编码由供应商和SDO控制，但遵循此处描述的指导原则是有利的，因为它可以在对现有系统进行最小更改的情况下实现最大的互操作性。
For example, RADIUS server support for new attributes using "basic data types" can typically be accomplished by editing a RADIUS dictionary, whereas "complex data types" typically require RADIUS server code changes, which can add complexity and delays in implementation.
例如，RADIUS服务器对使用“基本数据类型”的新属性的支持通常可以通过编辑RADIUS字典来实现，而“复杂数据类型”通常需要更改RADIUS服务器代码，这会增加实现的复杂性和延迟。
Vendor RADIUS Attribute specifications SHOULD self-allocate attributes from the vendor space rather than request an allocation from within the standard space.
供应商半径属性规范应该从供应商空间自行分配属性，而不是从标准空间内请求分配。
VSA encodings that do not follow the [RFC2865], Section 5.26 encoding scheme are NOT RECOMMENDED. Although [RFC2865] does not mandate it, implementations commonly assume that the Vendor Id can be used as a key to determine the on-the-wire encoding of a VSA. Vendors therefore SHOULD NOT use multiple encodings for VSAs that are associated with a particular Vendor Id. A vendor wishing to use multiple VSA encodings SHOULD request one Vendor Id for each VSA encoding that they will use.
不建议使用不符合[RFC2865]第5.26节编码方案的VSA编码。尽管[RFC2865]没有强制要求，但实现通常假定供应商Id可以用作确定VSA在线编码的密钥。因此，供应商不应为与特定供应商Id关联的VSA使用多个编码。希望使用多个VSA编码的供应商应为其将使用的每个VSA编码请求一个供应商Id。
RADIUS specifications define how an existing service or protocol can be provisioned using RADIUS, usually via the Service-Type Attribute. Therefore, it is expected that a RADIUS attribute specification will reference documents defining the protocol or service to be provisioned. Within the IETF, a RADIUS attribute specification
RADIUS规范定义了如何使用RADIUS（通常通过“服务类型”属性）配置现有服务或协议。因此，预计RADIUS属性规范将引用定义要提供的协议或服务的文档。在IETF中，半径属性规范
SHOULD NOT be used to define the protocol or service being provisioned. New services using RADIUS for provisioning SHOULD be defined elsewhere and referenced in the RADIUS specification.
不应用于定义正在配置的协议或服务。应在其他地方定义并在RADIUS规范中引用使用RADIUS进行资源调配的新服务。
New attributes, or new values of existing attributes, SHOULD NOT be used to define new RADIUS commands. RADIUS attributes are intended to:
新属性或现有属性的新值不应用于定义新的半径命令。半径属性旨在：
* authenticate users
* 验证用户
* authorize users (i.e., service provisioning or changes to provisioning)
* 授权用户（即服务供应或供应更改）
* account for user activity (i.e., logging of session activity)
* 用户活动的帐户（即，记录会话活动）
Requirements for allocation of new commands (i.e., the Code field in the packet header) and new attributes within the standard space are described in [RFC3575], Section 2.1.
[RFC3575]第2.1节描述了在标准空间内分配新命令（即数据包头中的代码字段）和新属性的要求。
[RFC2865], Section 5.26 defines Vendor-Specific Attributes as follows:
[RFC2865]，第5.26节定义了供应商特定属性，如下所示：
This Attribute is available to allow vendors to support their own extended Attributes not suitable for general usage. It MUST NOT affect the operation of the RADIUS protocol.
此属性可用于允许供应商支持自己的扩展属性，这些扩展属性不适合一般使用。它不得影响RADIUS协议的运行。
Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.
未配备解释客户发送的供应商特定信息的服务器必须忽略该信息（尽管可能会报告）。未收到所需供应商特定信息的客户机应尝试在没有供应商特定信息的情况下运行，尽管他们可能会在降级模式下这样做（并报告他们正在这样做）。
The limitation on changes to the RADIUS protocol effectively prohibits VSAs from changing fundamental aspects of RADIUS operation, such as modifying RADIUS packet sequences or adding new commands. However, the requirement for clients and servers to be able to operate in the absence of VSAs has proven to be less of a constraint since it is still possible for a RADIUS client and server to mutually indicate support for VSAs, after which behavior expectations can be reset.
对RADIUS协议更改的限制实际上禁止VSA更改RADIUS操作的基本方面，例如修改RADIUS数据包序列或添加新命令。然而，客户机和服务器能够在没有VSA的情况下运行的要求已被证明不是一个约束，因为RADIUS客户机和服务器仍然可以相互指示对VSA的支持，之后可以重置行为预期。
Therefore, RFC 2865 provides considerable latitude for development of new attributes within the vendor space, while prohibiting development of protocol variants. This flexibility implies that RADIUS attributes can often be developed within the vendor space without loss (and possibly even with gain) in functionality.
因此，RFC 2865为在供应商空间内开发新属性提供了相当大的自由度，同时禁止开发协议变体。这种灵活性意味着通常可以在供应商空间内开发RADIUS属性，而不会损失（甚至可能获得）功能。
As a result, translation of RADIUS attributes developed within the vendor space into the standard space may provide only modest benefits, while accelerating the exhaustion of the standard space. We do not expect that all RADIUS attribute specifications requiring interoperability will be developed within the IETF, and allocated from the standard space. A more scalable approach is to recognize the flexibility of the vendor space, while working toward improvements in the quality and availability of RADIUS attribute specifications, regardless of where they are developed.
因此，将供应商空间中开发的RADIUS属性转换为标准空间可能只会带来适度的好处，同时加速标准空间的耗尽。我们不期望要求互操作性的所有RADIUS属性规范都将在IETF内开发，并从标准空间分配。一种更具可扩展性的方法是认识到供应商空间的灵活性，同时努力提高RADIUS属性规范的质量和可用性，而不管这些规范是在哪里开发的。
It is therefore NOT RECOMMENDED that specifications intended solely for use by a vendor or SDO be translated into the standard space.
因此，不建议将仅供供应商或SDO使用的规范转换为标准空间。
This section outlines the rationale behind the above recommendations.
本节概述了上述建议背后的基本原理。
The RADIUS operational model includes several assumptions:
RADIUS运行模型包括几个假设：
* The RADIUS protocol is stateless.
* RADIUS协议是无状态的。
* Provisioning of services is not possible within an Access-Reject or Disconnect-Request.
* 在访问拒绝或断开连接请求中不可能提供服务。
* There is a distinction between authorization checks and user authentication.
* 授权检查和用户身份验证之间存在区别。
* The protocol provides for authentication and integrity protection of packets.
* 该协议提供了数据包的身份验证和完整性保护。
* The RADIUS protocol is a Request/Response protocol.
* RADIUS协议是一种请求/响应协议。
* The protocol defines packet length restrictions.
* 该协议定义了数据包长度限制。
While RADIUS server implementations may keep state, the RADIUS protocol is stateless, although information may be passed from one protocol transaction to another via the State Attribute. As a result, documents that require stateful protocol behavior without use of the State Attribute are inherently incompatible with RADIUS as defined in [RFC2865] and MUST be redesigned. See [RFC5080], Section 2.1.1 for additional discussion surrounding the use of the State Attribute.
虽然RADIUS服务器实现可以保持状态，但RADIUS协议是无状态的，尽管信息可以通过state属性从一个协议事务传递到另一个协议事务。因此，需要有状态协议行为而不使用State属性的文档本质上与[RFC2865]中定义的RADIUS不兼容，必须重新设计。有关使用状态属性的更多讨论，请参见[RFC5080]，第2.1.1节。
As noted in [RFC5080], Section 2.6, the intent of an Access-Reject is to deny access to the requested service. As a result, RADIUS does not allow the provisioning of services within an Access-Reject or
如[RFC5080]第2.6节所述，拒绝访问的目的是拒绝访问请求的服务。因此，RADIUS不允许在访问或拒绝中提供服务
Disconnect-Request. Documents that include provisioning of services within an Access-Reject or Disconnect-Request are inherently incompatible with RADIUS and need to be redesigned.
断开请求。包含在访问拒绝或断开连接请求中提供服务的文档本质上与RADIUS不兼容，需要重新设计。
[RFC5176], Section 3 notes the following:
[RFC5176]，第3节注释如下：
A Disconnect-Request MUST contain only NAS and session identification attributes. If other attributes are included in a Disconnect-Request, implementations MUST send a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included.
断开连接请求必须仅包含NAS和会话标识属性。如果断开连接请求中包含其他属性，则实现必须发送断开连接NAK；可能包含值为“Unsupported Attribute”的错误原因属性。
As a result, documents that include provisioning of services within a Disconnect-Request are inherently incompatible with RADIUS and need to be redesigned.
因此，包含在断开连接请求中提供服务的文档本质上与RADIUS不兼容，需要重新设计。
As noted in [RFC5080], Section 2.1.1, a RADIUS Access-Request may not contain user authentication attributes or a State Attribute linking the Access-Request to an earlier user authentication. Such an Access-Request, known as an authorization check, provides no assurance that it corresponds to a live user. RADIUS specifications defining attributes containing confidential information (such as Tunnel-Password) should be careful to prohibit such attributes from being returned in response to an authorization check. Also, [RFC5080], Section 2.1.1 notes that authentication mechanisms need to tie a sequence of Access-Request/Access-Challenge packets together into one authentication session. The State Attribute is RECOMMENDED for this purpose.
如[RFC5080]第2.1.1节所述，RADIUS访问请求可能不包含用户身份验证属性或将访问请求链接到早期用户身份验证的状态属性。这种被称为授权检查的访问请求不能保证它与活动用户相对应。定义包含机密信息的属性（如隧道密码）的RADIUS规范应小心，以禁止在响应授权检查时返回此类属性。此外，[RFC5080]，第2.1.1节指出，身份验证机制需要将一系列访问请求/访问质询数据包绑定到一个身份验证会话中。为此，建议使用“状态”属性。
While [RFC2865] did not require authentication and integrity protection of RADIUS Access-Request packets, subsequent authentication mechanism specifications, such as RADIUS/EAP [RFC3579] and Digest Authentication [RFC5090], have mandated authentication and integrity protection for certain RADIUS packets. [RFC5080], Section 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, including Access-Request packets performing authorization checks. It is expected that specifications for new RADIUS authentication mechanisms will continue this practice.
虽然[RFC2865]不要求对RADIUS访问请求数据包进行身份验证和完整性保护，但随后的身份验证机制规范，如RADIUS/EAP[RFC3579]和摘要身份验证[RFC5090]，已强制要求对某些RADIUS数据包进行身份验证和完整性保护。[RFC5080]，第2.1.1节为所有访问请求数据包（包括执行授权检查的访问请求数据包）推荐了此行为。预计新RADIUS认证机制的规范将继续这种做法。
The RADIUS protocol as defined in [RFC2865] is a request-response protocol spoken between RADIUS clients and servers. A single RADIUS request packet ([RFC2865], [RFC2866], or [RFC5176]) will solicit in response at most a single response packet, sent to the IP address and port of the RADIUS client that originated the request. Changes to this model are likely to require major revisions to existing implementations, and this practice is NOT RECOMMENDED.
[RFC2865]中定义的RADIUS协议是RADIUS客户端和服务器之间的请求-响应协议。单个RADIUS请求数据包（[RFC2865]、[RFC2866]或[RFC5176]）将请求最多一个响应数据包，发送到发起请求的RADIUS客户端的IP地址和端口。对此模型的更改可能需要对现有实现进行重大修订，不建议采用这种做法。
The Length field in the RADIUS packet header is defined in [RFC2865] Section 3. It is noted there that the maximum length of a RADIUS packet is 4096 octets. As a result, attribute designers SHOULD NOT assume that a RADIUS implementation can successfully process RADIUS packets larger than 4096 octets.
RADIUS数据包头中的长度字段在[RFC2865]第3节中定义。注意，RADIUS数据包的最大长度为4096个八位字节。因此，属性设计器不应假设RADIUS实现可以成功处理大于4096个八位字节的RADIUS数据包。
Even when packets are less than 4096 octets, they may be larger than the Path Maximum Transmission Unit (PMTU). Any packet larger than the PMTU will be fragmented, making communications more brittle as firewalls and filtering devices often discard fragments. Transport of fragmented UDP packets appears to be a poorly tested code path on network devices. Some devices appear to be incapable of transporting fragmented UDP packets, making it difficult to deploy RADIUS in a network where those devices are deployed. We RECOMMEND that RADIUS messages be kept as small possible.
即使数据包小于4096个八位字节，它们也可能大于路径最大传输单元（PMTU）。任何大于PMTU的数据包都将被碎片化，这使得通信更加脆弱，因为防火墙和过滤设备通常会丢弃碎片。在网络设备上，碎片UDP数据包的传输似乎是一个测试不良的代码路径。有些设备似乎无法传输分段的UDP数据包，这使得在部署这些设备的网络中部署RADIUS变得困难。我们建议RADIUS消息尽可能小。
If a situation is envisaged where it may be necessary to carry authentication, authorization, or accounting data in a packet larger than 4096 octets, then one of the following approaches is RECOMMENDED:
如果设想可能需要在大于4096个八位字节的数据包中携带身份验证、授权或记帐数据，则建议采用以下方法之一：
1. Utilization of a sequence of packets. For RADIUS authentication, a sequence of Access-Request/Access-Challenge packets would be used. For this to be feasible, attribute designers need to enable inclusion of attributes that can consume considerable space within Access-Challenge packets. To maintain compatibility with existing NASes, either the use of Access-Challenge packets needs to be permissible (as with RADIUS/EAP, defined in [RFC3579]) or support for receipt of an Access-Challenge needs to be indicated by the NAS (as in RADIUS Location [RFC5580]). Also, the specification needs to clearly describe how attribute splitting is to be signaled and how attributes included within the sequence are to be interpreted, without requiring stateful operation. Unfortunately, previous specifications have not always exhibited the required foresight. For example, even though very large filter rules are conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849] is not permitted in an Access-Challenge packet, nor is a mechanism specified to allow a set of NAS-Filter-Rule Attributes to be split across an Access-Request/Access-Challenge sequence.
1. 数据包序列的利用率。对于RADIUS身份验证，将使用一系列访问请求/访问质询数据包。为了实现这一点，属性设计者需要允许包含可能在访问质询数据包中消耗大量空间的属性。为了保持与现有NASE的兼容性，需要允许使用访问质询数据包（如[RFC3579]中定义的RADIUS/EAP），或者NAS需要指示对接收访问质询的支持（如RADIUS位置[RFC5580]）。此外，规范还需要清楚地描述如何用信号表示属性拆分，以及如何解释序列中包含的属性，而不需要有状态操作。不幸的是，以前的规范并不总是显示出所需的预见性。例如，即使可以想到非常大的过滤规则，[RFC4849]中定义的NAS过滤规则属性在访问质询数据包中是不允许的，也没有指定允许跨访问请求/访问质询序列分割一组NAS过滤规则属性的机制。
In the case of RADIUS accounting, transporting large amounts of data would require a sequence of Accounting-Request packets. This is a non-trivial change to RADIUS, since RADIUS accounting clients would need to be modified to split the
在RADIUS记帐的情况下，传输大量数据需要一系列记帐请求数据包。这是对RADIUS的一个非常重要的更改，因为需要修改RADIUS记帐客户机以拆分
attribute stream across multiple Accounting-Requests, and billing servers would need to be modified to reassemble and interpret the attribute stream.
跨多个记帐请求和计费服务器的属性流需要修改以重新组合和解释属性流。
2. Utilization of names rather than values. Where an attribute relates to a policy that could conceivably be pre-provisioned on the NAS, then the name of the pre-provisioned policy can be transmitted in an attribute rather than the policy itself, which could be quite large. An example of this is the Filter-Id Attribute defined in [RFC2865], Section 5.11, which enables a set of pre-provisioned filter rules to be referenced by name.
2. 使用名称而不是值。如果属性与可以在NAS上预配置的策略相关，那么预配置策略的名称可以在属性中传输，而不是在策略本身中传输，策略本身可能非常大。这方面的一个例子是[RFC2865]第5.11节中定义的过滤器Id属性，该属性允许按名称引用一组预先设置的过滤器规则。
3. Utilization of Packetization Layer Path MTU Discovery techniques, as specified in [RFC4821]. As a last resort, where the above techniques cannot be made to work, it may be possible to apply the techniques described in [RFC4821] to discover the maximum supported RADIUS packet size on the path between a RADIUS client and a home server. While such an approach can avoid the complexity of utilization of a sequence of packets, dynamic discovery is likely to be time consuming and cannot be guaranteed to work with existing RADIUS implementations. As a result, this technique is not generally applicable.
3. 利用[RFC4821]中规定的打包层路径MTU发现技术。作为最后的手段，在无法使上述技术发挥作用的情况下，可以应用[RFC4821]中描述的技术来发现RADIUS客户端和家庭服务器之间的路径上支持的最大RADIUS数据包大小。虽然这种方法可以避免数据包序列利用的复杂性，但动态发现可能很耗时，并且不能保证与现有RADIUS实现一起工作。因此，这种技术并不普遍适用。
While [RFC2865], Section 5 defines basic data types, later specifications did not follow this practice. This problem has led implementations to define their own names for data types, resulting in non-standard names for those types.
虽然[RFC2865]第5节定义了基本数据类型，但后来的规范没有遵循这种做法。这个问题导致实现为数据类型定义自己的名称，从而导致这些类型的名称不标准。
In addition, the number of vendors and SDOs creating new attributes within the vendor space has grown, and this has led to some divergence in approaches to RADIUS attribute design. For example, vendors and SDOs have evolved the data model to support functions such as new data types along with attribute grouping and attribute fragmentation, with different groups taking different approaches. These approaches are often incompatible, leading to additional complexity in RADIUS implementations.
此外，在供应商空间中创建新属性的供应商和SDO的数量有所增加，这导致RADIUS属性设计方法出现了一些分歧。例如，供应商和SDO已经改进了数据模型，以支持新的数据类型以及属性分组和属性分段等功能，不同的组采用不同的方法。这些方法通常不兼容，导致RADIUS实现的额外复杂性。
In order to avoid repeating old mistakes, this section describes the history of the RADIUS data model and attempts to codify existing practices.
为了避免重蹈覆辙，本节介绍了RADIUS数据模型的历史，并试图编纂现有实践。
[RFC2865], Section 5 explicitly defines five data types: text, string, address, integer, and time. Both the names and interpretations of the types are given.
[RFC2865]，第5节明确定义了五种数据类型：文本、字符串、地址、整数和时间。给出了类型的名称和解释。
Subsequent RADIUS specifications defined attributes by using type names not defined in [RFC2865], without defining the new names as done in [RFC2865]. They did not consistently indicate the format of the value field using the same conventions as [RFC2865]. As a result, the data type is ambiguous in some cases and may not be consistent among different implementations.
后续的RADIUS规范使用[RFC2865]中未定义的类型名称定义属性，而没有像[RFC2865]中那样定义新名称。它们没有使用与[RFC2865]相同的约定一致地指示值字段的格式。因此，数据类型在某些情况下是不明确的，并且在不同的实现中可能不一致。
It is out of the scope of this document to resolve all potential ambiguities within existing RADIUS specifications. However, in order to prevent future ambiguities, it is RECOMMENDED that future RADIUS attribute specifications explicitly define newly created data types at the beginning of the document and indicate clearly the data type to be used for each attribute.
解决现有RADIUS规范中的所有潜在歧义超出了本文件的范围。但是，为了防止将来出现歧义，建议将来的RADIUS属性规范在文档开头明确定义新创建的数据类型，并明确指出每个属性要使用的数据类型。
For example, [RFC3162] utilizes, but does not explicitly define, a type that encapsulates an IPv6 address (Sections 2.1 and 2.4) and another type that encapsulates an IPv6 prefix (Section 2.3). The IPv6 address attributes confusingly are referenced as type "Address" in the document. This is a similar name as the "address" type defined in [RFC2865], which was defined to refer solely to IPv4 addresses.
例如，[RFC3162]利用但未明确定义一种封装IPv6地址的类型（第2.1节和第2.4节）和另一种封装IPv6前缀的类型（第2.3节）。IPv6地址属性在文档中被混淆地引用为类型“address”。这是一个与[RFC2865]中定义的“地址”类型类似的名称，其定义仅指IPv4地址。
While the Framed-Interface-Id Attribute defined in [RFC3162], Section 2.2 included a value field of 8 octets, the data type was not explicitly indicated; therefore, there is controversy over whether the format of the data was intended to be an 8-octet String or whether a special Interface-Id type was intended.
虽然[RFC3162]第2.2节中定义的框架接口Id属性包含8个八位字节的值字段，但未明确指出数据类型；因此，对于数据的格式是8位字节字符串还是特殊的接口Id类型存在争议。
Given that attributes encapsulating an IPv6 address and an IPv6 prefix are already in use, it is RECOMMENDED that RADIUS server implementations include support for these as basic types, in addition to the types defined in [RFC2865]. Where the intent is to represent a specific IPv6 address, an "IPv6 address" type SHOULD be used. Although it is possible to use an "IPv6 Prefix" type with a prefix length of 128 to represent an IPv6 address, this usage is NOT RECOMMENDED. Implementations supporting the Framed-Interface-Id Attribute may select a data type of their choosing (most likely an 8-octet String or a special "Interface Id" data type).
鉴于封装IPv6地址和IPv6前缀的属性已经在使用，建议RADIUS服务器实现除了[RFC2865]中定义的类型外，还包括对这些基本类型的支持。如果目的是表示特定的IPv6地址，则应使用“IPv6地址”类型。虽然可以使用前缀长度为128的“IPv6前缀”类型来表示IPv6地址，但不建议使用此用法。支持框架接口Id属性的实现可以选择他们选择的数据类型（最有可能是8位字节字符串或特殊的“接口Id”数据类型）。
It is worth noting that since RADIUS only supports unsigned integers of 32 bits, attributes using signed integer data types or unsigned integer types of other sizes will require code changes and SHOULD be avoided.
值得注意的是，由于RADIUS仅支持32位的无符号整数，因此使用有符号整数数据类型或其他大小的无符号整数类型的属性将需要更改代码，应避免。
For [RFC2865] RADIUS VSAs, the length limitation of the String and Text types is 247 octets instead of 253 octets, due to the additional overhead of the Vendor-Specific Attribute.
对于[RFC2865]RADIUS VSA，由于供应商特定属性的额外开销，字符串和文本类型的长度限制为247个八位字节，而不是253个八位字节。
[RFC2868] defines an attribute grouping mechanism based on the use of a one-octet tag value. Tunnel attributes that refer to the same tunnel are grouped together by virtue of using the same tag value.
[RFC2868]定义了基于使用一个八位字节标记值的属性分组机制。引用同一隧道的隧道属性通过使用相同的标记值分组在一起。
This tagging mechanism has some drawbacks. There are a limited number of unique tags (31). The tags are not well suited for use with arbitrary binary data values because it is not always possible to tell if the first byte after the Length is the tag or the first byte of the untagged value (assuming the tag is optional).
这种标记机制有一些缺点。唯一标记的数量有限（31）。这些标记不适合与任意二进制数据值一起使用，因为并不总是能够分辨长度后的第一个字节是标记还是未标记值的第一个字节（假设标记是可选的）。
Other limitations of the tagging mechanism are that when integer values are tagged, the value portion is reduced to three bytes, meaning only 24-bit numbers can be represented. The tagging mechanism does not offer an ability to create nested groups of attributes. Some RADIUS implementations treat tagged attributes as having the additional data types tagged-string and tagged-integer. These types increase the complexity of implementing and managing RADIUS systems.
标记机制的其他限制是，当标记整数值时，值部分减少到三个字节，这意味着只能表示24位数字。标记机制不提供创建嵌套属性组的功能。一些RADIUS实现将标记属性视为具有标记字符串和标记整数的附加数据类型。这些类型增加了实施和管理RADIUS系统的复杂性。
For these reasons, the tagging scheme described in RFC 2868 is NOT RECOMMENDED for use as a generic grouping mechanism.
由于这些原因，不建议将RFC 2868中描述的标记方案用作通用分组机制。
As described in this section, the creation of complex types can lead to interoperability and deployment issues, so they need to be introduced with care. For example, the RADIUS attribute encoding is summarized in [RFC2865]:
如本节所述，创建复杂类型可能会导致互操作性和部署问题，因此需要谨慎地引入它们。例如，在[RFC2865]中总结了半径属性编码：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
However, some standard attributes pack multiple sub-fields into the "Value" field, resulting in the creation a non-standard, i.e., complex, type. Separating these sub-fields into different attributes, each with its own type and length, would have the following benefits:
但是，某些标准属性将多个子字段打包到“值”字段中，导致创建非标准（即复杂）类型。将这些子字段划分为不同的属性，每个属性都有自己的类型和长度，将有以下好处：
* When manual data entry is required, it is easier for an administrator to enter the data as well-known types rather than as complex structures.
* 当需要手动输入数据时，管理员更容易以已知类型而不是复杂结构输入数据。
* It enables additional error checking by leveraging the parsing and validation routines for well-known types.
* 它通过利用已知类型的解析和验证例程来实现额外的错误检查。
* It simplifies implementations by eliminating special-case, attribute-specific parsing.
* 它通过消除特定于属性的特殊情况解析简化了实现。
One of the fundamental goals of the RADIUS protocol design was to allow RADIUS servers to be configured to support new attributes, without requiring server code changes. RADIUS server implementations typically provide support for basic data types and define attributes in a data dictionary. This architecture enables a new attribute to be supported by the addition of a dictionary entry, without requiring other RADIUS server code changes.
RADIUS协议设计的基本目标之一是允许配置RADIUS服务器以支持新属性，而无需更改服务器代码。RADIUS服务器实现通常提供对基本数据类型的支持，并在数据字典中定义属性。此体系结构允许通过添加字典条目来支持新属性，而无需更改其他RADIUS服务器代码。
Code changes can also be required in policy management systems and in the RADIUS server's receive path. These changes are due to limitations in RADIUS server policy languages, which commonly provide for limited operations (such as comparisons or arithmetic operations) on the existing data types. Many existing RADIUS policy languages typically are not capable of parsing sub-elements or providing more sophisticated matching functionality.
策略管理系统和RADIUS服务器的接收路径中也可能需要更改代码。这些更改是由于RADIUS服务器策略语言的限制造成的，这些语言通常对现有数据类型提供有限的操作（如比较或算术操作）。许多现有的RADIUS策略语言通常无法解析子元素或提供更复杂的匹配功能。
On the RADIUS client, code changes are typically required in order to implement a new attribute. The RADIUS client typically has to compose the attribute dynamically when sending. When receiving, a RADIUS client needs to be able to parse the attribute and carry out the requested service. As a result, a detailed understanding of the new attribute is required on clients, and data dictionaries are less useful on clients than on servers.
在RADIUS客户端上，通常需要更改代码才能实现新属性。RADIUS客户端在发送时通常必须动态组合属性。接收时，RADIUS客户端需要能够解析属性并执行请求的服务。因此，需要对客户机上的新属性进行详细了解，数据字典在客户机上的用处不如在服务器上。
Given these limitations, the introduction of new types can require code changes on the RADIUS server, which would be unnecessary if basic data types had been used instead. In addition, if "ad hoc" types are used, attribute-specific parsing is required, which means more complex software to develop and maintain. More complexity can lead to more error-prone implementations, interoperability problems,
鉴于这些限制，引入新类型可能需要在RADIUS服务器上更改代码，如果使用基本数据类型，则不需要更改代码。此外，如果使用“特殊”类型，则需要特定于属性的解析，这意味着需要开发和维护更复杂的软件。更复杂的情况会导致更容易出错的实现、互操作性问题、，
and even security vulnerabilities. These issues can increase costs to network administrators as well as reduce reliability and introduce deployment barriers.
甚至还有安全漏洞。这些问题会增加网络管理员的成本，降低可靠性并引入部署障碍。
As described in Section 2.1, the introduction of complex data types is discouraged where viable alternatives are available. A potential exception is attributes that inherently require code changes on both the client and server. For example, as described in Appendix B, complex attributes have been used in situations involving authentication and security attributes, which need to be dynamically computed and verified. Supporting this functionality requires code changes on both the RADIUS client and server, regardless of the attribute format. As a result, in most cases, the use of complex attributes to represent these methods is acceptable and does not create additional interoperability or deployment issues.
如第2.1节所述，如果可行的替代方案可用，则不鼓励引入复杂数据类型。一个潜在的例外是固有地需要在客户端和服务器上更改代码的属性。例如，如附录B所述，复杂属性用于涉及身份验证和安全属性的情况，这些属性需要动态计算和验证。支持此功能需要在RADIUS客户端和服务器上更改代码，而不考虑属性格式。因此，在大多数情况下，使用复杂属性来表示这些方法是可以接受的，并且不会产生额外的互操作性或部署问题。
Another exception to the recommendation against complex types is for types that can be treated as opaque data by the RADIUS server. For example, the EAP-Message Attribute, defined in [RFC3579], Section 3.1, contains a complex data type that is an Extensible Authentication Protocol (EAP) packet. Since these complex types do not need to be parsed by the RADIUS server, the issues arising from server limitations do not arise. Similarly, since attributes of these complex types can be configured on the server using a data type of String, dictionary limitations are also not encountered. Appendix A.1 includes a series of checklists that may be used to analyze a design for RECOMMENDED and NOT RECOMMENDED behavior in relation to complex types.
针对复杂类型的建议的另一个例外是可被RADIUS服务器视为不透明数据的类型。例如，[RFC3579]第3.1节中定义的EAP消息属性包含一个复杂的数据类型，即可扩展身份验证协议（EAP）数据包。由于这些复杂类型不需要由RADIUS服务器解析，因此不会出现由服务器限制引起的问题。类似地，由于可以在服务器上使用字符串数据类型配置这些复杂类型的属性，因此也不会遇到字典限制。附录A.1包括一系列检查表，可用于分析与复杂类型相关的推荐和非推荐行为的设计。
If the RADIUS Server simply passes the contents of an attribute to some non-RADIUS portion of the network, then the data is opaque to RADIUS and SHOULD be defined to be of type String. A concrete way of judging this requirement is whether or not the attribute definition in the RADIUS document contains delineated fields for sub-parts of the data. If those fields need to be delineated in RADIUS, then the data is not opaque to RADIUS, and it SHOULD be separated into individual RADIUS attributes.
如果RADIUS服务器只是将属性的内容传递给网络的某个非RADIUS部分，那么该数据对RADIUS是不透明的，应该定义为字符串类型。判断此要求的具体方法是RADIUS文档中的属性定义是否包含数据子部分的划定字段。如果需要在RADIUS中描绘这些字段，则数据对RADIUS不是不透明的，并且应该将其分离为各个RADIUS属性。
An examination of existing RADIUS RFCs discloses a number of complex attributes that have already been defined. Appendix B includes a listing of complex attributes used within [RFC2865], [RFC2868], [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of these attributes includes reasons why a complex type is acceptable or suggestions for how the attribute could have been defined to follow the RADIUS data model.
对现有RADIUS RFC的检查揭示了许多已经定义的复杂属性。附录B包括[RFC2865]、[RFC2868]、[RFC2869]、[RFC3162]、[RFC4818]和[RFC4675]中使用的复杂属性列表。对这些属性的讨论包括为什么可以接受复杂类型的原因，或者关于如何定义属性以遵循RADIUS数据模型的建议。
In other cases, the data in the complex type are described textually in a specification. This is possible because the data types are not sent within the attributes but are a matter for endpoint interpretation. An implementation can define additional data types and use these data types today by matching them to the attribute's textual definition.
在其他情况下，复杂类型中的数据在规范中以文本形式描述。这是可能的，因为数据类型不是在属性中发送的，而是端点解释的问题。实现可以定义其他数据类型，并通过将这些数据类型与属性的文本定义相匹配来使用这些数据类型。
The usage model for RADIUS VSAs is described in [RFC2865], Section 6.2:
[RFC2865]第6.2节中描述了半径VSA的使用模型：
Note that RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) and the use of that should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful.
注意，RADIUS定义了供应商特定扩展（属性26）的机制，应鼓励使用该机制，而不是分配全局属性类型，用于仅针对一家供应商的RADIUS实现的功能，在这种情况下，互操作性被认为是没有用的。
Nevertheless, many new attributes have been defined in the vendor space in situations where interoperability is not only useful but is required. For example, SDOs outside the IETF (such as the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have been assigned Vendor-Ids, enabling them to define their own VSA encoding and assign Vendor types within their own vendor space, as defined by their unique Vendor-Id.
然而，在互操作性不仅有用而且需要的情况下，在供应商空间中定义了许多新属性。例如，IETF之外的SDO（如IEEE 802和第三代合作伙伴关系项目（3GPP））已分配供应商Id，使其能够定义自己的VSA编码，并在自己的供应商空间内分配由其唯一供应商Id定义的供应商类型。
The use of VSAs by SDOs outside the IETF has gained in popularity for several reasons:
IETF之外的SDO对VSA的使用越来越受欢迎，原因如下：
Efficiency As with SNMP, which defines an "Enterprise" Object Identifier (OID) space suitable for use by vendors as well as other SDOs, the definition of Vendor-Specific Attributes has become a common occurrence as part of standards activity outside the IETF. For reasons of efficiency, it is easiest if the RADIUS attributes required to manage a standard are developed within the same SDO that develops the standard itself. As noted in "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few vendors are willing to simultaneously fund individuals to participate within an SDO to complete a standard as well as to participate in the IETF in order to complete the associated RADIUS attributes specification.
效率与SNMP一样，SNMP定义了适合供应商和其他SDO使用的“企业”对象标识符（OID）空间，供应商特定属性的定义已成为IETF之外标准活动的一部分。出于效率考虑，如果管理标准所需的半径属性是在开发标准本身的同一SDO中开发的，则最简单。如“将MIB工作从IETF桥接MIB工作组转移到IEEE 802.1工作组”[RFC4663]中所述，目前很少有供应商愿意同时资助个人参与SDO以完成标准，也很少有供应商愿意参与IETF以完成相关的RADIUS属性规范。
Attribute scarcity The standard space is limited to 255 unique attributes. Of these, only about half remain available for allocation. In the vendor space, the number of attributes available is a function of the encoding of the attribute (the size of the Vendor type field).
属性空间标准空间限制为255个唯一属性。其中只有大约一半可供分配。在供应商空间中，可用属性的数量是属性编码（供应商类型字段的大小）的函数。
Vendors and SDOs are reminded that the standard space and the enumerated value space for enumerated attributes are reserved for allocation through work published via the IETF, as noted in [RFC3575], Section 2.1. In the past, some vendors and SDOs have assigned vendor-specific meaning to "unused" values from the standard space. This process results in interoperability issues and is counterproductive. Similarly, the vendor-specific enumeration practice discussed in [RFC2882], Section 2.2.1 is NOT RECOMMENDED.
供应商和SDO应注意，枚举属性的标准空间和枚举值空间是为通过IETF发布的作品分配而保留的，如[RFC3575]第2.1节所述。过去，一些供应商和SDO已将供应商特定的含义指定给标准空间中的“未使用”值。此过程会导致互操作性问题，并且会适得其反。同样，不建议采用[RFC2882]第2.2.1节中讨论的供应商特定枚举实践。
If it is not possible to follow the IETF process, vendors and SDOs SHOULD self-allocate an attribute, which MUST be in their own vendor space as defined by their unique Vendor-Id, as discussed in Sections 3.3.2 and 3.3.3.
如果无法遵循IETF流程，供应商和SDO应自行分配一个属性，该属性必须位于其唯一供应商Id定义的自己的供应商空间中，如第3.3.2和3.3.3节所述。
The design and specification of VSAs for multi-vendor usage SHOULD be undertaken with the same level of care as standard RADIUS attributes. Specifically, the provisions of this document that apply to standard RADIUS attributes also apply to VSAs for multi-vendor usage.
多供应商使用的VSA的设计和规范应与标准RADIUS属性一样谨慎。具体而言，本文件适用于标准RADIUS属性的规定也适用于多供应商使用的VSA。
As noted in [RFC3575], Section 2.1, vendors are encouraged to utilize VSAs to define 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".
如[RFC3575]第2.1节所述，鼓励供应商利用VSA定义功能“仅针对一家供应商实施的RADIUS，在这种情况下，互操作性被认为是无用的。对于仅针对一家供应商实施的RADIUS的功能，应鼓励使用该功能，而不是分配全局属性类型”。
The recommendation for vendors to allocate attributes from a vendor space rather than via the IETF process is a recognition that vendors desire to assert change control over their own RADIUS specifications. This change control can be obtained by requesting a PEN from the Internet Assigned Number Authority (IANA) for use as a Vendor-Id within a Vendor-Specific Attribute. The vendor can then allocate attributes within the vendor space defined by that Vendor-Id at their sole discretion. Similarly, the use of data types (complex or otherwise) within that vendor space is solely under the discretion of the vendor.
建议供应商从供应商空间而不是通过IETF流程分配属性，这是因为供应商希望对自己的RADIUS规范进行变更控制。可以通过从Internet分配号码管理局（IANA）请求笔作为供应商特定属性中的供应商Id来获得此更改控制。然后，供应商可自行决定在供应商Id定义的供应商空间内分配属性。同样，在该供应商空间内使用数据类型（复杂或其他）完全由供应商自行决定。
Given the expanded utilization of RADIUS, it has become apparent that requiring SDOs to accomplish all their RADIUS work within the IETF is inherently inefficient and unscalable. It is therefore RECOMMENDED
鉴于RADIUS的使用范围不断扩大，要求SDO在IETF内完成其所有RADIUS工作显然效率低下且无法扩展。因此，建议
that SDO RADIUS Attribute specifications allocate attributes from the vendor space rather than request an allocation from the RADIUS standard space for attributes matching any of the following criteria:
SDO RADIUS属性规范从供应商空间分配属性，而不是请求从RADIUS标准空间分配符合以下任何条件的属性：
* Attributes relying on data types not defined within RADIUS
* 依赖于RADIUS中未定义的数据类型的属性
* Attributes intended primarily for use within an SDO
* 主要用于SDO的属性
* Attributes intended primarily for use within a group of SDOs
* 主要用于SDO组内的属性
Any new RADIUS attributes or values intended for interoperable use across a broad spectrum of the Internet community SHOULD follow the allocation process defined in [RFC3575].
任何新的RADIUS属性或值都应遵循[RFC3575]中定义的分配过程，以便在互联网社区的广泛范围内进行互操作。
The recommendation for SDOs to allocate attributes from a vendor space rather than via the IETF process is a recognition that SDOs desire to assert change control over their own RADIUS specifications. This change control can be obtained by requesting a PEN from the Internet Assigned Number Authority (IANA) for use as a Vendor-Id within a Vendor-Specific Attribute. The SDO can then allocate attributes within the vendor space defined by that Vendor-Id at their sole discretion. Similarly, the use of data types (complex or otherwise) within that vendor space is solely under the discretion of the SDO.
SDO从供应商空间而不是通过IETF流程分配属性的建议是，SDO希望对自己的RADIUS规范进行变更控制。可以通过从Internet分配号码管理局（IANA）请求笔作为供应商特定属性中的供应商Id来获得此更改控制。然后，SDO可以自行决定在该供应商Id定义的供应商空间内分配属性。同样，在该供应商空间内使用数据类型（复杂或其他）完全由SDO决定。
A polymorphic attribute is one whose format or meaning is dynamic. For example, rather than using a fixed data format, an attribute's format might change based on the contents of another attribute. Or, the meaning of an attribute may depend on earlier packets in a sequence.
多态属性的格式或含义是动态的。例如，一个属性的格式可能会根据另一个属性的内容而改变，而不是使用固定的数据格式。或者，属性的含义可能取决于序列中较早的数据包。
RADIUS server dictionary entries are typically static, enabling the user to enter the contents of an attribute without support for changing the format based on dynamic conditions. However, this limitation on static types does not prevent implementations from implementing policies that return different attributes based on the contents of received attributes; this is a common feature of existing RADIUS implementations.
RADIUS服务器字典条目通常是静态的，使用户可以输入属性的内容，而不支持根据动态条件更改格式。但是，这种对静态类型的限制并不妨碍实现实现基于接收属性的内容返回不同属性的策略；这是现有RADIUS实现的一个常见功能。
In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely enables capabilities that would not be available through use of multiple attributes. Polymorphism requires code changes in the RADIUS server in situations where attributes with fixed formats would not require such changes. Thus, polymorphism increases complexity while decreasing generality, without delivering any corresponding benefits.
一般来说，不建议使用多态性。多态性很少启用通过使用多个属性无法使用的功能。多态性需要在RADIUS服务器中更改代码，而固定格式的属性不需要更改。因此，多态性增加了复杂性，同时降低了通用性，而没有带来任何相应的好处。
Note that changing an attribute's format dynamically is not the same thing as using a fixed format and computing the attribute itself dynamically. RADIUS authentication attributes, such as User-Password, EAP-Message, etc., while being computed dynamically, use a fixed format.
请注意，动态更改属性的格式与使用固定格式并动态计算属性本身不同。RADIUS身份验证属性（如用户密码、EAP消息等）在动态计算时使用固定格式。
This document has no action items for IANA. However, it does provide guidelines for Expert Reviewers appointed as described in [RFC3575].
本文件没有IANA的行动项目。但是，它确实为[RFC3575]中所述的专家评审员提供了指南。
This specification provides guidelines for the design of RADIUS attributes used in authentication, authorization, and accounting. Threats and security issues for this application are described in [RFC3579] and [RFC3580]; security issues encountered in roaming are described in [RFC2607].
本规范提供了用于身份验证、授权和记帐的RADIUS属性的设计指南。[RFC3579]和[RFC3580]中描述了此应用程序的威胁和安全问题；[RFC2607]中描述了漫游中遇到的安全问题。
Obfuscation of RADIUS attributes on a per-attribute basis is necessary in some cases. The current standard mechanism for this is described in [RFC2865], Section 5.2 (for obscuring User-Password values) and is based on the MD5 algorithm specified in [RFC1321]. The MD5 and SHA-1 algorithms have recently become a focus of scrutiny and concern in security circles, and as a result, the use of these algorithms in new attributes is NOT RECOMMENDED. In addition, previous documents referred to this method as generating "encrypted" data. This terminology is no longer accepted within the cryptographic community.
在某些情况下，有必要对每个属性的半径属性进行模糊处理。[RFC2865]第5.2节（用于模糊用户密码值）描述了当前的标准机制，并基于[RFC1321]中规定的MD5算法。MD5和SHA-1算法最近已成为安全界关注的焦点，因此，不建议在新属性中使用这些算法。此外，以前的文档将此方法称为生成“加密”数据。加密社区不再接受此术语。
Where new RADIUS attributes use cryptographic algorithms, algorithm negotiation SHOULD be supported. Specification of a mandatory-to-implement algorithm is REQUIRED, and it is RECOMMENDED that the mandatory-to-implement algorithm be certifiable under FIPS 140 [FIPS].
如果新的RADIUS属性使用加密算法，则应支持算法协商。需要指定强制执行算法，建议强制执行算法可根据FIPS 140[FIPS]进行认证。
Where new RADIUS attributes encapsulate complex data types, or transport opaque data, the security considerations discussed in Section 5.1 SHOULD be addressed.
如果新的RADIUS属性封装了复杂的数据类型或传输不透明的数据，则应解决第5.1节中讨论的安全注意事项。
Message authentication in RADIUS is provided largely via the Message-Authenticator attribute. See Section 3.2 of [RFC3579] and also Section 2.2.2 of [RFC5080], which say that client implementations SHOULD include a Message-Authenticator Attribute in every Access-Request.
RADIUS中的消息身份验证主要通过消息验证器属性提供。请参见[RFC3579]的第3.2节和[RFC5080]的第2.2.2节，其中指出客户端实现应在每个访问请求中包含消息验证器属性。
In general, the security of the RADIUS protocol is poor. Robust deployments SHOULD support a secure communications protocol such as IPsec. See Section 4 of [RFC3579] and Section 5 of [RFC3580] for a more in-depth explanation of these issues.
一般来说，RADIUS协议的安全性较差。强健的部署应支持安全通信协议，如IPsec。有关这些问题的更深入解释，请参见[RFC3579]第4节和[RFC3580]第5节。
Implementations not following the suggestions outlined in this document may be subject to problems such as ambiguous protocol decoding, packet loss leading to loss of billing information, and denial-of-service attacks.
不遵循本文档中概述的建议的实现可能会遇到诸如协议解码不明确、导致计费信息丢失的数据包丢失以及拒绝服务攻击等问题。
The introduction of complex data types brings the potential for the introduction of new security vulnerabilities. Experience shows that the common data types have few security vulnerabilities, or else that all known issues have been found and fixed. New data types require new code, which may introduce new bugs and therefore new attack vectors.
复杂数据类型的引入带来了引入新安全漏洞的可能性。经验表明，常见数据类型几乎没有安全漏洞，或者所有已知问题都已被发现并修复。新的数据类型需要新的代码，这可能会引入新的bug，从而产生新的攻击向量。
Some systems permit complex attributes to be defined via a method that is more capable than traditional RADIUS dictionaries. These systems can reduce the security threat of new types significantly, but they do not remove it entirely.
一些系统允许通过比传统RADIUS字典更强大的方法定义复杂属性。这些系统可以显著降低新类型的安全威胁，但不能完全消除这种威胁。
RADIUS servers are highly valued targets, as they control network access and interact with databases that store usernames and passwords. An extreme outcome of a vulnerability due to a new, complex type would be that an attacker is capable of taking complete control over the RADIUS server.
RADIUS服务器是非常有价值的目标，因为它们控制网络访问并与存储用户名和密码的数据库交互。由于新的复杂类型而导致的漏洞的极端后果是攻击者能够完全控制RADIUS服务器。
The use of attributes representing opaque data does not reduce this threat. The threat merely moves from the RADIUS server to the system that consumes that opaque data. The threat is particularly severe when the opaque data originates from the user and is not validated by the NAS. In those cases, the RADIUS server is potentially exposed to attack by malware residing on an unauthenticated host.
使用表示不透明数据的属性并不能减少这种威胁。威胁只是从RADIUS服务器转移到使用不透明数据的系统。当不透明数据源于用户且未经NAS验证时，威胁尤其严重。在这些情况下，RADIUS服务器可能会受到驻留在未经验证主机上的恶意软件的攻击。
Any system consuming opaque data that originates from a RADIUS system SHOULD be properly isolated from that RADIUS system and SHOULD run with minimal privileges. Any potential vulnerabilities in the non-RADIUS system will then have minimal impact on the security of the system as a whole.
任何使用源自RADIUS系统的不透明数据的系统都应与RADIUS系统正确隔离，并应以最低权限运行。非RADIUS系统中的任何潜在漏洞将对整个系统的安全性产生最小的影响。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC3575]Aboba，B.“RADIUS（远程认证拨入用户服务）的IANA注意事项”，RFC 3575，2003年7月。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
[RFC1155]Rose，M.和K.McCloghrie，“基于TCP/IP的互联网管理信息的结构和识别”，STD 16，RFC 1155，1990年5月。
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", RFC 1157, May 1990.
[RFC1157]Case，J.，Fedor，M.，Schoffstall，M.，和J.Davin，“简单网络管理协议（SNMP）”，RFC 1157，1990年5月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]Zorn，G.，“微软特定于供应商的半径属性”，RFC 2548，1999年3月。
[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月。
[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月。
[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月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580]Congdon，P.，Aboba，B.，Smith，A.，Zorn，G.，和J.Roese，“IEEE 802.1X远程认证拨入用户服务（RADIUS）使用指南”，RFC 35802003年9月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181]Heard，C.，Ed.，“MIB文件的作者和评审者指南”，BCP 111，RFC 41812005年9月。
[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG", RFC 4663, September 2006.
[RFC4663]Harrington，D.，“将MIB工作从IETF桥接MIB工作组转移到IEEE 802.1工作组”，RFC 4663，2006年9月。
[RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006.
[RFC4675]Congdon，P.，Sanchez，M.，和B.Aboba，“虚拟LAN和优先级支持的RADIUS属性”，RFC 4675，2006年9月。
[RFC4679] Mammoliti, V., Zorn, G., Arberg, P., and R. Rennison, "DSL Forum Vendor-Specific RADIUS Attributes", RFC 4679, September 2006.
[RFC4679]Mammoliti，V.，Zorn，G.，Arberg，P.，和R.Rennison，“DSL论坛供应商特定半径属性”，RFC 4679，2006年9月。
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007.
[RFC4818]Salowey，J.和R.Droms，“RADIUS-IPv6-Prefix属性”，RFC 4818，2007年4月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter Rule Attribute", RFC 4849, April 2007.
[RFC4849]Congdon，P.，Sanchez，M.和B.Aboba，“半径过滤器规则属性”，RFC 4849，2007年4月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080]Nelson，D.和A.DeKok，“通用远程身份验证拨入用户服务（RADIUS）实施问题和建议修复”，RFC 50802007年12月。
[RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 5090, February 2008.
[RFC5090]Sterman，B.，Sadolevsky，D.，Schwartz，D.，Williams，D.，和W.Beck，“摘要认证的半径扩展”，RFC 50902008年2月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5176]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 51762008年1月。
[DOCTORS] AAA Doctors Mailing List, www.ietf.org/mail-archive/web/aaa-doctors.
[医生]AAA医生邮件列表，www.ietf.org/mail-archive/web/AAA-DOCTORS。
[FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic Modules", http://csrc.nist.gov/publications/PubsFIPS.html.
[FIPS]FIPS 140-3（草案），“加密模块的安全要求”，http://csrc.nist.gov/publications/PubsFIPS.html.
[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q-2003, January 2003.
[IEEE-802.1Q]IEEE局域网和城域网标准：虚拟桥接局域网标准草案，P802.1Q-2003，2003年1月。
[RFC5580] Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009.
[RFC5580]Tschofenig，H.，Ed.，Adrangi，F.，Jones，M.，Lior，A.，和B.Aboba，“以半径和直径携带定位物体”，RFC 55802009年8月。
[AAA-SIP] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", Work in Progress, November 2004.
[AAA-SIP]Sterman，B.，Sadolevsky，D.，Schwartz，D.，Williams，D.，和W.Beck，“用于摘要认证的半径扩展”，正在进行的工作，2004年11月。
The following text provides guidelines for the design of attributes used by the RADIUS protocol. Specifications that follow these guidelines are expected to achieve maximum interoperability with minimal changes to existing systems.
以下文本提供了RADIUS协议所用属性的设计指南。遵循这些准则的规范有望在对现有系统进行最小更改的情况下实现最大的互操作性。
Does the data fit within the basic data types described in Section 2.1? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS attribute or in a [RFC2865] format RADIUS VSA that uses one of the existing RADIUS data types.
数据是否符合第2.1节所述的基本数据类型？如果是，则应将其封装为[RFC2865]格式的RADIUS属性或使用现有RADIUS数据类型之一的[RFC2865]格式的RADIUS VSA。
Does the data provide authentication and/or security capabilities for the RADIUS protocol as outlined below? If so, use of a complex data type is acceptable under the following circumstances:
数据是否为RADIUS协议提供如下所述的身份验证和/或安全功能？如果是，在以下情况下，可以使用复杂数据类型：
* Complex data types that carry authentication methods that RADIUS servers are expected to parse and verify as part of an authentication process.
* 携带身份验证方法的复杂数据类型，RADIUS服务器在身份验证过程中需要解析和验证这些方法。
* Complex data types that carry security information intended to increase the security of the RADIUS protocol itself.
* 携带安全信息的复杂数据类型，旨在提高RADIUS协议本身的安全性。
Any data type carrying authentication and/or security data that is not meant to be parsed by a RADIUS server is an "opaque data type", as defined in Section A.1.3.
任何携带认证和/或安全数据的数据类型，如果不打算由RADIUS服务器解析，则属于“不透明数据类型”，如第a.1.3节所定义。
Does the attribute encapsulate an existing data structure defined outside of the RADIUS specifications? Can the attribute be treated as opaque data by RADIUS servers (including proxies)? If both questions can be answered affirmatively, a complex structure MAY be used in a RADIUS specification.
该属性是否封装了RADIUS规范之外定义的现有数据结构？RADIUS服务器（包括代理）是否可以将该属性视为不透明数据？如果这两个问题都能得到肯定的回答，则可以在半径规范中使用复杂结构。
The specification of the attribute SHOULD define the encapsulating attribute to be of type String. The specification SHOULD refer to an external document defining the structure. The specification SHOULD NOT define or describe the structure, for reasons discussed in Section 3.2.3.
属性的规范应将封装属性定义为字符串类型。规范应参考定义结构的外部文件。由于第3.2.3节讨论的原因，规范不应定义或描述结构。
There is a trade-off in design between reusing existing formats for historical compatibility or choosing new formats for a "better" design. This trade-off does not always require the "better" design to be used. As a result, pre-existing complex data types described in Appendix B MAY be used.
在设计中，需要在重用现有格式以实现历史兼容性和选择新格式以实现“更好”设计之间进行权衡。这种权衡并不总是要求使用“更好”的设计。因此，可以使用附录B中描述的预先存在的复杂数据类型。
This section suggests alternatives to data types that do not fall within the "basic data type" definition. Section A.2.1 describes simple data types, which should be replaced by basic data types. Section A.2.2 describes more complex data types, which should be replaced by multiple attributes using the basic data types.
本节建议不属于“基本数据类型”定义的数据类型的替代方案。第A.2.1节描述了简单数据类型，这些数据类型应替换为基本数据类型。第A.2.2节描述了更复杂的数据类型，应使用基本数据类型将其替换为多个属性。
Does the attribute use any of the following data types? If so, the data type SHOULD be replaced with the suggested alternatives, or it SHOULD NOT be used at all.
该属性是否使用以下任何数据类型？如果是这样，则应使用建议的备选方案替换该数据类型，否则根本不应使用该数据类型。
* Signed integers of any size. SHOULD NOT be used. SHOULD be replaced with one or more unsigned integer attributes. The definition of the attribute can contain information that would otherwise go into the sign value of the integer.
* 任意大小的有符号整数。不应使用。应替换为一个或多个无符号整数属性。属性的定义可以包含否则将进入整数符号值的信息。
* 8-bit unsigned integers. SHOULD be replaced with 32-bit unsigned integer. There is insufficient justification to save three bytes.
* 8位无符号整数。应替换为32位无符号整数。没有足够的理由保存三个字节。
* 16-bit unsigned integers. SHOULD be replaced with 32-bit unsigned integer. There is insufficient justification to save two bytes.
* 16位无符号整数。应替换为32位无符号整数。没有足够的理由保存两个字节。
* Unsigned integers of size other than 32 bits. SHOULD be replaced by an unsigned integer of 32 bits. There is insufficient justification to define a new size of integer.
* 大小不是32位的无符号整数。应替换为32位的无符号整数。没有足够的理由来定义整数的新大小。
* Integers of any size in non-network byte order. SHOULD be replaced by unsigned integer of 32 bits in network. There is no reason to transport integers in any format other than network byte order.
* 非网络字节顺序的任意大小的整数。在网络中应替换为32位的无符号整数。没有理由以网络字节顺序以外的任何格式传输整数。
* Multi-field text strings. Each field SHOULD be encapsulated in a separate attribute.
* 多字段文本字符串。每个字段应封装在单独的属性中。
* Polymorphic attributes. Multiple attributes, each with a static data type, SHOULD be defined instead.
* 多态属性。应该定义多个属性，每个属性都有一个静态数据类型。
* Nested attribute-value pairs (AVPs). Attributes should be defined in a flat typespace.
* 嵌套属性值对（AVP）。属性应该在平面类型空间中定义。
Does the attribute:
属性是否：
* define a complex data type not described in Appendix B?
* 定义附录B中未描述的复杂数据类型？
* that a RADIUS server and/or client is expected to parse, validate, or create the contents of via a dynamic computation (i.e., a type that cannot be treated as opaque data (Section A.1.3))?
* RADIUS服务器和/或客户端应通过动态计算（即，不能视为不透明数据的类型（第a.1.3节））解析、验证或创建的内容？
* involve functionality that could be implemented without code changes on both the client and server (i.e., a type that doesn't require dynamic computation and verification, such as those performed for authentication or security attributes)?
* 涉及可以在客户端和服务器上实现而无需代码更改的功能（即，不需要动态计算和验证的类型，例如为身份验证或安全属性执行的类型）？
If so, this data type SHOULD be replaced with simpler types, as discussed in Appendix A.2.1. See also Section 2.1 for a discussion of why complex types are problematic.
如果是这样，则应将该数据类型替换为更简单的类型，如附录A.2.1所述。另请参见第2.1节，了解为什么复杂类型会有问题。
Does the specification contain Vendor-Specific Attributes that match any of the following criteria? If so, the VSA encoding should be replaced with the [RFC2865], Section 5.26 encoding or should not be used at all.
规范是否包含符合以下任何标准的供应商特定属性？如果是这样，VSA编码应替换为[RFC2865]，第5.26节编码，或者根本不应使用。
* Vendor types of more than 8 bits. SHOULD NOT be used. Vendor types of 8 bits SHOULD be used instead.
* 超过8位的供应商类型。不应使用。应使用8位的供应商类型。
* Vendor lengths of less than 8 bits (i.e., zero bits). SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used instead.
* 供应商长度小于8位（即零位）。不应使用。应改用8位的供应商长度。
* Vendor lengths of more than 8 bits. SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used instead.
* 供应商长度超过8位。不应使用。应改用8位的供应商长度。
* Vendor-specific contents that are not in Type-Length-Value format. SHOULD NOT be used. Vendor-Specific Attributes SHOULD be in Type-Length-Value format.
* 不是类型长度值格式的供应商特定内容。不应使用。供应商特定属性应采用类型长度值格式。
In general, Vendor-Specific Attributes SHOULD follow the encoding suggested in Section 5.26 of [RFC2865]. Vendor extensions to non-standard encodings are NOT RECOMMENDED as they can negatively affect interoperability.
一般而言，供应商特定属性应遵循[RFC2865]第5.26节中建议的编码。不建议供应商对非标准编码进行扩展，因为它们会对互操作性产生负面影响。
Does the specification change the RADIUS operation model as outlined in the list below? If so, then another method of achieving the design objectives SHOULD be used. Potential problem areas include the following:
规范是否改变了下表中概述的RADIUS运行模式？如果是，则应使用另一种实现设计目标的方法。潜在问题领域包括以下方面：
* Defining new commands in RADIUS using attributes. The addition of new commands to RADIUS MUST be handled via allocation of a new Code and not by the use of an attribute. This restriction includes new commands created by overloading the Service-Type Attribute to define new values that modify the functionality of Access-Request packets.
* 使用属性在RADIUS中定义新命令。向RADIUS添加新命令必须通过分配新代码而不是使用属性来处理。此限制包括通过重载服务类型属性创建的新命令，以定义修改访问请求数据包功能的新值。
* Using RADIUS as a transport protocol for data unrelated to authentication, authorization, or accounting. Using RADIUS to transport authentication methods such as EAP is explicitly permitted, even if those methods require the transport of relatively large amounts of data. Transport of opaque data relating to AAA is also permitted, as discussed in Section 3.2.3. However, if the specification does not relate to AAA, then RADIUS SHOULD NOT be used.
* 将RADIUS用作与身份验证、授权或记帐无关的数据的传输协议。明确允许使用RADIUS传输EAP等身份验证方法，即使这些方法需要传输相对大量的数据。如第3.2.3节所述，也允许传输与AAA相关的不透明数据。但是，如果规范与AAA无关，则不应使用半径。
* Assuming support for packet lengths greater than 4096 octets. Attribute designers cannot assume that RADIUS implementations can successfully handle packets larger than 4096 octets. If a specification could lead to a RADIUS packet larger than 4096 octets, then the alternatives described in Section 3.3 SHOULD be considered.
* 假设支持数据包长度大于4096个八位字节。属性设计器不能假设RADIUS实现可以成功处理大于4096个八位字节的数据包。如果规范可能导致RADIUS数据包大于4096个八位字节，则应考虑第3.3节中描述的备选方案。
* Stateless operation. The RADIUS protocol is stateless, and documents that require stateful protocol behavior without the use of the State Attribute need to be redesigned.
* 无状态操作。RADIUS协议是无状态的，需要有状态协议行为而不使用State属性的文档需要重新设计。
* Provisioning of service in an Access-Reject. Such provisioning is not permitted, and MUST NOT be used. If limited access needs to be provided, then an Access-Accept with appropriate authorizations can be used instead.
* 在访问拒绝中提供服务。不允许且不得使用此类资源调配。如果需要提供受限访问，则可以使用具有适当授权的访问接受。
* Provisioning of service in a Disconnect-Request. Such provisioning is not permitted and MUST NOT be used. If limited access needs to be provided, then a CoA-Request [RFC5176] with appropriate authorizations can be used instead.
* 在断开连接请求中提供服务。不允许且不得使用此类资源调配。如果需要提供有限访问，则可以使用具有适当授权的CoA请求[RFC5176]。
* Lack of user authentication or authorization restrictions. In an authorization check, where there is no demonstration of a live user, confidential data cannot be returned. Where there is a link to a previous user authentication, the State Attribute SHOULD be present.
* 缺少用户身份验证或授权限制。在授权检查中，如果没有实时用户的演示，则无法返回机密数据。如果存在指向先前用户身份验证的链接，则应该存在State属性。
* Lack of per-packet integrity and authentication. It is expected that documents will support per-packet integrity and authentication.
* 缺少每个数据包的完整性和身份验证。预计文档将支持每个数据包的完整性和身份验证。
* Modification of RADIUS packet sequences. In RADIUS, each request is encapsulated in its own packet and elicits a single response that is sent to the requester. Since changes to this paradigm are likely to require major modifications to RADIUS client and server implementations, they SHOULD be avoided if possible.
* 修改RADIUS数据包序列。在RADIUS中，每个请求都封装在自己的数据包中，并引发发送给请求者的单个响应。由于此范例的更改可能需要对RADIUS客户端和服务器实现进行重大修改，因此应尽可能避免这些更改。
For further details, see Section 3.1.
有关更多详细信息，请参见第3.1节。
Does the attribute have a limited scope of applicability as outlined below? If so, then the attributes SHOULD be allocated from the vendor space rather than requesting allocation from the standard space.
该属性是否具有如下所述的有限适用范围？如果是这样，那么属性应该从供应商空间分配，而不是从标准空间请求分配。
* attributes intended for a vendor to support their own systems and not suitable for general usage
* 用于供应商支持其自身系统的属性，不适用于一般用途
* attributes relying on data types not defined within RADIUS
* 依赖于RADIUS中未定义的数据类型的属性
* attributes intended primarily for use within an SDO
* 主要用于SDO的属性
* attributes intended primarily for use within a group of SDOs
* 主要用于SDO组内的属性
Note that the points listed above do not relax the recommendations discussed in this document. Instead, they recognize that the RADIUS data model has limitations. In certain situations where
请注意，上面列出的要点并没有放松本文件中讨论的建议。相反，他们认识到RADIUS数据模型具有局限性。在某些情况下
interoperability can be strongly constrained by the SDO or vendor, an expanded data model MAY be used. It is RECOMMENDED, however, that the RADIUS data model be used, even when it is marginally less efficient than alternatives.
互操作性可能受到SDO或供应商的强烈限制，可以使用扩展的数据模型。但是，建议使用RADIUS数据模型，即使其效率略低于替代方案。
When attributes are used primarily within a group of SDOs, and are not applicable to the wider Internet community, we expect that one SDO will be responsible for allocation from their own private vendor space.
当属性主要在一组SDO中使用，并且不适用于更广泛的Internet社区时，我们希望一个SDO将负责从其自己的私有供应商空间进行分配。
This appendix summarizes RADIUS attributes with complex data types that are defined in existing RFCs.
本附录总结了现有RFC中定义的具有复杂数据类型的RADIUS属性。
This appendix is published for informational purposes only and reflects the usage of attributes with complex data types at the time of the publication of this document.
本附录仅供参考，反映了本文档发布时复杂数据类型属性的使用情况。
[RFC2865], Section 5.3 defines the CHAP-Password Attribute, which is sent from the RADIUS client to the RADIUS server in an Access-Request. The data type of the CHAP Identifier is not given, only the one-octet length:
[RFC2865]，第5.3节定义了CHAP密码属性，该属性在访问请求中从RADIUS客户端发送到RADIUS服务器。没有给出CHAP标识符的数据类型，只有一个八位字节长度：
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | CHAP Ident | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | CHAP Ident | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Since this is an authentication attribute, code changes are required on the RADIUS client and server to support it, regardless of the attribute format. Therefore, this complex data type is acceptable in this situation.
由于这是一个身份验证属性，因此无论属性格式如何，RADIUS客户端和服务器都需要更改代码以支持它。因此，这种复杂的数据类型在这种情况下是可以接受的。
[RFC2865], Section 5.40 defines the CHAP-Challenge Attribute, which is sent from the RADIUS client to the RADIUS server in an Access-Request. While the data type of the CHAP Identifier is given, the text also says:
[RFC2865]，第5.40节定义了CHAP质询属性，该属性在访问请求中从RADIUS客户端发送到RADIUS服务器。虽然给出了CHAP标识符的数据类型，但文本中还显示：
If the CHAP challenge value is 16 octets long it MAY be placed in the Request Authenticator field instead of using this attribute.
如果CHAP质询值为16个八位字节长，则可以将其放置在请求验证器字段中，而不使用此属性。
Defining attributes to contain values taken from the RADIUS packet header is NOT RECOMMENDED. Attributes should have values that are packed into a RADIUS AVP.
不建议定义包含取自RADIUS数据包头的值的属性。属性应具有打包到RADIUS AVP中的值。
[RFC2868], Section 3.5 defines the Tunnel-Password Attribute, which is sent from the RADIUS server to the client in an Access-Accept. This attribute includes Tag and Salt fields, as well as a String field that consists of three logical sub-fields: the Data-Length (required and one octet), Password sub-fields (required), and the optional Padding sub-field. The attribute appears as follows:
[RFC2868]，第3.5节定义了隧道密码属性，该属性以访问接受的形式从RADIUS服务器发送到客户端。此属性包括标记字段和Salt字段，以及由三个逻辑子字段组成的字符串字段：数据长度（必需和一个八位字节）、密码子字段（必需）和可选填充子字段。该属性显示如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt (cont) | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt (cont) | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Since this is a security attribute, code changes are required on the RADIUS client and server to support it, regardless of the attribute format. However, while use of a complex data type is acceptable in this situation, the design of the Tunnel-Password Attribute is problematic from a security perspective since it uses MD5 as a cipher and provides a password to a NAS, potentially without proper authorization.
由于这是一个安全属性，因此无论属性格式如何，RADIUS客户端和服务器都需要更改代码以支持它。然而，尽管在这种情况下可以接受使用复杂数据类型，但隧道密码属性的设计从安全角度来看是有问题的，因为它使用MD5作为密码并向NAS提供密码，可能没有适当的授权。
[RFC2869], Section 5.4 defines the ARAP-Password Attribute, which is sent from the RADIUS client to the server in an Access-Request. It contains four 4-octet values instead of having a single Value field:
[RFC2869]，第5.4节定义了ARAP密码属性，该属性在访问请求中从RADIUS客户端发送到服务器。它包含四个4-octet值，而不是一个值字段：
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 | Value1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Value1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As with the CHAP-Password Attribute, this is an authentication attribute that would have required code changes on the RADIUS client and server, regardless of format.
与CHAP密码属性一样，这是一个身份验证属性，无论格式如何，RADIUS客户端和服务器上都需要更改代码。
[RFC2869], Section 5.5 defines the ARAP-Features Attribute, which is sent from the RADIUS server to the client in an Access-Accept or Access-Challenge. It contains a compound string of two single octet values, plus three 4-octet values, which the RADIUS client encapsulates in a feature flags packet in the Apple Remote Access Protocol (ARAP):
[RFC2869]，第5.5节定义了ARAP Features属性，该属性在访问接受或访问质询中从RADIUS服务器发送到客户端。它包含一个由两个单八位组值和三个4个八位组值组成的复合字符串，RADIUS客户端将其封装在Apple远程访问协议（ARAP）的功能标志包中：
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 | Value1 | Value2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Value1 | Value2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unlike the previous attributes, this attribute contains no encrypted component, nor is it directly involved in authentication. The individual sub-fields therefore could have been encapsulated in separate attributes.
与前面的属性不同，此属性不包含加密组件，也不直接参与身份验证。因此，各个子字段可以封装在单独的属性中。
While the contents of this attribute are intended to be placed in an ARAP packet, the fields need to be set by the RADIUS server. Using standard RADIUS data types would have simplified RADIUS server implementations and subsequent management. The current form of the attribute requires either the RADIUS server implementation or the RADIUS server administrator to understand the internals of the ARAP protocol.
虽然此属性的内容要放在ARAP数据包中，但字段需要由RADIUS服务器设置。使用标准RADIUS数据类型将简化RADIUS服务器的实施和后续管理。属性的当前形式要求RADIUS服务器实现或RADIUS服务器管理员了解ARAP协议的内部内容。
[RFC2869], Section 5.11 defines the Connect-Info Attribute, which is used to indicate the nature of the connection.
[RFC2869]，第5.11节定义了连接信息属性，该属性用于指示连接的性质。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Even though the type is Text, the rest of the description indicates that it is a complex attribute:
即使类型为文本，描述的其余部分也表明它是一个复杂属性：
The Text field consists of UTF-8 encoded 10646 [8] characters. The connection speed SHOULD be included at the beginning of the first Connect-Info attribute in the packet. If the transmit and receive connection speeds differ, they may both be included in the first attribute with the transmit speed first (the speed the NAS modem transmits at), a slash (/), the receive speed, then optionally other information.
文本字段由UTF-8编码的10646[8]个字符组成。连接速度应包含在数据包中第一个Connect Info属性的开头。如果发送和接收连接速度不同，则它们可能都包含在第一个属性中，首先是发送速度（NAS调制解调器的传输速度）、斜杠（/）、接收速度，然后是可选的其他信息。
For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
例如，“28800 V42BIS/LAPM”或“52000/31200 V90”
More than one Connect-Info attribute may be present in an Accounting-Request packet to accommodate expected efforts by ITU to have modems report more connection information in a standard format that might exceed 252 octets.
计费请求数据包中可能存在多个连接信息属性，以适应ITU的预期努力，使调制解调器以可能超过252个八位字节的标准格式报告更多的连接信息。
This attribute contains no encrypted component and is not directly involved in authentication. The individual sub-fields could therefore have been encapsulated in separate attributes.
此属性不包含加密组件，也不直接参与身份验证。因此，各个子字段可以封装在单独的属性中。
However, since the definition refers to potential standardization activity within ITU, the Connect-Info Attribute can also be thought of as opaque data whose definition is provided elsewhere. The Connect-Info Attribute could therefore qualify for an exception as described in Section 3.2.4.
然而，由于定义涉及国际电联内部的潜在标准化活动，连接信息属性也可以被视为不透明数据，其定义在别处提供。因此，Connect Info属性可能符合第3.2.4节所述的例外情况。
Section 2.3 of [RFC3162] defines the Framed-IPv6-Prefix Attribute, and Section 3 of [RFC4818] reuses this format for the Delegated-IPv6-Prefix Attribute; these attributes are sent from the RADIUS server to the client in an Access-Accept.
[RFC3162]的第2.3节定义了Framed-IPv6-Prefix属性，[RFC4818]的第3节将此格式用于Delegated-IPv6-Prefix属性；这些属性在Access Accept中从RADIUS服务器发送到客户端。
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 | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-fields encoded in these attributes are strongly related, and there was no previous definition of this data structure that could be referenced. Support for this attribute requires code changes on both the client and server, due to a new data type being defined. In this case, it appears to be acceptable to encode them in one attribute.
这些属性中编码的子字段具有很强的相关性，并且以前没有可引用的此数据结构的定义。由于定义了新的数据类型，因此支持此属性需要在客户端和服务器上更改代码。在这种情况下，将它们编码到一个属性中似乎是可以接受的。
[RFC4675], Section 2.1 defines the Egress-VLANID Attribute, which can be sent by a RADIUS client or server.
[RFC4675]，第2.1节定义了出口VLANID属性，该属性可由RADIUS客户端或服务器发送。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
While it appears superficially to be of type Integer, the Value field is actually a packed structure, as follows:
虽然表面上看起来是Integer类型，但值字段实际上是一个压缩结构，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Indic. | Pad | VLANID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Indic. | Pad | VLANID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of the VLANID field is defined by the [IEEE-802.1Q] specification. The Tag Indicator field is either 0x31 or 0x32, for compatibility with the Egress-VLAN-Name, as discussed below. The complex structure of Egress-VLANID overlaps with that of the base Integer data type, meaning that no code changes are required for a RADIUS server to support this attribute. Code changes are required on the NAS, if only to implement the VLAN ID enforcement.
VLANID字段的长度由[IEEE-802.1Q]规范定义。标记指示符字段为0x31或0x32，以与出口VLAN名称兼容，如下所述。出口VLANID的复杂结构与基本整数数据类型的结构重叠，这意味着RADIUS服务器无需更改代码即可支持此属性。如果只是为了实施VLAN ID强制，NAS上需要更改代码。
Given the IEEE VLAN requirements and the limited data model of RADIUS, the chosen method is likely the best of the possible alternatives.
考虑到IEEE VLAN要求和RADIUS的有限数据模型，选择的方法可能是最好的备选方案。
[RFC4675], Section 2.3 defines the Egress-VLAN-Name Attribute, which can be sent by a RADIUS client or server.
[RFC4675]，第2.3节定义了出口VLAN名称属性，该属性可由RADIUS客户端或服务器发送。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag Indic. | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag Indic. | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tag Indicator is either the character '1' or '2', which in ASCII map to the identical values for Tag Indicator in Egress-VLANID above. The complex structure of this attribute is acceptable for reasons identical to those given for Egress-VLANID.
标记指示符是字符“1”或“2”，在ASCII中映射到上述出口VLANID中标记指示符的相同值。由于与出口VLANID相同的原因，此属性的复杂结构是可以接受的。
[RFC5090] attempts to standardize the functionality provided by an expired Internet-Draft [AAA-SIP], which improperly uses two attributes from the standard space without having been assigned them by IANA. This self-allocation is forbidden, as described in Section 2. In addition, the document uses nested attributes, which are discouraged in Section 2.1. The updated document uses basic data types and allocates nearly 20 attributes in the process.
[RFC5090]试图标准化过期的互联网草案[AAA-SIP]提供的功能，该草案未经IANA分配，不正确地使用标准空间中的两个属性。如第2节所述，禁止这种自我分配。此外，文档使用嵌套属性，这在第2.1节中是不鼓励的。更新后的文档使用基本数据类型，并在此过程中分配了近20个属性。
However, the document has seen wide-spread implementation, but [RFC5090] has not. One explanation may be that implementors disagreed with the trade-offs made in the updated specification. It may have been better to simply document the existing format and request IANA allocation of two attributes. The resulting design would have used nested attributes but may have gained more wide-spread implementation.
然而，该文件已广泛实施，但[RFC5090]尚未实施。一种解释可能是，实现者不同意更新规范中的权衡。最好只记录现有格式并请求IANA分配两个属性。最终的设计将使用嵌套属性，但可能获得更广泛的实现。
Acknowledgments
致谢
We would like to acknowledge David Nelson, Bernard Aboba, Emile van Bergen, Barney Wolff, Glen Zorn, Avi Lior, and Hannes Tschofenig for contributions to this document.
我们感谢David Nelson、Bernard Aboba、Emile van Bergen、Barney Wolff、Glen Zorn、Avi Lior和Hannes Tschofenig对本文件的贡献。
Authors' Addresses
作者地址
Alan DeKok (editor) The FreeRADIUS Server Project http://freeradius.org/
Alan DeKok（编辑）FreeRADIUS服务器项目http://freeradius.org/
EMail: aland@freeradius.org
EMail: aland@freeradius.org
Greg Weber Knoxville, TN 37932 USA
格雷格·韦伯·诺克斯维尔，美国田纳西州37932
EMail: gdweber@gmail.com
EMail: gdweber@gmail.com