Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 6929 Network RADIUS
Updates: 2865, 3575, 6158 A. Lior
Category: Standards Track April 2013
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 6929 Network RADIUS
Updates: 2865, 3575, 6158 A. Lior
Category: Standards Track April 2013
ISSN: 2070-1721
Remote Authentication Dial-In User Service (RADIUS) Protocol Extensions
远程身份验证拨入用户服务（RADIUS）协议扩展
Abstract
摘要
The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems.
远程身份验证拨入用户服务（RADIUS）协议的当前8位属性类型空间即将用尽。此外，经验表明，越来越需要复杂的分组，以及能够承载253个八位字节以上数据的属性。本文档定义了解决上述所有问题的RADIUS更改。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6929.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6929.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Caveats and Limitations ....................................5
1.1.1. Failure to Meet Certain Goals .......................5
1.1.2. Implementation Recommendations ......................5
1.2. Terminology ................................................6
1.3. Requirements Language ......................................7
2. Extensions to RADIUS ............................................7
2.1. Extended Type ..............................................8
2.2. Long Extended Type .........................................9
2.3. TLV Data Type .............................................12
2.3.1. TLV Nesting ........................................14
2.4. EVS Data Type .............................................14
2.5. Integer64 Data Type .......................................16
2.6. Vendor-Id Field ...........................................16
2.7. Attribute Naming and Type Identifiers .....................17
2.7.1. Attribute and TLV Naming ...........................17
2.7.2. Attribute Type Identifiers .........................18
2.7.3. TLV Identifiers ....................................18
2.7.4. VSA Identifiers ....................................18
2.8. Invalid Attributes ........................................19
3. Attribute Definitions ..........................................21
3.1. Extended-Type-1 ...........................................21
3.2. Extended-Type-2 ...........................................22
3.3. Extended-Type-3 ...........................................23
3.4. Extended-Type-4 ...........................................24
3.5. Long-Extended-Type-1 ......................................25
3.6. Long-Extended-Type-2 ......................................26
4. Vendor-Specific Attributes .....................................27
4.1. Extended-Vendor-Specific-1 ................................28
4.2. Extended-Vendor-Specific-2 ................................29
4.3. Extended-Vendor-Specific-3 ................................30
4.4. Extended-Vendor-Specific-4 ................................31
4.5. Extended-Vendor-Specific-5 ................................32
4.6. Extended-Vendor-Specific-6 ................................34
5. Compatibility with Traditional RADIUS ..........................35
5.1. Attribute Allocation ......................................35
5.2. Proxy Servers .............................................36
1. Introduction ....................................................3
1.1. Caveats and Limitations ....................................5
1.1.1. Failure to Meet Certain Goals .......................5
1.1.2. Implementation Recommendations ......................5
1.2. Terminology ................................................6
1.3. Requirements Language ......................................7
2. Extensions to RADIUS ............................................7
2.1. Extended Type ..............................................8
2.2. Long Extended Type .........................................9
2.3. TLV Data Type .............................................12
2.3.1. TLV Nesting ........................................14
2.4. EVS Data Type .............................................14
2.5. Integer64 Data Type .......................................16
2.6. Vendor-Id Field ...........................................16
2.7. Attribute Naming and Type Identifiers .....................17
2.7.1. Attribute and TLV Naming ...........................17
2.7.2. Attribute Type Identifiers .........................18
2.7.3. TLV Identifiers ....................................18
2.7.4. VSA Identifiers ....................................18
2.8. Invalid Attributes ........................................19
3. Attribute Definitions ..........................................21
3.1. Extended-Type-1 ...........................................21
3.2. Extended-Type-2 ...........................................22
3.3. Extended-Type-3 ...........................................23
3.4. Extended-Type-4 ...........................................24
3.5. Long-Extended-Type-1 ......................................25
3.6. Long-Extended-Type-2 ......................................26
4. Vendor-Specific Attributes .....................................27
4.1. Extended-Vendor-Specific-1 ................................28
4.2. Extended-Vendor-Specific-2 ................................29
4.3. Extended-Vendor-Specific-3 ................................30
4.4. Extended-Vendor-Specific-4 ................................31
4.5. Extended-Vendor-Specific-5 ................................32
4.6. Extended-Vendor-Specific-6 ................................34
5. Compatibility with Traditional RADIUS ..........................35
5.1. Attribute Allocation ......................................35
5.2. Proxy Servers .............................................36
6. Guidelines .....................................................37
6.1. Updates to RFC 6158 .......................................37
6.2. Guidelines for Simple Data Types ..........................38
6.3. Guidelines for Complex Data Types .........................38
6.4. Design Guidelines for the New Types .......................39
6.5. TLV Guidelines ............................................40
6.6. Allocation Request Guidelines .............................40
6.7. Allocation Request Guidelines for TLVs ....................41
6.8. Implementation Guidelines .................................42
6.9. Vendor Guidelines .........................................42
7. Rationale for This Design ......................................42
7.1. Attribute Audit ...........................................43
8. Diameter Considerations ........................................44
9. Examples .......................................................44
9.1. Extended Type .............................................46
9.2. Long Extended Type ........................................47
10. IANA Considerations ...........................................50
10.1. Attribute Allocations ....................................50
10.2. RADIUS Attribute Type Tree ...............................50
10.3. Allocation Instructions ..................................52
10.3.1. Requested Allocation from the Standard Space ......52
10.3.2. Requested Allocation from the Short
Extended Space ....................................52
10.3.3. Requested Allocation from the Long
Extended Space ....................................52
10.3.4. Allocation Preferences ............................52
10.3.5. Extending the Type Space via the TLV Data Type ....53
10.3.6. Allocation within a TLV ...........................53
10.3.7. Allocation of Other Data Types ....................54
11. Security Considerations .......................................54
12. References ....................................................54
12.1. Normative References .....................................54
12.2. Informative References ...................................55
13. Acknowledgments ...............................................55
Appendix A. Extended Attribute Generator Program ..................56
6. Guidelines .....................................................37
6.1. Updates to RFC 6158 .......................................37
6.2. Guidelines for Simple Data Types ..........................38
6.3. Guidelines for Complex Data Types .........................38
6.4. Design Guidelines for the New Types .......................39
6.5. TLV Guidelines ............................................40
6.6. Allocation Request Guidelines .............................40
6.7. Allocation Request Guidelines for TLVs ....................41
6.8. Implementation Guidelines .................................42
6.9. Vendor Guidelines .........................................42
7. Rationale for This Design ......................................42
7.1. Attribute Audit ...........................................43
8. Diameter Considerations ........................................44
9. Examples .......................................................44
9.1. Extended Type .............................................46
9.2. Long Extended Type ........................................47
10. IANA Considerations ...........................................50
10.1. Attribute Allocations ....................................50
10.2. RADIUS Attribute Type Tree ...............................50
10.3. Allocation Instructions ..................................52
10.3.1. Requested Allocation from the Standard Space ......52
10.3.2. Requested Allocation from the Short
Extended Space ....................................52
10.3.3. Requested Allocation from the Long
Extended Space ....................................52
10.3.4. Allocation Preferences ............................52
10.3.5. Extending the Type Space via the TLV Data Type ....53
10.3.6. Allocation within a TLV ...........................53
10.3.7. Allocation of Other Data Types ....................54
11. Security Considerations .......................................54
12. References ....................................................54
12.1. Normative References .....................................54
12.2. Informative References ...................................55
13. Acknowledgments ...............................................55
Appendix A. Extended Attribute Generator Program ..................56
Under current allocation pressure, we expect that the RADIUS Attribute Type space will be exhausted by 2014 or 2015. We therefore need a way to extend the type space so that new specifications may continue to be developed. Other issues have also been shown with RADIUS. The attribute grouping method defined in [RFC2868] has been shown to be impractical, and a more powerful mechanism is needed. Multiple Attributes have been defined that transport more than the 253 octets of data originally envisioned with the protocol. Each of these attributes is handled as a "special case" inside of RADIUS implementations, instead of as a general method. We therefore also
在当前分配压力下，我们预计RADIUS属性类型空间将在2014年或2015年耗尽。因此，我们需要一种扩展类型空间的方法，以便可以继续开发新的规范。RADIUS还显示了其他问题。[RFC2868]中定义的属性分组方法已被证明是不切实际的，需要更强大的机制。已经定义了多个属性，它们传输的数据超过了协议最初设想的253个八位字节。这些属性中的每一个都作为RADIUS实现内部的“特殊情况”处理，而不是作为一般方法处理。因此，我们也
need a standardized method of transporting large quantities of data. Finally, some vendors are close to allocating all of the Attributes within their Vendor-Specific Attribute space. It would be useful to leverage changes to the base protocol for extending the Vendor-Specific Attribute space.
需要传输大量数据的标准化方法。最后，一些供应商接近于在其特定于供应商的属性空间中分配所有属性。利用对基本协议的更改来扩展特定于供应商的属性空间将非常有用。
We satisfy all of these requirements through the following changes given in this document:
我们通过本文件中给出的以下变更满足所有这些要求：
* Defining an "Extended Type" format, which adds 8 bits of "Extended Type" to the RADIUS Attribute Type space, by using one octet of the "Value" field. This method gives us a general way of extending the Attribute Type space (Section 2.1).
* 定义“扩展类型”格式，通过使用“值”字段的一个八位字节，将8位“扩展类型”添加到半径属性类型空间。该方法为我们提供了扩展属性类型空间的一般方法（第2.1节）。
* Allocating 4 attributes as using the format of "Extended Type". This allocation extends the RADIUS Attribute Type space by approximately 1000 values (Sections 3.1, 3.2, 3.3, and 3.4).
* 使用“扩展类型”格式分配4个属性。此分配将半径属性类型空间扩展了约1000个值（第3.1、3.2、3.3和3.4节）。
* Defining a "Long Extended Type" format, which inserts an additional octet between the "Extended Type" octet and the "Value" field. This method gives us a general way of adding more functionality to the protocol (Section 2.2).
* 定义“长扩展类型”格式，在“扩展类型”八位字节和“值”字段之间插入一个额外的八位字节。该方法为我们提供了向协议添加更多功能的一般方法（第2.2节）。
* Defining a method that uses the additional octet in the "Long Extended Type" to indicate data fragmentation across multiple Attributes. This method provides a standard way for an Attribute to carry more than 253 octets of data (Section 2.2).
* 定义一种方法，该方法使用“长扩展类型”中的附加八位字节来指示跨多个属性的数据分段。该方法为属性提供了一种标准方法，以承载253个八位字节以上的数据（第2.2节）。
* Allocating 2 attributes as using the format "Long Extended Type". This allocation extends the RADIUS Attribute Type space by an additional 500 values (Sections 3.5 and 3.6).
* 使用“长扩展类型”格式分配2个属性。此分配将半径属性类型空间额外扩展500个值（第3.5节和第3.6节）。
* Defining a new "Type-Length-Value" (TLV) data type. This data type allows an attribute to carry TLVs as "sub-Attributes", which can in turn encapsulate other TLVs as "sub-sub-Attributes". This change creates a standard way to group a set of Attributes (Section 2.3).
* 定义新的“类型长度值”（TLV）数据类型。此数据类型允许属性将TLV作为“子属性”携带，而子属性又可以将其他TLV封装为“子属性”。此更改创建了一种对一组属性进行分组的标准方法（第2.3节）。
* Defining a new "Extended-Vendor-Specific" (EVS) data type. This data type allows an attribute to carry Vendor-Specific Attributes (VSAs) inside of the new Attribute formats (Section 2.4).
* 定义新的“扩展供应商特定”（EVS）数据类型。此数据类型允许属性在新属性格式（第2.4节）中包含供应商特定属性（VSA）。
* Defining a new "integer64" data type. This data type allows counters that track more than 2^32 octets of data (Section 2.5).
* 定义新的“integer64”数据类型。此数据类型允许计数器跟踪超过2^32个八位字节的数据（第2.5节）。
* Allocating 6 attributes using the new EVS data type. This allocation extends the Vendor-Specific Attribute Type space by over 1500 values (Sections 4.1 through 4.6).
* 使用新的EVS数据类型分配6个属性。此分配将特定于供应商的属性类型空间扩展了1500多个值（第4.1节至第4.6节）。
* Defining the "Vendor-Id" for Vendor-Specific Attributes to encompass the entire 4 octets of the Vendor field. [RFC2865] Section 5.26 defined it to be 3 octets, with the fourth octet being zero (Section 2.6).
* 为特定于供应商的属性定义“供应商Id”，以包含供应商字段的整个4个八位字节。[RFC2865]第5.26节将其定义为3个八位字节，第四个八位字节为零（第2.6节）。
* Describing compatibility with existing RADIUS systems (Section 5).
* 描述与现有RADIUS系统的兼容性（第5节）。
* Defining guidelines for the use of these changes for IANA, implementations of this specification, and for future RADIUS specifications (Section 6).
* 为IANA、本规范的实施以及未来的RADIUS规范定义使用这些变更的指南（第6节）。
As with any protocol change, the changes defined here are the result of a series of compromises. We have tried to find a balance between flexibility, space in the RADIUS message, compatibility with existing deployments, and difficulty of implementation.
与任何协议更改一样，此处定义的更改是一系列妥协的结果。我们试图在灵活性、RADIUS消息中的空间、与现有部署的兼容性以及实现难度之间找到平衡。
This section describes some caveats and limitations of the proposal.
本节介绍了提案的一些注意事项和限制。
One goal that was not met by the above modifications is to have an incentive for standards to use the new space. That incentive is being provided by the exhaustion of the standard space.
上述修改未能实现的一个目标是鼓励标准使用新空间。标准空间的耗尽提供了这种激励。
It is RECOMMENDED that implementations support this specification. It is RECOMMENDED that new specifications use the formats defined in this specification.
建议实现支持此规范。建议新规范使用本规范中定义的格式。
The alternative to the above recommendations is a circular argument of not implementing this specification because no other standards reference it, and also not defining new standards referencing this specification because no implementations exist.
上述建议的替代方案是循环论证，即不实施本规范，因为没有其他标准引用它，也不定义引用本规范的新标准，因为没有实施。
As noted earlier, the standard space is almost entirely allocated. Ignoring the looming crisis benefits no one.
如前所述，标准空间几乎全部分配。忽视迫在眉睫的危机对任何人都没有好处。
This document uses the following terms:
本文件使用以下术语：
Silently discard
默默地抛弃
This means the implementation discards the packet without further processing. The implementation MAY provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.
这意味着实现将丢弃数据包，而无需进一步处理。该实现可以提供记录错误的能力，包括静默丢弃的数据包的内容，并且应该在统计计数器中记录事件。
Invalid attribute
无效属性
This means that the Length field of an Attribute is valid (as per [RFC2865], Section 5, top of page 25) but the contents of the Attribute do not follow the correct format, for example, an Attribute of type "address" that encapsulates more than four, or less than four, octets of data. See Section 2.8 for a more complete definition.
这意味着属性的长度字段是有效的（根据[RFC2865]，第5节，第25页顶部），但属性的内容没有遵循正确的格式，例如，封装四个或四个以上八位字节数据的“address”类型属性。有关更完整的定义，请参见第2.8节。
Standard space
标准空间
This refers to codes in the RADIUS Attribute Type space that are allocated by IANA and that follow the format defined in Section 5 of [RFC2865].
这是指IANA分配的RADIUS属性类型空间中的代码，该代码遵循[RFC2865]第5节中定义的格式。
Extended space
扩展空间
This refers to codes in the RADIUS Attribute Type space that require the extensions defined in this document and are an extension of the standard space, but that cannot be represented within the standard space.
这是指半径属性类型空间中的代码，需要本文档中定义的扩展名，是标准空间的扩展名，但不能在标准空间中表示。
Short extended space
短扩展空间
This refers to codes in the extended space that use the "Extended Type" format.
这是指扩展空间中使用“扩展类型”格式的代码。
Long extended space
长扩展空间
This refers to codes in the extended space that use the "Long Extended Type" format.
这是指扩展空间中使用“长扩展类型”格式的代码。
The following terms are used here with the meanings defined in BCP 26 [RFC5226]: "namespace", "assigned value", "registration", "Private Use", "Reserved", "Unassigned", "IETF Review", and "Standards Action".
以下术语的含义见BCP 26[RFC5226]：“名称空间”、“指定值”、“注册”、“私人使用”、“保留”、“未指定”、“IETF审查”和“标准行动”。
In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
在本文件中，使用了几个词来表示规范的要求。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section defines two new Attribute formats: "Extended Type" and "Long Extended Type". It defines a new Type-Length-Value (TLV) data type, an Extended-Vendor-Specific (EVS) data type, and an Integer64 data type. It defines a new method for naming attributes and identifying Attributes using the new Attribute formats. It finally defines the new term "invalid attribute" and describes how it affects implementations.
本节定义了两种新的属性格式：“扩展类型”和“长扩展类型”。它定义了新的类型长度值（TLV）数据类型、扩展供应商特定（EVS）数据类型和Integer64数据类型。它定义了一种使用新属性格式命名属性和识别属性的新方法。最后定义了新术语“无效属性”，并描述了它如何影响实现。
The new Attribute formats are designed to be compatible with the Attribute format given in [RFC2865] Section 5. The meaning and interpretation of the Type and Length fields are unchanged from that specification. This reuse allows the new formats to be compatible with RADIUS implementations that do not implement this specification. Those implementations can simply ignore the "Value" field of an attribute or forward it verbatim.
新的属性格式设计为与[RFC2865]第5节中给出的属性格式兼容。类型和长度字段的含义和解释与该规范相同。这种重用允许新格式与未实现此规范的RADIUS实现兼容。这些实现可以简单地忽略属性的“值”字段或逐字转发它。
The changes to the Attribute format come about by "stealing" one or more octets from the "Value" field. This change has the effect that the "Value" field of [RFC2865] Section 5 contains both the new octets given here and any attribute-specific Value. The result is that "Value"s in this specification are limited to less than 253 octets in size. This limitation is overcome through the use of the "Long Extended Type" format.
属性格式的更改是通过从“值”字段“窃取”一个或多个八位字节来实现的。此更改的效果是[RFC2865]第5节的“值”字段包含此处给出的新八位字节和任何特定于属性的值。结果是，本规范中的“值”限制为小于253个八位字节。通过使用“长扩展类型”格式可以克服此限制。
We reiterate that the formats given in this document do not insert new data into an attribute. Instead, we "steal" one octet of Value, so that the definition of the Length field remains unchanged. The new Attribute formats are designed to be compatible with the Attribute format given in [RFC2865] Section 5. The meaning and interpretation of the Type and Length fields is unchanged from that specification. This reuse allows the new formats to be compatible with RADIUS implementations that do not implement this specification. Those implementations can simply ignore the "Value" field of an attribute or forward it verbatim.
我们重申，本文档中给出的格式不会在属性中插入新数据。相反，我们“窃取”了一个八位字节的值，因此长度字段的定义保持不变。新的属性格式设计为与[RFC2865]第5节中给出的属性格式兼容。类型和长度字段的含义和解释与该规范相同。这种重用允许新格式与未实现此规范的RADIUS实现兼容。这些实现可以简单地忽略属性的“值”字段或逐字转发它。
This section defines a new Attribute format, called "Extended Type". A summary of the Attribute format is shown below. The fields are transmitted from left to right.
本节定义了一种新的属性格式，称为“扩展类型”。属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
This field is identical to the Type field of the Attribute format defined in [RFC2865] Section 5.
该字段与[RFC2865]第5节中定义的属性格式的类型字段相同。
Length
长
The Length field is one octet and indicates the length of this Attribute, including the Type, Length, "Extended-Type", and "Value" fields. Permitted values are between 4 and 255. If a client or server receives an Extended Attribute with a Length of 2 or 3, then that Attribute MUST be considered to be an "invalid attribute" and handled as per Section 2.8, below.
长度字段是一个八位字节，表示该属性的长度，包括类型、长度、“扩展类型”和“值”字段。允许的值介于4和255之间。如果客户端或服务器接收到长度为2或3的扩展属性，则该属性必须视为“无效属性”，并按照下面第2.8节进行处理。
Extended-Type
扩展型
The Extended-Type field is one octet. Up-to-date values of this field are specified according to the policies and rules described in Section 10. Unlike the Type field defined in [RFC2865] Section 5, no values are allocated for experimental or implementation-specific use. Values 241-255 are reserved and MUST NOT be used.
扩展类型字段是一个八位字节。该字段的最新值是根据第10节中描述的策略和规则指定的。与[RFC2865]第5节中定义的类型字段不同，没有为实验或实施特定用途分配值。值241-255为保留值，不得使用。
The Extended-Type is meaningful only within a context defined by the Type field. That is, this field may be thought of as defining a new type space of the form "Type.Extended-Type". See Section 3.5, below, for additional discussion.
扩展类型只有在类型字段定义的上下文中才有意义。也就是说，这个字段可以被认为是定义了一个新的类型空间，形式为“type.Extended type”。更多讨论见下文第3.5节。
A RADIUS server MAY ignore Attributes with an unknown "Type.Extended-Type".
RADIUS服务器可能会忽略具有未知“类型.扩展类型”的属性。
A RADIUS client MAY ignore Attributes with an unknown "Type.Extended-Type".
RADIUS客户端可能会忽略未知“Type.Extended Type”的属性。
Value
价值
This field is similar to the "Value" field of the Attribute format defined in [RFC2865] Section 5. The format of the data MUST be a valid RADIUS data type.
该字段类似于[RFC2865]第5节中定义的属性格式的“值”字段。数据格式必须是有效的RADIUS数据类型。
The "Value" field is one or more octets.
“值”字段是一个或多个八位字节。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
支持此规范的实现必须使用“Type.Extended Type”标识符来确定“Value”字段的解释。
The addition of the Extended-Type field decreases the maximum length for attributes of type "text" or "string" from 253 to 252 octets. Where an Attribute needs to carry more than 252 octets of data, the "Long Extended Type" format MUST be used.
添加扩展类型字段将“text”或“string”类型属性的最大长度从253个八位字节减少到252个八位字节。如果属性需要携带超过252个八位字节的数据，则必须使用“长扩展类型”格式。
Experience has shown that the "experimental" and "implementation-specific" attributes defined in [RFC2865] Section 5 have had little practical value. We therefore do not continue that practice here with the Extended-Type field.
经验表明，[RFC2865]第5节中定义的“实验性”和“具体实施”属性几乎没有实际价值。因此，在这里，我们不在扩展类型字段中继续这种做法。
This section defines a new Attribute format, called "Long Extended Type". It leverages the "Extended Type" format in order to permit the transport of attributes encapsulating more than 253 octets of data. A summary of the Attribute format is shown below. The fields are transmitted from left to right.
本节定义了一种新的属性格式，称为“长扩展类型”。它利用“扩展类型”格式，以便允许传输封装253个八位字节以上数据的属性。属性格式的摘要如下所示。字段从左向右传输。
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 | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
This field is identical to the Type field of the Attribute format defined in [RFC2865] Section 5.
该字段与[RFC2865]第5节中定义的属性格式的类型字段相同。
Length
长
The Length field is one octet and indicates the length of this Attribute, including the Type, Length, Extended-Type, and "Value" fields. Permitted values are between 5 and 255. If a client or
长度字段是一个八位字节，表示该属性的长度，包括类型、长度、扩展类型和“值”字段。允许的值介于5和255之间。如果客户或
server receives a "Long Extended Type" with a Length of 2, 3, or 4, then that Attribute MUST be considered to be an "invalid attribute" and handled as per Section 2.8, below.
服务器收到一个长度为2、3或4的“长扩展类型”，则该属性必须被视为“无效属性”，并按照下面的第2.8节进行处理。
Note that this Length is limited to the length of this fragment. There is no field that gives an explicit value for the total size of the fragmented attribute.
请注意，此长度仅限于此片段的长度。没有字段可以为碎片属性的总大小提供显式值。
Extended-Type
扩展型
This field is identical to the Extended-Type field defined above in Section 2.1.
该字段与上文第2.1节中定义的扩展类型字段相同。
M (More)
M（更多）
The More field is one (1) bit in length and indicates whether or not the current attribute contains "more" than 251 octets of data. The More field MUST be clear (0) if the Length field has a value of less than 255. The More field MAY be set (1) if the Length field has a value of 255.
“更多”字段的长度为一（1）位，表示当前属性是否包含超过251个八位字节的数据。如果长度字段的值小于255，“更多”字段必须清除（0）。如果长度字段的值为255，则可以设置更多字段（1）。
If the More field is set (1), it indicates that the "Value" field has been fragmented across multiple RADIUS attributes. When the More field is set (1), the Attribute MUST have a Length field of value 255, there MUST be an attribute following this one, and the next attribute MUST have both the same Type and "Extended Type". That is, multiple fragments of the same value MUST be in order and MUST be consecutive attributes in the packet, and the last attribute in a packet MUST NOT have the More field set (1).
如果设置了“更多”字段（1），则表示“值”字段已跨多个半径属性分段。设置“更多”字段（1）时，该属性的长度字段值必须为255，该字段后面必须有一个属性，下一个属性必须具有相同的类型和“扩展类型”。也就是说，具有相同值的多个片段必须有序，并且必须是数据包中的连续属性，并且数据包中的最后一个属性不得具有更多字段集（1）。
That is, a packet containing a fragmented attribute needs to contain all fragments of the Attribute, and those fragments need to be contiguous in the packet. RADIUS does not support inter-packet fragmentation, which means that fragmenting an attribute across multiple packets is impossible.
也就是说，包含碎片属性的数据包需要包含该属性的所有片段，并且这些片段需要在数据包中是连续的。RADIUS不支持包间分段，这意味着不可能跨多个包对属性进行分段。
If a client or server receives an attribute fragment with the "More" field set (1) but for which no subsequent fragment can be found, then the fragmented attribute is considered to be an "invalid attribute" and handled as per Section 2.8, below.
如果客户机或服务器接收到带有“更多”字段集（1）的属性片段，但找不到后续片段，则该片段属性被视为“无效属性”，并按照下面第2.8节进行处理。
Reserved
含蓄的
This field is 7 bits long and is reserved for future use. Implementations MUST set it to zero (0) when encoding an attribute for sending in a packet. The contents SHOULD be ignored on reception.
此字段的长度为7位，保留供将来使用。在编码用于在数据包中发送的属性时，实现必须将其设置为零（0）。接待时应忽略这些内容。
Future specifications may define additional meaning for this field. Implementations therefore MUST NOT treat this field as invalid if it is non-zero.
未来的规范可能会定义此字段的其他含义。因此，如果此字段为非零，则实现不得将其视为无效字段。
Value
价值
This field is similar to the "Value" field of the Attribute format defined in [RFC2865] Section 5. It may contain a complete set of data (when the Length field has a value of less than 255), or it may contain a fragment of data.
该字段类似于[RFC2865]第5节中定义的属性格式的“值”字段。它可能包含一组完整的数据（当长度字段的值小于255时），也可能包含一段数据。
The "Value" field is one or more octets.
“值”字段是一个或多个八位字节。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
支持此规范的实现必须使用“Type.Extended Type”标识符来确定“Value”字段的解释。
Any interpretation of the resulting data MUST occur after the fragments have been reassembled. The length of the data MUST be taken as the sum of the lengths of the fragments (i.e., "Value" fields) from which it is constructed. The format of the data SHOULD be a valid RADIUS data type. If the reassembled data does not match the expected format, all fragments MUST be treated as "invalid attributes", and the reassembled data MUST be discarded.
对结果数据的任何解释必须在碎片重新组装后进行。数据的长度必须视为构建数据的片段（即“值”字段）长度之和。数据的格式应为有效的RADIUS数据类型。如果重新组装的数据与预期的格式不匹配，则必须将所有片段视为“无效属性”，并且必须丢弃重新组装的数据。
We note that the maximum size of a fragmented attribute is limited only by the RADIUS packet length limitation (i.e., 4096 octets, not counting various headers and overhead). Implementations MUST be able to handle the case where one fragmented attribute completely fills the packet.
我们注意到，碎片属性的最大大小仅受RADIUS数据包长度限制（即4096个八位字节，不包括各种头和开销）的限制。实现必须能够处理一个碎片属性完全填充数据包的情况。
This definition increases the RADIUS Attribute Type space as above but also provides for transport of Attributes that could contain more than 253 octets of data.
此定义如上所述增加了RADIUS属性类型空间，但也提供了可能包含253个八位字节以上数据的属性的传输。
Note that [RFC2865] Section 5 says:
请注意，[RFC2865]第5节规定：
If multiple Attributes with the same Type are present, the order of Attributes with the same Type MUST be preserved by any proxies. The order of Attributes of different Types is not required to be preserved. A RADIUS server or client MUST NOT have any dependencies on the order of attributes of different types. A RADIUS server or client MUST NOT require attributes of the same type to be contiguous.
如果存在多个相同类型的属性，则任何代理都必须保留相同类型属性的顺序。不需要保留不同类型属性的顺序。RADIUS服务器或客户端不得依赖于不同类型属性的顺序。RADIUS服务器或客户端不能要求相同类型的属性是连续的。
These requirements also apply to the "Long Extended Type" Attribute, including fragments. Implementations MUST be able to process non-contiguous fragments -- that is, fragments that are mixed
这些要求也适用于“长扩展类型”属性，包括片段。实现必须能够处理非连续片段——即混合的片段
together with other attributes of a different Type. This will allow them to accept packets, so long as the Attributes can be correctly decoded.
以及其他不同类型的属性。这将允许他们接受数据包，只要属性可以正确解码。
We define a new data type in RADIUS, called "tlv". The "tlv" data type is an encapsulation layer that permits the "Value" field of an Attribute to contain new sub-Attributes. These sub-Attributes can in turn contain "Value"s of data type TLV. This capability both extends the Attribute space and permits "nested" attributes to be used. This nesting can be used to encapsulate or group data into one or more logical containers.
我们在RADIUS中定义了一种新的数据类型，称为“tlv”。“tlv”数据类型是一个封装层，它允许属性的“值”字段包含新的子属性。这些子属性可以依次包含TLV数据类型的“值”。此功能既扩展了属性空间，又允许使用“嵌套”属性。此嵌套可用于将数据封装或分组到一个或多个逻辑容器中。
The "tlv" data type reuses the RADIUS Attribute format, as given below:
“tlv”数据类型重用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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-Type | TLV-Length | TLV-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-Type | TLV-Length | TLV-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV-Type
TLV型
The TLV-Type field is one octet. Up-to-date values of this field are specified according to the policies and rules described in Section 10. Values 254-255 are "Reserved" for use by future extensions to RADIUS. The value 26 has no special meaning and MUST NOT be treated as a Vendor-Specific Attribute.
TLV类型字段是一个八位字节。该字段的最新值是根据第10节中描述的策略和规则指定的。值254-255是“保留”的，供将来的RADIUS扩展使用。值26没有特殊含义，不得视为特定于供应商的属性。
As with the Extended-Type field defined above, the TLV-Type is meaningful only within the context defined by "Type" fields of the encapsulating Attributes. That is, the field may be thought of as defining a new type space of the form "Type.Extended-Type.TLV-Type". Where TLVs are nested, the type space is of the form "Type.Extended-Type.TLV-Type.TLV-Type", etc.
与上面定义的扩展类型字段一样，TLV类型只有在封装属性的“Type”字段定义的上下文中才有意义。也就是说，该字段可以被认为是定义了一个新的类型空间，其形式为“type.Extended type.TLV type”。当TLV嵌套时，类型空间的形式为“type.Extended type.TLV type.TLV type”，等等。
A RADIUS server MAY ignore Attributes with an unknown "TLV-Type".
RADIUS服务器可能会忽略具有未知“TLV类型”的属性。
A RADIUS client MAY ignore Attributes with an unknown "TLV-Type".
RADIUS客户端可能会忽略具有未知“TLV类型”的属性。
A RADIUS proxy SHOULD forward Attributes with an unknown "TLV-Type" verbatim.
RADIUS代理应逐字转发具有未知“TLV类型”的属性。
TLV-Length
TLV长度
The TLV-Length field is one octet and indicates the length of this TLV, including the TLV-Type, TLV-Length, and TLV-Value fields. It MUST have a value between 3 and 255. If a client or server receives a TLV with an invalid TLV-Length, then the Attribute that encapsulates that TLV MUST be considered to be an "invalid attribute" and handled as per Section 2.8, below.
TLV长度字段是一个八位字节，指示此TLV的长度，包括TLV类型、TLV长度和TLV值字段。它的值必须介于3和255之间。如果客户机或服务器收到的TLV长度无效，则封装该TLV的属性必须视为“无效属性”，并按照以下第2.8节进行处理。
TLV-Value
TLV值
The TLV-Value field is one or more octets and contains information specific to the Attribute. The format and length of the TLV-Value field are determined by the TLV-Type and TLV-Length fields.
TLV值字段是一个或多个八位字节，包含特定于属性的信息。TLV值字段的格式和长度由TLV类型和TLV长度字段确定。
The TLV-Value field SHOULD encapsulate a standard RADIUS data type. Non-standard data types SHOULD NOT be used within TLV-Value fields. We note that the TLV-Value field MAY also contain one or more attributes of data type TLV; data type TLV allows for simple grouping and multiple layers of nesting.
TLV值字段应封装标准半径数据类型。TLV值字段中不应使用非标准数据类型。我们注意到，TLV值字段还可能包含一个或多个数据类型为TLV的属性；数据类型TLV允许简单的分组和多层嵌套。
The TLV-Value field is limited to containing 253 or fewer octets of data. Specifications that require a TLV to contain more than 253 octets of data are incompatible with RADIUS and need to be redesigned. Specifications that require the transport of empty "Value"s (i.e., Length = 2) are incompatible with RADIUS and need to be redesigned.
TLV值字段仅限于包含253个或更少的八位字节的数据。要求TLV包含253个八位字节以上数据的规范与RADIUS不兼容，需要重新设计。要求运输空“值”（即长度=2）的规范与半径不兼容，需要重新设计。
The TLV-Value field MUST NOT contain data using the "Extended Type" formats defined in this document. The base Extended Attributes format allows for sufficient flexibility that nesting them inside of a TLV offers little additional value.
TLV值字段不得包含使用本文档中定义的“扩展类型”格式的数据。基本扩展属性格式提供了足够的灵活性，将它们嵌套在TLV中几乎没有额外价值。
This TLV definition is compatible with the suggested format of the "String" field of the Vendor-Specific Attribute, as defined in [RFC2865] Section 5.26, though that specification does not discuss nesting.
该TLV定义与[RFC2865]第5.26节中定义的供应商特定属性的“字符串”字段的建议格式兼容，尽管该规范未讨论嵌套。
Vendors MAY use attributes of type "TLV" in any Vendor-Specific Attribute. It is RECOMMENDED to use type "TLV" for VSAs, in preference to any other format.
供应商可在任何供应商特定属性中使用“TLV”类型的属性。建议VSA使用类型“TLV”，优先于任何其他格式。
If multiple TLVs with the same TLV-Type are present, the order of TLVs with the same TLV-Type MUST be preserved by any proxies. The order of TLVs of different TLV-Types is not required to be preserved. A RADIUS server or client MUST NOT have any dependencies on the order of TLVs of different TLV-Types. A RADIUS server or client MUST NOT require TLVs of the same TLV-Type to be contiguous.
如果存在多个具有相同TLV类型的TLV，则任何代理都必须保留具有相同TLV类型的TLV的顺序。不同TLV类型的TLV顺序无需保留。RADIUS服务器或客户端不得依赖于不同TLV类型的TLV顺序。RADIUS服务器或客户端不得要求相同TLV类型的TLV连续。
The interpretation of multiple TLVs of the same TLV-Type MUST be that of a logical "and", unless otherwise specified. That is, multiple TLVs are interpreted as specifying an unordered set of values. Specifications SHOULD NOT define TLVs to be interpreted as a logical "or". Doing so would mean that a RADIUS client or server would make an arbitrary and non-deterministic choice among the values.
除非另有规定，同一TLV类型的多个TLV的解释必须是逻辑“和”。也就是说，多个TLV被解释为指定一组无序的值。规范不应将TLV定义为逻辑“或”。这样做意味着RADIUS客户机或服务器将在这些值中做出任意和不确定的选择。
TLVs may contain other TLVs. When this occurs, the "container" TLV MUST be completely filled by the "contained" TLVs. That is, the "container" TLV-Length field MUST be exactly two (2) more than the sum of the "contained" TLV-Length fields. If the "contained" TLVs overfill the "container" TLV, the "container" TLV MUST be considered to be an "invalid attribute" and handled as described in Section 2.8, below.
TLV可能包含其他TLV。发生这种情况时，“容器”TLV必须完全由“包含的”TLV填充。也就是说，“容器”TLV长度字段必须正好比“包含的”TLV长度字段的总和多两（2）个。如果“包含的”TLV超过了“容器”TLV，“容器”TLV必须被视为“无效属性”，并按照下面第2.8节的说明进行处理。
The depth of TLV nesting is limited only by the restrictions on the TLV-Length field. The limit of 253 octets of data results in a limit of 126 levels of nesting. However, nesting depths of more than 4 are NOT RECOMMENDED. They have not been demonstrated to be necessary in practice, and they appear to make implementations more complex. Reception of packets with such deeply nested TLVs may indicate implementation errors or deliberate attacks. Where implementations do not support deep nesting of TLVs, it is RECOMMENDED that the unsupported layers are treated as "invalid attributes".
TLV嵌套的深度仅受TLV长度字段的限制。253个八位字节的数据限制导致126个嵌套级别的限制。但是，不建议嵌套深度超过4。它们在实践中没有被证明是必要的，而且它们似乎使实现更加复杂。接收具有这种深度嵌套TLV的数据包可能表示实现错误或蓄意攻击。如果实现不支持TLV的深度嵌套，建议将不支持的层视为“无效属性”。
We define a new data type in RADIUS, called "evs", for "Extended-Vendor-Specific". The "evs" data type is an encapsulation layer that permits the EVS-Value field of an Attribute to contain a Vendor-Id, followed by an EVS-Type, and then vendor-defined data. This data can in turn contain valid RADIUS data types or any other data as determined by the vendor.
我们在RADIUS中定义了一种新的数据类型，称为“evs”，用于“扩展的特定于供应商的”。“evs”数据类型是一个封装层，它允许属性的evs值字段包含供应商Id，后跟evs类型，然后是供应商定义的数据。该数据可以包含有效的RADIUS数据类型或供应商确定的任何其他数据。
This data type is intended for use in attributes that carry vendor-specific information, as is done with the Vendor-Specific Attribute (Attribute number 26). It is RECOMMENDED that this data type be used by a vendor only when the Vendor-Specific Attribute Type space has been fully allocated.
此数据类型用于携带供应商特定信息的属性，与供应商特定属性（属性编号26）一样。建议仅当供应商特定的属性类型空间已完全分配时，供应商才使用此数据类型。
Where [RFC2865] Section 5.26 makes a recommendation for the format of the data following the Vendor-Id, we give a strict definition. Experience has shown that many vendors have not followed the [RFC2865] recommendations, leading to interoperability issues. We hope here to give vendors sufficient flexibility as to meet their needs while minimizing the use of non-standard VSA formats.
[RFC2865]第5.26节对供应商Id后的数据格式提出了建议，我们给出了严格的定义。经验表明，许多供应商没有遵循[RFC2865]建议，导致互操作性问题。我们希望在此为供应商提供足够的灵活性，以满足他们的需求，同时最大限度地减少非标准VSA格式的使用。
The "evs" data type MAY be used in Attributes having the format of "Extended Type" or "Long Extended Type". It MUST NOT be used in any other Attribute definition, including standard RADIUS attributes, TLVs, and VSAs.
“evs”数据类型可用于具有“扩展类型”或“长扩展类型”格式的属性中。它不得用于任何其他属性定义，包括标准半径属性、TLV和VSA。
A summary of the "evs" data type format is shown below. The fields are transmitted from left to right.
“evs”数据类型格式的摘要如下所示。字段从左向右传输。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EVS-Type | EVS-Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EVS-Type | EVS-Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id
供应商Id
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
供应商Id字段的4个八位字节是供应商的网络管理私有企业代码[PEN]，按网络字节顺序排列。
EVS-Type
电动汽车类型
The EVS-Type field is one octet. Values are assigned at the sole discretion of the vendor.
EVS类型字段是一个八位字节。价值分配由供应商自行决定。
EVS-Value
EVS值
The EVS-Value field is one or more octets. It SHOULD encapsulate a standard RADIUS data type. Using non-standard data types is NOT RECOMMENDED. We note that the EVS-Value field may be of data type TLV. However, it MUST NOT be of data type "evs", as the use cases are unclear for one vendor delegating Attribute Type space to another vendor.
EVS值字段是一个或多个八位字节。它应该封装一个标准的RADIUS数据类型。不建议使用非标准数据类型。我们注意到EVS值字段可能是TLV数据类型。但是，它不能是数据类型“evs”，因为一个供应商将属性类型空间委托给另一个供应商的用例不清楚。
The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. While we recognize that vendors have complete control over the contents and format of the EVS-Value field, we recommend that good practices be followed.
信息的实际格式是特定于站点或应用程序的，一个健壮的实现应该支持字段作为无差别的八位字节。虽然我们认识到供应商完全可以控制EVS值字段的内容和格式，但我们建议遵循良好做法。
Further codification of the range of allowed usage of this field is outside the scope of this specification.
该字段允许使用范围的进一步编码不在本规范范围内。
Note that unlike the format described in [RFC2865] Section 5.26, this data type has no "Vendor-Length" field. The length of the EVS-Value field is implicit and is determined by taking the "Length" of the encapsulating RADIUS attribute and then subtracting the length of the
请注意，与[RFC2865]第5.26节中描述的格式不同，此数据类型没有“供应商长度”字段。EVS值字段的长度是隐式的，通过获取封装半径属性的“长度”，然后减去封装半径属性的长度来确定
Attribute header (2 octets), the "Extended Type" (1 octet), the Vendor-Id (4 octets), and the EVS-Type (1 octet). That is, for "Extended Type" Attributes the length of the EVS-Value field is eight (8) less than the value of the Length field, and for "Long Extended Type" Attributes the length of the EVS-Value field is nine (9) less than the value of the Length field.
属性头（2个八位字节）、“扩展类型”（1个八位字节）、供应商Id（4个八位字节）和EVS类型（1个八位字节）。也就是说，对于“扩展类型”属性，EVS值字段的长度比长度字段的值小八（8），对于“长扩展类型”属性，EVS值字段的长度比长度字段的值小九（9）。
We define a new data type in RADIUS, called "integer64", which carries a 64-bit unsigned integer in network byte order.
我们在RADIUS中定义了一种新的数据类型，称为“integer64”，它以网络字节顺序携带一个64位无符号整数。
This data type is intended to be used in any situation where there is a need to have counters that can count past 2^32. The expected use of this data type is within Accounting-Request packets, but this data type SHOULD be used in any packet where 32-bit integers are expected to be insufficient.
此数据类型适用于需要计数器计数超过2^32的任何情况。此数据类型的预期用途是在记帐请求数据包中，但此数据类型应用于预期32位整数不足的任何数据包中。
The "integer64" data type can be used in Attributes of any format, standard space, extended attributes, TLVs, and VSAs.
“integer64”数据类型可用于任何格式的属性、标准空间、扩展属性、TLV和VSA。
A summary of the "integer64" data type format is shown below. The fields are transmitted from left to right.
“integer64”数据类型格式的摘要如下所示。字段从左向右传输。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attributes having data type "integer64" MUST have the relevant Length field set to eight more than the length of the Attribute header. For standard space Attributes and TLVs, this means that the Length field MUST be set to ten (10). For "Extended Type" Attributes, the Length field MUST be set to eleven (11). For "Long Extended Type" Attributes, the Length field MUST be set to twelve (12).
数据类型为“integer64”的属性必须将相关长度字段设置为比属性头的长度多8个。对于标准空间属性和TLV，这意味着长度字段必须设置为十（10）。对于“扩展类型”属性，长度字段必须设置为十一（11）。对于“长扩展类型”属性，长度字段必须设置为十二（12）。
We define the Vendor-Id field of Vendor-Specific Attributes to encompass the entire 4 octets of the Vendor field. [RFC2865] Section 5.26 defined it to be 3 octets, with the fourth octet being zero. This change has no immediate impact on RADIUS, as the maximum Private Enterprise Code defined is still within 16 bits.
我们定义了供应商特定属性的供应商Id字段，以包含供应商字段的整个4个八位字节。[RFC2865]第5.26节将其定义为3个八位字节，第四个八位字节为零。此更改对RADIUS没有直接影响，因为定义的最大私有企业代码仍在16位以内。
However, it is best to make advance preparations for changes in the protocol. As such, it is RECOMMENDED that all implementations support four (4) octets for the Vendor-Id field, instead of three (3).
然而，最好提前为议定书的修改做好准备。因此，建议所有实现支持供应商Id字段的四（4）个八位字节，而不是三（3）个八位字节。
Attributes have traditionally been identified by a unique name and number. For example, the Attribute "User-Name" has been allocated number one (1). This scheme needs to be extended in order to be able to refer to attributes of "Extended Type", and to TLVs. It will also be used by IANA for allocating RADIUS Attribute Type values.
传统上，属性由唯一的名称和编号标识。例如，属性“用户名”已被分配到第一（1）位。该方案需要扩展，以便能够引用“扩展类型”的属性和TLV。IANA还将使用它来分配半径属性类型值。
The names and identifiers given here are intended to be used only in specifications. The system presented here may not be useful when referring to the contents of a RADIUS packet. It imposes no requirements on implementations, as implementations are free to reference RADIUS attributes via any method they choose.
此处给出的名称和标识符仅用于规范中。这里介绍的系统在引用RADIUS数据包的内容时可能没有用处。它对实现没有任何要求，因为实现可以通过选择的任何方法自由引用RADIUS属性。
RADIUS specifications traditionally use names consisting of one or more words, separated by hyphens, e.g., "User-Name". However, these names are not allocated from a registry, and there is no restriction other than convention on their global uniqueness.
RADIUS规范通常使用由一个或多个单词组成的名称，用连字符分隔，例如“用户名”。但是，这些名称不是从注册表中分配的，并且除了对其全局唯一性的约定之外，没有其他限制。
Similarly, vendors have often used their company name as the prefix for VSA names, though this practice is not universal. For example, for a vendor named "Example", the name "Example-Attribute-Name" SHOULD be used instead of "Attribute-Name". The second form can conflict with attributes from other vendors, whereas the first form cannot.
类似地，供应商经常使用其公司名称作为VSA名称的前缀，尽管这种做法并不普遍。例如，对于名为“示例”的供应商，应使用名称“示例属性名称”而不是“属性名称”。第二个表单可以与其他供应商的属性冲突，而第一个表单不能。
It is therefore RECOMMENDED that specifications give names to Attributes that attempt to be globally unique across all RADIUS Attributes. It is RECOMMENDED that a vendor use its name as a unique prefix for attribute names, e.g., Livingston-IP-Pool instead of IP-Pool. It is RECOMMENDED that implementations enforce uniqueness on names; not doing so would lead to ambiguity and problems.
因此，建议规范为试图在所有RADIUS属性中全局唯一的属性命名。建议供应商使用其名称作为属性名称的唯一前缀，例如，Livingston IP池而不是IP池。建议实现对名称强制唯一性；不这样做会导致歧义和问题。
We recognize that these suggestions may sometimes be difficult to implement in practice.
我们认识到，这些建议有时可能难以在实践中实施。
TLVs SHOULD be named with a unique prefix that is shared among related attributes. For example, a specification that defines a set of TLVs related to time could create attributes called "Time-Zone", "Time-Day", "Time-Hour", "Time-Minute", etc.
TLV应使用在相关属性之间共享的唯一前缀命名。例如，定义一组与时间相关的TLV的规范可以创建称为“时区”、“时间日”、“时间小时”、“时间分钟”等属性。
The RADIUS Attribute Type space defines a context for a particular "Extended-Type" field. The "Extended-Type" field allows for 256 possible type code values, with values 1 through 240 available for allocation. We define here an identification method that uses a "dotted number" notation similar to that used for Object Identifiers (OIDs), formatted as "Type.Extended-Type".
RADIUS属性类型空间定义特定“扩展类型”字段的上下文。“扩展类型”字段允许256个可能的类型代码值，值1到240可用于分配。我们在这里定义了一种标识方法，它使用“点编号”表示法，类似于用于对象标识符（OID）的表示法，格式为“Type.Extended Type”。
For example, an attribute within the Type space of 241, having Extended-Type of one (1), is uniquely identified as "241.1". Similarly, an attribute within the Type space of 246, having Extended-Type of ten (10), is uniquely identified as "246.10".
例如，类型空间241中具有扩展类型1的属性被唯一标识为“241.1”。类似地，类型空间246中具有扩展类型十（10）的属性被唯一标识为“246.10”。
We can extend the Attribute reference scheme defined above for TLVs. This is done by leveraging the "dotted number" notation. As above, we define an additional TLV Type space, within the "Extended Type" space, by appending another "dotted number" in order to identify the TLV. This method can be repeated in sequence for nested TLVs.
我们可以扩展上面为TLV定义的属性引用方案。这是通过利用“虚线数字”符号实现的。如上所述，我们在“扩展类型”空间中定义了一个额外的TLV类型空间，通过附加另一个“点编号”来标识TLV。对于嵌套TLV，可以按顺序重复此方法。
For example, let us say that "245.1" identifies RADIUS Attribute Type 245, containing an "Extended Type" of one (1), which is of type "TLV". That attribute will contain 256 possible TLVs, one for each value of the TLV-Type field. The first TLV-Type value of one (1) can then be identified by appending a ".1" to the number of the encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, the sequence "245.2.3.4" identifies RADIUS attribute 245, containing an "Extended Type" of two (2), which is of type "TLV", which in turn contains a TLV with TLV-Type number three (3), which in turn contains another TLV, with TLV-Type number four (4).
例如，假设“245.1”标识半径属性类型245，其中包含一（1）个“扩展类型”，类型为“TLV”。该属性将包含256个可能的TLV，TLV类型字段的每个值对应一个TLV。然后，可以通过在封装属性（“241.1”）的编号后添加“.1”来识别一（1）的第一个TLV类型值，从而生成“241.1.1”。类似地，序列“245.2.3.4”标识半径属性245，包含两（2）个“扩展类型”，类型为“TLV”，依次包含TLV类型编号为3（3）的TLV，再依次包含另一个TLV类型编号为4（4）。
There has historically been no method for numerically addressing VSAs. The "dotted number" method defined here can also be leveraged to create such an addressing scheme. However, as the VSAs are completely under the control of each individual vendor, this section provides a suggested practice but does not define a standard of any kind.
历史上一直没有对VSA进行数字寻址的方法。这里定义的“点编号”方法也可以用来创建这样的寻址方案。但是，由于VSA完全受每个供应商的控制，本节提供了建议的做法，但未定义任何类型的标准。
The Vendor-Specific Attribute has been assigned the Attribute number 26. It in turn carries a 32-bit Vendor-Id, and possibly additional VSAs. Where the VSAs follow the format recommended by [RFC2865] Section 5.26, a VSA can be identified as "26.Vendor-Id.Vendor-Type".
供应商特定属性已分配属性编号26。它又携带一个32位的供应商Id，可能还有额外的VSA。如果VSA遵循[RFC2865]第5.26节建议的格式，则VSA可标识为“26.供应商Id.供应商类型”。
For example, Livingston has Vendor-Id 307 and has defined an attribute "IP-Pool" as number 6. This VSA can be uniquely identified as 26.307.6, but it cannot be uniquely identified by name, as other vendors may have used the same name.
例如，Livingston具有供应商Id 307，并将属性“IP池”定义为数字6。此VSA可以唯一标识为26.307.6，但不能通过名称唯一标识，因为其他供应商可能使用了相同的名称。
Note that there are few restrictions on the size of the numerical values in this notation. The Vendor-Id is a 32-bit number, and the VSA may have been assigned from a 16-bit Vendor-Specific Attribute Type space. Implementations SHOULD be capable of handling 32-bit numbers at each level of the "dotted number" notation.
请注意，此符号中的数值大小几乎没有限制。供应商Id是32位数字，VSA可能是从16位供应商特定属性类型空间分配的。实现应该能够在“点数字”表示法的每个级别处理32位数字。
For example, the company USR has historically used Vendor-Id 429 and has defined a "Version-Id" attribute as number 32768. This VSA can be uniquely identified as 26.429.32768 but again cannot be uniquely identified by name.
例如，公司USR历史上使用过供应商Id 429，并将“版本Id”属性定义为编号32768。此VSA可以唯一标识为26.429.32768，但同样不能通过名称唯一标识。
Where a VSA is a TLV, the "dotted number" notation can be used as above: 26.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3, where the "TLVn" values are the numerical values assigned by the vendor to the different nested TLVs.
如果VSA是TLV，则可以如上所述使用“点编号”表示法：26.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3，其中“TLVn”值是供应商分配给不同嵌套TLV的数值。
The term "invalid attribute" is new to this specification. It is defined to mean that the Length field of an Attribute permits the packet to be accepted as not being "malformed". However, the "Value" field of the Attribute does not follow the format required by the data type defined for that Attribute, and therefore the Attribute is "malformed". In order to distinguish the two cases, we refer to "malformed" packets and "invalid attributes".
术语“无效属性”是本规范中的新术语。它的定义是指属性的长度字段允许数据包被接受为没有“格式错误”。但是，属性的“值”字段不遵循为该属性定义的数据类型所需的格式，因此该属性“格式不正确”。为了区分这两种情况，我们提到了“格式错误”的数据包和“无效属性”。
For example, an implementation receives a packet that is well formed. That packet contains an Attribute allegedly of data type "address" but that has Length not equal to four. In that situation, the packet is well formed, but the Attribute is not. Therefore, it is an "invalid attribute".
例如，实现接收格式良好的数据包。该数据包包含一个据称为数据类型“address”的属性，但其长度不等于4。在这种情况下，数据包是格式良好的，但属性不是。因此，它是一个“无效属性”。
A similar analysis can be performed when an attribute carries TLVs. The encapsulating attribute may be well formed, but the TLV may be an "invalid attribute". The existence of an "invalid attribute" in a packet or attribute MUST NOT result in the implementation discarding the entire packet or treating the packet as a negative acknowledgment. Instead, only the "invalid attribute" is treated specially.
当属性携带TLV时，可以执行类似的分析。封装属性可能格式良好，但TLV可能是“无效属性”。数据包或属性中存在“无效属性”不得导致实现丢弃整个数据包或将数据包视为否定确认。相反，只对“无效属性”进行特殊处理。
When an implementation receives an "invalid attribute", it SHOULD be silently discarded, except when the implementation is acting as a proxy (see Section 5.2 for discussion of proxy servers). If it is
当一个实现接收到一个“无效属性”时，它应该被悄悄地丢弃，除非该实现充当代理（有关代理服务器的讨论，请参见第5.2节）。如果是
not discarded, it MUST NOT be handled in the same manner as a well-formed attribute. For example, receiving an Attribute of data type "address" containing either less than four octets or more than four octets of data means that the Attribute MUST NOT be treated as being of data type "address". The reason here is that if the Attribute does not carry an IPv4 address, the receiver has no idea what format the data is in, and it is therefore not an IPv4 address.
如果不丢弃，则不能以与格式良好的属性相同的方式处理它。例如，接收包含少于四个八位字节或多于四个八位字节的数据类型“address”的属性意味着该属性不能被视为数据类型“address”。这里的原因是，如果属性不携带IPv4地址，则接收方不知道数据的格式，因此它不是IPv4地址。
For Attributes of type "Long Extended Type", an Attribute is considered to be an "invalid attribute" when it does not match the criteria set out in Section 2.2, above.
对于类型为“长扩展类型”的属性，如果属性不符合上述第2.2节中规定的标准，则该属性被视为“无效属性”。
For Attributes of type "TLV", an Attribute is considered to be an "invalid attribute" when the TLV-Length field allows the encapsulating Attribute to be parsed but the TLV-Value field does not match the criteria for that TLV. Implementations SHOULD NOT treat the "invalid attribute" property as being transitive. That is, the Attribute encapsulating the "invalid attribute" SHOULD NOT be treated as an "invalid attribute". That encapsulating Attribute might contain multiple TLVs, only one of which is an "invalid attribute".
对于“TLV”类型的属性，如果TLV长度字段允许解析封装属性，但TLV值字段与该TLV的条件不匹配，则该属性被视为“无效属性”。实现不应将“invalid attribute”属性视为可传递的。也就是说，封装“无效属性”的属性不应被视为“无效属性”。该封装属性可能包含多个TLV，其中只有一个是“无效属性”。
However, a TLV definition may require particular sub-TLVs to be present and/or to have specific values. If a sub-TLV is missing or contains incorrect value(s), or if it is an "invalid attribute", then the encapsulating TLV SHOULD be treated as an "invalid attribute". This requirement ensures that strongly connected TLVs are either handled as a coherent whole or ignored entirely.
然而，TLV定义可能要求存在特定子TLV和/或具有特定值。如果子TLV缺失或包含不正确的值，或者是“无效属性”，则封装TLV应视为“无效属性”。该要求确保将强连接的TLV作为一个连贯的整体处理或完全忽略。
It is RECOMMENDED that Attributes with unknown Type, Extended-Type, TLV-Type, or EVS-Type are treated as "invalid attributes". This recommendation is compatible with the suggestion in [RFC2865] Section 5 that implementations "MAY ignore Attributes with an unknown Type".
建议将未知类型、扩展类型、TLV类型或EVS类型的属性视为“无效属性”。此建议与[RFC2865]第5节中的建议一致，即实现“可能忽略未知类型的属性”。
We define four (4) attributes of "Extended Type", which are allocated from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. We also define two (2) attributes of "Long Extended Type", which are allocated from the "Reserved" Attribute Type codes of 245 and 246.
我们定义了四（4）个“扩展类型”属性，它们是从241、242、243和244的“保留”属性类型代码中分配的。我们还定义了两（2）个“长扩展类型”属性，它们是从245和246的“保留”属性类型代码中分配的。
Type Name
---- ----
241 Extended-Type-1
242 Extended-Type-2
243 Extended-Type-3
244 Extended-Type-4
245 Long-Extended-Type-1
246 Long-Extended-Type-2
Type Name
---- ----
241 Extended-Type-1
242 Extended-Type-2
243 Extended-Type-3
244 Extended-Type-4
245 Long-Extended-Type-1
246 Long-Extended-Type-2
The rest of this section gives detailed definitions for each Attribute based on the above summary.
本节的其余部分根据上述总结给出了每个属性的详细定义。
Description
描述
This attribute encapsulates attributes of the "Extended Type" format, in the RADIUS Attribute Type space of 241.{1-255}.
此属性将“扩展类型”格式的属性封装在半径属性类型空间241.{1-255}中。
A summary of the Extended-Type-1 Attribute format is shown below. The fields are transmitted from left to right.
扩展类型1属性格式的摘要如下所示。字段从左向右传输。
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 | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
241 for Extended-Type-1.
241适用于扩展型1。
Length
长
>= 4
>= 4
Extended-Type
扩展型
The Extended-Type field is one octet. Up-to-date values of this field are specified in the 241.{1-255} RADIUS Attribute Type space, according to the policies and rules described in Section 10. Further definition of this field is given in Section 2.1, above.
扩展类型字段是一个八位字节。根据第10节中描述的策略和规则，此字段的最新值在241.{1-255}RADIUS属性类型空间中指定。上述第2.1节给出了该字段的进一步定义。
Value
价值
The "Value" field is one or more octets.
“值”字段是一个或多个八位字节。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
支持此规范的实现必须使用“Type.Extended Type”标识符来确定“Value”字段的解释。
Description
描述
This attribute encapsulates attributes of the "Extended Type" format, in the RADIUS Attribute Type space of 242.{1-255}.
此属性在242.{1-255}的半径属性类型空间中封装“扩展类型”格式的属性。
A summary of the Extended-Type-2 Attribute format is shown below. The fields are transmitted from left to right.
扩展类型2属性格式的摘要如下所示。字段从左向右传输。
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 | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
242 for Extended-Type-2.
242适用于扩展型2。
Length
长
>= 4
>= 4
Extended-Type
扩展型
The Extended-Type field is one octet. Up-to-date values of this field are specified in the 242.{1-255} RADIUS Attribute Type space, according to the policies and rules described in Section 10. Further definition of this field is given in Section 2.1, above.
扩展类型字段是一个八位字节。根据第10节中描述的策略和规则，此字段的最新值在242.{1-255}RADIUS属性类型空间中指定。上述第2.1节给出了该字段的进一步定义。
Value
价值
The "Value" field is one or more octets.
“值”字段是一个或多个八位字节。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
支持此规范的实现必须使用“Type.Extended Type”标识符来确定“Value”字段的解释。
Description
描述
This attribute encapsulates attributes of the "Extended Type" format, in the RADIUS Attribute Type space of 243.{1-255}.
此属性在243.{1-255}的半径属性类型空间中封装“扩展类型”格式的属性。
A summary of the Extended-Type-3 Attribute format is shown below. The fields are transmitted from left to right.
扩展类型3属性格式的摘要如下所示。字段从左向右传输。
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 | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
243 for Extended-Type-3.
243适用于扩展型3。
Length
长
>= 4
>= 4
Extended-Type
扩展型
The Extended-Type field is one octet. Up-to-date values of this field are specified in the 243.{1-255} RADIUS Attribute Type space, according to the policies and rules described in Section 10. Further definition of this field is given in Section 2.1, above.
扩展类型字段是一个八位字节。根据第10节中描述的策略和规则，此字段的最新值在243.{1-255}RADIUS属性类型空间中指定。上述第2.1节给出了该字段的进一步定义。
Value
价值
The "Value" field is one or more octets.
“值”字段是一个或多个八位字节。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
支持此规范的实现必须使用“Type.Extended Type”标识符来确定“Value”字段的解释。
Description
描述
This attribute encapsulates attributes of the "Extended Type" format, in the RADIUS Attribute Type space of 244.{1-255}.
此属性在244.{1-255}的半径属性类型空间中封装“扩展类型”格式的属性。
A summary of the Extended-Type-4 Attribute format is shown below. The fields are transmitted from left to right.
扩展类型4属性格式的摘要如下所示。字段从左向右传输。
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 | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
244 for Extended-Type-4.
244适用于扩展型-4。
Length
长
>= 4
>= 4
Extended-Type
扩展型
The Extended-Type field is one octet. Up-to-date values of this field are specified in the 244.{1-255} RADIUS Attribute Type space, according to the policies and rules described in Section 10. Further definition of this field is given in Section 2.1, above.
扩展类型字段是一个八位字节。根据第10节中描述的策略和规则，此字段的最新值在244.{1-255}RADIUS属性类型空间中指定。上述第2.1节给出了该字段的进一步定义。
Value
价值
The "Value" field is one or more octets.
“值”字段是一个或多个八位字节。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the Value Field.
支持此规范的实现必须使用“Type.Extended Type”标识符来确定值字段的解释。
Description
描述
This attribute encapsulates attributes of the "Long Extended Type" format, in the RADIUS Attribute Type space of 245.{1-255}.
此属性将“长扩展类型”格式的属性封装在半径属性类型空间245.{1-255}中。
A summary of the Long-Extended-Type-1 Attribute format is shown below. The fields are transmitted from left to right.
Long-Extended-Type-1属性格式的摘要如下所示。字段从左向右传输。
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 | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
245 for Long-Extended-Type-1
245适用于加长型1
Length
长
>= 5
>= 5
Extended-Type
扩展型
The Extended-Type field is one octet. Up-to-date values of this field are specified in the 245.{1-255} RADIUS Attribute Type space, according to the policies and rules described in Section 10. Further definition of this field is given in Section 2.1, above.
扩展类型字段是一个八位字节。根据第10节中描述的策略和规则，此字段的最新值在245.{1-255}RADIUS属性类型空间中指定。上述第2.1节给出了该字段的进一步定义。
M (More)
M（更多）
The More field is one (1) bit in length and indicates whether or not the current attribute contains "more" than 251 octets of data. Further definition of this field is given in Section 2.2, above.
“更多”字段的长度为一（1）位，表示当前属性是否包含超过251个八位字节的数据。上述第2.2节给出了该字段的进一步定义。
Reserved
含蓄的
This field is 7 bits long and is reserved for future use. Implementations MUST set it to zero (0) when encoding an attribute for sending in a packet. The contents SHOULD be ignored on reception.
此字段的长度为7位，保留供将来使用。在编码用于在数据包中发送的属性时，实现必须将其设置为零（0）。接待时应忽略这些内容。
Value
价值
The "Value" field is one or more octets.
“值”字段是一个或多个八位字节。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
支持此规范的实现必须使用“Type.Extended Type”标识符来确定“Value”字段的解释。
Description
描述
This attribute encapsulates attributes of the "Long Extended Type" format, in the RADIUS Attribute Type space of 246.{1-255}.
此属性将“长扩展类型”格式的属性封装在246.{1-255}的RADIUS属性类型空间中。
A summary of the Long-Extended-Type-2 Attribute format is shown below. The fields are transmitted from left to right.
Long-Extended-Type-2属性格式的摘要如下所示。字段从左向右传输。
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 | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
246 for Long-Extended-Type-2
246适用于长加长型2
Length
长
>= 5
>= 5
Extended-Type
扩展型
The Extended-Type field is one octet. Up-to-date values of this field are specified in the 246.{1-255} RADIUS Attribute Type space, according to the policies and rules described in Section 10. Further definition of this field is given in Section 2.1, above.
扩展类型字段是一个八位字节。根据第10节中描述的策略和规则，此字段的最新值在246.{1-255}RADIUS属性类型空间中指定。上述第2.1节给出了该字段的进一步定义。
M (More)
M（更多）
The More field is one (1) bit in length and indicates whether or not the current attribute contains "more" than 251 octets of data. Further definition of this field is given in Section 2.2, above.
“更多”字段的长度为一（1）位，表示当前属性是否包含超过251个八位字节的数据。上述第2.2节给出了该字段的进一步定义。
Reserved
含蓄的
This field is 7 bits long and is reserved for future use. Implementations MUST set it to zero (0) when encoding an attribute for sending in a packet. The contents SHOULD be ignored on reception.
此字段的长度为7位，保留供将来使用。在编码用于在数据包中发送的属性时，实现必须将其设置为零（0）。接待时应忽略这些内容。
Value
价值
The "Value" field is one or more octets.
“值”字段是一个或多个八位字节。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to determine the interpretation of the "Value" field.
支持此规范的实现必须使用“Type.Extended Type”标识符来确定“Value”字段的解释。
We define six new attributes that can carry vendor-specific information. We define four (4) attributes of the "Extended Type" format, with Type codes (241.26, 242.26, 243.26, 244.26), using the "evs" data type. We also define two (2) attributes using "Long Extended Type" format, with Type codes (245.26, 246.26), which are of the "evs" data type.
我们定义了六个新属性，它们可以携带特定于供应商的信息。我们使用“evs”数据类型定义了四（4）个“扩展类型”格式的属性，类型代码为（241.26、242.26、243.26、244.26）。我们还使用“长扩展类型”格式定义了两（2）个属性，类型代码（245.26、246.26）为“evs”数据类型。
Type.Extended-Type Name
------------------ ----
241.26 Extended-Vendor-Specific-1
242.26 Extended-Vendor-Specific-2
243.26 Extended-Vendor-Specific-3
244.26 Extended-Vendor-Specific-4
245.26 Extended-Vendor-Specific-5
246.26 Extended-Vendor-Specific-6
Type.Extended-Type Name
------------------ ----
241.26 Extended-Vendor-Specific-1
242.26 Extended-Vendor-Specific-2
243.26 Extended-Vendor-Specific-3
244.26 Extended-Vendor-Specific-4
245.26 Extended-Vendor-Specific-5
246.26 Extended-Vendor-Specific-6
The rest of this section gives detailed definitions for each Attribute based on the above summary.
本节的其余部分根据上述总结给出了每个属性的详细定义。
Description
描述
This attribute defines a RADIUS Type Code of 241.26, using the "evs" data type.
此属性使用“evs”数据类型定义半径类型代码241.26。
A summary of the Extended-Vendor-Specific-1 Attribute format is shown below. The fields are transmitted from left to right.
扩展的特定于供应商的-1属性格式摘要如下所示。字段从左向右传输。
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 | Extended-Type | Vendor-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type | Vendor-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type
Type.Extended-Type
241.26 for Extended-Vendor-Specific-1
241.26适用于扩展供应商特定的-1
Length
长
>= 9
>= 9
Vendor-Id
供应商Id
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
供应商Id字段的4个八位字节是供应商的网络管理私有企业代码[PEN]，按网络字节顺序排列。
Vendor-Type
供应商类型
The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.
供应商类型字段是一个八位字节。价值分配由供应商自行决定。
Value
价值
The "Value" field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
“值”字段是一个或多个八位字节。信息的实际格式是特定于站点或应用程序的，一个健壮的实现应该支持字段作为无差别的八位字节。
The codification of the range of allowed usage of this field is outside the scope of this specification.
该字段允许使用范围的编码不在本规范范围内。
The length of the "Value" field is eight (8) less than the value of the Length field.
“值”字段的长度比“长度”字段的值小八（8）。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to determine the interpretation of the "Value" field.
支持此规范的实现必须使用“Type.Extended Type.Vendor-Id.Vendor-Type”标识符来确定“Value”字段的解释。
Description
描述
This attribute defines a RADIUS Type Code of 242.26, using the "evs" data type.
此属性使用“evs”数据类型定义半径类型代码242.26。
A summary of the Extended-Vendor-Specific-2 Attribute format is shown below. The fields are transmitted from left to right.
扩展的特定于供应商的-2属性格式摘要如下所示。字段从左向右传输。
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 | Extended-Type | Vendor-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type | Vendor-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type
Type.Extended-Type
242.26 for Extended-Vendor-Specific-2
242.26适用于扩展的供应商特定-2
Length
长
>= 9
>= 9
Vendor-Id
供应商Id
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
供应商Id字段的4个八位字节是供应商的网络管理私有企业代码[PEN]，按网络字节顺序排列。
Vendor-Type
供应商类型
The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.
供应商类型字段是一个八位字节。价值分配由供应商自行决定。
Value
价值
The "Value" field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
“值”字段是一个或多个八位字节。信息的实际格式是特定于站点或应用程序的，一个健壮的实现应该支持字段作为无差别的八位字节。
The codification of the range of allowed usage of this field is outside the scope of this specification.
该字段允许使用范围的编码不在本规范范围内。
The length of the "Value" field is eight (8) less than the value of the Length field.
“值”字段的长度比“长度”字段的值小八（8）。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to determine the interpretation of the "Value" field.
支持此规范的实现必须使用“Type.Extended Type.Vendor-Id.Vendor-Type”标识符来确定“Value”字段的解释。
Description
描述
This attribute defines a RADIUS Type Code of 243.26, using the "evs" data type.
该属性使用“evs”数据类型定义半径类型代码243.26。
A summary of the Extended-Vendor-Specific-3 Attribute format is shown below. The fields are transmitted from left to right.
扩展的特定于供应商的-3属性格式摘要如下所示。字段从左向右传输。
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 | Extended-Type | Vendor-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type | Vendor-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type
Type.Extended-Type
243.26 for Extended-Vendor-Specific-3
243.26适用于扩展供应商特定-3
Length
长
>= 9
>= 9
Vendor-Id
供应商Id
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
供应商Id字段的4个八位字节是供应商的网络管理私有企业代码[PEN]，按网络字节顺序排列。
Vendor-Type
供应商类型
The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.
供应商类型字段是一个八位字节。价值分配由供应商自行决定。
Value
价值
The "Value" field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
“值”字段是一个或多个八位字节。信息的实际格式是特定于站点或应用程序的，一个健壮的实现应该支持字段作为无差别的八位字节。
The codification of the range of allowed usage of this field is outside the scope of this specification.
该字段允许使用范围的编码不在本规范范围内。
The length of the "Value" field is eight (8) less than the value of the Length field.
“值”字段的长度比“长度”字段的值小八（8）。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to determine the interpretation of the "Value" field.
支持此规范的实现必须使用“Type.Extended Type.Vendor-Id.Vendor-Type”标识符来确定“Value”字段的解释。
Description
描述
This attribute defines a RADIUS Type Code of 244.26, using the "evs" data type.
该属性使用“evs”数据类型定义半径类型代码244.26。
A summary of the Extended-Vendor-Specific-4 Attribute format is shown below. The fields are transmitted from left to right.
扩展的特定于供应商的-4属性格式摘要如下所示。字段从左向右传输。
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 | Extended-Type | Vendor-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type | Vendor-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type
Type.Extended-Type
244.26 for Extended-Vendor-Specific-4
244.26适用于扩展供应商特定的-4
Length
长
>= 9
>= 9
Vendor-Id
供应商Id
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
供应商Id字段的4个八位字节是供应商的网络管理私有企业代码[PEN]，按网络字节顺序排列。
Vendor-Type
供应商类型
The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.
供应商类型字段是一个八位字节。价值分配由供应商自行决定。
Value
价值
The "Value" field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
“值”字段是一个或多个八位字节。信息的实际格式是特定于站点或应用程序的，一个健壮的实现应该支持字段作为无差别的八位字节。
The codification of the range of allowed usage of this field is outside the scope of this specification.
该字段允许使用范围的编码不在本规范范围内。
The length of the "Value" field is eight (8) less than the value of the Length field.
“值”字段的长度比“长度”字段的值小八（8）。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to determine the interpretation of the "Value" field.
支持此规范的实现必须使用“Type.Extended Type.Vendor-Id.Vendor-Type”标识符来确定“Value”字段的解释。
Description
描述
This attribute defines a RADIUS Type Code of 245.26, using the "evs" data type.
该属性使用“evs”数据类型定义半径类型代码245.26。
A summary of the Extended-Vendor-Specific-5 Attribute format is shown below. The fields are transmitted from left to right.
扩展的特定于供应商的-5属性格式摘要如下所示。字段从左向右传输。
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 | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type
Type.Extended-Type
245.26 for Extended-Vendor-Specific-5
245.26适用于扩展供应商特定的-5
Length
长
>= 10 (first fragment)
>= 5 (subsequent fragments)
>= 10 (first fragment)
>= 5 (subsequent fragments)
When a VSA is fragmented across multiple Attributes, only the first Attribute contains the Vendor-Id and Vendor-Type fields. Subsequent Attributes contain fragments of the "Value" field only.
当VSA跨多个属性分段时，只有第一个属性包含供应商Id和供应商类型字段。后续属性仅包含“值”字段的片段。
M (More)
M（更多）
The More field is one (1) bit in length and indicates whether or not the current attribute contains "more" than 251 octets of data. Further definition of this field is given in Section 2.2, above.
“更多”字段的长度为一（1）位，表示当前属性是否包含超过251个八位字节的数据。上述第2.2节给出了该字段的进一步定义。
Reserved
含蓄的
This field is 7 bits long and is reserved for future use. Implementations MUST set it to zero (0) when encoding an attribute for sending in a packet. The contents SHOULD be ignored on reception.
此字段的长度为7位，保留供将来使用。在编码用于在数据包中发送的属性时，实现必须将其设置为零（0）。接待时应忽略这些内容。
Vendor-Id
供应商Id
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
供应商Id字段的4个八位字节是供应商的网络管理私有企业代码[PEN]，按网络字节顺序排列。
Vendor-Type
供应商类型
The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.
供应商类型字段是一个八位字节。价值分配由供应商自行决定。
Value
价值
The "Value" field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
“值”字段是一个或多个八位字节。信息的实际格式是特定于站点或应用程序的，一个健壮的实现应该支持字段作为无差别的八位字节。
The codification of the range of allowed usage of this field is outside the scope of this specification.
该字段允许使用范围的编码不在本规范范围内。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to determine the interpretation of the "Value" field.
支持此规范的实现必须使用“Type.Extended Type.Vendor-Id.Vendor-Type”标识符来确定“Value”字段的解释。
Description
描述
This attribute defines a RADIUS Type Code of 246.26, using the "evs" data type.
此属性使用“evs”数据类型定义半径类型代码246.26。
A summary of the Extended-Vendor-Specific-6 Attribute format is shown below. The fields are transmitted from left to right.
扩展的特定于供应商的-6属性格式摘要如下所示。字段从左向右传输。
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 | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type
Type.Extended-Type
246.26 for Extended-Vendor-Specific-6
246.26适用于扩展供应商特定的-6
Length
长
>= 10 (first fragment)
>= 5 (subsequent fragments)
>= 10 (first fragment)
>= 5 (subsequent fragments)
When a VSA is fragmented across multiple Attributes, only the first Attribute contains the Vendor-Id and Vendor-Type fields. Subsequent Attributes contain fragments of the "Value" field only.
当VSA跨多个属性分段时，只有第一个属性包含供应商Id和供应商类型字段。后续属性仅包含“值”字段的片段。
M (More)
M（更多）
The More field is one (1) bit in length and indicates whether or not the current attribute contains "more" than 251 octets of data. Further definition of this field is given in Section 2.2, above.
“更多”字段的长度为一（1）位，表示当前属性是否包含超过251个八位字节的数据。上述第2.2节给出了该字段的进一步定义。
Reserved
含蓄的
This field is 7 bits long and is reserved for future use. Implementations MUST set it to zero (0) when encoding an attribute for sending in a packet. The contents SHOULD be ignored on reception.
此字段的长度为7位，保留供将来使用。在编码用于在数据包中发送的属性时，实现必须将其设置为零（0）。接待时应忽略这些内容。
Vendor-Id
供应商Id
The 4 octets of the Vendor-Id field are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
供应商Id字段的4个八位字节是供应商的网络管理私有企业代码[PEN]，按网络字节顺序排列。
Vendor-Type
供应商类型
The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.
供应商类型字段是一个八位字节。价值分配由供应商自行决定。
Value
价值
The "Value" field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
“值”字段是一个或多个八位字节。信息的实际格式是特定于站点或应用程序的，一个健壮的实现应该支持字段作为无差别的八位字节。
The codification of the range of allowed usage of this field is outside the scope of this specification.
该字段允许使用范围的编码不在本规范范围内。
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to determine the interpretation of the "Value" field.
支持此规范的实现必须使用“Type.Extended Type.Vendor-Id.Vendor-Type”标识符来确定“Value”字段的解释。
There are a number of potential compatibility issues with traditional RADIUS, as defined in [RFC6158] and earlier. This section describes them.
如[RFC6158]及更早版本中所定义，与传统RADIUS存在许多潜在的兼容性问题。本节介绍了它们。
Some vendors have used Attribute Type codes from the "Reserved" space as part of vendor-defined dictionaries. This practice is considered antisocial behavior, as noted in [RFC6158]. These vendor definitions conflict with the Attributes in the RADIUS Attribute Type space. The conflicting definitions may make it difficult for implementations to support both those Vendor Attributes, and the new Extended Attribute formats.
一些供应商使用“保留”空间中的属性类型代码作为供应商定义字典的一部分。如[RFC6158]所述，这种行为被视为反社会行为。这些供应商定义与RADIUS属性类型空间中的属性冲突。相互冲突的定义可能使实现难以同时支持这些供应商属性和新的扩展属性格式。
We RECOMMEND that RADIUS client and server implementations delete all references to these improperly defined attributes. Failing that, we RECOMMEND that RADIUS server implementations have a per-client configurable flag that indicates which type of attributes are being sent from the client. If the flag is set to "Non-Standard Attributes", the conflicting attributes can be interpreted as being improperly defined Vendor-Specific Attributes. If the flag is set to
我们建议RADIUS客户端和服务器实现删除对这些未正确定义的属性的所有引用。否则，我们建议RADIUS服务器实现具有每个客户端可配置的标志，该标志指示从客户端发送的属性类型。如果该标志设置为“非标准属性”，则冲突属性可能被解释为定义不正确的供应商特定属性。如果该标志设置为
"IETF Attributes", the Attributes MUST be interpreted as being of the Extended Attributes format. The default SHOULD be to interpret the Attributes as being of the Extended Attributes format.
“IETF属性”，属性必须解释为扩展属性格式。默认情况下，应将属性解释为扩展属性格式。
Other methods of determining how to decode the Attributes into a "correct" form are NOT RECOMMENDED. Those methods are likely to be fragile and prone to error.
不建议使用其他方法确定如何将属性解码为“正确”形式。这些方法可能很脆弱，容易出错。
We RECOMMEND that RADIUS server implementations reuse the above flag to determine which types of attributes to send in a reply message. If the request is expected to contain the improperly defined attributes, the reply SHOULD NOT contain Extended Attributes. If the request is expected to contain Extended Attributes, the reply MUST NOT contain the improper Attributes.
我们建议RADIUS服务器实现重用上述标志来确定在回复消息中发送哪些类型的属性。如果请求预期包含未正确定义的属性，则回复不应包含扩展属性。如果请求预期包含扩展属性，则回复不得包含不正确的属性。
RADIUS clients will have fewer issues than servers. Clients MUST NOT send improperly defined Attributes in a request. For replies, clients MUST interpret attributes as being of the Extended Attributes format, instead of the improper definitions. These requirements impose no change in the RADIUS specifications, as such usage by vendors has always been in conflict with the standard requirements and the standards process.
RADIUS客户端的问题将少于服务器。客户端不得在请求中发送定义不正确的属性。对于回复，客户端必须将属性解释为扩展属性格式，而不是不正确的定义。这些要求不会改变RADIUS规范，因为供应商的此类使用始终与标准要求和标准流程相冲突。
Existing clients that send these improperly defined attributes usually have a configuration setting that can disable this behavior. We RECOMMEND that vendors ship products with the default set to "disabled". We RECOMMEND that administrators set this flag to "disabled" on all equipment that they manage.
发送这些未正确定义的属性的现有客户端通常具有可禁用此行为的配置设置。我们建议供应商装运默认设置为“禁用”的产品。我们建议管理员在其管理的所有设备上将此标志设置为“禁用”。
RADIUS proxy servers will need to forward Attributes having the new format, even if they do not implement support for the encoding and decoding of those attributes. We remind implementers of the following text in [RFC2865] Section 2.3:
RADIUS代理服务器将需要转发具有新格式的属性，即使它们不支持这些属性的编码和解码。我们提醒实施者注意[RFC2865]第2.3节中的以下内容：
The forwarding server MUST NOT change the order of any attributes of the same type, including Proxy-State.
转发服务器不得更改相同类型的任何属性（包括代理状态）的顺序。
This requirement solves some of the issues related to proxying of the new format, but not all. The reason is that proxy servers are permitted to examine the contents of the packets that they forward. Many proxy implementations not only examine the Attributes, but they refuse to forward attributes that they do not understand (i.e., attributes for which they have no local dictionary definitions).
此需求解决了与新格式代理相关的一些问题，但不是全部。原因是允许代理服务器检查它们转发的数据包的内容。许多代理实现不仅检查属性，而且拒绝转发他们不理解的属性（即没有本地字典定义的属性）。
This practice is NOT RECOMMENDED. Proxy servers SHOULD forward attributes, even attributes that they do not understand or that are not in a local dictionary. When forwarded, these attributes SHOULD be sent verbatim, with no modifications or changes. This requirement includes "invalid attributes", as there may be some other system in the network that understands them.
不建议采用这种做法。代理服务器应该转发属性，甚至是它们不理解或不在本地字典中的属性。转发时，应逐字发送这些属性，不进行任何修改或更改。此要求包括“无效属性”，因为网络中可能有其他系统理解这些属性。
The only exception to this recommendation is when local site policy dictates that filtering of attributes has to occur. For example, a filter at a visited network may require removal of certain authorization rules that apply to the home network but not to the visited network. This filtering can sometimes be done even when the contents of the Attributes are unknown, such as when all Vendor-Specific Attributes are designated for removal.
此建议的唯一例外是当本地站点策略规定必须进行属性筛选时。例如，到访网络处的过滤器可能需要删除适用于家庭网络但不适用于到访网络的某些授权规则。有时，即使属性的内容未知，也可以执行此筛选，例如指定删除所有特定于供应商的属性。
As seen during testing performed in 2010 via the EDUcation ROAMing (EDUROAM) service (A. DeKok, unpublished data), many proxies do not follow these practices for unknown Attributes. Some proxies filter out unknown attributes or attributes that have unexpected lengths (24%, 17/70), some truncate the Attributes to the "expected" length (11%, 8/70), some discard the request entirely (1%, 1/70), and the rest (63%, 44/70) follow the recommended practice of passing the Attributes verbatim. It will be difficult to widely use the Extended Attributes format until all non-conformant proxies are fixed. We therefore RECOMMEND that all proxies that do not support the Extended Attributes (241 through 246) define them as being of data type "string" and delete all other local definitions for those attributes.
正如在2010年通过教育漫游（EDUROAM）服务（A.DeKok，未发布的数据）进行的测试中所看到的，对于未知属性，许多代理不遵循这些做法。有些代理过滤掉未知属性或具有意外长度的属性（24%，17/70），有些代理将属性截断为“预期”长度（11%，8/70），有些代理完全放弃请求（1%，1/70），其余代理（63%，44/70）遵循逐字传递属性的推荐做法。在所有不一致的代理都固定下来之前，很难广泛使用扩展属性格式。因此，我们建议所有不支持扩展属性（241到246）的代理将其定义为数据类型“字符串”，并删除这些属性的所有其他本地定义。
This last change should enable wider usage of the Extended Attributes format.
最后一个更改应该能够更广泛地使用扩展属性格式。
This specification proposes a number of changes to RADIUS and therefore requires a set of guidelines, as has been done in [RFC6158]. These guidelines include suggestions related to design, interaction with IANA, usage, and implementation of attributes using the new formats.
本规范提出了对半径的一些更改，因此需要一套指南，如[RFC6158]中所述。这些指南包括与设计、与IANA的交互、使用和使用新格式实现属性相关的建议。
This specification updates [RFC6158] by adding the data types "evs", "tlv", and "integer64"; defining them to be "basic" data types; and permitting their use subject to the restrictions outlined below.
本规范通过添加数据类型“evs”、“tlv”和“integer64”来更新[RFC6158]；将它们定义为“基本”数据类型；并允许其在下述限制条件下使用。
The recommendations for the use of the new data types and Attribute formats are given below.
下面给出了使用新数据类型和属性格式的建议。
[RFC6158] Section A.2.1 says in part:
[RFC6158]第A.2.1节部分说明：
* 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位的无符号整数。没有足够的理由来定义整数的新大小。
We update that specification to permit unsigned integers of 64 bits, for the reasons defined above in Section 2.5. The updated text is as follows:
出于上文第2.5节定义的原因，我们更新了该规范，以允许64位无符号整数。最新案文如下：
* Unsigned integers of size other than 32 or 64 bits. SHOULD be replaced by an unsigned integer of 32 or 64 bits. There is insufficient justification to define a new size of integer.
* 大小不是32或64位的无符号整数。应替换为32或64位的无符号整数。没有足够的理由来定义整数的新大小。
That section later continues with the following list item:
该部分后面将继续列出以下列表项：
* Nested attribute-value pairs (AVPs). Attributes should be defined in a flat typespace.
* 嵌套属性值对（AVP）。属性应该在平面类型空间中定义。
We update that specification to permit nested TLVs, as defined in this document:
我们更新了该规范，以允许本文件中定义的嵌套TLV：
* Nested attribute-value pairs (AVPs) using the extended Attribute format MAY be used. All other nested AVP or TLV formats MUST NOT be used.
* 可以使用使用扩展属性格式的嵌套属性值对（AVP）。不得使用所有其他嵌套AVP或TLV格式。
The [RFC6158] recommendations for "basic" data types apply to the three types listed above. All other recommendations given in [RFC6158] for "basic" data types remain unchanged.
[RFC6158]对“基本”数据类型的建议适用于上述三种类型。[RFC6158]中给出的关于“基本”数据类型的所有其他建议保持不变。
[RFC6158] Section 2.1 says:
[RFC6158]第2.1节规定：
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 to link related attributes).
复杂数据类型可用于非RADIUS系统中降低复杂性的情况，或使用基本数据类型比较麻烦的情况（例如需要分组以链接相关属性的情况）。
Since the extended Attribute format allows for grouping of complex types via TLVs, the guidelines for complex data types need to be updated as follows:
由于扩展属性格式允许通过TLV对复杂类型进行分组，因此复杂数据类型的指南需要更新如下：
[RFC6158], Section 3.2.4, describes situations in which complex data types might be appropriate. They SHOULD NOT be used even in those situations, without careful consideration of the described
[RFC6158]第3.2.4节描述了复杂数据类型可能适用的情况。即使在这些情况下，也不应在未仔细考虑所述问题的情况下使用它们
limitations. In all other cases not covered by the complex data type exceptions, complex data types MUST NOT be used. Instead, complex data types MUST be decomposed into TLVs.
局限性在复杂数据类型例外未涵盖的所有其他情况下，不得使用复杂数据类型。相反，复杂的数据类型必须分解为TLV。
The checklist in [RFC6158] Appendix A.2.2 is similarly updated to add a new requirement at the top of that section, as follows:
[RFC6158]附录A.2.2中的检查表也进行了类似更新，以便在该节顶部添加新要求，如下所示：
Does the Attribute
属性是否正确
* define a complex type that can be represented via TLVs?
* 定义可以通过TLV表示的复杂类型？
If so, this data type MUST be represented via TLVs.
如果是这样，则必须通过TLV表示此数据类型。
Note that this requirement does not override [RFC6158] Appendix A.1, which permits the transport of complex types in certain situations.
请注意，本要求并未覆盖[RFC6158]附录A.1，该附录允许在某些情况下运输复杂类型。
All other recommendations given in [RFC6158] for "complex" data types remain unchanged.
[RFC6158]中给出的关于“复杂”数据类型的所有其他建议保持不变。
This section gives design guidelines for specifications defining attributes using the new format. The items listed below are not exhaustive. As experience is gained with the new formats, later specifications may define additional guidelines.
本节给出了使用新格式定义属性的规范的设计指南。下面列出的项目并非详尽无遗。随着使用新格式的经验的积累，以后的规范可能会定义额外的指南。
* The data type "evs" MUST NOT be used for standard RADIUS Attributes, or for TLVs, or for VSAs.
* 数据类型“evs”不得用于标准半径属性、TLV或VSA。
* The data type TLV SHOULD NOT be used for standard RADIUS attributes.
* 数据类型TLV不应用于标准半径属性。
* [RFC2866] "tagged" attributes MUST NOT be defined in the Extended-Type space. The "tlv" data type should be used instead to group attributes.
* [RFC2866]“标记”属性不能在扩展类型空间中定义。应使用“tlv”数据类型对属性进行分组。
* The "integer64" data type MAY be used in any RADIUS attribute. The use of 64-bit integers was not recommended in [RFC6158], but their utility is now evident.
* “integer64”数据类型可用于任何半径属性。[RFC6158]中不建议使用64位整数，但它们的实用性现在很明显。
* Any attribute that is allocated from the long extended space of data type "text", "string", or "tlv" can potentially carry more than 251 octets of data. Specifications defining such attributes SHOULD define a maximum length to guide implementations.
* 从数据类型“text”、“string”或“tlv”的长扩展空间分配的任何属性都可能包含251个以上的八位字节的数据。定义这些属性的规范应该定义一个最大长度来指导实现。
All other recommendations given in [RFC6158] for attribute design guidelines apply to attributes using the short extended space and long extended space.
[RFC6158]中关于属性设计指南的所有其他建议适用于使用短扩展空间和长扩展空间的属性。
The following items give design guidelines for specifications using TLVs.
以下项目给出了使用TLV规范的设计指南。
* When multiple Attributes are intended to be grouped or managed together, the use of TLVs to group related attributes is RECOMMENDED.
* 如果要将多个属性分组或一起管理，建议使用TLV对相关属性进行分组。
* More than 4 layers (depth) of TLV nesting is NOT RECOMMENDED.
* 不建议TLV嵌套超过4层（深度）。
* Interpretation of an attribute depends only on its type definition (e.g., Type.Extended-Type.TLV-Type) and not on its encoding or location in the RADIUS packet.
* 属性的解释仅取决于其类型定义（例如，type.Extended type.TLV type），而不取决于其编码或在RADIUS数据包中的位置。
* Where a group of TLVs is strictly defined, and not expected to change, and totals less than 247 octets of data, the specifications SHOULD request allocation from the short extended space.
* 如果严格定义了一组TLV，并且预计不会更改，并且数据总量少于247个八位字节，则规范应请求从短扩展空间进行分配。
* Where a group of TLVs is loosely defined or is expected to change, the specifications SHOULD request allocation from the long extended space.
* 如果一组TLV定义松散或预期会更改，则规范应请求从长扩展空间进行分配。
All other recommendations given in [RFC6158] for attribute design guidelines apply to attributes using the TLV format.
[RFC6158]中关于属性设计指南的所有其他建议适用于使用TLV格式的属性。
The following items give guidelines for allocation requests made in a RADIUS specification.
以下各项为RADIUS规范中的分配请求提供了指南。
* Discretion is recommended when requesting allocation of attributes. The new space is much larger than the old one, but it is not infinite.
* 建议在请求分配属性时自行决定。新空间比旧空间大得多，但它不是无限的。
* Specifications that allocate many attributes MUST NOT request that allocation be made from the standard space. That space is under allocation pressure, and the extended space is more suitable for large allocations. As a guideline, we suggest that one specification allocating twenty percent (20%) or more of the standard space would meet the above criteria.
* 分配多个属性的规范不能要求从标准空间进行分配。该空间处于分配压力下，扩展空间更适合大型分配。作为指导原则，我们建议分配百分之二十（20%）或更多标准空间的一个规范将满足上述标准。
* Specifications that allocate many related attributes SHOULD define one or more TLVs to contain related attributes.
* 分配多个相关属性的规范应定义一个或多个TLV以包含相关属性。
* Specifications SHOULD request allocation from a specific space. The IANA considerations given in Section 10, below, give instructions to IANA, but authors should assist IANA where possible.
* 规范应要求从特定空间进行分配。下文第10节中给出的IANA注意事项为IANA提供了指导，但作者应尽可能协助IANA。
* Specifications of an attribute that encodes 252 octets or less of data MAY request allocation from the short extended space.
* 编码252个八位字节或更少数据的属性的规范可以从短扩展空间请求分配。
* Specifications of an attribute that always encode less than 253 octets of data MUST NOT request allocation from the long extended space. The standard space or the short extended space MUST be used instead.
* 编码数据少于253个八位字节的属性的规范不得请求从长扩展空间进行分配。必须使用标准空间或较短的扩展空间。
* Specifications of an attribute that encodes 253 octets or more of data MUST request allocation from the long extended space.
* 编码253个八位字节或更多数据的属性的规范必须从长扩展空间请求分配。
* When the extended space is nearing exhaustion, a new specification will have to be written that requests allocation of one or more RADIUS attributes from the "Reserved" portion of the standard space, values 247-255, using an appropriate format ("Short Extended Type", or "Long Extended Type").
* 当扩展空间接近用尽时，必须编写一个新规范，要求使用适当的格式（“短扩展类型”或“长扩展类型”）从标准空间的“保留”部分分配一个或多个RADIUS属性，值247-255。
An allocation request made in a specification SHOULD use one of the following formats when allocating an attribute type code:
规范中的分配请求在分配属性类型代码时应使用以下格式之一：
* TBDn - request allocation of an attribute from the standard space. The value "n" should be 1 or more, to track individual attributes that are to be allocated.
* TBDn—请求从标准空间分配属性。值“n”应为1或更多，以跟踪要分配的各个属性。
* SHORT-TBDn - request allocation of an attribute from the short extended space. The value "n" should be 1 or more, to track individual attributes that are to be allocated.
* SHORT TBDn—请求从短扩展空间分配属性。值“n”应为1或更多，以跟踪要分配的各个属性。
* LONG-TBDn - request allocation of an attribute from the long extended space. The value "n" should be 1 or more, to track individual attributes that are to be allocated.
* LONG TBDn—请求从长扩展空间分配属性。值“n”应为1或更多，以跟踪要分配的各个属性。
These guidelines should help specification authors and IANA communicate effectively and clearly.
这些指南应该有助于规范作者和IANA有效、清晰地沟通。
Specifications may allocate a new attribute of type TLV and at the same time allocate sub-Attributes within that TLV. These specifications SHOULD request allocation of specific values for the sub-TLV. The "dotted number" notation MUST be used.
规范可以分配TLV类型的新属性，同时在该TLV内分配子属性。这些规范应要求为子TLV分配特定值。必须使用“虚线数字”符号。
For example, a specification may request allocation of a TLV as SHORT-TBD1. Within that attribute, it could request allocation of three sub-TLVs, as SHORT-TBD1.1, SHORT-TBD1.2, and SHORT-TBD1.3.
例如，规范可以请求将TLV分配为SHORT-TBD1。在该属性中，它可以请求分配三个子TLV，如SHORT-TBD1.1、SHORT-TBD1.2和SHORT-TBD1.3。
Specifications may request allocation of additional sub-TLVs within an existing attribute of type TLV. Those specifications SHOULD use the "TBDn" format for every entry in the "dotted number" notation.
规范可能要求在TLV类型的现有属性内分配额外的子TLV。这些规范应使用“点编号”符号中的每个条目的“TBDn”格式。
For example, a specification may request allocation within an existing TLV, with "dotted number" notation MM.NN. Within that attribute, the specification could request allocation of three sub-TLVs, as MM.NN.TBD1, MM.NN.TBD2, and MM.NN.TBD3.
例如，规范可能要求在现有TLV内进行分配，并使用“点编号”表示法MM.NN。在该属性中，规范可以请求分配三个子TLV，如MM.NN.TBD1、MM.NN.TBD2和MM.NN.TBD3。
* RADIUS client implementations SHOULD support this specification in order to permit the easy deployment of specifications using the changes defined herein.
* RADIUS客户端实现应支持此规范，以便使用此处定义的更改轻松部署规范。
* RADIUS server implementations SHOULD support this specification in order to permit the easy deployment of specifications using the changes defined herein.
* RADIUS服务器实现应支持此规范，以便使用此处定义的更改轻松部署规范。
* RADIUS proxy servers MUST follow the specifications in Section 5.2.
* RADIUS代理服务器必须遵守第5.2节中的规范。
* Vendors SHOULD use the existing Vendor-Specific Attribute Type space in preference to the new Extended-Vendor-Specific Attributes, as this specification may take time to become widely deployed.
* 供应商应优先使用现有的供应商特定属性类型空间，而不是新的扩展供应商特定属性，因为此规范可能需要时间才能广泛部署。
* Vendors SHOULD implement this specification. The changes to RADIUS are relatively small and are likely to quickly be used in new specifications.
* 供应商应实施本规范。半径的变化相对较小，很可能很快用于新的规范中。
The path to extending the RADIUS protocol has been long and arduous. A number of proposals have been made and discarded by the RADEXT working group. These proposals have been judged to be either too bulky, too complex, too simple, or unworkable in practice. We do not otherwise explain here why earlier proposals did not obtain working group consensus.
扩展RADIUS协议的道路漫长而艰难。RADEXT工作组已经提出并放弃了一些建议。这些建议要么过于庞大、过于复杂、过于简单，要么在实践中行不通。我们在此不作其他解释，解释为什么先前的提案没有获得工作组的共识。
The changes outlined here have the benefit of being simple, as the "Extended Type" format requires only a one-octet change to the Attribute format. The downside is that the "Long Extended Type" format is awkward, and the 7 Reserved bits will likely never be used for anything.
这里概述的更改具有简单的优点，因为“扩展类型”格式只需要对属性格式进行一个八位字节的更改。缺点是“长扩展类型”格式很笨拙，7个保留位可能永远不会用于任何用途。
An audit of almost five thousand publicly available attributes [ATTR] (2010) shows the statistics summarized below. The Attributes include over 100 Vendor dictionaries, along with the IANA-assigned attributes:
对近5000个公共可用属性[ATTR]（2010年）的审计显示，统计数据汇总如下。这些属性包括100多个供应商字典，以及IANA指定的属性：
Count Data Type
----- ---------
2257 integer
1762 text
273 IPv4 Address
225 string
96 other data types
35 IPv6 Address
18 date
10 integer64
4 Interface Id
3 IPv6 Prefix
Count Data Type
----- ---------
2257 integer
1762 text
273 IPv4 Address
225 string
96 other data types
35 IPv6 Address
18 date
10 integer64
4 Interface Id
3 IPv6 Prefix
4683 Total
总计4683
The entries in the "Data Type" column are data types recommended by [RFC6158], along with "integer64". The "other data types" row encompasses all other data types, including complex data types and data types transporting opaque data.
“数据类型”列中的条目是[RFC6158]推荐的数据类型，以及“integer64”。“其他数据类型”行包含所有其他数据类型，包括复杂数据类型和传输不透明数据的数据类型。
We see that over half of the Attributes encode less than 16 octets of data. It is therefore important to have an extension mechanism that adds as little as possible to the size of these attributes. Another result is that the overwhelming majority of attributes use simple data types.
我们看到，超过一半的属性编码的数据少于16个八位字节。因此，重要的是要有一个扩展机制，尽可能少地增加这些属性的大小。另一个结果是绝大多数属性使用简单的数据类型。
Of the Attributes defined above, 177 were declared as being inside of a TLV. This is approximately 4% of the total. We did not investigate whether additional attributes were defined in a flat namespace but could have been defined as being inside of a TLV. We expect that the number could be as high as 10% of attributes.
在上面定义的属性中，177个被声明为TLV内部。这大约占总数的4%。我们没有调查是否在平面名称空间中定义了其他属性，但可以将其定义为TLV内部。我们预计这一数字可能高达属性的10%。
Manual inspection of the dictionaries shows that approximately 20 (or 0.5%) attributes have the ability to transport more than 253 octets of data. These attributes are divided between VSAs and a small number of standard Attributes such as EAP-Message.
手动检查字典显示，大约20个（或0.5%）属性能够传输253个八位组以上的数据。这些属性分为VSA和少量标准属性，如EAP消息。
The results of this audit and analysis are reflected in the design of the extended attributes. The extended format has minimal overhead, permits TLVs, and has support for "long" attributes.
审计和分析的结果反映在扩展属性的设计中。扩展格式具有最小的开销，允许TLV，并支持“长”属性。
The Attribute formats defined in this specification need to be transported in Diameter. While Diameter supports attributes longer than 253 octets and grouped attributes, we do not use that functionality here. Instead, we define the simplest possible encapsulation method.
本规范中定义的属性格式需要按直径传输。虽然Diameter支持长度超过253个八位字节的属性和分组属性，但我们这里不使用该功能。相反，我们定义了最简单的封装方法。
The new formats MUST be treated the same as traditional RADIUS attributes when converting from RADIUS to Diameter, or vice versa. That is, the new attribute space is not converted to any "extended" Diameter attribute space. Fragmented attributes are not converted to a single long Diameter attribute. The new EVS data types are not converted to Diameter attributes with the "V" bit set.
从半径转换为直径时，新格式必须与传统半径属性相同，反之亦然。也就是说，新属性空间不会转换为任何“扩展”直径属性空间。碎片属性不会转换为单个长直径属性。新EVS数据类型不会转换为设置了“V”位的直径属性。
In short, this document mandates no changes for existing RADIUS-to-Diameter or Diameter-to-RADIUS gateways.
简言之，本文档不要求对现有的“半径到直径”或“直径到半径”网关进行任何更改。
A few examples are presented here in order to illustrate the encoding of the new Attribute formats. These examples are not intended to be exhaustive, as many others are possible. For simplicity, we do not show complete packets, but only attributes.
为了说明新属性格式的编码，这里给出了几个示例。这些示例并非详尽无遗，因为还有许多其他示例。为简单起见，我们不显示完整的数据包，只显示属性。
The examples are given using a domain-specific language implemented by the program given in Appendix A of this document. The language is line oriented and composed of a sequence of lines matching the ABNF grammar ([RFC5234]) given below:
这些示例使用由本文件附录a中给出的程序实现的特定于领域的语言给出。该语言是面向行的，由一系列符合ABNF语法（[RFC5234]）的行组成，如下所示：
Identifier = 1*DIGIT *( "." 1*DIGIT )
Identifier = 1*DIGIT *( "." 1*DIGIT )
HEXCHAR = HEXDIG HEXDIG
HEXCHAR = HEXDIG HEXDIG
STRING = DQUOTE 1*CHAR DQUOTE
字符串=DQUOTE 1*CHAR DQUOTE
TLV = "{" SP 1*DIGIT SP DATA SP "}"
TLV = "{" SP 1*DIGIT SP DATA SP "}"
DATA = (HEXCHAR *(SP HEXCHAR)) / (TLV *(SP TLV)) / STRING
DATA = (HEXCHAR *(SP HEXCHAR)) / (TLV *(SP TLV)) / STRING
LINE = Identifier SP DATA
LINE = Identifier SP DATA
The program has additional restrictions on its input that are not reflected in the above grammar. For example, the portions of the identifier that refer to Type and Extended-Type are limited to values between 1 and 255. We trust that the source code in Appendix A is clear and that these restrictions do not negatively affect the comprehensibility of the examples.
程序对其输入有额外的限制，这些限制未反映在上述语法中。例如，标识符中引用类型和扩展类型的部分被限制为1到255之间的值。我们相信附录A中的源代码是明确的，这些限制不会对示例的可理解性产生负面影响。
The program reads the input text and interprets it as a set of instructions to create RADIUS attributes. It then prints the hex encoding of those attributes. It implements the minimum set of functionality that achieves that goal. This minimalism means that it does not use attribute dictionaries; it does not implement support for RADIUS data types; it can be used to encode attributes with invalid data fields; and there is no requirement for consistency from one example to the next. For example, it can be used to encode a User-Name attribute that contains non-UTF8 data or a Framed-IP-Address that contains 253 octets of ASCII data. As a result, it MUST NOT be used to create RADIUS attributes for transport in a RADIUS message.
程序读取输入文本并将其解释为创建半径属性的一组指令。然后打印这些属性的十六进制编码。它实现了实现该目标的最小功能集。这种极简主义意味着它不使用属性字典；它不支持RADIUS数据类型；它可用于编码具有无效数据字段的属性；而且，从一个示例到下一个示例之间不需要一致性。例如，它可以用于编码包含非UTF8数据的用户名属性或包含253个八位字节ASCII数据的带帧IP地址。因此，它不能用于创建RADIUS消息中传输的RADIUS属性。
However, the program correctly encodes the RADIUS attribute fields of "Type", "Length", "Extended-Type", "More", "Reserved", "Vendor-Id", "Vendor-Type", and "Vendor-Length". It encodes RADIUS attribute data types "evs" and "tlv". It can therefore be used to encode example attributes from inputs that are human readable.
但是，程序正确地编码了“类型”、“长度”、“扩展类型”、“更多”、“保留”、“供应商Id”、“供应商类型”和“供应商长度”等半径属性字段。它对半径属性数据类型“evs”和“tlv”进行编码。因此，它可以用于从人类可读的输入中对示例属性进行编码。
We do not give examples of "invalid attributes". We also note that the examples show format, rather than consistent meaning. A particular Attribute Type code may be used to demonstrate two different formats. In real specifications, attributes have a static definitions based on their type code.
我们没有给出“无效属性”的示例。我们还注意到，示例显示的是格式，而不是一致的含义。特定属性类型代码可用于演示两种不同的格式。在实际规范中，属性具有基于其类型代码的静态定义。
The examples given below are strictly for demonstration purposes only and do not provide a standard of any kind.
下面给出的示例仅用于演示目的，不提供任何类型的标准。
The following is a series of examples of the "Extended Type" format.
下面是“扩展类型”格式的一系列示例。
Attribute encapsulating textual data:
封装文本数据的属性：
241.1 "bob" -> f1 06 01 62 6f 62
241.1“bob”->f1 06 01 62 6f 62
Attribute encapsulating a TLV with TLV-Type of one (1):
用一（1）个TLV类型封装TLV的属性：
241.2 { 1 23 45 }
-> f1 07 02 01 04 23 45
241.2 { 1 23 45 }
-> f1 07 02 01 04 23 45
Attribute encapsulating two TLVs, one after the other:
一个接一个封装两个TLV的属性：
241.2 { 1 23 45 } { 2 67 89 }
-> f1 0b 02 01 04 23 45 02 04 67 89
241.2 { 1 23 45 } { 2 67 89 }
-> f1 0b 02 01 04 23 45 02 04 67 89
Attribute encapsulating two TLVs, where the second TLV is itself encapsulating a TLV:
封装两个TLV的属性，其中第二个TLV本身封装一个TLV：
241.2 { 1 23 45 } { 3 { 1 ab cd } }
-> f1 0d 02 01 04 23 45 03 06 01 04 ab cd
241.2 { 1 23 45 } { 3 { 1 ab cd } }
-> f1 0d 02 01 04 23 45 03 06 01 04 ab cd
Attribute encapsulating two TLVs, where the second TLV is itself encapsulating two TLVs:
属性封装两个TLV，其中第二个TLV本身封装两个TLV：
241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } }
-> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f
241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } }
-> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f
Attribute encapsulating a TLV, which in turn encapsulates a TLV, to a depth of 5 nestings:
封装TLV的属性，该属性反过来封装TLV，深度为5个嵌套：
241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } }
-> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef
241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } }
-> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef
Attribute encapsulating an Extended-Vendor-Specific Attribute, with Vendor-Id of 1 and Vendor-Type of 4, which in turn encapsulates textual data:
属性封装扩展的特定于供应商的属性，供应商Id为1，供应商类型为4，这反过来又封装了文本数据：
241.26.1.4 "test" -> f1 0c 1a 00 00 00 01 04 74 65 73 74
241.26.1.4“试验”->f1 0c 1a 00 00 01 04 74 65 73 74
Attribute encapsulating an Extended-Vendor-Specific Attribute, with Vendor-Id of 1 and Vendor-Type of 5, which in turn encapsulates a TLV with TLV-Type of 3, which encapsulates textual data:
属性封装扩展的特定于供应商的属性，供应商Id为1，供应商类型为5，这反过来又封装了TLV类型为3的TLV，它封装了文本数据：
241.26.1.5 { 3 "test" }
-> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74
241.26.1.5 { 3 "test" }
-> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74
The following is a series of examples of the "Long Extended Type" format.
下面是“长扩展类型”格式的一系列示例。
Attribute encapsulating textual data:
封装文本数据的属性：
245.1 "bob" -> f5 07 01 00 62 6f 62
245.1“bob”->f5 07 01 00 62 6f 62
Attribute encapsulating a TLV with TLV-Type of one (1):
用一（1）个TLV类型封装TLV的属性：
245.2 { 1 23 45 }
-> f5 08 02 00 01 04 23 45
245.2 { 1 23 45 }
-> f5 08 02 00 01 04 23 45
Attribute encapsulating two TLVs, one after the other:
一个接一个封装两个TLV的属性：
245.2 { 1 23 45 } { 2 67 89 }
-> f5 0c 02 00 01 04 23 45 02 04 67 89
245.2 { 1 23 45 } { 2 67 89 }
-> f5 0c 02 00 01 04 23 45 02 04 67 89
Attribute encapsulating two TLVs, where the second TLV is itself encapsulating a TLV:
封装两个TLV的属性，其中第二个TLV本身封装一个TLV：
245.2 { 1 23 45 } { 3 { 1 ab cd } }
-> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd
245.2 { 1 23 45 } { 3 { 1 ab cd } }
-> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd
Attribute encapsulating two TLVs, where the second TLV is itself encapsulating two TLVs:
属性封装两个TLV，其中第二个TLV本身封装两个TLV：
245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } }
-> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f
245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } }
-> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f
Attribute encapsulating a TLV, which in turn encapsulates a TLV, to a depth of 5 nestings:
封装TLV的属性，该属性反过来封装TLV，深度为5个嵌套：
245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } }
-> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef
245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } }
-> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef
Attribute encapsulating an Extended-Vendor-Specific Attribute, with Vendor-Id of 1 and Vendor-Type of 4, which in turn encapsulates textual data:
属性封装扩展的特定于供应商的属性，供应商Id为1，供应商类型为4，这反过来又封装了文本数据：
245.26.1.4 "test" -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74
245.26.1.4“试验”->f5 0d 1a 00 00 01 04 74 65 73 74
Attribute encapsulating an Extended-Vendor-Specific Attribute, with Vendor-Id of 1 and Vendor-Type of 5, which in turn encapsulates a TLV with TLV-Type of 3, which encapsulates textual data:
属性封装扩展的特定于供应商的属性，供应商Id为1，供应商类型为5，这反过来又封装了TLV类型为3的TLV，它封装了文本数据：
245.26.1.5 { 3 "test" }
-> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74
245.26.1.5 { 3 "test" }
-> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74
Attribute encapsulating more than 251 octets of data. The "Data" portions are indented for readability:
封装超过251个八位字节数据的属性。为了便于阅读，“数据”部分缩进：
245.4 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc ccccccccccc" -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
245.4"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"->f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aaBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB f5 1304 00 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
Below is an example of an attribute encapsulating an Extended-Vendor-Specific Attribute, with Vendor-Id of 1 and Vendor-Type of 6, which in turn encapsulates more than 251 octets of data.
下面是一个封装扩展供应商特定属性的属性示例，供应商Id为1，供应商类型为6，这反过来又封装了251个八位字节以上的数据。
As the VSA encapsulates more than 251 octets of data, it is split into two RADIUS attributes. The first attribute has the More field set, and it carries the Vendor-Id and Vendor-Type. The second attribute has the More field clear and carries the rest of the data portion of the VSA. Note that the second attribute does not include the Vendor-Id ad Vendor-Type fields.
由于VSA封装了超过251个八位字节的数据，它被分为两个RADIUS属性。第一个属性具有更多字段集，它携带供应商Id和供应商类型。第二个属性具有更清晰的字段，并承载VSA的其余数据部分。请注意，第二个属性不包括供应商Id和供应商类型字段。
The "Data" portions are indented for readability:
为了便于阅读，“数据”部分缩进：
245.26.1.6 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc ccccccccccccccccc" -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 18 1a 00 bb bb bb bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
245.26.1.6 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"——>f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aaBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBbb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
This document updates [RFC3575] in that it adds new IANA considerations for RADIUS attributes. These considerations modify and extend the IANA considerations for RADIUS, rather than replacing them.
本文档更新了[RFC3575]，为RADIUS属性添加了新的IANA注意事项。这些注意事项修改和扩展了RADIUS的IANA注意事项，而不是替换它们。
The IANA considerations of this document are limited to the "RADIUS Attribute Types" registry. Some Attribute Type values that were previously marked "Reserved" are now allocated, and the registry is extended from a simple 8-bit array to a tree-like structure, up to a maximum depth of 125 nodes. Detailed instructions are given below.
本文档中的IANA注意事项仅限于“RADIUS属性类型”注册表。现在分配一些以前标记为“保留”的属性类型值，注册表从简单的8位数组扩展到树状结构，最大深度为125个节点。详细说明如下。
IANA has moved the following Attribute Type values from "Reserved" to "Allocated" with the corresponding names:
IANA已使用相应的名称将以下属性类型值从“保留”移动到“已分配”：
* 241 Extended-Type-1 * 242 Extended-Type-2 * 243 Extended-Type-3 * 244 Extended-Type-4 * 245 Long-Extended-Type-1 * 246 Long-Extended-Type-2
* 241扩展型-1*242扩展型-2*243扩展型-3*244扩展型-4*245长扩展型-1*246长扩展型-2
These values serve as an encapsulation layer for the new RADIUS Attribute Type tree.
这些值用作新RADIUS属性类型树的封装层。
Each of the Attribute Type values allocated above extends the "RADIUS Attribute Types" to an N-ary tree, via a "dotted number" notation. Allocation of an Attribute Type value "TYPE" using the new "Extended Type" format results in allocation of 255 new Attribute Type values of format "TYPE.1" through "TYPE.255". Value twenty-six (26) is assigned as "Extended-Vendor-Specific-*". Values "TYPE.241" through "TYPE.255" are marked "Reserved". All other values are "Unassigned".
上面分配的每个属性类型值都通过“点编号”表示法将“半径属性类型”扩展到一个N元树。使用新的“扩展类型”格式分配属性类型值“类型”会导致分配255个格式为“Type.1”到“Type.255”的新属性类型值。值二十六（26）被指定为“扩展供应商特定-*”。值“TYPE.241”到“TYPE.255”标记为“Reserved”。所有其他值均为“未指定”。
The initial set of Attribute Type values and names assigned by this document is given below.
本文档分配的初始属性类型值和名称集如下所示。
* 241 Extended-Attribute-1
* 241.{1-25} Unassigned
* 241.26 Extended-Vendor-Specific-1
* 241.{27-240} Unassigned
* 241.{241-255} Reserved
* 242 Extended-Attribute-2
* 242.{1-25} Unassigned
* 242.26 Extended-Vendor-Specific-2
* 242.{27-240} Unassigned
* 242.{241-255} Reserved
* 243 Extended-Attribute-3
* 243.{1-25} Unassigned
* 243.26 Extended-Vendor-Specific-3
* 243.{27-240} Unassigned
* 243.{241-255} Reserved
* 244 Extended-Attribute-4
* 244.{1-25} Unassigned
* 244.26 Extended-Vendor-Specific-4
* 244.{27-240} Unassigned
* 244.{241-255} Reserved
* 245 Extended-Attribute-5
* 245.{1-25} Unassigned
* 245.26 Extended-Vendor-Specific-5
* 245.{27-240} Unassigned
* 245.{241-255} Reserved
* 246 Extended-Attribute-6
* 246.{1-25} Unassigned
* 246.26 Extended-Vendor-Specific-6
* 246.{27-240} Unassigned
* 246.{241-255} Reserved
* 241 Extended-Attribute-1
* 241.{1-25} Unassigned
* 241.26 Extended-Vendor-Specific-1
* 241.{27-240} Unassigned
* 241.{241-255} Reserved
* 242 Extended-Attribute-2
* 242.{1-25} Unassigned
* 242.26 Extended-Vendor-Specific-2
* 242.{27-240} Unassigned
* 242.{241-255} Reserved
* 243 Extended-Attribute-3
* 243.{1-25} Unassigned
* 243.26 Extended-Vendor-Specific-3
* 243.{27-240} Unassigned
* 243.{241-255} Reserved
* 244 Extended-Attribute-4
* 244.{1-25} Unassigned
* 244.26 Extended-Vendor-Specific-4
* 244.{27-240} Unassigned
* 244.{241-255} Reserved
* 245 Extended-Attribute-5
* 245.{1-25} Unassigned
* 245.26 Extended-Vendor-Specific-5
* 245.{27-240} Unassigned
* 245.{241-255} Reserved
* 246 Extended-Attribute-6
* 246.{1-25} Unassigned
* 246.26 Extended-Vendor-Specific-6
* 246.{27-240} Unassigned
* 246.{241-255} Reserved
As per [RFC5226], the values marked "Unassigned" above are available for assignment by IANA in future RADIUS specifications. The values marked "Reserved" are reserved for future use.
根据[RFC5226]，以上标记为“未分配”的值可由IANA在未来的半径规范中分配。标记为“保留”的值保留供将来使用。
The Extended-Vendor-Specific spaces (TYPE.26) are for Private Use, and allocations are not managed by IANA.
扩展的特定于供应商的空间（类型.26）供私人使用，分配不由IANA管理。
Allocation of Reserved entries in the extended space requires Standards Action.
在扩展空间中分配保留项需要标准操作。
All other allocations in the extended space require IETF Review.
扩展空间中的所有其他分配都需要IETF审查。
This section defines what actions IANA needs to take when allocating new attributes. Different actions are required when allocating attributes from the standard space, attributes of the "Extended Type" format, attributes of the "Long Extended Type" format, preferential allocations, attributes of data type TLV, attributes within a TLV, and attributes of other data types.
本节定义了IANA在分配新属性时需要采取的行动。从标准空间分配属性、“扩展类型”格式的属性、“长扩展类型”格式的属性、优先分配、数据类型TLV的属性、TLV内的属性以及其他数据类型的属性时，需要执行不同的操作。
Specifications can request allocation of an Attribute from within the standard space (e.g., Attribute Type Codes 1 through 255), subject to the considerations of [RFC3575] and this document.
根据[RFC3575]和本文件的考虑，规范可以请求从标准空间内分配属性（例如，属性类型代码1到255）。
Specifications can request allocation of an Attribute that requires the format "Extended Type", by specifying the short extended space. In that case, IANA should assign the lowest Unassigned number from the Attribute Type space with the relevant format.
规范可以通过指定较短的扩展空间，请求分配需要“扩展类型”格式的属性。在这种情况下，IANA应使用相关格式从属性类型空间中分配最低的未分配编号。
Specifications can request allocation of an Attribute that requires the format "Long Extended Type", by specifying the extended space (long). In that case, IANA should assign the lowest Unassigned number from the Attribute Type space with the relevant format.
规范可以通过指定扩展空间（Long）请求分配需要格式为“Long Extended Type”的属性。在这种情况下，IANA应使用相关格式从属性类型空间中分配最低的未分配编号。
Specifications that make no request for allocation from a specific type space should have Attributes allocated using the following criteria:
不请求从特定类型空间分配的规范应具有使用以下条件分配的属性：
* When the standard space has no more Unassigned attributes, all allocations should be performed from the extended space.
* 当标准空间没有更多未分配的属性时，应从扩展空间执行所有分配。
* Specifications that allocate a small number of attributes (i.e., less than ten) should have all allocations made from the standard space.
* 分配少量属性（即少于10个）的规范应具有从标准空间进行的所有分配。
* Specifications that would allocate more than twenty percent of the remaining standard space attributes should have all allocations made from the extended space.
* 分配超过20%的剩余标准空间属性的规范应具有从扩展空间进行的所有分配。
* Specifications that request allocation of an attribute of data type TLV should have that attribute allocated from the extended space.
* 请求分配数据类型为TLV的属性的规范应该从扩展空间中分配该属性。
* Specifications that request allocation of an attribute that can transport 253 or more octets of data should have that attribute allocated from within the long extended space. We note that Section 6.5 above makes recommendations related to this allocation.
* 请求分配可传输253个或更多八位字节数据的属性的规范应在长扩展空间内分配该属性。我们注意到，上文第6.5节提出了与此分配相关的建议。
There is otherwise no requirement that all attributes within a specification be allocated from one type space or another. Specifications can simultaneously allocate attributes from both the standard space and the extended space.
否则，不要求从一个类型空间或另一个类型空间分配规范中的所有属性。规范可以同时从标准空间和扩展空间分配属性。
When specifications request allocation of an attribute of data type TLV, that allocation extends the Attribute Type tree by one more level. Allocation of an Attribute Type value "TYPE.TLV", with data type TLV, results in allocation of 255 new Attribute Type values, of format "TYPE.TLV.1" through "TYPE.TLV.255". Values 254-255 are marked "Reserved". All other values are "Unassigned". Value 26 has no special meaning.
当规范请求分配数据类型为TLV的属性时，该分配会将属性类型树再扩展一级。分配数据类型为TLV的属性类型值“Type.TLV”会导致分配255个新的属性类型值，格式为“Type.TLV.1”到“Type.TLV.255”。值254-255标记为“保留”。所有其他值均为“未指定”。值26没有特殊意义。
For example, if a new attribute "Example-TLV" of data type TLV is assigned the identifier "245.1", then the extended tree will be allocated as below:
例如，如果为数据类型为TLV的新属性“example TLV”分配了标识符“245.1”，则扩展树将按如下方式分配：
* 245.1 Example-TLV
* 245.1.{1-253} Unassigned
* 245.1.{254-255} Reserved
* 245.1 Example-TLV
* 245.1.{1-253} Unassigned
* 245.1.{254-255} Reserved
Note that this example does not define an "Example-TLV" attribute.
请注意，此示例未定义“示例TLV”属性。
The Attribute Type tree can be extended multiple levels in one specification when the specification requests allocation of nested TLVs, as discussed below.
当规范请求分配嵌套TLV时，属性类型树可以在一个规范中扩展到多个级别，如下所述。
Specifications can request allocation of Attribute Type values within an Attribute of data type TLV. The encapsulating TLV can be allocated in the same specification, or it can have been previously allocated.
规范可以请求在数据类型为TLV的属性中分配属性类型值。封装TLV可以在同一规范中分配，也可以在以前分配过。
Specifications need to request allocation within a specific Attribute Type value (e.g., "TYPE.TLV.*"). Allocations are performed from the smallest Unassigned value, proceeding to the largest Unassigned value.
规范需要在特定的属性类型值（例如，“Type.TLV.*”）内请求分配。分配从最小的未分配值开始执行，然后继续到最大的未分配值。
Where the Attribute being allocated is of data type TLV, the Attribute Type tree is extended by one level, as given in the previous section. Allocations can then be made within that level.
如果要分配的属性是数据类型TLV，则属性类型树将扩展一级，如前一节所述。然后可以在该级别内进行分配。
Attribute Type value allocations are otherwise allocated from the smallest Unassigned value, proceeding to the largest Unassigned value, e.g., starting from 241.1, proceeding through 241.255, then to 242.1, through 242.255, etc.
属性类型值分配从最小的未分配值开始分配到最大的未分配值，例如，从241.1开始，一直到241.255，然后到242.1，一直到242.255，等等。
This document defines new formats for data carried inside of RADIUS but otherwise makes no changes to the security of the RADIUS protocol.
本文档定义了RADIUS内部传输的数据的新格式，但对RADIUS协议的安全性没有任何更改。
Attacks on cryptographic hashes are well known and are getting better with time, as discussed in [RFC4270]. The security of the RADIUS protocol is dependent on MD5 [RFC1321], which has security issues as discussed in [RFC6151]. It is not known if the issues described in [RFC6151] apply to RADIUS. For other issues, we incorporate by reference the security considerations of [RFC6158] Section 5.
对加密散列的攻击是众所周知的，并且随着时间的推移会变得更好，如[RFC4270]中所述。RADIUS协议的安全性取决于MD5[RFC1321]，该协议存在[RFC6151]中讨论的安全问题。不知道[RFC6151]中描述的问题是否适用于RADIUS。对于其他问题，我们参考[RFC6158]第5节的安全考虑。
As with any protocol change, code changes are required in order to implement the new features. These code changes have the potential to introduce new vulnerabilities in the software. Since the RADIUS server performs network authentication, it is an inviting target for attackers. We RECOMMEND that access to RADIUS servers be kept to a minimum.
与任何协议更改一样，需要更改代码才能实现新功能。这些代码更改有可能在软件中引入新的漏洞。由于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月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011.
[RFC6158]DeKok，A.，Ed.，和G.Weber，“半径设计指南”，BCP 158，RFC 6158，2011年3月。
[PEN] IANA, "PRIVATE ENTERPRISE NUMBERS", <http://www.iana.org/assignments/enterprise-numbers>.
[PEN]IANA，“私营企业编号”<http://www.iana.org/assignments/enterprise-numbers>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[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月。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4270]Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 42702005年11月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 61512011年3月。
[ATTR] "alandekok/freeradius-server", available from GitHub, data retrieved September 2010, <http://github.com/alandekok/ freeradius-server/tree/master/share/>.
[ATTR]“alandekok/freeradius服务器”，可从GitHub获得，数据检索于2010年9月<http://github.com/alandekok/ freeradius服务器/树/主/共享/>。
This document is the result of long discussions in the IETF RADEXT working group. The authors would like to thank all of the participants who contributed various ideas over the years. Their feedback has been invaluable and has helped to make this specification better.
本文件是IETF RADEXT工作组长期讨论的结果。作者要感谢多年来贡献了各种想法的所有参与者。他们的反馈非常宝贵，有助于改进本规范。
This section contains "C" program source code that can be used for testing. It reads a line-oriented text file, parses it to create RADIUS formatted attributes, and prints the hex version of those attributes to standard output.
本节包含可用于测试的“C”程序源代码。它读取一个面向行的文本文件，对其进行解析以创建RADIUS格式的属性，并将这些属性的十六进制版本打印到标准输出。
The input accepts grammar similar to that given in Section 9, with some modifications for usability. For example, blank lines are allowed, lines beginning with a '#' character are interpreted as comments, numbers (RADIUS Types, etc.) are checked for minimum/ maximum values, and RADIUS attribute lengths are enforced.
输入接受与第9节中给出的语法相似的语法，并对可用性进行了一些修改。例如，允许使用空行，以“#”字符开头的行解释为注释，检查数字（半径类型等）的最小值/最大值，并强制使用半径属性长度。
The program is included here for demonstration purposes only, and does not define a standard of any kind.
本程序仅用于演示目的，不定义任何类型的标准。
------------------------------------------------------------
/*
* Copyright (c) 2013 IETF Trust and the persons identified as
* authors of the code. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* - Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* - Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials provided
* with the distribution.
*
* - Neither the name of Internet Society, IETF or IETF Trust, nor
* the names of specific contributors, may be used to endorse or
* promote products derived from this software without specific
* prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
* CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
* ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
------------------------------------------------------------
/*
* Copyright (c) 2013 IETF Trust and the persons identified as
* authors of the code. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* - Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* - Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials provided
* with the distribution.
*
* - Neither the name of Internet Society, IETF or IETF Trust, nor
* the names of specific contributors, may be used to endorse or
* promote products derived from this software without specific
* prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
* CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
* ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* Author: Alan DeKok <aland@networkradius.com>
*/
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <errno.h>
#include <ctype.h>
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* Author: Alan DeKok <aland@networkradius.com>
*/
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <errno.h>
#include <ctype.h>
static int encode_tlv(char *buffer, uint8_t *output, size_t outlen);
static int encode_tlv(char *buffer, uint8_t *output, size_t outlen);
static const char *hextab = "0123456789abcdef";
static const char *hextab = "0123456789abcdef";
static int encode_data_string(char *buffer,
uint8_t *output, size_t outlen)
{
int length = 0;
char *p;
static int encode_data_string(char *buffer,
uint8_t *output, size_t outlen)
{
int length = 0;
char *p;
p = buffer + 1;
p = buffer + 1;
while (*p && (outlen > 0)) {
if (*p == '"') {
return length;
}
while (*p && (outlen > 0)) {
if (*p == '"') {
return length;
}
if (*p != '\\') {
*(output++) = *(p++);
outlen--;
length++;
continue;
}
if (*p != '\\') {
*(output++) = *(p++);
outlen--;
length++;
continue;
}
switch (p[1]) {
default:
*(output++) = p[1];
break;
switch (p[1]) {
default:
*(output++) = p[1];
break;
case 'n':
*(output++) = '\n';
break;
case 'n':
*(output++) = '\n';
break;
case 'r':
*(output++) = '\r';
break;
case 'r':
*(output++) = '\r';
break;
case 't':
*(output++) = '\t';
break;
}
case 't':
*(output++) = '\t';
break;
}
outlen--;
length++;
}
outlen--;
length++;
}
fprintf(stderr, "String is not terminated\n");
return 0;
}
fprintf(stderr, "String is not terminated\n");
return 0;
}
static int encode_data_tlv(char *buffer, char **endptr,
uint8_t *output, size_t outlen)
{
int depth = 0;
int length;
char *p;
static int encode_data_tlv(char *buffer, char **endptr,
uint8_t *output, size_t outlen)
{
int depth = 0;
int length;
char *p;
for (p = buffer; *p != '\0'; p++) {
if (*p == '{') depth++;
if (*p == '}') {
depth--;
if (depth == 0) break;
}
}
for (p = buffer; *p != '\0'; p++) {
if (*p == '{') depth++;
if (*p == '}') {
depth--;
if (depth == 0) break;
}
}
if (*p != '}') {
fprintf(stderr, "No trailing '}' in string starting "
"with \"%s\"\n",
buffer);
return 0;
}
if (*p != '}') {
fprintf(stderr, "No trailing '}' in string starting "
"with \"%s\"\n",
buffer);
return 0;
}
*endptr = p + 1;
*p = '\0';
*endptr = p + 1;
*p = '\0';
p = buffer + 1;
while (isspace((int) *p)) p++;
p = buffer + 1;
while (isspace((int) *p)) p++;
length = encode_tlv(p, output, outlen);
if (length == 0) return 0;
length = encode_tlv(p, output, outlen);
if (length == 0) return 0;
return length;
}
return length;
}
static int encode_data(char *p, uint8_t *output, size_t outlen)
{
int length;
static int encode_data(char *p, uint8_t *output, size_t outlen)
{
int length;
if (!isspace((int) *p)) {
fprintf(stderr, "Invalid character following attribute "
"definition\n");
return 0;
}
if (!isspace((int) *p)) {
fprintf(stderr, "Invalid character following attribute "
"definition\n");
return 0;
}
while (isspace((int) *p)) p++;
while (isspace((int) *p)) p++;
if (*p == '{') {
int sublen;
char *q;
if (*p == '{') {
int sublen;
char *q;
length = 0;
长度=0；
do {
while (isspace((int) *p)) p++;
if (!*p) {
if (length == 0) {
fprintf(stderr, "No data\n");
return 0;
}
do {
while (isspace((int) *p)) p++;
if (!*p) {
if (length == 0) {
fprintf(stderr, "No data\n");
return 0;
}
break;
}
break;
}
sublen = encode_data_tlv(p, &q, output, outlen);
if (sublen == 0) return 0;
sublen = encode_data_tlv(p, &q, output, outlen);
if (sublen == 0) return 0;
length += sublen;
output += sublen;
outlen -= sublen;
p = q;
} while (*q);
length += sublen;
output += sublen;
outlen -= sublen;
p = q;
} while (*q);
return length;
}
return length;
}
if (*p == '"') {
length = encode_data_string(p, output, outlen);
return length;
}
if (*p == '"') {
length = encode_data_string(p, output, outlen);
return length;
}
length = 0;
while (*p) {
length = 0;
while (*p) {
char *c1, *c2;
char *c1, *c2;
while (isspace((int) *p)) p++;
while (isspace((int) *p)) p++;
if (!*p) break;
if (!*p) break;
if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) ||
!(c2 = memchr(hextab, tolower((int) p[1]), 16))) {
fprintf(stderr, "Invalid data starting at "
"\"%s\"\n", p);
return 0;
}
if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) ||
!(c2 = memchr(hextab, tolower((int) p[1]), 16))) {
fprintf(stderr, "Invalid data starting at "
"\"%s\"\n", p);
return 0;
}
*output = ((c1 - hextab) << 4) + (c2 - hextab);
output++;
length++;
p += 2;
*output = ((c1 - hextab) << 4) + (c2 - hextab);
output++;
length++;
p += 2;
outlen--;
if (outlen == 0) {
fprintf(stderr, "Too much data\n");
return 0;
}
}
outlen--;
if (outlen == 0) {
fprintf(stderr, "Too much data\n");
return 0;
}
}
if (length == 0) {
fprintf(stderr, "Empty string\n");
return 0;
}
if (length == 0) {
fprintf(stderr, "Empty string\n");
return 0;
}
return length;
}
return length;
}
static int decode_attr(char *buffer, char **endptr)
{
long attr;
static int decode_attr(char *buffer, char **endptr)
{
long attr;
attr = strtol(buffer, endptr, 10);
if (*endptr == buffer) {
fprintf(stderr, "No valid number found in string "
"starting with \"%s\"\n", buffer);
return 0;
}
attr = strtol(buffer, endptr, 10);
if (*endptr == buffer) {
fprintf(stderr, "No valid number found in string "
"starting with \"%s\"\n", buffer);
return 0;
}
if (!**endptr) {
fprintf(stderr, "Nothing follows attribute number\n");
return 0;
}
if (!**endptr) {
fprintf(stderr, "Nothing follows attribute number\n");
return 0;
}
if ((attr <= 0) || (attr > 256)) {
fprintf(stderr, "Attribute number is out of valid "
"range\n");
return 0;
}
if ((attr <= 0) || (attr > 256)) {
fprintf(stderr, "Attribute number is out of valid "
"range\n");
return 0;
}
return (int) attr;
}
return (int) attr;
}
static int decode_vendor(char *buffer, char **endptr)
{
long vendor;
static int decode_vendor(char *buffer, char **endptr)
{
long vendor;
if (*buffer != '.') {
fprintf(stderr, "Invalid separator before vendor id\n");
return 0;
}
if (*buffer != '.') {
fprintf(stderr, "Invalid separator before vendor id\n");
return 0;
}
vendor = strtol(buffer + 1, endptr, 10);
if (*endptr == (buffer + 1)) {
fprintf(stderr, "No valid vendor number found\n");
return 0;
}
vendor = strtol(buffer + 1, endptr, 10);
if (*endptr == (buffer + 1)) {
fprintf(stderr, "No valid vendor number found\n");
return 0;
}
if (!**endptr) {
fprintf(stderr, "Nothing follows vendor number\n");
return 0;
}
if (!**endptr) {
fprintf(stderr, "Nothing follows vendor number\n");
return 0;
}
if ((vendor <= 0) || (vendor > (1 << 24))) {
fprintf(stderr, "Vendor number is out of valid range\n");
return 0;
}
if ((vendor <= 0) || (vendor > (1 << 24))) {
fprintf(stderr, "Vendor number is out of valid range\n");
return 0;
}
if (**endptr != '.') {
fprintf(stderr, "Invalid data following vendor number\n");
return 0;
}
(*endptr)++;
if (**endptr != '.') {
fprintf(stderr, "Invalid data following vendor number\n");
return 0;
}
(*endptr)++;
return (int) vendor;
}
return (int) vendor;
}
static int encode_tlv(char *buffer, uint8_t *output, size_t outlen)
{
int attr;
int length;
char *p;
static int encode_tlv(char *buffer, uint8_t *output, size_t outlen)
{
int attr;
int length;
char *p;
attr = decode_attr(buffer, &p);
if (attr == 0) return 0;
attr = decode_attr(buffer, &p);
if (attr == 0) return 0;
output[0] = attr;
output[1] = 2;
output[0] = attr;
output[1] = 2;
if (*p == '.') {
p++;
length = encode_tlv(p, output + 2, outlen - 2);
if (*p == '.') {
p++;
length = encode_tlv(p, output + 2, outlen - 2);
} else {
length = encode_data(p, output + 2, outlen - 2);
}
} else {
length = encode_data(p, output + 2, outlen - 2);
}
if (length == 0) return 0;
if (length > (255 - 2)) {
fprintf(stderr, "TLV data is too long\n");
return 0;
}
if (length == 0) return 0;
if (length > (255 - 2)) {
fprintf(stderr, "TLV data is too long\n");
return 0;
}
output[1] += length;
output[1] += length;
return length + 2;
}
return length + 2;
}
static int encode_vsa(char *buffer, uint8_t *output, size_t outlen)
{
int vendor;
int attr;
int length;
char *p;
static int encode_vsa(char *buffer, uint8_t *output, size_t outlen)
{
int vendor;
int attr;
int length;
char *p;
vendor = decode_vendor(buffer, &p);
if (vendor == 0) return 0;
vendor = decode_vendor(buffer, &p);
if (vendor == 0) return 0;
output[0] = 0;
output[1] = (vendor >> 16) & 0xff;
output[2] = (vendor >> 8) & 0xff;
output[3] = vendor & 0xff;
output[0] = 0;
output[1] = (vendor >> 16) & 0xff;
output[2] = (vendor >> 8) & 0xff;
output[3] = vendor & 0xff;
length = encode_tlv(p, output + 4, outlen - 4);
if (length == 0) return 0;
if (length > (255 - 6)) {
fprintf(stderr, "VSA data is too long\n");
return 0;
}
length = encode_tlv(p, output + 4, outlen - 4);
if (length == 0) return 0;
if (length > (255 - 6)) {
fprintf(stderr, "VSA data is too long\n");
return 0;
}
return length + 4;
}
return length + 4;
}
static int encode_evs(char *buffer, uint8_t *output, size_t outlen)
{
int vendor;
int attr;
int length;
char *p;
static int encode_evs(char *buffer, uint8_t *output, size_t outlen)
{
int vendor;
int attr;
int length;
char *p;
vendor = decode_vendor(buffer, &p);
if (vendor == 0) return 0;
vendor = decode_vendor(buffer, &p);
if (vendor == 0) return 0;
attr = decode_attr(p, &p);
if (attr == 0) return 0;
attr = decode_attr(p, &p);
if (attr == 0) return 0;
output[0] = 0;
output[1] = (vendor >> 16) & 0xff;
output[2] = (vendor >> 8) & 0xff;
output[3] = vendor & 0xff;
output[4] = attr;
output[0] = 0;
output[1] = (vendor >> 16) & 0xff;
output[2] = (vendor >> 8) & 0xff;
output[3] = vendor & 0xff;
output[4] = attr;
length = encode_data(p, output + 5, outlen - 5);
if (length == 0) return 0;
length = encode_data(p, output + 5, outlen - 5);
if (length == 0) return 0;
return length + 5;
}
return length + 5;
}
static int encode_extended(char *buffer,
uint8_t *output, size_t outlen)
{
int attr;
int length;
char *p;
static int encode_extended(char *buffer,
uint8_t *output, size_t outlen)
{
int attr;
int length;
char *p;
attr = decode_attr(buffer, &p);
if (attr == 0) return 0;
attr = decode_attr(buffer, &p);
if (attr == 0) return 0;
output[0] = attr;
输出[0]=attr；
if (attr == 26) {
length = encode_evs(p, output + 1, outlen - 1);
} else {
length = encode_data(p, output + 1, outlen - 1);
}
if (length == 0) return 0;
if (length > (255 - 3)) {
fprintf(stderr, "Extended Attr data is too long\n");
if (attr == 26) {
length = encode_evs(p, output + 1, outlen - 1);
} else {
length = encode_data(p, output + 1, outlen - 1);
}
if (length == 0) return 0;
if (length > (255 - 3)) {
fprintf(stderr, "Extended Attr data is too long\n");
return 0;
}
return 0;
}
return length + 1;
}
return length + 1;
}
static int encode_extended_flags(char *buffer,
uint8_t *output, size_t outlen)
{
int attr;
int length, total;
char *p;
static int encode_extended_flags(char *buffer,
uint8_t *output, size_t outlen)
{
int attr;
int length, total;
char *p;
attr = decode_attr(buffer, &p);
if (attr == 0) return 0;
attr = decode_attr(buffer, &p);
if (attr == 0) return 0;
/* output[0] is the extended attribute */
output[1] = 4;
output[2] = attr;
output[3] = 0;
/* output[0] is the extended attribute */
output[1] = 4;
output[2] = attr;
output[3] = 0;
if (attr == 26) {
length = encode_evs(p, output + 4, outlen - 4);
if (length == 0) return 0;
if (attr == 26) {
length = encode_evs(p, output + 4, outlen - 4);
if (length == 0) return 0;
output[1] += 5;
length -= 5;
} else {
length = encode_data(p, output + 4, outlen - 4);
}
if (length == 0) return 0;
output[1] += 5;
length -= 5;
} else {
length = encode_data(p, output + 4, outlen - 4);
}
if (length == 0) return 0;
total = 0;
while (1) {
int sublen = 255 - output[1];
total = 0;
while (1) {
int sublen = 255 - output[1];
if (length <= sublen) {
output[1] += length;
total += output[1];
break;
}
if (length <= sublen) {
output[1] += length;
total += output[1];
break;
}
length -= sublen;
length -= sublen;
memmove(output + 255 + 4, output + 255, length);
memcpy(output + 255, output, 4);
memmove(output + 255 + 4, output + 255, length);
memcpy(output + 255, output, 4);
output[1] = 255;
输出[1]=255；
output[3] |= 0x80;
输出[3]|=0x80；
output += 255;
output[1] = 4;
total += 255;
}
output += 255;
output[1] = 4;
total += 255;
}
return total;
}
return total;
}
static int encode_rfc(char *buffer, uint8_t *output, size_t outlen)
{
int attr;
int length, sublen;
char *p;
static int encode_rfc(char *buffer, uint8_t *output, size_t outlen)
{
int attr;
int length, sublen;
char *p;
attr = decode_attr(buffer, &p);
if (attr == 0) return 0;
attr = decode_attr(buffer, &p);
if (attr == 0) return 0;
length = 2;
output[0] = attr;
output[1] = 2;
length = 2;
output[0] = attr;
output[1] = 2;
if (attr == 26) {
sublen = encode_vsa(p, output + 2, outlen - 2);
if (attr == 26) {
sublen = encode_vsa(p, output + 2, outlen - 2);
} else if ((*p == ' ') || ((attr < 241) || (attr > 246))) {
sublen = encode_data(p, output + 2, outlen - 2);
} else if ((*p == ' ') || ((attr < 241) || (attr > 246))) {
sublen = encode_data(p, output + 2, outlen - 2);
} else {
if (*p != '.') {
fprintf(stderr, "Invalid data following "
"attribute number\n");
return 0;
}
} else {
if (*p != '.') {
fprintf(stderr, "Invalid data following "
"attribute number\n");
return 0;
}
if (attr < 245) {
sublen = encode_extended(p + 1,
output + 2, outlen - 2);
} else {
if (attr < 245) {
sublen = encode_extended(p + 1,
output + 2, outlen - 2);
} else {
/*
* Not like the others!
*/
return encode_extended_flags(p + 1, output, outlen);
}
}
if (sublen == 0) return 0;
/*
* Not like the others!
*/
return encode_extended_flags(p + 1, output, outlen);
}
}
if (sublen == 0) return 0;
if (sublen > (255 -2)) {
fprintf(stderr, "RFC Data is too long\n");
return 0;
}
if (sublen > (255 -2)) {
fprintf(stderr, "RFC Data is too long\n");
return 0;
}
output[1] += sublen;
return length + sublen;
}
output[1] += sublen;
return length + sublen;
}
int main(int argc, char *argv[])
{
int lineno;
size_t i, outlen;
FILE *fp;
char input[8192], buffer[8192];
uint8_t output[4096];
int main(int argc, char *argv[])
{
int lineno;
size_t i, outlen;
FILE *fp;
char input[8192], buffer[8192];
uint8_t output[4096];
if ((argc < 2) || (strcmp(argv[1], "-") == 0)) {
fp = stdin;
} else {
fp = fopen(argv[1], "r");
if (!fp) {
fprintf(stderr, "Error opening %s: %s\n",
argv[1], strerror(errno));
exit(1);
}
}
if ((argc < 2) || (strcmp(argv[1], "-") == 0)) {
fp = stdin;
} else {
fp = fopen(argv[1], "r");
if (!fp) {
fprintf(stderr, "Error opening %s: %s\n",
argv[1], strerror(errno));
exit(1);
}
}
lineno = 0;
while (fgets(buffer, sizeof(buffer), fp) != NULL) {
char *p = strchr(buffer, '\n');
lineno = 0;
while (fgets(buffer, sizeof(buffer), fp) != NULL) {
char *p = strchr(buffer, '\n');
lineno++;
lineno++;
if (!p) {
if (!feof(fp)) {
fprintf(stderr, "Line %d too long in %s\n",
lineno, argv[1]);
exit(1);
}
} else {
*p = '\0';
}
if (!p) {
if (!feof(fp)) {
fprintf(stderr, "Line %d too long in %s\n",
lineno, argv[1]);
exit(1);
}
} else {
*p = '\0';
}
p = strchr(buffer, '#');
if (p) *p = '\0';
p = strchr(buffer, '#');
if (p) *p = '\0';
p = buffer;
p=缓冲区；
while (isspace((int) *p)) p++;
if (!*p) continue;
while (isspace((int) *p)) p++;
if (!*p) continue;
strcpy(input, p);
outlen = encode_rfc(input, output, sizeof(output));
if (outlen == 0) {
fprintf(stderr, "Parse error in line %d of %s\n",
lineno, input);
exit(1);
}
strcpy(input, p);
outlen = encode_rfc(input, output, sizeof(output));
if (outlen == 0) {
fprintf(stderr, "Parse error in line %d of %s\n",
lineno, input);
exit(1);
}
printf("%s -> ", buffer);
for (i = 0; i < outlen; i++) {
printf("%02x ", output[i]);
}
printf("%s -> ", buffer);
for (i = 0; i < outlen; i++) {
printf("%02x ", output[i]);
}
printf("\n");
}
printf("\n");
}
if (fp != stdin) fclose(fp);
if (fp != stdin) fclose(fp);
return 0;
}
------------------------------------------------------------
return 0;
}
------------------------------------------------------------
Authors' Addresses
作者地址
Alan DeKok Network RADIUS SARL 57bis blvd des Alpes 38240 Meylan France
阿兰·德科克网络半径萨尔57比斯阿尔卑斯大道法国梅兰38240号
EMail: aland@networkradius.com
URI: http://networkradius.com
EMail: aland@networkradius.com
URI: http://networkradius.com
Avi Lior
阿维利奥
EMail: avi.ietf@lior.org
EMail: avi.ietf@lior.org