Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 8044 FreeRADIUS
Updates: 2865, 3162, 4072, 6158, 6572, 7268 January 2017
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 8044 FreeRADIUS
Updates: 2865, 3162, 4072, 6158, 6572, 7268 January 2017
Category: Standards Track
ISSN: 2070-1721
Data Types in RADIUS
RADIUS中的数据类型
Abstract
摘要
RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types and update the "RADIUS Attribute Types" registry to include a Data Type field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268.
RADIUS规范使用数据类型已有20年，但没有将其定义为托管实体。在此期间，RADIUS实现命名了数据类型，并在属性定义中使用了它们。本文件更新了规范，以更好地遵循既定惯例。我们通过命名RFC 6158中定义的数据类型来实现这一点，这些数据类型至少在RFC 2865发布后就已被使用。我们为数据类型提供一个IANA注册表，并更新“RADIUS属性类型”注册表，以包含每个属性的数据类型字段。最后，我们建议RADIUS规范的作者优先于现有实践使用这些类型。本文档更新了RFCs 2865、3162、4072、6158、6572和7268。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8044.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8044.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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 ....................................................4
1.1. Specification Problems with Data Types .....................4
1.2. Implementation Problems with Data Types ....................5
1.3. No Mandated Changes ........................................5
1.4. Requirements Language ......................................5
2. Use of Data Types ...............................................6
2.1. Specification Use of Data Types ............................6
2.1.1. Field Names for Attribute Values ....................6
2.1.2. Attribute Definitions Using Data Types ..............7
2.1.3. Format of Attribute Definitions .....................8
2.1.4. Defining a New Data Type ............................9
2.2. Implementation Use of Data Types ...........................9
3. Data Type Definitions ..........................................10
3.1. integer ...................................................12
3.2. enum ......................................................12
3.3. time ......................................................13
3.4. text ......................................................14
3.5. string ....................................................15
3.6. concat ....................................................16
3.7. ifid ......................................................17
3.8. ipv4addr ..................................................18
3.9. ipv6addr ..................................................18
3.10. ipv6prefix ...............................................19
3.11. ipv4prefix ...............................................20
3.12. integer64 ................................................22
3.13. tlv ......................................................23
3.14. vsa ......................................................24
3.15. extended .................................................26
3.16. long-extended ............................................27
3.17. evs ......................................................30
4. Updated Registries .............................................31
4.1. New "Data Type" Registry ..................................31
4.2. Updates to the "RADIUS Attribute Types" Registry ..........32
5. Security Considerations ........................................32
6. IANA Considerations ............................................33
7. References .....................................................33
7.1. Normative References ......................................33
7.2. Informative References ....................................34
Acknowledgments ...................................................35
Author's Address ..................................................35
1. Introduction ....................................................4
1.1. Specification Problems with Data Types .....................4
1.2. Implementation Problems with Data Types ....................5
1.3. No Mandated Changes ........................................5
1.4. Requirements Language ......................................5
2. Use of Data Types ...............................................6
2.1. Specification Use of Data Types ............................6
2.1.1. Field Names for Attribute Values ....................6
2.1.2. Attribute Definitions Using Data Types ..............7
2.1.3. Format of Attribute Definitions .....................8
2.1.4. Defining a New Data Type ............................9
2.2. Implementation Use of Data Types ...........................9
3. Data Type Definitions ..........................................10
3.1. integer ...................................................12
3.2. enum ......................................................12
3.3. time ......................................................13
3.4. text ......................................................14
3.5. string ....................................................15
3.6. concat ....................................................16
3.7. ifid ......................................................17
3.8. ipv4addr ..................................................18
3.9. ipv6addr ..................................................18
3.10. ipv6prefix ...............................................19
3.11. ipv4prefix ...............................................20
3.12. integer64 ................................................22
3.13. tlv ......................................................23
3.14. vsa ......................................................24
3.15. extended .................................................26
3.16. long-extended ............................................27
3.17. evs ......................................................30
4. Updated Registries .............................................31
4.1. New "Data Type" Registry ..................................31
4.2. Updates to the "RADIUS Attribute Types" Registry ..........32
5. Security Considerations ........................................32
6. IANA Considerations ............................................33
7. References .....................................................33
7.1. Normative References ......................................33
7.2. Informative References ....................................34
Acknowledgments ...................................................35
Author's Address ..................................................35
RADIUS specifications have historically defined attributes in terms of name, value, and data type. Of these three pieces of information, the name is recorded by IANA in the "RADIUS Attribute Types" registry but is not otherwise managed or restricted, as discussed in [RFC6929], Section 2.7.1. The value is managed by IANA and recorded in that registry. The data type is not managed or recorded in the "RADIUS Attribute Types" registry. Experience has shown that there is a need to create well-known data types and have them managed by IANA.
RADIUS规范历史上定义了名称、值和数据类型方面的属性。在这三条信息中，名称由IANA记录在“RADIUS属性类型”注册表中，但不受其他管理或限制，如[RFC6929]第2.7.1节所述。该值由IANA管理并记录在该注册表中。“RADIUS属性类型”注册表中未管理或记录该数据类型。经验表明，有必要创建众所周知的数据类型，并由IANA进行管理。
This document defines an IANA RADIUS "Data Type" registry and updates the "RADIUS Attribute Types" registry to use those newly defined data types. It recommends how both specifications and implementations should use the data types. It extends the "RADIUS Attribute Types" registry to have a data type for each assigned attribute.
本文档定义了IANA RADIUS“数据类型”注册表，并更新“RADIUS属性类型”注册表以使用这些新定义的数据类型。它建议规范和实现如何使用数据类型。它扩展了“RADIUS属性类型”注册表，使每个指定的属性都有一个数据类型。
In this section, we review the use of data types in specifications and implementations. We highlight ambiguities and inconsistencies. The rest of this document is devoted to resolving those problems.
在本节中，我们将回顾数据类型在规范和实现中的使用。我们强调含糊不清和不一致之处。本文件其余部分致力于解决这些问题。
When attributes are defined in the specifications, the terms "Value" and "String" are used to refer to the contents of an attribute. However, these names are used recursively and inconsistently. We suggest that defining a field to recursively contain itself is problematic.
在规范中定义属性时，术语“值”和“字符串”用于表示属性的内容。但是，这些名称是递归使用的，并且不一致。我们认为，定义一个递归地包含自身的字段是有问题的。
A number of data type names and definitions are given in [RFC2865], Section 5, at the bottom of page 25. These data types are named and clearly defined. However, this practice was not continued in later specifications.
[RFC2865]第5节第25页底部给出了许多数据类型名称和定义。这些数据类型已命名并明确定义。但是，在以后的规范中没有继续这种做法。
Specifically, [RFC2865] defines attributes of data type "address" to carry IPv4 addresses. Despite this definition, [RFC3162] defines attributes of data type "Address" to carry IPv6 addresses. We suggest that the use of the word "address" to refer to disparate data types is problematic.
具体而言，[RFC2865]定义了数据类型“address”的属性以承载IPv4地址。尽管有此定义，[RFC3162]定义了数据类型“Address”的属性以承载IPv6地址。我们建议使用“地址”一词来表示不同的数据类型是有问题的。
Other failures are that [RFC3162] does not give a data type name and definition for the data types IPv6 address, Interface-Id, or IPv6 prefix. [RFC2869] defines Event-Timestamp to carry a time but does not reuse the "time" data type defined in [RFC2865]. Instead, it just repeats the "time" definition. [RFC6572] defines multiple attributes that carry IPv4 prefixes. However, an "IPv4 prefix" data
其他故障是[RFC3162]未提供数据类型名称和数据类型IPv6地址、接口Id或IPv6前缀的定义。[RFC2869]定义事件时间戳以携带时间，但不重用[RFC2865]中定义的“时间”数据类型。相反，它只是重复“时间”的定义。[RFC6572]定义了多个带有IPv4前缀的属性。但是，“IPv4前缀”数据
type is not named, defined as a data type, or called out as an addition to RADIUS. Further, [RFC6572] does not follow the recommendations of [RFC6158] and does not explain why it fails to follow those recommendations.
类型未命名、未定义为数据类型或未作为RADIUS的附加项调用。此外，[RFC6572]没有遵循[RFC6158]的建议，也没有解释为什么它没有遵循这些建议。
These ambiguities and inconsistencies need to be resolved.
这些模棱两可和不一致之处需要解决。
RADIUS implementations often use "dictionaries" to map attribute names to type values and define data types for each attribute. The data types in the dictionaries are defined by each implementation but correspond to the "ad hoc" data types used in the specifications.
RADIUS实现通常使用“字典”将属性名称映射到类型值，并为每个属性定义数据类型。字典中的数据类型由每个实现定义，但与规范中使用的“特殊”数据类型相对应。
In effect, implementations have seen the need for well-defined data types and have created them. It is time for RADIUS specifications to follow this practice.
实际上，实现已经看到了对定义良好的数据类型的需求，并创建了它们。是时候让RADIUS规范遵循这种做法了。
This document mandates no changes to any past, present, or future RADIUS implementation. It instead documents existing practice in order to simplify the process of writing RADIUS specifications, clarify the interpretation of RADIUS standards, and improve the communication between specification authors and IANA.
本文档不要求对任何过去、现在或将来的RADIUS实施进行任何更改。相反，它记录了现有实践，以简化编写RADIUS规范的过程，澄清RADIUS标准的解释，并改进规范作者与IANA之间的沟通。
This document suggests that implementations SHOULD use the data types defined here, in preference to any ad hoc data types currently in use. This suggestion should have a minimal effect on implementations, as most ad hoc data types are compatible with the ones defined here. Any difference will typically be limited to the name of the data type.
本文档建议实现应使用此处定义的数据类型，而不是当前使用的任何特殊数据类型。这个建议对实现的影响应该很小，因为大多数特殊数据类型都与这里定义的数据类型兼容。任何差异通常仅限于数据类型的名称。
This document updates [RFC6158] to permit the data types defined in the "Data Type" registry as "basic data types", as per Section 2.1 of [RFC6158]. The recommendations of [RFC6158] are otherwise unchanged.
根据[RFC6158]第2.1节，本文件更新[RFC6158]，以允许在“数据类型”注册表中定义为“基本数据类型”的数据类型。[RFC6158]的建议在其他方面保持不变。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The data types can be used in two places: specifications and implementations. This section discusses both uses and gives guidance on using the data types.
数据类型可以在两个地方使用：规范和实现。本节讨论这两种用法，并提供有关使用数据类型的指导。
In this section, we give recommendations for how specifications should be written using data types. We first describe how attribute field names can be consistently named. We then describe how attribute definitions should use the data types and deprecate the use of "ASCII art" for attribute definitions. We suggest a format for new attribute definitions. This format includes recommended fields and suggestions for how those fields should be described.
在本节中，我们将给出如何使用数据类型编写规范的建议。我们首先描述如何一致地命名属性字段名。然后，我们描述属性定义应该如何使用数据类型，并反对使用“ASCII艺术”作为属性定义。我们建议使用新属性定义的格式。此格式包括建议的字段以及如何描述这些字段的建议。
Finally, we make recommendations for how new data types should be defined.
最后，我们建议如何定义新的数据类型。
Previous specifications used inconsistent and conflicting names for the contents of RADIUS attributes. For example, the term "Value" is used in [RFC2865], Section 5 to define a field that carries the contents of an attribute. It is then used in later sections as the subfield of attribute contents. The result is that the field is defined as recursively containing itself. Similarly, "String" is used both as a data type and as a subfield of other data types.
以前的规范对RADIUS属性的内容使用了不一致和冲突的名称。例如，术语“值”在[RFC2865]第5节中用于定义携带属性内容的字段。然后，它将在后面的部分中用作属性内容的子字段。结果是该字段被定义为递归地包含自身。类似地，“字符串”既用作数据类型，也用作其他数据类型的子字段。
We correct this ambiguity by using context-specific names for various fields of attributes and data types. It then becomes clear that, for example, a field called "VSA-Data" must contain different data than a field called "EVS-Data". Each new name is defined where it is used.
我们通过为属性和数据类型的各个字段使用特定于上下文的名称来纠正这种歧义。然后很明显，例如，名为“VSA数据”的字段必须包含与名为“EVS数据”的字段不同的数据。每个新名称都是在其使用位置定义的。
We also define the following term:
我们还定义了以下术语：
Attr-Data
属性数据
The Value field of an Attribute as defined in [RFC2865], Section 5. The contents of this field MUST be of a valid data type as defined in the RADIUS "Data Type" registry.
[RFC2865]第5节中定义的属性值字段。此字段的内容必须是RADIUS“数据类型”注册表中定义的有效数据类型。
We consistently use "Attr-Data" to refer to the contents of an attribute, instead of the more ambiguous name "Value". It is RECOMMENDED that new specifications follow this practice.
我们一贯使用“Attr Data”来引用属性的内容，而不是更模糊的名称“Value”。建议新规范遵循此做法。
We consistently use "Value" to refer to the contents of a data type, where that data type is simple. For example, an "integer" can have a "Value". In contrast, a Vendor-Specific Attribute carries complex information and thus cannot have a "Value".
我们一贯使用“值”来表示数据类型的内容，其中数据类型很简单。例如，“整数”可以有一个“值”。相反，特定于供应商的属性包含复杂的信息，因此不能有“值”。
For data types that carry complex information, we name the fields based on the data type. For example, a Vendor-Specific Attribute is defined to carry a "vsa" data type, and the contents of that data type are described herein as "VSA-Data".
对于携带复杂信息的数据类型，我们根据数据类型命名字段。例如，供应商特定属性被定义为携带“vsa”数据类型，并且该数据类型的内容在本文中被描述为“vsa数据”。
These terms are used in preference to the term "String", which was previously used in ambiguous ways. It is RECOMMENDED that future specifications use type-specific names and the same naming scheme for new types. This use will maintain consistent definitions and help to avoid ambiguities.
这些术语优先于术语“字符串”使用，而“字符串”以前使用的方式模棱两可。建议将来的规范对新类型使用特定于类型的名称和相同的命名方案。这种使用将保持一致的定义，并有助于避免歧义。
New RADIUS specifications MUST define attributes using data types from the RADIUS "Data Type" registry. The specification may, of course, define a new data type, update the "Data Type" registry, and use the new data type, all in the same document. The guidelines given in [RFC6929] MUST be followed when defining a new data type.
新的RADIUS规范必须使用RADIUS“数据类型”注册表中的数据类型定义属性。当然，规范可以在同一文档中定义新的数据类型、更新“数据类型”注册表和使用新的数据类型。定义新数据类型时，必须遵循[RFC6929]中给出的准则。
Attributes can usually be completely described via the Attribute Type value, name, and data type. The use of ASCII art is then limited only to the definition of new data types and for complex data types.
属性通常可以通过属性类型值、名称和数据类型进行完整描述。ASCII art的使用仅限于新数据类型和复杂数据类型的定义。
Use of the new extended attributes [RFC6929] makes ASCII art even more problematic. An attribute can be allocated from any of the extended spaces, with more than one option for the attribute header format. This allocation decision is made after the specification has been accepted for publication. As the allocation affects the format of the attribute header, it is essentially impossible to create the correct ASCII art prior to final publication. Allocation from the different spaces also changes the value of the Length field, making it difficult to define it correctly prior to final publication of the document.
使用新的扩展属性[RFC6929]使ASCII art变得更加麻烦。可以从任何扩展空间分配属性，属性头格式有多个选项。此分配决定是在规范被接受发布后作出的。由于分配会影响属性头的格式，因此在最终发布之前基本上不可能创建正确的ASCII art。来自不同空间的分配也会更改“长度”字段的值，使得在最终发布文档之前很难正确定义它。
It is therefore RECOMMENDED that ASCII art diagrams not be used for new RADIUS attribute specifications.
因此，建议在新的半径属性规范中不要使用ASCII art图表。
When defining a new attribute, the following fields SHOULD be given:
定义新属性时，应提供以下字段：
Description
描述
A description of the meaning and interpretation of the attribute.
对属性的含义和解释的描述。
Type
类型
The Attribute Type value, given in the "dotted number" notation from [RFC6929]. Specifications can often leave this as "TBD" (to be determined) and request that IANA fill in the allocated values.
属性类型值，以[RFC6929]中的“点编号”表示法给出。规范通常会将其保留为“待定”，并要求IANA填写分配的值。
Length
长
A description of the length of the attribute. For attributes of variable length, a maximum length SHOULD be given. Since the Length value may depend on the Type value, the definition of Length may be affected by IANA allocations.
属性长度的描述。对于可变长度的属性，应给出最大长度。由于长度值可能取决于类型值，因此长度的定义可能会受到IANA分配的影响。
Data Type
数据类型
One of the named data types from the RADIUS "Data Type" registry.
RADIUS“数据类型”注册表中的命名数据类型之一。
Value
价值
A description of any attribute-specific limitations on the values carried by the specified data type. If there are no attribute-specific limitations, then the description of this field can be omitted, so long as the Description field is sufficiently explanatory.
对指定数据类型携带的值的任何属性特定限制的描述。如果没有特定于属性的限制，那么只要描述字段具有足够的解释性，就可以省略该字段的描述。
Where the values are limited to a subset of the possible range, valid range(s) MUST be defined.
如果值限于可能范围的子集，则必须定义有效范围。
For attributes of data type "enum", a list of enumerated values and names MUST be given, as shown in [RFC2865], Section 5.6.
对于数据类型为“enum”的属性，必须给出枚举值和名称的列表，如[RFC2865]第5.6节所示。
Using a consistent format for attribute definitions helps to make the definitions clearer.
对属性定义使用一致的格式有助于使定义更清晰。
When a specification needs to define a new data type, it SHOULD follow the format used by the definitions in Section 3 of this document. The text at the start of the data type definition MUST describe the data type, including the expected use, and why a new data type is required. That text SHOULD include limits on expected values and why those limits exist. The fields "Name", "Value", "Length", and "Format" MUST be given, along with values.
当规范需要定义新的数据类型时，应遵循本文件第3节中定义使用的格式。数据类型定义开头的文本必须描述数据类型，包括预期用途，以及为什么需要新数据类型。该文本应包括对预期值的限制以及存在这些限制的原因。必须提供字段“名称”、“值”、“长度”和“格式”以及值。
The Name field SHOULD be a single name, all lowercase.
名称字段应为一个名称，全部小写。
Contractions such as "ipv4addr" are RECOMMENDED where they add clarity.
在增加清晰度的地方，建议使用“ipv4addr”等缩略语。
We note that the use of "Value" in the RADIUS "Data Type" registry can be confusing. That name is also used in attribute definitions, but with a different meaning. We trust that the meaning here is clear from the context.
我们注意到，在RADIUS“数据类型”注册表中使用“值”可能会令人困惑。该名称也用于属性定义，但含义不同。我们相信，从上下文来看，这里的含义是明确的。
The Value field SHOULD be given as "TBD" in specifications. That number is assigned by IANA.
在规范中，值字段应表示为“待定”。该编号由IANA分配。
The Format field SHOULD be defined with ASCII art in order to have a precise definition. Machine-readable formats are also RECOMMENDED.
格式字段应使用ASCII art定义，以获得精确的定义。还建议使用机器可读的格式。
The definition of a new data type should be done only when absolutely necessary. We do not expect a need for a large number of new data types. When defining a new data type, the guidelines of [RFC6929] with respect to data types MUST be followed.
只有在绝对必要时才应定义新数据类型。我们并不期望需要大量的新数据类型。定义新数据类型时，必须遵循[RFC6929]中有关数据类型的指导原则。
It is RECOMMENDED that vendors not define "vendor-specific" data types. As discussed in [RFC6929], those data types are rarely necessary and can cause interoperability problems.
建议供应商不要定义“特定于供应商”的数据类型。正如[RFC6929]中所讨论的，这些数据类型很少是必需的，可能会导致互操作性问题。
Any new data type MUST have a unique name in the RADIUS "Data Type" registry. The number of the data type will be assigned by IANA.
任何新数据类型必须在RADIUS“数据类型”注册表中具有唯一名称。数据类型的编号将由IANA分配。
Implementations not supporting a particular data type MUST treat attributes of that data type as being of data type "string", as defined in Section 3.5. It is RECOMMENDED that such attributes be treated as "invalid attributes", as defined in [RFC6929], Section 2.8.
不支持特定数据类型的实现必须将该数据类型的属性视为第3.5节中定义的数据类型“字符串”。建议将此类属性视为[RFC6929]第2.8节中定义的“无效属性”。
Where the contents of a data type do not match the definition, implementations MUST treat the enclosing attribute as being an invalid attribute. This requirement includes, but is not limited to, the following situations:
如果数据类型的内容与定义不匹配，则实现必须将封闭属性视为无效属性。该要求包括但不限于以下情况：
* Attributes with values outside of the allowed range(s) for the data type, e.g., as given in the data types "integer", "ipv4addr", "ipv6addr", "ipv4prefix", "ipv6prefix", or "enum".
* 值超出数据类型允许范围的属性，例如数据类型“integer”、“ipv4addr”、“ipv6addr”、“ipv4prefix”、“ipv6prefix”或“enum”中给出的属性。
* "text" attributes where the contents do not match the required format.
* 内容与所需格式不匹配的“文本”属性。
* Attributes where the length is shorter or longer than the allowed length(s) for the given data type.
* 属性，其中长度小于或大于给定数据类型允许的长度。
The requirements for Reserved fields are more difficult to quantify. Implementations SHOULD be able to receive and process attributes where Reserved fields are non-zero. We do not, however, define any "correct" processing of such attributes. Instead, specifications that define one or more new meanings for Reserved fields SHOULD describe how each new meaning is compatible with older implementations. We expect that such descriptions are derived from practical experience with implementations. Implementations MUST set Reserved fields to zero when creating attributes.
保留字段的要求更难量化。实现应该能够接收和处理保留字段非零的属性。但是，我们不定义对此类属性的任何“正确”处理。相反，为保留字段定义一个或多个新含义的规范应该描述每个新含义如何与旧的实现兼容。我们期望这样的描述来自于实现的实际经验。在创建属性时，实现必须将保留字段设置为零。
This section defines the new data types. For each data type, it gives a definition, a name, a number, a length, and an encoding format. Where relevant, it describes subfields contained within the data type. These definitions have no impact on existing RADIUS implementations. There is no requirement that implementations use these names.
本节定义了新的数据类型。对于每种数据类型，它都给出了定义、名称、数字、长度和编码格式。如果相关，它描述数据类型中包含的子字段。这些定义对现有的RADIUS实现没有影响。不要求实现使用这些名称。
Where possible, the name of each data type has been taken from previous specifications. In some cases, a different name has been chosen. The change of name is sometimes required to avoid ambiguity (i.e., "address" versus "Address"). Otherwise, the new name has been chosen to be compatible with [RFC2865] or with usage in common implementations. In some cases, new names are chosen to clarify the interpretation of the data type.
在可能的情况下，每个数据类型的名称都取自以前的规范。在某些情况下，选择了不同的名称。有时需要更改名称以避免歧义（即“地址”与“地址”）。否则，选择的新名称将与[RFC2865]兼容或与常见实现中的用法兼容。在某些情况下，选择新名称以澄清数据类型的解释。
The numbers assigned herein for the data types have no meaning other than to permit them to be tracked by IANA. As RADIUS does not encode information about data types in a packet, the numbers assigned to a data type will never occur in a packet. It is RECOMMENDED that new implementations use the names defined in this document in order to avoid confusion. Existing implementations may choose to use the names defined here, but that is not required.
此处为数据类型分配的编号除了允许IANA对其进行跟踪外没有其他意义。由于RADIUS不对数据包中的数据类型信息进行编码，因此分配给数据类型的数字永远不会出现在数据包中。建议新的实现使用本文档中定义的名称，以避免混淆。现有实现可以选择使用此处定义的名称，但这不是必需的。
The encoding of each data type is taken from previous specifications. The fields are transmitted from left to right.
每个数据类型的编码取自以前的规范。字段从左向右传输。
Where the data types have interdependencies, the simplest data type is given first, and dependent ones are given later.
当数据类型具有相互依赖性时，首先给出最简单的数据类型，然后给出相关的数据类型。
We do not create specific data types for the "tagged" attributes (i.e., attributes containing a Tag field) defined in [RFC2868]. That specification defines the tagged attributes as being backwards compatible with pre-existing data types. In addition, [RFC6158], Section 2.1 says that tagged attributes should not be used. There is therefore no benefit to defining additional data types for these attributes. We trust that implementors will be aware that tagged attributes must be treated differently from non-tagged attributes of the same data type.
我们不会为[RFC2868]中定义的“标记”属性（即，包含标记字段的属性）创建特定的数据类型。该规范将标记的属性定义为与预先存在的数据类型向后兼容。此外，[RFC6158]，第2.1节规定不应使用标记属性。因此，为这些属性定义其他数据类型没有任何好处。我们相信实现者会意识到，标记属性必须与相同数据类型的未标记属性区别对待。
Similarly, we do not create data types for some attributes having a complex structure, such as CHAP-Password, ARAP-Features, or Location-Information. ("CHAP" refers to the Challenge Handshake Authentication Protocol, and "ARAP" refers to the Apple Remote Access Protocol.) We need to strike a balance between correcting earlier mistakes and making this document more complex. In some cases, it is better to treat complex attributes as being of type "string", even though they need to be interpreted by RADIUS implementations. The guidelines given in Section 6.3 of [RFC6929] were used to make this determination.
类似地，我们不会为某些具有复杂结构的属性创建数据类型，例如CHAP密码、ARAP功能或位置信息。（“CHAP”指的是质询握手认证协议，“ARAP”指的是苹果远程访问协议。）我们需要在纠正早期错误和使本文档更加复杂之间取得平衡。在某些情况下，最好将复杂属性视为“字符串”类型，即使它们需要由RADIUS实现进行解释。使用[RFC6929]第6.3节中给出的指南进行此确定。
The "integer" data type encodes a 32-bit unsigned integer in network byte order. Where the range of values for a particular attribute is limited to a subset of the values, specifications MUST define the valid range. Attributes with Values outside of the allowed ranges SHOULD be treated as invalid attributes.
“整数”数据类型按网络字节顺序编码32位无符号整数。如果特定属性的值范围仅限于值的子集，则规范必须定义有效范围。值超出允许范围的属性应视为无效属性。
Name
名称
integer
整数
Value
价值
1
1.
Length
长
Four octets
四个八位组
Format
总体安排
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "enum" data type encodes a 32-bit unsigned integer in network byte order. It differs from the "integer" data type only in that it is used to define enumerated types, such as Service-Type (Section 5.6 of [RFC2865]). Specifications MUST define a valid set of enumerated values, along with a unique name for each value. Attributes with Values outside of the allowed enumerations SHOULD be treated as invalid attributes.
“enum”数据类型按网络字节顺序编码32位无符号整数。它与“整数”数据类型的不同之处在于，它用于定义枚举类型，例如服务类型（RFC2865的第5.6节）。规范必须定义一组有效的枚举值，以及每个值的唯一名称。值超出允许枚举范围的属性应视为无效属性。
Name
名称
enum
枚举
Value
价值
2
2.
Length
长
Four octets
四个八位组
Format
总体安排
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "time" data type encodes time as a 32-bit unsigned value in network byte order and in seconds since 00:00:00 UTC, January 1, 1970. We note that dates before the year 2017 are likely to indicate configuration errors or lack of access to the correct time.
自1970年1月1日UTC 00:00:00以来，“time”数据类型将时间编码为32位无符号值，以网络字节顺序和秒为单位。我们注意到2017年之前的日期可能表示配置错误或无法访问正确的时间。
Note that the "time" attribute is defined to be unsigned, which means that it is not subject to a signed integer overflow in the year 2038.
请注意，“time”属性被定义为无符号，这意味着它在2038年不会受到有符号整数溢出的影响。
Name
名称
time
时间
Value
价值
3
3.
Length
长
Four octets
四个八位组
Format
总体安排
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "text" data type encodes UTF-8 text [RFC3629]. The maximum length of the text is given by the encapsulating attribute. Where the range of lengths for a particular attribute is limited to a subset of possible lengths, specifications MUST define the valid range(s). Attributes with lengths outside of the allowed values SHOULD be treated as invalid attributes.
“文本”数据类型编码UTF-8文本[RFC3629]。文本的最大长度由封装属性给出。如果特定属性的长度范围限制为可能长度的子集，则规范必须定义有效范围。长度超出允许值的属性应视为无效属性。
Attributes of type "text" that are allocated in the standard space (Section 1.2 of [RFC6929]) are limited to no more than 253 octets of data. Attributes of type "text" that are allocated in the extended space can be longer. In both cases, these limits are reduced when the data is encapsulated inside of another attribute.
在标准空间（RFC6929）第1.2节）中分配的“文本”类型属性限制为不超过253个八位字节的数据。在扩展空间中分配的“text”类型的属性可以更长。在这两种情况下，当数据封装在另一个属性中时，这些限制都会减少。
Where the text is intended to carry data in a particular format (e.g., Framed-Route), the format MUST be given. The specification SHOULD describe the format in a machine-readable way, such as via the Augmented Backus-Naur Form (ABNF) [RFC5234]. Attributes with Values not matching the defined format SHOULD be treated as invalid attributes.
如果文本旨在以特定格式（如框架路线）传输数据，则必须给出格式。该规范应以机器可读的方式描述该格式，例如通过增强的巴科斯-诺尔格式（ABNF）[RFC5234]。值与定义格式不匹配的属性应视为无效属性。
Note that the "text" data type does not terminate with a NUL octet (hex 00). The Attribute has a Length field and does not use a terminator. Texts of length zero (0) MUST NOT be sent; omit the entire attribute instead.
请注意，“文本”数据类型不会以NUL八位字节（十六进制00）终止。该属性有一个长度字段，不使用终止符。不得发送长度为零（0）的文本；而忽略整个属性。
Name
名称
text
文本
Value
价值
4
4.
Length
长
One or more octets
一个或多个八位组
Format
总体安排
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-
| Value ...
+-+-+-+-+-+-+-+-
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-
| Value ...
+-+-+-+-+-+-+-+-
The "string" data type encodes binary data as a sequence of undistinguished octets. Where the range of lengths for a particular attribute is limited to a subset of possible lengths, specifications MUST define the valid range(s). Attributes with lengths outside of the allowed values SHOULD be treated as invalid attributes.
“字符串”数据类型将二进制数据编码为无差别的八位字节序列。如果特定属性的长度范围限制为可能长度的子集，则规范必须定义有效范围。长度超出允许值的属性应视为无效属性。
Attributes of type "string" that are allocated in the standard space (Section 1.2 of [RFC6929]) are limited to no more than 253 octets of data. Attributes of type "string" that are allocated in the extended space can be longer. In both cases, these limits are reduced when the data is encapsulated inside of another attribute.
在标准空间（RFC6929）第1.2节）中分配的“字符串”类型属性限制为不超过253个八位字节的数据。在扩展空间中分配的“string”类型的属性可以更长。在这两种情况下，当数据封装在另一个属性中时，这些限制都会减少。
Note that the "string" data type does not terminate with a NUL octet (hex 00). The Attribute has a Length field and does not use a terminator. Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. Where there is a need to encapsulate complex data structures and TLVs cannot be used, the "string" data type MUST be used. This requirement includes encapsulation of data structures defined outside of RADIUS that are opaque to the RADIUS infrastructure. It also includes encapsulation of some data structures that are not opaque to RADIUS, such as the contents of CHAP-Password.
请注意，“字符串”数据类型不会以NUL八位字节（十六进制00）终止。该属性有一个长度字段，不使用终止符。不得发送长度为零（0）的字符串；而忽略整个属性。如果需要封装复杂的数据结构，并且不能使用TLV，则必须使用“字符串”数据类型。此要求包括对RADIUS基础设施不透明的RADIUS外部定义的数据结构进行封装。它还包括一些对RADIUS不不透明的数据结构的封装，例如CHAP密码的内容。
There is little reason to define a new RADIUS data type for only one attribute. However, where the complex data type cannot be represented as TLVs and is expected to be used in many attributes, a new data type SHOULD be defined.
几乎没有理由只为一个属性定义新的半径数据类型。但是，如果复杂数据类型不能表示为TLV，并且预期将在许多属性中使用，则应定义新的数据类型。
These requirements are stronger than [RFC6158], which makes the above encapsulation a "SHOULD". This document defines data types for use in RADIUS, so there are few reasons to avoid using them.
这些要求比[RFC6158]更强，这使得上述封装成为“应该”。本文档定义了在RADIUS中使用的数据类型，因此没有什么理由避免使用它们。
Name
名称
string
一串
Value
价值
5
5.
Length
长
One or more octets
一个或多个八位组
Format
总体安排
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-
| Octets ...
+-+-+-+-+-+-+-+-
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-
| Octets ...
+-+-+-+-+-+-+-+-
The "concat" data type permits the transport of more than 253 octets of data in a "standard space" [RFC6929] attribute. It is otherwise identical to the "string" data type.
“concat”数据类型允许在“标准空间”[RFC6929]属性中传输超过253个八位字节的数据。它在其他方面与“字符串”数据类型相同。
If multiple attributes of this data type are contained in a packet, all attributes of the same type code MUST be in order, and they MUST be consecutive attributes in the packet.
如果此数据类型的多个属性包含在一个数据包中，则同一类型代码的所有属性必须有序，并且它们必须是数据包中的连续属性。
The amount of data transported in a "concat" data type can be no more than the RADIUS packet size. In practice, the requirement to transport multiple attributes means that the limit may be substantially smaller than one RADIUS packet. As a rough guide, it is RECOMMENDED that this data type transport no more than 2048 octets of data.
“concat”数据类型中传输的数据量不能超过RADIUS数据包大小。在实践中，传输多个属性的要求意味着限制可能大大小于一个RADIUS数据包。作为粗略的指导，建议此数据类型传输的数据不超过2048个八位字节。
The "concat" data type MAY be used for "standard space" attributes. It MUST NOT be used for attributes in the "short extended space" or the "long extended space". It MUST NOT be used in any field or subfields of the following data types: "tlv", "vsa", "extended", "long-extended", or "evs".
“concat”数据类型可用于“标准空间”属性。它不得用于“短扩展空间”或“长扩展空间”中的属性。不得在以下数据类型的任何字段或子字段中使用：“tlv”、“vsa”、“扩展”、“长扩展”或“evs”。
Name
名称
concat
海螺
Value
价值
6
6.
Length
长
One or more octets
一个或多个八位组
Format
总体安排
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-
| Octets ...
+-+-+-+-+-+-+-+-
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-
| Octets ...
+-+-+-+-+-+-+-+-
The "ifid" data type encodes an Interface-Id as an 8-octet IPv6 Interface Identifier in network byte order.
“ifid”数据类型按网络字节顺序将接口Id编码为8字节IPv6接口标识符。
Name
名称
ifid
ifid
Value
价值
7
7.
Length
长
Eight octets
八个八位组
Format
总体安排
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Interface-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Interface-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "ipv4addr" data type encodes an IPv4 address in network byte order. Where the range of addresses for a particular attribute is limited to a subset of possible addresses, specifications MUST define the valid range(s). Attributes with Address values outside of the allowed range(s) SHOULD be treated as invalid attributes.
“ipv4addr”数据类型按网络字节顺序对IPv4地址进行编码。如果特定属性的地址范围限于可能地址的子集，则规范必须定义有效范围。地址值超出允许范围的属性应视为无效属性。
Name
名称
ipv4addr
ipv4addr
Value
价值
8
8.
Length
长
Four octets
四个八位组
Format
总体安排
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "ipv6addr" data type encodes an IPv6 address in network byte order. Where the range of addresses for a particular attribute is limited to a subset of possible addresses, specifications MUST define the valid range(s). Attributes with Address values outside of the allowed range(s) SHOULD be treated as invalid attributes.
“ipv6addr”数据类型按网络字节顺序对IPv6地址进行编码。如果特定属性的地址范围限于可能地址的子集，则规范必须定义有效范围。地址值超出允许范围的属性应视为无效属性。
Name
名称
ipv6addr
ipv6addr
Value
价值
9
9
Length
长
Sixteen octets
十六个八位组
Format
总体安排
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "ipv6prefix" data type encodes an IPv6 prefix, using both a prefix length and an IPv6 address in network byte order. Where the range of prefixes for a particular attribute is limited to a subset of possible prefixes, specifications MUST define the valid range(s). Attributes with Address values outside of the allowed range(s) SHOULD be treated as invalid attributes.
“ipv6prefix”数据类型使用前缀长度和网络字节顺序中的IPv6地址对IPv6前缀进行编码。如果特定属性的前缀范围限于可能前缀的子集，则规范必须定义有效范围。地址值超出允许范围的属性应视为无效属性。
Attributes with a Prefix-Length field having a value greater than 128 MUST be treated as invalid attributes.
前缀长度字段值大于128的属性必须视为无效属性。
Name
名称
ipv6prefix
IPV6前缀
Value
价值
10
10
Length
长
At least two, and no more than eighteen, octets
至少两个八位字节，但不超过十八个
Format
总体安排
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix-Length | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix-Length | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
子字段
Reserved
含蓄的
This field, which is reserved and MUST be present, is always set to zero. This field is one octet in length.
此字段是保留的，必须存在，始终设置为零。此字段的长度为一个八位字节。
Prefix-Length
前缀长度
The length of the prefix, in bits. At least 0 and no larger than 128. This field is one octet in length.
前缀的长度，以位为单位。至少为0且不大于128。此字段的长度为一个八位字节。
Prefix
前缀
The Prefix field is up to 16 octets in length. Bits outside of the Prefix-Length, if included, MUST be zero.
前缀字段的长度最多为16个八位字节。前缀长度之外的位（如果包括）必须为零。
The Prefix field SHOULD NOT contain more octets than necessary to encode the Prefix field.
前缀字段包含的八位字节数不应超过编码前缀字段所需的八位字节数。
The "ipv4prefix" data type encodes an IPv4 prefix, using both a prefix length and an IPv4 address in network byte order. Where the range of prefixes for a particular attribute is limited to a subset of possible prefixes, specifications MUST define the valid range(s). Attributes with Address values outside of the allowed range(s) SHOULD be treated as invalid attributes.
“ipv4prefix”数据类型使用前缀长度和网络字节顺序中的IPv4地址对IPv4前缀进行编码。如果特定属性的前缀范围限于可能前缀的子集，则规范必须定义有效范围。地址值超出允许范围的属性应视为无效属性。
Attributes with a Prefix-Length field having a value greater than 32 MUST be treated as invalid attributes.
前缀长度字段值大于32的属性必须视为无效属性。
Name
名称
ipv4prefix
IPv4前缀
Value
价值
11
11
Length
长
Six octets
六个八位组
Format
总体安排
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix-Length | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix-Length | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
子字段
Reserved
含蓄的
This field, which is reserved and MUST be present, is always set to zero. This field is one octet in length.
此字段是保留的，必须存在，始终设置为零。此字段的长度为一个八位字节。
Note that this definition differs from that given in [RFC6572]. See "Prefix-Length", below, for an explanation.
请注意，该定义与[RFC6572]中给出的定义不同。请参阅下面的“前缀长度”以了解解释。
Prefix-Length
前缀长度
The length of the prefix, in bits. The values MUST be no larger than 32. This field is one octet in length. Note that this definition differs from that given in [RFC6572].
前缀的长度，以位为单位。这些值不得大于32。此字段的长度为一个八位字节。请注意，该定义与[RFC6572]中给出的定义不同。
As compared to [RFC6572], the Prefix-Length field has increased in size by two bits, both of which must be zero. The Reserved field has decreased in size by two bits. The result is that both fields are aligned on octet boundaries, which removes the need for bit masking of the fields.
与[RFC6572]相比，前缀长度字段的大小增加了两位，两位都必须为零。保留字段的大小减少了两位。结果是两个字段都在八位组边界上对齐，从而消除了字段位屏蔽的需要。
Since [RFC6572] required the Reserved field to be zero, the definition here is compatible with the definition in the original specification.
由于[RFC6572]要求保留字段为零，因此此处的定义与原始规范中的定义兼容。
Prefix
前缀
The Prefix field is 4 octets in length. Bits outside of the Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type, this field is fixed length. If the address is all zeros (i.e., "0.0.0.0"), then the Prefix-Length MUST be set to 32.
前缀字段的长度为4个八位字节。前缀长度之外的位必须为零。与“ipv6prefix”数据类型不同，此字段是固定长度的。如果地址为全零（即“0.0.0.0”），则前缀长度必须设置为32。
The "integer64" data type encodes a 64-bit unsigned integer in network byte order. Where the range of values for a particular attribute is limited to a subset of the values, specifications MUST define the valid range(s). Attributes with Values outside of the allowed range(s) SHOULD be treated as invalid attributes.
“integer64”数据类型按网络字节顺序编码64位无符号整数。如果特定属性的值范围仅限于值的子集，则规范必须定义有效范围。值超出允许范围的属性应视为无效属性。
Name
名称
integer64
整数64
Value
价值
12
12
Length
长
Eight octets
八个八位组
Format
总体安排
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "tlv" data type encodes a Type-Length-Value, as defined in [RFC6929], Section 2.3.
“tlv”数据类型编码类型长度值，如[RFC6929]第2.3节所定义。
Name
名称
tlv
tlv
Value
价值
13
13
Length
长
Three or more octets
三个或更多的八位组
Format
总体安排
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-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
子字段
TLV-Type
TLV型
This field is one octet. Up-to-date values of this field are specified according to the policies and rules described in [RFC6929], Section 10. Values of 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.
这个字段是一个八位字节。此字段的最新值根据[RFC6929]第10节中描述的策略和规则指定。254-255的值保留供将来的RADIUS扩展使用。值26没有特殊含义，不得视为特定于供应商的属性。
The TLV-Type is meaningful only within the context defined by Type fields of the encapsulating Attributes, using the dotted-number notation introduced in [RFC6929].
TLV类型仅在封装属性的类型字段定义的上下文中有意义，使用[RFC6929]中引入的虚线数字表示法。
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 is handled as per [RFC6929], Section 2.8.
TLV长度字段是一个八位字节，指示此TLV的长度，包括TLV类型、TLV长度和TLV值字段。它的值必须介于3和255之间。如果客户端或服务器接收到具有无效TLV长度的TLV，则封装该TLV的属性必须视为无效属性，并按照[RFC6929]第2.8节进行处理。
TLVs having a TLV-Length of two (2) MUST NOT be sent; omit the entire TLV instead.
不得发送TLV长度为两（2）的TLV；忽略整个TLV。
TLV-Data
TLV数据
The TLV-Data field is one or more octets and contains information specific to the attribute. The format and length of the TLV-Data field are determined by the TLV-Type and TLV-Length fields.
TLV数据字段是一个或多个八位字节，包含特定于属性的信息。TLV数据字段的格式和长度由TLV类型和TLV长度字段确定。
The TLV-Data field MUST contain only known RADIUS data types. The TLV-Data field MUST NOT contain any of the following data types: "concat", "vsa", "extended", "long-extended", or "evs".
TLV数据字段必须仅包含已知的半径数据类型。TLV数据字段不得包含以下任何数据类型：“concat”、“vsa”、“extended”、“long extended”或“evs”。
The "vsa" data type encodes vendor-specific data, as given in [RFC2865], Section 5.26. It is used only in the Attr-Data field of a Vendor-Specific Attribute. It MUST NOT appear in the contents of any other data type.
“vsa”数据类型对供应商特定数据进行编码，如[RFC2865]第5.26节所述。它仅在供应商特定属性的Attr数据字段中使用。它不得出现在任何其他数据类型的内容中。
Where an implementation determines that an attribute of data type "vsa" contains data that does not match the expected format, it SHOULD treat that attribute as being an invalid attribute.
如果实现确定数据类型为“vsa”的属性包含与预期格式不匹配的数据，则应将该属性视为无效属性。
Name
名称
vsa
vsa
Value
价值
14
14
Length
长
Five or more octets
五个或更多的八位组
Format
总体安排
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VSA-Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VSA-Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
子字段
Vendor-Id
供应商Id
The 4 octets are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
4个八位字节是供应商的网络管理专用企业代码[PEN]，按网络字节顺序排列。
VSA-Data
VSA数据
The VSA-Data field is one or more octets. The actual format of the information is site specific or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
VSA数据字段是一个或多个八位字节。信息的实际格式是特定于站点或特定于应用程序的，一个健壮的实现应该支持字段作为无差别的八位字节。
The codification of the range of allowed usage of this field is outside the scope of this specification.
该字段允许使用范围的编码不在本规范范围内。
The "vsa" data type SHOULD contain a sequence of "tlv" data types. The interpretation of the TLV-Type and TLV-Data fields is dependent on the vendor's definition of that attribute.
“vsa”数据类型应包含一系列“tlv”数据类型。TLV类型和TLV数据字段的解释取决于供应商对该属性的定义。
The "vsa" data type MUST be used as the contents of the Attr-Data field of the Vendor-Specific Attribute. The "vsa" data type MUST NOT appear in the contents of any other data type.
“vsa”数据类型必须用作供应商特定属性的Attr数据字段的内容。“vsa”数据类型不得出现在任何其他数据类型的内容中。
The "extended" data type encodes the "Extended Type" format, as given in [RFC6929], Section 2.1. It is used only in the Attr-Data field of an attribute allocated from the standard space. It MUST NOT appear in the contents of any other data type.
“扩展”数据类型对“扩展类型”格式进行编码，如[RFC6929]第2.1节所述。它仅在从标准空间分配的属性的Attr数据字段中使用。它不得出现在任何其他数据类型的内容中。
Name
名称
extended
延伸
Value
价值
15
15
Length
长
Two or more octets
两个或多个八位组
Format
总体安排
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended-Type | Ext-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended-Type | Ext-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
子字段
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 [RFC6929], 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.
扩展类型字段是一个八位字节。此字段的最新值根据[RFC6929]第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 [RFC6929], Section 2.1 for additional discussion.
扩展类型只有在类型字段定义的上下文中才有意义。也就是说，这个字段可以被认为是定义了一个新的类型空间，形式为“type.Extended type”。更多讨论见[RFC6929]，第2.1节。
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”的属性。
Ext-Data
外部数据
The Ext-Data field is one or more octets.
Ext数据字段是一个或多个八位字节。
The contents of this field MUST be a valid data type as defined in the RADIUS "Data Type" registry. The Ext-Data field MUST NOT contain any of the following data types: "concat", "vsa", "extended", "long-extended", or "evs".
此字段的内容必须是RADIUS“数据类型”注册表中定义的有效数据类型。Ext数据字段不得包含以下任何数据类型：“concat”、“vsa”、“extended”、“long extended”或“evs”。
Implementations supporting this specification MUST use the Identifier of "Type.Extended-Type" to determine the interpretation of the Ext-Data field.
支持此规范的实现必须使用“Type.Extended Type”标识符来确定Ext数据字段的解释。
The "long-extended" data type encodes the "Long Extended Type" format, as given in [RFC6929], Section 2.2. It is used only in the Attr-Data field of an attribute. It MUST NOT appear in the contents of any other data type.
“长扩展”数据类型对“长扩展类型”格式进行编码，如[RFC6929]第2.2节所述。它仅在属性的Attr数据字段中使用。它不得出现在任何其他数据类型的内容中。
Name
名称
long-extended
长期的
Value
价值
16
16
Length
长
Three or more octets
三个或更多的八位组
Format
总体安排
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended-Type |M|T| Reserved | Ext-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended-Type |M|T| Reserved | Ext-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
子字段
Extended-Type
扩展型
This field is identical to the Extended-Type field defined above in Section 3.15.
该字段与上文第3.15节中定义的扩展类型字段相同。
M (More)
M（更多）
The More field (M flag) 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 less than 255. The More field MAY be set (1) if the Length field has a value of 255.
“更多”字段（M标志）的长度为一（1）位，指示当前属性是否包含超过251个八位字节的数据。如果长度字段的值小于255，“更多”字段必须清除（0）。如果长度字段的值为255，则可以设置更多字段（1）。
If the More field is set (1), it indicates that the Ext-Data field has been fragmented across multiple RADIUS attributes.
如果设置了“更多”字段（1），则表示Ext数据字段已在多个RADIUS属性中分段。
When the More field is set (1), the Attribute MUST have a Length field value of 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）时，该属性的长度字段值必须为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 is handled as per [RFC6929], Section 2.8.
如果客户机或服务器接收到具有更多字段集（1）的属性片段，但找不到后续片段，则该片段属性被视为无效属性，并按照[RFC6929]第2.8节进行处理。
T (Truncation)
T（截断）
This field is one bit in size and is called "T" for Truncation. It indicates that the attribute is intentionally truncated in this chunk and is to be continued in the next chunk of the sequence. The combination of the M flag and the T flag indicates that the attribute is fragmented (M flag) but that all of the fragments are not available in this chunk (T flag). Proxies implementing [RFC6929] will see these attributes as
此字段的大小为一位，称为“T”表示截断。它表示该属性在该块中被有意截断，并将在序列的下一块中继续。M标志和T标志的组合表示该属性是分段的（M标志），但该块中的所有片段都不可用（T标志）。实现[RFC6929]的代理将这些属性视为
invalid (they will not be able to reconstruct them), but they will still forward them, as Section 5.2 of [RFC6929] indicates that they SHOULD forward unknown attributes anyway.
无效（它们将无法重建），但仍将转发它们，因为[RFC6929]第5.2节指出它们无论如何都应该转发未知属性。
Please see [RFC7499] for further discussion of the uses of this flag.
请参阅[RFC7499]了解此标志用法的进一步讨论。
Reserved
含蓄的
This field is six 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.
此字段长度为6位，保留供将来使用。在编码用于在数据包中发送的属性时，实现必须将其设置为零（0）。接待时应忽略这些内容。
Future specifications may define one or more additional meanings for this field. Implementations therefore MUST NOT treat this field as invalid if it is non-zero.
未来的规范可能会定义此字段的一个或多个附加含义。因此，如果此字段为非零，则实现不得将其视为无效字段。
Ext-Data
外部数据
The Ext-Data field is one or more octets.
Ext数据字段是一个或多个八位字节。
The contents of this field MUST be a valid data type as defined in the RADIUS "Data Type" registry. The Ext-Data field MUST NOT contain any of the following data types: "concat", "vsa", "extended", "long-extended", or "evs".
此字段的内容必须是RADIUS“数据类型”注册表中定义的有效数据类型。Ext数据字段不得包含以下任何数据类型：“concat”、“vsa”、“extended”、“long extended”或“evs”。
Implementations supporting this specification MUST use the Identifier of "Type.Extended-Type" to determine the interpretation of the Ext-Data field.
支持此规范的实现必须使用“Type.Extended Type”标识符来确定Ext数据字段的解释。
The length of the data MUST be taken as the sum of the lengths of the fragments (i.e., Ext-Data fields) from which it is constructed. Any interpretation of the resulting data MUST occur after the fragments have been reassembled. If the reassembled data does not match the expected format, each fragment MUST be treated as an invalid attribute, and the reassembled data MUST be discarded.
数据的长度必须视为构建数据的片段（即Ext数据字段）长度之和。对结果数据的任何解释必须在碎片重新组装后进行。如果重新组装的数据与预期的格式不匹配，则必须将每个片段视为无效属性，并且必须丢弃重新组装的数据。
We note that the maximum size of a fragmented attribute is limited only by the RADIUS packet length limitation. Implementations MUST be able to handle the case where one fragmented attribute completely fills the packet.
我们注意到，碎片属性的最大大小仅受到RADIUS数据包长度限制的限制。实现必须能够处理一个碎片属性完全填充数据包的情况。
The "evs" data type encodes an Extended-Vendor-Specific Attribute, as given in [RFC6929], Section 2.4. The "evs" data type is used solely to extend the vendor-specific space. It MAY appear inside of an "extended" data type or a "long-extended" data type. It MUST NOT appear in the contents of any other data type.
“evs”数据类型编码扩展的供应商特定属性，如[RFC6929]第2.4节所述。“evs”数据类型仅用于扩展特定于供应商的空间。它可能出现在“扩展”数据类型或“长扩展”数据类型的内部。它不得出现在任何其他数据类型的内容中。
Where an implementation determines that an attribute of data type "evs" contains data that does not match the expected format, it SHOULD treat that attribute as being an invalid attribute.
如果实现确定数据类型为“evs”的属性包含与预期格式不匹配的数据，则应将该属性视为无效属性。
Name
名称
evs
电动汽车
Value
价值
17
17
Length
长
Six or more octets
六个或更多的八位组
Format
总体安排
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | EVS-Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | EVS-Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
子字段
Vendor-Id
供应商Id
The 4 octets are the Network Management Private Enterprise Code [PEN] of the vendor in network byte order.
4个八位字节是供应商的网络管理专用企业代码[PEN]，按网络字节顺序排列。
Vendor-Type
供应商类型
The Vendor-Type field is one octet. Values are assigned at the sole discretion of the vendor.
供应商类型字段是一个八位字节。价值分配由供应商自行决定。
EVS-Data
电动汽车数据
The EVS-Data field is one or more octets. It SHOULD encapsulate a previously defined RADIUS data type. Non-standard data types SHOULD NOT be used. We note that the EVS-Data field may be of data type "tlv".
EVS数据字段是一个或多个八位字节。它应该封装以前定义的RADIUS数据类型。不应使用非标准数据类型。我们注意到EVS数据字段的数据类型可能为“tlv”。
The actual format of the information is site specific or application specific, and a robust implementation SHOULD support the field as undistinguished octets. We recognize that vendors have complete control over the contents and format of the Ext-Data field; at the same time, we recommend that good practices be followed.
信息的实际格式是特定于站点或特定于应用程序的，一个健壮的实现应该支持字段作为无差别的八位字节。我们认识到，供应商完全可以控制Ext数据字段的内容和格式；同时，我们建议遵循良好做法。
Further codification of the range of allowed usage of this field is outside the scope of this specification.
该字段允许使用范围的进一步编码不在本规范范围内。
This section defines a new IANA registry for RADIUS data types and then updates the existing "RADIUS Attribute Types" registry to use the data types from the new registry.
本节为RADIUS数据类型定义一个新的IANA注册表，然后更新现有的“RADIUS属性类型”注册表以使用新注册表中的数据类型。
This section defines a new registry located under "RADIUS Types", called "Data Type". The registration procedures for the "Data Type" registry are "Standards Action" [RFC5226].
本节定义了一个位于“RADIUS类型”下的新注册表，称为“数据类型”。“数据类型”注册表的注册程序为“标准行动”[RFC5226]。
The "Data Type" registry contains three columns of data, as follows.
“数据类型”注册表包含三列数据，如下所示。
Value
价值
The number of the data type. The Value field is an artifact of the registry and has no on-the-wire meaning.
数据类型的编号。值字段是注册表的工件，没有在线意义。
Description
描述
The name of the data type. This field is used only for the registry and has no on-the-wire meaning.
数据类型的名称。此字段仅用于注册表，没有在线含义。
Reference
参考
The specification where the data type was defined.
定义数据类型的规范。
The initial contents of the registry are as follows.
登记处的初步内容如下。
Value Description Reference
----- ----------- -------------------
1 integer [RFC2865], RFC 8044
2 enum [RFC2865], RFC 8044
3 time [RFC2865], RFC 8044
4 text [RFC2865], RFC 8044
5 string [RFC2865], RFC 8044
6 concat RFC 8044
7 ifid [RFC3162], RFC 8044
8 ipv4addr [RFC2865], RFC 8044
9 ipv6addr [RFC3162], RFC 8044
10 ipv6prefix [RFC3162], RFC 8044
11 ipv4prefix [RFC6572], RFC 8044
12 integer64 [RFC6929], RFC 8044
13 tlv [RFC6929], RFC 8044
14 vsa [RFC2865], RFC 8044
15 extended [RFC6929], RFC 8044
16 long-extended [RFC6929], RFC 8044
17 evs [RFC6929], RFC 8044
Value Description Reference
----- ----------- -------------------
1 integer [RFC2865], RFC 8044
2 enum [RFC2865], RFC 8044
3 time [RFC2865], RFC 8044
4 text [RFC2865], RFC 8044
5 string [RFC2865], RFC 8044
6 concat RFC 8044
7 ifid [RFC3162], RFC 8044
8 ipv4addr [RFC2865], RFC 8044
9 ipv6addr [RFC3162], RFC 8044
10 ipv6prefix [RFC3162], RFC 8044
11 ipv4prefix [RFC6572], RFC 8044
12 integer64 [RFC6929], RFC 8044
13 tlv [RFC6929], RFC 8044
14 vsa [RFC2865], RFC 8044
15 extended [RFC6929], RFC 8044
16 long-extended [RFC6929], RFC 8044
17 evs [RFC6929], RFC 8044
This section updates the "RADIUS Attribute Types" registry to have a new column, which is inserted between the existing "Description" and "Reference" columns. The new column is named "Data Type". The contents of that column are the name of a data type, corresponding to the attribute in that row, or blank if the Attribute Type is unassigned. The name of the data type is taken from the RADIUS "Data Type" registry, as defined above.
本节更新“RADIUS属性类型”注册表，使其具有一个新列，该列插入现有的“说明”和“参考”列之间。新列名为“数据类型”。该列的内容是数据类型的名称，对应于该行中的属性，如果属性类型未指定，则为空。数据类型的名称取自上述定义的RADIUS“数据类型”注册表。
The existing registration requirements for the "RADIUS Attribute Types" registry are otherwise unchanged.
“半径属性类型”注册表的现有注册要求在其他方面保持不变。
This specification is concerned solely with updates to IANA registries. As such, there are no security considerations with the document itself.
本规范仅涉及IANA注册的更新。因此，文档本身没有安全考虑。
However, the use of inconsistent names and poorly defined entities in a protocol is problematic. Inconsistencies in specifications can lead to security and interoperability problems in implementations. Further, having one canonical source for the definition of data types means that an implementor has fewer specifications to read. The implementation work is therefore simpler and more likely to be correct.
然而，在协议中使用不一致的名称和定义不良的实体是有问题的。规范中的不一致可能导致实现中的安全性和互操作性问题。此外，拥有一个用于定义数据类型的规范源意味着实现者要读取的规范更少。因此，实施工作更简单，更可能是正确的。
The goal of this specification is to reduce ambiguities in the RADIUS protocol, which we believe will lead to more robust and more secure implementations.
本规范的目标是减少RADIUS协议中的歧义，我们相信这将导致更健壮和更安全的实现。
IANA has created one new registry, as described in Section 4.1.
IANA已创建了一个新的注册表，如第4.1节所述。
IANA has updated the "RADIUS Attribute Types" registry, as described in Section 4.2.
IANA已更新了“半径属性类型”注册表，如第4.2节所述。
IANA requires that all allocation requests in the "RADIUS Attribute Types" registry contain a Data Type field, which is required to contain one of the "Data Type" names contained in the RADIUS "Data Type" registry.
IANA要求“RADIUS属性类型”注册表中的所有分配请求都包含一个数据类型字段，该字段必须包含RADIUS“数据类型”注册表中包含的一个“数据类型”名称。
IANA requires that updates to the RADIUS "Data Type" registry contain the following fields, with the associated instructions:
IANA要求RADIUS“数据类型”注册表的更新包含以下字段和相关说明：
* Value. IANA is instructed to assign the next unused integer in sequence to new data type definitions.
* 价值IANA被指示按顺序将下一个未使用的整数分配给新的数据类型定义。
* Name. IANA is instructed to require that this name be unique in the registry.
* 名称IANA被指示要求该名称在注册表中是唯一的。
* Reference. IANA is instructed to update this field with a reference to the document that defines the data type.
* 参考指示IANA使用定义数据类型的文档的引用更新此字段。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <http://www.rfc-editor.org/info/rfc2865>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 2865，DOI 10.17487/RFC2865，2000年6月<http://www.rfc-editor.org/info/rfc2865>.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, DOI 10.17487/RFC3162, August 2001, <http://www.rfc-editor.org/info/rfc3162>.
[RFC3162]Aboba，B.，Zorn，G.和D.Mitton，“RADIUS和IPv6”，RFC 3162，DOI 10.17487/RFC3162，2001年8月<http://www.rfc-editor.org/info/rfc3162>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, DOI 10.17487/RFC4072, August 2005, <http://www.rfc-editor.org/info/rfc4072>.
[RFC4072]Eronen，P.，Ed.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，DOI 10.17487/RFC4072，2005年8月<http://www.rfc-editor.org/info/rfc4072>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011, <http://www.rfc-editor.org/info/rfc6158>.
[RFC6158]DeKok，A.，Ed.，和G.Weber，“半径设计指南”，BCP 158，RFC 6158，DOI 10.17487/RFC6158，2011年3月<http://www.rfc-editor.org/info/rfc6158>.
[RFC6572] Xia, F., Sarikaya, B., Korhonen, J., Ed., Gundavelli, S., and D. Damic, "RADIUS Support for Proxy Mobile IPv6", RFC 6572, DOI 10.17487/RFC6572, June 2012, <http://www.rfc-editor.org/info/rfc6572>.
[RFC6572]Xia，F.，Sarikaya，B.，Korhonen，J.，Ed.，Gundavelli，S.，和D.Damic，“代理移动IPv6的RADIUS支持”，RFC 6572，DOI 10.17487/RFC6572，2012年6月<http://www.rfc-editor.org/info/rfc6572>.
[RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia, F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of Fragmentation of RADIUS Packets", RFC 7499, DOI 10.17487/RFC7499, April 2015, <http://www.rfc-editor.org/info/rfc7499>.
[RFC7499]Perez Mendez，A.，Ed.，Marin Lopez，R.，Pereniguez Garcia，F.，Lopez Millan，G.，Lopez，D.，和A.DeKok，“支持RADIUS数据包碎片化”，RFC 7499，DOI 10.17487/RFC7499，2015年4月<http://www.rfc-editor.org/info/rfc7499>.
[PEN] IANA, "PRIVATE ENTERPRISE NUMBERS", <http://www.iana.org/assignments/enterprise-numbers/>.
[PEN]IANA，“私营企业编号”<http://www.iana.org/assignments/enterprise-numbers/>.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, DOI 10.17487/RFC2868, June 2000, <http://www.rfc-editor.org/info/rfc2868>.
[RFC2868]Zorn，G.，Leifer，D.，Rubens，A.，Shriver，J.，Holdrege，M.，和I.Goyret，“隧道协议支持的半径属性”，RFC 2868，DOI 10.17487/RFC2868，2000年6月<http://www.rfc-editor.org/info/rfc2868>.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, DOI 10.17487/RFC2869, June 2000, <http://www.rfc-editor.org/info/rfc2869>.
[RFC2869]Rigney，C.，Willats，W.，和P.Calhoun，“半径延伸”，RFC 2869，DOI 10.17487/RFC2869，2000年6月<http://www.rfc-editor.org/info/rfc2869>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013, <http://www.rfc-editor.org/info/rfc6929>.
[RFC6929]DeKok，A.和A.Lior，“远程身份验证拨入用户服务（RADIUS）协议扩展”，RFC 6929，DOI 10.17487/RFC6929，2013年4月<http://www.rfc-editor.org/info/rfc6929>.
[RFC7268] Aboba, B., Malinen, J., Congdon, P., Salowey, J., and M. Jones, "RADIUS Attributes for IEEE 802 Networks", RFC 7268, DOI 10.17487/RFC7268, July 2014, <http://www.rfc-editor.org/info/rfc7268>.
[RFC7268]Aboba，B.，Malinen，J.，Congdon，P.，Salowey，J.，和M.Jones，“IEEE 802网络的半径属性”，RFC 7268，DOI 10.17487/RFC7268，2014年7月<http://www.rfc-editor.org/info/rfc7268>.
Acknowledgments
致谢
Thanks to the RADEXT WG participants for their patience and reviews of this document.
感谢RADEXT工作组参与者对本文件的耐心和审阅。
Author's Address
作者地址
Alan DeKok The FreeRADIUS Server Project
Alan DeKok FreeRADIUS服务器项目
Email: aland@freeradius.org
Email: aland@freeradius.org