Internet Engineering Task Force (IETF) B. Aboba
Request for Comments: 7268 Microsoft Corporation
Updates: 3580, 4072 J. Malinen
Category: Standards Track Independent
ISSN: 2070-1721 P. Congdon
Tallac Networks
J. Salowey
Cisco Systems
M. Jones
Azuca Systems
July 2014
Internet Engineering Task Force (IETF) B. Aboba
Request for Comments: 7268 Microsoft Corporation
Updates: 3580, 4072 J. Malinen
Category: Standards Track Independent
ISSN: 2070-1721 P. Congdon
Tallac Networks
J. Salowey
Cisco Systems
M. Jones
Azuca Systems
July 2014
RADIUS Attributes for IEEE 802 Networks
IEEE 802网络的RADIUS属性
Abstract
摘要
RFC 3580 provides guidelines for the use of the Remote Authentication Dial-In User Service (RADIUS) within IEEE 802 local area networks (LANs). This document defines additional attributes for use within IEEE 802 networks and clarifies the usage of the EAP-Key-Name Attribute and the Called-Station-Id Attribute. This document updates RFCs 3580 and 4072.
RFC 3580提供了在IEEE 802局域网（LAN）内使用远程认证拨入用户服务（RADIUS）的指南。本文档定义了IEEE 802网络中使用的其他属性，并澄清了EAP密钥名称属性和被叫站点Id属性的用法。本文档更新了RFCs 3580和4072。
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/rfc7268.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7268.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................4
2. RADIUS Attributes ...............................................5
2.1. Allowed-Called-Station-Id ..................................5
2.2. EAP-Key-Name ...............................................6
2.3. EAP-Peer-Id ................................................7
2.4. EAP-Server-Id ..............................................8
2.5. Mobility-Domain-Id .........................................9
2.6. Preauth-Timeout ...........................................10
2.7. Network-Id-Name ...........................................11
2.8. EAPoL-Announcement ........................................12
2.9. WLAN-HESSID ...............................................14
2.10. WLAN-Venue-Info ..........................................14
2.11. WLAN-Venue-Language ......................................16
2.12. WLAN-Venue-Name ..........................................17
2.13. WLAN-Reason-Code .........................................18
2.14. WLAN-Pairwise-Cipher .....................................19
2.15. WLAN-Group-Cipher ........................................20
2.16. WLAN-AKM-Suite ...........................................21
2.17. WLAN-Group-Mgmt-Cipher ...................................22
2.18. WLAN-RF-Band .............................................23
3. Table of Attributes ............................................24
4. IANA Considerations ............................................25
5. Security Considerations ........................................25
6. References .....................................................26
6.1. Normative References ......................................26
6.2. Informative References ....................................27
7. Acknowledgments ................................................28
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................4
2. RADIUS Attributes ...............................................5
2.1. Allowed-Called-Station-Id ..................................5
2.2. EAP-Key-Name ...............................................6
2.3. EAP-Peer-Id ................................................7
2.4. EAP-Server-Id ..............................................8
2.5. Mobility-Domain-Id .........................................9
2.6. Preauth-Timeout ...........................................10
2.7. Network-Id-Name ...........................................11
2.8. EAPoL-Announcement ........................................12
2.9. WLAN-HESSID ...............................................14
2.10. WLAN-Venue-Info ..........................................14
2.11. WLAN-Venue-Language ......................................16
2.12. WLAN-Venue-Name ..........................................17
2.13. WLAN-Reason-Code .........................................18
2.14. WLAN-Pairwise-Cipher .....................................19
2.15. WLAN-Group-Cipher ........................................20
2.16. WLAN-AKM-Suite ...........................................21
2.17. WLAN-Group-Mgmt-Cipher ...................................22
2.18. WLAN-RF-Band .............................................23
3. Table of Attributes ............................................24
4. IANA Considerations ............................................25
5. Security Considerations ........................................25
6. References .....................................................26
6.1. Normative References ......................................26
6.2. Informative References ....................................27
7. Acknowledgments ................................................28
In situations where it is desirable to centrally manage authentication, authorization, and accounting (AAA) for IEEE 802 [IEEE-802] networks, deployment of a backend authentication and accounting server is desirable. In such situations, it is expected that IEEE 802 authenticators will function as AAA clients.
在需要集中管理IEEE 802[IEEE-802]网络的认证、授权和计费（AAA）的情况下，需要部署后端认证和计费服务器。在这种情况下，预计IEEE 802认证器将作为AAA客户端运行。
"IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines" [RFC3580] provides guidelines for the use of the Remote Authentication Dial-In User Service (RADIUS) within networks utilizing IEEE 802 local area networks. This document defines additional attributes suitable for usage by IEEE 802 authenticators acting as AAA clients.
“IEEE 802.1X远程认证拨入用户服务（RADIUS）使用指南”[RFC3580]提供了在使用IEEE 802局域网的网络中使用远程认证拨入用户服务（RADIUS）的指南。本文档定义了适用于充当AAA客户端的IEEE 802身份验证程序使用的其他属性。
This document uses the following terms:
本文件使用以下术语：
Access Point (AP) A Station that provides access to the distribution services via the wireless medium for associated Stations.
接入点（AP）通过无线媒体为相关站点提供对分发服务的访问的站点。
Association The service used to establish Access Point/Station mapping and enable Station invocation of the distribution system services.
关联用于建立接入点/站点映射和启用分发系统服务的站点调用的服务。
Authenticator An entity that requires authentication from the Supplicant. The authenticator may be connected to the Supplicant at the other end of a point-to-point LAN segment or wireless link.
Authenticator需要请求方进行身份验证的实体。认证器可以在点到点LAN段或无线链路的另一端连接到请求者。
Authentication Server An entity that provides an authentication service to an authenticator. This service verifies the claim of identity made by the Supplicant using the credentials provided by the Supplicant
身份验证服务器向身份验证者提供身份验证服务的实体。此服务使用请求者提供的凭据验证请求者的身份声明
Station (STA) Any device that contains an IEEE 802.11 conformant Medium Access Control (MAC) and Physical Layer (PHY) interface to the wireless medium (WM).
站点（STA）包含符合IEEE 802.11的媒体访问控制（MAC）和无线媒体（WM）物理层（PHY）接口的任何设备。
Supplicant An entity that is being authenticated by an authenticator. The Supplicant may be connected to the authenticator at one end of a point-to-point LAN segment or 802.11 wireless link.
请求者正在由验证器进行身份验证的实体。请求者可以在点到点LAN段或802.11无线链路的一端连接到认证器。
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]中所述进行解释。
Description
描述
The Allowed-Called-Station-Id Attribute allows the RADIUS server to specify the authenticator MAC addresses and/or networks to which the user is allowed to connect. One or more Allowed-Called-Station-Id Attributes MAY be included in an Access-Accept, CoA-Request, or Accounting-Request packet.
Allowed Called Station Id属性允许RADIUS服务器指定允许用户连接的验证器MAC地址和/或网络。一个或多个允许的被叫站Id属性可以包括在接入接受、CoA请求或记帐请求分组中。
The Allowed-Called-Station-Id Attribute can be useful in situations where pre-authentication is supported (e.g., IEEE 802.11 pre-authentication). In these scenarios, a Called-Station-Id Attribute typically will not be included within the Access-Request so that the RADIUS server will not know the network that the user is attempting to access. The Allowed-Called-Station-Id enables the RADIUS server to restrict the networks and attachment points to which the user can subsequently connect.
在支持预认证的情况下（例如，IEEE 802.11预认证），允许的被叫站Id属性非常有用。在这些场景中，访问请求中通常不包括被调用的站点Id属性，因此RADIUS服务器将不知道用户试图访问的网络。允许的被叫站点Id允许RADIUS服务器限制用户随后可以连接的网络和连接点。
A summary of the Allowed-Called-Station-Id Attribute format is shown below. The fields are transmitted from left to right.
下面显示了允许的被叫站点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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
174
174
Length
长
>=3
>=3
String
一串
The String field is one or more octets, specifying a Called-Station-Id that the user MAY connect to; if the Called-Station-Id that the user connects to does not match one of the Allowed-Called-Station-Id Attributes, the Network Access Server (NAS) MUST NOT permit the user to access the network.
字符串字段是一个或多个八位字节，指定用户可以连接到的被叫站Id；如果用户连接到的被叫站Id与允许的被叫站Id属性之一不匹配，则网络访问服务器（NAS）不得允许用户访问网络。
In the case of IEEE 802, the Allowed-Called-Station-Id Attribute is used to store the Medium Access Control (MAC) address, represented as an uppercase ASCII character string in Canonical format and with octet values separated by a "-", for example, "00-10-A4-23-19-C0". Where restrictions on both the network and authenticator MAC address usage are intended, the network name MUST be appended to the authenticator MAC address, separated from the MAC address with a ":", for example, "00-10-A4-23-19-C0:AP1". Where no MAC address restriction is intended, the MAC address field MUST be omitted, but ":" and the network name field MUST be included, for example, ":AP1".
在IEEE 802的情况下，Allowed Called Station Id属性用于存储介质访问控制（MAC）地址，该地址以规范格式表示为大写ASCII字符串，八位字节值以“-”分隔，例如，“00-10-A4-23-19-C0”。如果打算限制网络和验证器MAC地址的使用，则必须将网络名称附加到验证器MAC地址，并用“：”与MAC地址分开，例如，“00-10-A4-23-19-C0:AP1”。如果没有MAC地址限制，则必须省略MAC地址字段，但必须包括“：”和网络名称字段，例如“：AP1”。
Within IEEE 802.11 [IEEE-802.11], the Service Set Identifier (SSID) constitutes the network name; within IEEE 802.1X [IEEE-802.1X] wired networks, the Network-Id Name (NID-Name) constitutes the network name. Since a NID-Name can be up to 253 octets in length, when used with [IEEE-802.1X] wired networks, there may not be sufficient room within the Allowed-Called-Station-Id Attribute to include both a MAC address and a network name. However, as the Allowed-Called-Station-Id Attribute is expected to be used largely in wireless access scenarios, this restriction is not considered serious.
在IEEE 802.11[IEEE-802.11]中，服务集标识符（SSID）构成网络名称；在IEEE 802.1X[IEEE-802.1X]有线网络中，网络Id名称（NID名称）构成网络名称。由于NID名称的长度可达253个八位字节，当与[IEEE-802.1X]有线网络一起使用时，在允许的被叫站Id属性中可能没有足够的空间来同时包含MAC地址和网络名称。然而，由于“允许的被叫站Id”属性预计将在无线接入场景中大量使用，因此这种限制并不严重。
Description
描述
The EAP-Key-Name Attribute, defined in "Diameter Extensible Authentication Protocol (EAP) Application" [RFC4072], contains the EAP Session-Id, as described in "Extensible Authentication Protocol (EAP) Key Management Framework" [RFC5247]. Exactly how this attribute is used depends on the link layer in question.
“Diameter可扩展身份验证协议（EAP）应用程序”[RFC4072]中定义的EAP密钥名称属性包含EAP会话Id，如“可扩展身份验证协议（EAP）密钥管理框架”[RFC5247]中所述。该属性的具体使用方式取决于所讨论的链接层。
It should be noted that not all link layers use this name. An EAP-Key-Name Attribute MAY be included within Access-Request, Access-Accept, and CoA-Request packets. A summary of the EAP-Key-Name Attribute format is shown below. The fields are transmitted from left to right.
应该注意的是，并非所有链接层都使用此名称。EAP密钥名称属性可以包括在访问请求、访问接受和CoA请求包中。EAP密钥名称属性格式的摘要如下所示。字段从左向右传输。
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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
102 [RFC4072]
102[RFC4072]
Length
长
>=3
>=3
String
一串
The String field is one or more octets, containing the EAP Session-Id, as defined in "Extensible Authentication Protocol (EAP) Key Management Framework" [RFC5247]. Since the NAS operates as a pass-through in EAP, it cannot know the EAP Session-Id before receiving it from the RADIUS server. As a result, an EAP-Key-Name Attribute sent in an Access-Request MUST only contain a single NUL character. A RADIUS server receiving an Access-Request with an EAP-Key-Name Attribute containing anything other than a single NUL character MUST silently discard the attribute. In addition, the RADIUS server SHOULD include this attribute in an Access-Accept or CoA-Request only if an EAP-Key-Name Attribute was present in the Access-Request. Since a NAS will typically only include an EAP-Key-Name Attribute in an Access-Request in situations where the attribute is required to provision service, if an EAP-Key-Name Attribute is included in an Access-Request but is not present in the Access-Accept, the NAS SHOULD treat the Access-Accept as though it were an Access-Reject. If an EAP-Key-Name Attribute was not present in the Access-Request but is included in the Access-Accept, then the NAS SHOULD silently discard the EAP-Key-Name Attribute. As noted in Section 6.2.2 of [IEEE-802.1X], the Connectivity Association Key Name (CKN) is derived from the EAP Session-Id, and, as described in Section 9.3.3 of [IEEE-802.1X], the CKN is subsequently used in the derivation of the Key Encrypting Key (KEK) and the Integrity Check Value Key (ICK), which protect the Secure Association Keys (SAKs) utilized by Media Access Control Security (MACsec). As a result, for the NAS to acquire information needed in the MACsec Key Agreement (MKA) exchange, it needs to include the EAP-Key-Name Attribute in the Access-Request and receive it from the RADIUS server in the Access-Accept.
字符串字段是一个或多个八位字节，包含“可扩展身份验证协议（EAP）密钥管理框架”[RFC5247]中定义的EAP会话Id。由于NAS在EAP中作为直通操作，因此在从RADIUS服务器接收EAP会话Id之前，它无法知道该会话Id。因此，在访问请求中发送的EAP密钥名称属性只能包含一个NUL字符。RADIUS服务器接收具有EAP Key Name属性（包含除单个NUL字符以外的任何内容）的访问请求时，必须以静默方式放弃该属性。此外，只有在访问请求中存在EAP密钥名属性时，RADIUS服务器才应在访问接受或CoA请求中包含此属性。由于在提供服务需要EAP密钥名称属性的情况下，NAS通常仅在访问请求中包含EAP密钥名称属性，因此，如果EAP密钥名称属性包含在访问请求中，但在访问接受中不存在，NAS应将访问接受视为访问拒绝。如果访问请求中不存在EAP密钥名称属性，但该属性包含在访问接受中，则NAS应自动放弃EAP密钥名称属性。如[IEEE-802.1X]第6.2.2节所述，连接关联密钥名称（CKN）源自EAP会话Id，并且如[IEEE-802.1X]第9.3.3节所述，CKN随后用于密钥加密密钥（KEK）和完整性检查值密钥（ICK）的推导，其保护安全关联密钥（SAK）由媒体访问控制安全（MACsec）利用。因此，NAS要获取MACsec密钥协议（MKA）交换中所需的信息，需要在访问请求中包含EAP密钥名称属性，并在访问接受中从RADIUS服务器接收该属性。
Description
描述
The EAP-Peer-Id Attribute contains a Peer-Id generated by the EAP method. Exactly how this name is used depends on the link layer in question. See [RFC5247] for more discussion. The EAP-Peer-Id Attribute MAY be included in Access-Request, Access-Accept, and Accounting-Request packets. More than one EAP-Peer-Id Attribute MUST NOT be included in an Access-Request; one or more EAP-Peer-Id Attributes MAY be included in an Access-Accept.
EAP对等Id属性包含由EAP方法生成的对等Id。该名称的确切使用方式取决于所讨论的链接层。有关更多讨论，请参阅[RFC5247]。EAP对等Id属性可以包括在访问请求、访问接受和记帐请求数据包中。访问请求中不得包含多个EAP对等Id属性；一个或多个EAP对等Id属性可以包括在访问接受中。
It should be noted that not all link layers use this name, and existing EAP method implementations do not generate it. Since the NAS operates as a pass-through in EAP [RFC3748], it cannot know the EAP-Peer-Id before receiving it from the RADIUS server. As a result, an EAP-Peer-Id Attribute sent in an Access-Request MUST only contain a single NUL character. A home RADIUS server receiving an Access-Request with an EAP-Peer-Id Attribute containing anything other than a single NUL character MUST silently discard the attribute. In addition, the home RADIUS server SHOULD include one or more EAP-Peer-Id Attributes in an Access-Accept only if an EAP-Peer-Id Attribute was present in the Access-Request. If a NAS receives EAP-Peer-Id Attribute(s) in an Access-Accept without having included one in an Access-Request, the NAS SHOULD silently discard the attribute(s). A summary of the EAP-Peer-Id Attribute format is shown below. The fields are transmitted from left to right.
应该注意的是，并非所有链路层都使用此名称，并且现有的EAP方法实现不会生成此名称。由于NAS在EAP[RFC3748]中作为直通操作，因此在从RADIUS服务器接收EAP对等Id之前，它无法知道该Id。因此，在访问请求中发送的EAP对等Id属性只能包含一个NUL字符。接收具有EAP对等Id属性（包含除单个NUL字符以外的任何内容）的访问请求的主RADIUS服务器必须以静默方式放弃该属性。此外，仅当访问请求中存在EAP对等Id属性时，主RADIUS服务器应在访问接受中包含一个或多个EAP对等Id属性。如果NAS在访问接受中接收到EAP对等Id属性，而未在访问请求中包含该属性，则NAS应自动放弃该属性。EAP对等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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
175
175
Length
长
>=3
>=3
String
一串
The String field is one or more octets, containing an EAP Peer-Id exported by the EAP method. For details, see Appendix A of [RFC5247]. A robust implementation SHOULD support the field as undistinguished octets. Only a single EAP Peer-Id may be included per attribute.
字符串字段是一个或多个八位字节，包含由EAP方法导出的EAP对等Id。详见[RFC5247]附录A。一个健壮的实现应该支持字段作为无差别的八位字节。每个属性只能包含一个EAP对等Id。
Description
描述
The EAP-Server-Id Attribute contains a Server-Id generated by the EAP method. Exactly how this name is used depends on the link layer in question. See [RFC5247] for more discussion. The EAP-Server-Id Attribute is only allowed in Access-Request, Access-Accept, and Accounting-Request packets. More than one EAP-Server-
EAP服务器Id属性包含由EAP方法生成的服务器Id。该名称的确切使用方式取决于所讨论的链接层。有关更多讨论，请参阅[RFC5247]。EAP服务器Id属性仅在访问请求、访问接受和记帐请求数据包中允许。多个EAP服务器-
Id Attribute MUST NOT be included in an Access-Request; one or more EAP-Server-Id Attributes MAY be included in an Access-Accept.
Id属性不能包含在访问请求中；Access Accept中可能包含一个或多个EAP服务器Id属性。
It should be noted that not all link layers use this name, and existing EAP method implementations do not generate it. Since the NAS operates as a pass-through in EAP [RFC3748], it cannot know the EAP-Server-Id before receiving it from the RADIUS server. As a result, an EAP-Server-Id Attribute sent in an Access-Request MUST contain only a single NUL character. A home RADIUS server receiving an Access-Request with an EAP-Server-Id Attribute containing anything other than a single NUL character MUST silently discard the attribute. In addition, the home RADIUS server SHOULD include this attribute in an Access-Accept only if an EAP-Server-Id Attribute was present in the Access-Request. A summary of the EAP-Server-Id Attribute format is shown below. The fields are transmitted from left to right.
应该注意的是，并非所有链路层都使用此名称，并且现有的EAP方法实现不会生成此名称。由于NAS在EAP[RFC3748]中作为直通操作，因此在从RADIUS服务器接收EAP服务器Id之前，它无法知道该服务器Id。因此，在访问请求中发送的EAP服务器Id属性只能包含一个NUL字符。接收具有EAP服务器Id属性（包含除单个NUL字符以外的任何内容）的访问请求的主RADIUS服务器必须以静默方式放弃该属性。此外，仅当访问请求中存在EAP服务器Id属性时，主RADIUS服务器才应在访问接受中包含此属性。EAP服务器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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
176
176
Length
长
>=3
>=3
String
一串
The String field is one or more octets, containing an EAP Server-Id exported by the EAP method. For details, see Appendix A of [RFC5247]. A robust implementation SHOULD support the field as undistinguished octets.
字符串字段是一个或多个八位字节，包含由EAP方法导出的EAP服务器Id。详见[RFC5247]附录A。一个健壮的实现应该支持字段作为无差别的八位字节。
Description
描述
A single Mobility-Domain-Id Attribute MAY be included in an Access-Request or Accounting-Request in order to enable the NAS to provide the RADIUS server with the Mobility Domain Identifier (MDID), defined in Section 8.4.2.49 of [IEEE-802.11]. A summary of the Mobility-Domain-Id Attribute format is shown below. The fields are transmitted from left to right.
为了使NAS能够向RADIUS服务器提供[IEEE-802.11]第8.4.2.49节中定义的移动域标识符（MDID），可以在访问请求或记帐请求中包括单个移动域Id属性。移动域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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
177
177
Length
长
6
6.
Value
价值
The Value field is four octets, containing a 32-bit unsigned integer. The two most significant octets MUST be set to zero by the sender and are ignored by the receiver; the two least significant octets contain the Mobility Domain Identifier (MDID) defined in Section 8.4.2.49 of [IEEE-802.11].
值字段是四个八位字节，包含一个32位无符号整数。发送方必须将两个最重要的八位字节设置为零，接收方则忽略这两个八位字节；两个最低有效八位字节包含[IEEE-802.11]第8.4.2.49节中定义的移动域标识符（MDID）。
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 | Mobility Domain Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Mobility Domain Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
描述
This attribute sets the maximum number of seconds that pre-authentication state is required to be kept by the NAS without being utilized within a user session. For example, when [IEEE-802.11] pre-authentication is used, if a user has not attempted to utilize the Pairwise Master Key (PMK) derived as a result of pre-authentication within the time specified by the Preauth-Timeout Attribute, the PMK MAY be discarded by the Access Point. However, once the session is underway, the Preauth-Timeout Attribute has no bearing on the maximum session time for the user or the maximum time during which key state may be kept prior to re-authentication. This is determined by the Session-Timeout Attribute, if present.
此属性设置NAS需要保持预身份验证状态而不在用户会话中使用的最大秒数。例如，当使用[IEEE-802.11]预认证时，如果用户在预认证超时属性指定的时间内没有尝试使用作为预认证结果而派生的成对主密钥（PMK），则接入点可能会丢弃PMK。但是，一旦会话正在进行，Preauth Timeout属性对用户的最大会话时间或在重新身份验证之前可以保持密钥状态的最大时间没有影响。这由会话超时属性（如果存在）确定。
A single Preauth-Timeout Attribute MAY be included within an Access-Accept or CoA-Request packet. A summary of the Preauth-Timeout Attribute format is shown below. The fields are transmitted from left to right.
访问接受或CoA请求数据包中可能包含单个预授权超时属性。预授权超时属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
178
178
Length
长
6
6.
Value
价值
The field is 4 octets, containing a 32-bit unsigned integer encoding the maximum time in seconds that pre-authentication state should be retained by the NAS.
该字段为4个八位字节，包含一个32位无符号整数，编码NAS应保留预身份验证状态的最长时间（以秒为单位）。
Description
描述
The Network-Id-Name Attribute is utilized by implementations of IEEE-802.1X [IEEE-802.1X] to specify the name of a Network-Id (NID-Name).
IEEE-802.1X[IEEE-802.1X]的实现使用网络Id名称属性来指定网络Id的名称（NID名称）。
Unlike the IEEE 802.11 SSID (which is a maximum of 32 octets in length), the NID-Name may be up to 253 octets in length. Consequently, if the MAC address is included within the Called-Station-Id Attribute, it is possible that there will not be enough remaining space to encode the NID-Name as well. Therefore, when used with IEEE 802.1X [IEEE-802.1X], the Called-Station-Id Attribute SHOULD contain only the MAC address, with the Network-Id-Name Attribute used to transmit the NID-Name. The Network-Id-Name Attribute MUST NOT be used to encode the IEEE 802.11 SSID; as noted in [RFC3580], the Called-Station-Id Attribute is used for this purpose.
与IEEE 802.11 SSID（最大长度为32个八位字节）不同，NID名称的长度可能最多为253个八位字节。因此，如果MAC地址包括在被叫站Id属性中，则可能没有足够的剩余空间来编码NID名称。因此，当与IEEE 802.1X[IEEE-802.1X]一起使用时，被叫站Id属性应仅包含MAC地址，网络Id名称属性用于传输NID名称。网络Id名称属性不得用于编码IEEE 802.11 SSID；如[RFC3580]中所述，被叫站Id属性用于此目的。
Zero or one Network-Id-Name Attribute is permitted within an Access-Request, Access-Challenge, Access-Accept or Accounting-Request packet. When included within an Access-Request packet, the Network-Id-Name Attribute represents a hint of the NID-Name to which the Supplicant should be granted access. When included within an Access-Accept packet, the Network-Id-Name Attribute represents the NID-Name to which the Supplicant is to be granted access. When included within an Accounting-Request packet, the Network-Id-Name Attribute represents the NID-Name to which the Supplicant has been granted access.
在访问请求、访问质询、访问接受或记帐请求数据包中允许零个或一个网络Id名称属性。当包含在访问请求数据包中时，networkid Name属性表示请求者应被授予访问权的NID名称的提示。当包含在Access Accept数据包中时，Network Id Name属性表示请求者将被授予访问权限的NID名称。当包含在记帐请求数据包中时，Network Id Name属性表示请求者已被授予访问权的NID名称。
A summary of the Network-Id-Name Attribute format is shown below. The fields are transmitted from left to right.
网络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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
179
179
Length
长
>=3
>=3
String
一串
The String field is one or more octets, containing a NID-Name. For details, see [IEEE-802.1X]. A robust implementation SHOULD support the field as undistinguished octets.
字符串字段是一个或多个八位字节，包含NID名称。有关详细信息，请参阅[IEEE-802.1X]。一个健壮的实现应该支持字段作为无差别的八位字节。
Description
描述
The EAPoL-Announcement Attribute contains EAPoL-Announcement Type-Length-Value (TLV) tuples defined within Table 11-8 of IEEE-802.1X [IEEE-802.1X]. The acronym "EAPoL" stands for Extensible Authentication Protocol over Local Area Network.
EAPoL公告属性包含IEEE-802.1X[IEEE-802.1X]表11-8中定义的EAPoL公告类型长度值（TLV）元组。首字母缩略词“EAPoL”代表局域网上的可扩展身份验证协议。
Zero or more EAPoL-Announcement Attributes are permitted within an Access-Request, Access-Accept, Access-Challenge, Access-Reject, Accounting-Request, CoA-Request, or Disconnect-Request packet.
访问请求、访问接受、访问质询、访问拒绝、记帐请求、CoA请求或断开连接请求数据包中允许零个或多个EAPoL公告属性。
When included within an Access-Request packet, EAPoL-Announcement Attributes contain EAPoL-Announcement TLVs that the user sent in an EAPoL-Announcement. When included within an Access-Accept, Access-Challenge, Access-Reject, CoA-Request or Disconnect-Request packet, EAPoL-Announcement Attributes contain EAPoL-Announcement TLVs that the NAS is to send to the user in a unicast EAPoL-Announcement. When sent within an Accounting-Request packet, EAPoL-Announcement Attributes contain EAPoL-Announcement TLVs that the NAS has most recently sent to the user in a unicast EAPoL-Announcement.
当包含在访问请求数据包中时，EAPoL公告属性包含用户在EAPoL公告中发送的EAPoL公告TLV。当包含在访问接受、访问质询、访问拒绝、CoA请求或断开连接请求数据包中时，EAPoL公告属性包含NAS将在单播EAPoL公告中发送给用户的EAPoL公告TLV。当在记帐请求数据包中发送时，EAPoL公告属性包含NAS最近在单播EAPoL公告中发送给用户的EAPoL公告TLV。
A summary of the EAPoL-Announcement Attribute format is shown below. The fields are transmitted from left to right.
EAPoL公告属性格式的摘要如下所示。字段从左向右传输。
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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
180
180
Length
长
>=3
>=3
String
一串
The String field is one or more octets, containing EAPoL-Announcement TLVs in the format defined in Figure 11-8 of Section 11.12 of [IEEE-802.1X]. Any EAPoL-Announcement TLV Type MAY be included within an EAPoL-Announcement Attribute, including Organizationally Specific TLVs. If multiple EAPoL-Announcement Attributes are present in a packet, their String fields MUST be concatenated before being parsed for EAPoL-Announcement TLVs; this allows EAPoL-Announcement TLVs longer than 253 octets to be transported by RADIUS. Similarly, EAPoL-Announcement TLVs larger than 253 octets MUST be fragmented between multiple EAPoL-Announcement Attributes.
字符串字段是一个或多个八位字节，包含[IEEE-802.1X]第11.12节图11-8中定义格式的EAPoL公告TLV。任何EAPoL公告TLV类型都可以包含在EAPoL公告属性中，包括特定于组织的TLV。如果数据包中存在多个EAPoL公告属性，则在解析EAPoL公告TLV之前，必须连接它们的字符串字段；这允许通过RADIUS传输长度超过253个八位字节的EAPoL公告TLV。类似地，大于253个八位字节的EAPoL公告TLV必须在多个EAPoL公告属性之间分段。
Description
描述
The WLAN-HESSID Attribute contains a MAC address that identifies the Homogenous Extended Service Set. The HESSID is a globally unique identifier that, in conjunction with the SSID, encoded within the Called-Station-Id Attribute as described in [RFC3580], may be used to provide network identification for a subscription service provider network (SSPN), as described in Section 8.4.2.94 of [IEEE-802.11]. Zero or one WLAN-HESSID Attribute is permitted within an Access-Request or Accounting-Request packet.
WLAN-HESSID属性包含标识同质扩展服务集的MAC地址。HESSID是一个全局唯一标识符，与SSID一起编码在[RFC3580]中所述的被叫站Id属性中，可用于为订阅服务提供商网络（SSPN）提供网络标识，如[IEEE-802.11]第8.4.2.94节所述。访问请求或记帐请求数据包中允许零个或一个WLAN-HESSID属性。
A summary of the WLAN-HESSID Attribute format is shown below. The fields are transmitted from left to right.
WLAN-HESSID属性格式的摘要如下所示。字段从左向右传输。
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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
181
181
Length
长
19
19
String
一串
The String field is encoded in uppercase ASCII characters with the octet values separated by dash characters, as described in RFC 3580 [RFC3580], for example, "00-10-A4-23-19-C0".
字符串字段以大写ASCII字符编码，八位值由破折号分隔，如RFC 3580[RFC3580]中所述，例如，“00-10-A4-23-19-C0”。
Description
描述
The WLAN-Venue-Info Attribute identifies the category of venue hosting the WLAN, as defined in Section 8.4.1.34 of [IEEE-802.11]. Zero or more WLAN-Venue-Info Attributes may be included in an Access-Request or Accounting-Request.
WLAN场馆信息属性标识承载WLAN的场馆类别，如[IEEE-802.11]第8.4.1.34节所定义。访问请求或记帐请求中可能包含零个或多个WLAN场馆信息属性。
A summary of the WLAN-Venue-Info Attribute format is shown below. The fields are transmitted from left to right.
WLAN场馆信息属性格式摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
182
182
Length
长
6
6.
Value
价值
The Value field is four octets, containing a 32-bit unsigned integer. The two most significant octets MUST be set to zero by the sender, and are ignored by the receiver; the two least significant octets contain the Venue Group and Venue Type fields.
值字段是四个八位字节，包含一个32位无符号整数。两个最重要的八位字节必须由发送方设置为零，接收方忽略；两个最不重要的八位字节包含场馆组和场馆类型字段。
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 | Venue Group | Venue Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Venue Group | Venue Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Venue Group
场馆组
The Venue Group field is a single octet and describes the broad category of the venue, e.g., "Assembly". See Section 8.4.1.34 of [IEEE-802.11] for Venue Group codes and descriptions.
场馆组字段是一个八位字节，描述场馆的大类别，例如“集会”。场馆组码和说明见[IEEE-802.11]第8.4.1.34节。
Venue Type
场馆类型
The Venue Type field is a single octet and describes the venue in a finer granularity within the Venue Group, e.g., "Library". See Section 8.4.1.34 of [IEEE-802.11] for Venue Type codes and descriptions.
场馆类型字段是一个八位字节，在场馆组中以更精细的粒度描述场馆，例如“图书馆”。场馆类型代码和说明见[IEEE-802.11]第8.4.1.34节。
Description
描述
The WLAN-Venue-Language Attribute is a string encoded by ISO-14962-1997 [ISO-14962-1997] that defines the language used in the WLAN-Venue-Name Attribute. Zero or more WLAN-Venue-Language Attributes may be included in an Access-Request or Accounting-Request, and each one indicates the language of the WLAN-Venue-Name Attribute that follows it.
WLAN场馆语言属性是由ISO-14962-1997[ISO-14962-1997]编码的字符串，定义了WLAN场馆名称属性中使用的语言。访问请求或记帐请求中可能包含零个或多个WLAN场馆语言属性，并且每个属性都指示其后面的WLAN场馆名称属性的语言。
A summary of the WLAN-Venue-Language Attribute format is shown below. The fields are transmitted from left to right.
WLAN场馆语言属性格式摘要如下所示。字段从左向右传输。
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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String (cont) |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String (cont) |
+-+-+-+-+-+-+-+-+
Type
类型
183
183
Length
长
4-5
4-5
String
一串
The String field is a two- or three-character language code selected from ISO-639 [ISO-639]. A two-character language code has a zero ("null" in ISO-14962-1997) appended to make it 3 octets in length.
字符串字段是从ISO-639[ISO-639]中选择的两个或三个字符的语言代码。两个字符的语言代码附加了一个零（ISO-14962-1997中为null），使其长度为3个八位字节。
Description
描述
The WLAN-Venue-Name Attribute provides additional metadata on the Basic Service Set (BSS). For example, this information may be used to assist a user in selecting the appropriate BSS with which to associate. Zero or more WLAN-Venue-Name Attributes may be included in an Access- Request or Accounting-Request in the same or different languages.
WLAN场馆名称属性提供基本服务集（BSS）上的附加元数据。例如，该信息可用于帮助用户选择要关联的适当bs。使用相同或不同语言的访问请求或记帐请求中可能包含零个或多个WLAN场馆名称属性。
A summary of the WLAN-Venue-Name Attribute format is shown below. The fields are transmitted from left to right.
WLAN场馆名称属性格式摘要如下所示。字段从左向右传输。
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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
184
184
Length
长
>=3
>=3
String
一串
The String field is encoded in UTF-8 and contains the venue's name. The maximum length of this field is 252 octets.
字符串字段以UTF-8编码，包含场馆名称。此字段的最大长度为252个八位字节。
Description
描述
The WLAN-Reason-Code Attribute contains information on the reason why a Station has been refused network access and has been disassociated or de-authenticated. This can occur due to policy or for reasons related to the user's subscription.
“WLAN原因代码”属性包含有关站点被拒绝网络访问并被解除关联或取消身份验证的原因的信息。这可能是由于策略或与用户订阅相关的原因造成的。
A WLAN-Reason-Code Attribute MAY be included within an Access-Reject or Disconnect-Request packet, as well as within an Accounting-Request packet. Upon receipt of an Access-Reject or Disconnect-Request packet containing a WLAN-Reason-Code Attribute, the WLAN-Reason-Code value is copied by the Access Point into the Reason Code field of a Disassociation or Deauthentication frame (see Clauses 8.3.3.4 and 8.3.3.12, respectively, in [IEEE-802.11]), which is subsequently transmitted to the Station.
WLAN原因码属性可以包括在接入拒绝或断开连接请求分组中，以及在记帐请求分组中。在接收到包含WLAN原因码属性的访问拒绝或断开请求数据包后，接入点将WLAN原因码值复制到解除关联或取消验证帧的原因码字段中（分别参见[IEEE-802.11]中的第8.3.3.4条和第8.3.3.12条），随后将其传输到电台。
A summary of the WLAN-Reason-Code Attribute format is shown below. The fields are transmitted from left to right.
WLAN原因码属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
185
185
Length
长
6
6.
Value
价值
The Value field is four octets, containing a 32-bit unsigned integer. The two most significant octets MUST be set to zero by the sender and are ignored by the receiver; the two least significant octets contain the Reason Code values defined in Table 8-36 of Section 8.4.1.7 of [IEEE-802.11].
值字段是四个八位字节，包含一个32位无符号整数。发送方必须将两个最重要的八位字节设置为零，接收方则忽略这两个八位字节；两个最低有效八位字节包含[IEEE-802.11]第8.4.1.7节表8-36中定义的原因码值。
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 | Reason Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reason Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
描述
The WLAN-Pairwise-Cipher Attribute contains information on the pairwise ciphersuite used to establish the robust security network association (RSNA) between the AP and mobile device. A WLAN-Pairwise-Cipher Attribute MAY be included within Access-Request and Accounting-Request packets.
WLAN成对密码属性包含用于在AP和移动设备之间建立可靠安全网络关联（RSNA）的成对密码套件的信息。WLAN成对密码属性可以包括在访问请求和记帐请求分组中。
A summary of the WLAN-Pairwise-Cipher Attribute format is shown below. The fields are transmitted from left to right.
WLAN成对密码属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
186
186
Length
长
6
6.
Value
价值
The Value field is four octets, containing a 32-bit unsigned integer, in Suite selector format as specified in Figure 8-187 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and Suite Type drawn from Table 8-99.
值字段为四个八位字节，包含一个32位无符号整数，采用[IEEE-802.11]第8.4.2.27.2节图8-187中规定的套件选择器格式，OUI值和套件类型取自表8-99。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Suite Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Suite Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
描述
The WLAN-Group-Cipher Attribute contains information on the group ciphersuite used to establish the robust security network association (RSNA) between the AP and mobile device. A WLAN-Group-Cipher Attribute MAY be included within Access-Request and Accounting-Request packets.
“WLAN组密码”属性包含有关用于在AP和移动设备之间建立可靠安全网络关联（RSNA）的组密码套件的信息。WLAN组密码属性可以包括在访问请求和记帐请求分组中。
A summary of the WLAN-Group-Cipher Attribute format is shown below. The fields are transmitted from left to right.
WLAN组密码属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
187
187
Length
长
6
6.
Value
价值
The Value field is four octets, containing a 32-bit unsigned integer, in Suite selector format as specified in Figure 8-187 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and Suite Type drawn from Table 8-99.
值字段为四个八位字节，包含一个32位无符号整数，采用[IEEE-802.11]第8.4.2.27.2节图8-187中规定的套件选择器格式，OUI值和套件类型取自表8-99。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Suite Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Suite Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
描述
The WLAN-AKM-Suite Attribute contains information on the authentication and key management suite used to establish the robust security network association (RSNA) between the AP and mobile device. A WLAN-AKM-Suite Attribute MAY be included within Access-Request and Accounting-Request packets.
WLAN AKM套件属性包含用于在AP和移动设备之间建立可靠安全网络关联（RSNA）的身份验证和密钥管理套件的信息。WLAN AKM套件属性可以包括在访问请求和记帐请求数据包中。
A summary of the WLAN-AKM-Suite Attribute format is shown below. The fields are transmitted from left to right.
WLAN AKM套件属性格式摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
188
188
Length
长
6
6.
Value
价值
The Value field is four octets, containing a 32-bit unsigned integer, in Suite selector format as specified in Figure 8-187 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and Suite Type drawn from Table 8-101:
值字段为四个八位字节，包含一个32位无符号整数，采用[IEEE-802.11]第8.4.2.27.2节图8-187中规定的套件选择器格式，OUI值和套件类型取自表8-101：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Suite Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Suite Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
描述
The WLAN-Group-Mgmt-Cipher Attribute contains information on the group management cipher used to establish the robust security network association (RSNA) between the AP and mobile device.
WLAN组管理密码属性包含有关用于在AP和移动设备之间建立可靠安全网络关联（RSNA）的组管理密码的信息。
Zero or one WLAN-Group-Mgmt-Cipher Attribute MAY be included within Access-Request and Accounting-Request packets. The presence of the Attribute indicates that the Station negotiated to use management frame protection during association.
访问请求和记帐请求数据包中可能包含零个或一个WLAN组管理密码属性。属性的存在表示站点在关联期间协商使用管理帧保护。
A summary of the WLAN-Group-Mgmt-Cipher Attribute format is shown below. The fields are transmitted from left to right.
WLAN组管理密码属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
189
189
Length
长
6
6.
Value
价值
The Value field is four octets, containing a 32-bit unsigned integer, in Suite selector format as specified in Figure 8-187 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and Suite Type drawn from Table 8-99:
值字段为四个八位字节，包含一个32位无符号整数，采用[IEEE-802.11]第8.4.2.27.2节图8-187中规定的套件选择器格式，OUI值和套件类型取自表8-99：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Suite Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Suite Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
描述
The WLAN-RF-Band Attribute contains information on the radio frequency (RF) band used by the Access Point for transmission and reception of information to and from the mobile device. Zero or one WLAN-RF-Band Attribute MAY be included within an Access-Request or Accounting-Request packet.
WLAN RF频带属性包含接入点用于向移动设备发送信息和从移动设备接收信息的射频（RF）频带的信息。在接入请求或计费请求分组中可以包括零个或一个WLAN RF频带属性。
A summary of the WLAN-RF-Band Attribute format is shown below. The fields are transmitted from left to right.
WLAN RF频带属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
190
190
Length
长
6
6.
Value
价值
The Value field is four octets, containing a 32-bit unsigned integer. The three most significant octets MUST be set to zero by the sender and are ignored by the receiver; the least significant octet contains the RF Band field, whose values are defined by the IEEE 802.11 Band ID field (Table 8-53a of [IEEE-802.11ad])
值字段是四个八位字节，包含一个32位无符号整数。发送方必须将三个最重要的八位字节设置为零，接收方则忽略这三个八位字节；最低有效八位位组包含RF频带字段，其值由IEEE 802.11频带ID字段定义（IEEE-802.11ad的表8-53a）
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 | RF Band |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | RF Band |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following table provides a guide to which attributes may be found in which kinds of packets and in what quantity.
下表提供了在哪些类型的数据包中可以找到哪些属性以及数量的指南。
Access- Access- Access- Access-Request Accept Reject Challenge # Attribute 0 0+ 0 0 174 Allowed-Called-Station-Id 0-1 0-1 0 0 102 EAP-Key-Name 0-1 0+ 0 0 175 EAP-Peer-Id 0-1 0+ 0 0 176 EAP-Server-Id 0-1 0 0 0 177 Mobility-Domain-Id 0-1 0-1 0 0 178 Preauth-Timeout 0-1 0 0 0 179 Network-Id-Name 0+ 0+ 0+ 0+ 180 EAPoL-Announcement 0-1 0 0 0 181 WLAN-HESSID 0-1 0 0 0 182 WLAN-Venue-Info 0+ 0 0 0 183 WLAN-Venue-Language 0+ 0 0 0 184 WLAN-Venue-Name 0 0 0-1 0 185 WLAN-Reason-Code 0-1 0 0 0 186 WLAN-Pairwise-Cipher 0-1 0 0 0 187 WLAN-Group-Cipher 0-1 0 0 0 188 WLAN-AKM-Suite 0-1 0 0 0 189 WLAN-Group-Mgmt-Cipher 0-1 0 0 0 190 WLAN-RF-Band
访问-访问-访问-访问请求接受拒绝质询#属性0 0+0 0 174允许被叫站Id 0-1 0-1 0 0 102 EAP密钥名0-1 0+0 0 0 175 EAP对等Id 0-1 0+0 0 0 176 EAP服务器Id 0-1 0 0 177移动域Id 0-1 0-1 0 0 178预授权超时0-1 0 0 0 179网络Id名0+0+0+0+0+180 EAPoL公告0-1 0 0 0 181WLAN-HESSID 0-1 0 0 0 0 182 WLAN场馆信息0+0 0 0 183 WLAN场馆语言0+0 0 184 WLAN场馆名称0 0-1 0 185 WLAN原因码0-1 0 0 0 186 WLAN成对密码0-1 0 0 0 187 WLAN组密码0-1 0 0 188 WLAN AKM套件0-1 0 0 189 WLAN组管理密码0-1 0 0 0 190 WLAN射频频段
CoA- Dis- Acct-Req Req Req # Attribute 0+ 0 0+ 174 Allowed-Called-Station-Id 0-1 0 0 102 EAP-Key-Name 0 0 0+ 175 EAP-Peer-Id 0 0 0+ 176 EAP-Server-Id 0 0 0-1 177 Mobility-Domain-Id 0-1 0 0 178 Preauth-Timeout 0 0 0-1 179 Network-Id-Name 0+ 0+ 0+ 180 EAPoL-Announcement 0 0 0-1 181 WLAN-HESSID 0 0 0-1 182 WLAN-Venue-Info 0 0 0+ 183 WLAN-Venue-Language 0 0 0+ 184 WLAN-Venue-Name 0 0-1 0-1 185 WLAN-Reason-Code 0 0 0-1 186 WLAN-Pairwise-Cipher 0 0 0-1 187 WLAN-Group-Cipher 0 0 0-1 188 WLAN-AKM-Suite 0 0 0-1 189 WLAN-Group-Mgmt-Cipher 0 0 0-1 190 WLAN-RF-Band
CoA-Dis-Acct Req Req#属性0+0 0+174允许被叫站Id 0-1 0 0 102 EAP密钥名0 0 0+175 EAP对等Id 0 0 0+176 EAP服务器Id 0 0-1 177移动域Id 0-1 0 0 178预授权超时0-1 179网络Id名0+0+0+0+180 EAPoL公告0-1 181 WLAN-HESSID 0 0-1 182 WLAN场馆信息0 0 0+183WLAN场馆语言0 0 0+184 WLAN场馆名称0 0-1 0-1 185 WLAN原因码0 0-1 186 WLAN成对密码0 0-1 187 WLAN组密码0 0-1 188 WLAN AKM套件0 0-1 189 WLAN组管理密码0 0 0-1 190 WLAN射频频段
The following table defines the above table entries.
下表定义了上述表格条目。
0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in the packet. 0-1 Zero or one instance of this attribute MAY be present in the packet.
0此属性不能出现在数据包中。数据包中可能存在0+零个或多个此属性的实例。0-1数据包中可能存在该属性的零个或一个实例。
This document uses the RADIUS [RFC2865] namespace; see <http://www.iana.org/assignments/radius-types>. Per this specification, RADIUS attribute types have been assigned for the following attributes:
本文档使用RADIUS[RFC2865]名称空间；看<http://www.iana.org/assignments/radius-types>. 根据本规范，已为以下属性指定半径属性类型：
Attribute Type
========= ====
Allowed-Called-Station-Id 174
EAP-Peer-Id 175
EAP-Server-Id 176
Mobility-Domain-Id 177
Preauth-Timeout 178
Network-Id-Name 179
EAPoL-Announcement 180
WLAN-HESSID 181
WLAN-Venue-Info 182
WLAN-Venue-Language 183
WLAN-Venue-Name 184
WLAN-Reason-Code 185
WLAN-Pairwise-Cipher 186
WLAN-Group-Cipher 187
WLAN-AKM-Suite 188
WLAN-Group-Mgmt-Cipher 189
WLAN-RF-Band 190
Attribute Type
========= ====
Allowed-Called-Station-Id 174
EAP-Peer-Id 175
EAP-Server-Id 176
Mobility-Domain-Id 177
Preauth-Timeout 178
Network-Id-Name 179
EAPoL-Announcement 180
WLAN-HESSID 181
WLAN-Venue-Info 182
WLAN-Venue-Language 183
WLAN-Venue-Name 184
WLAN-Reason-Code 185
WLAN-Pairwise-Cipher 186
WLAN-Group-Cipher 187
WLAN-AKM-Suite 188
WLAN-Group-Mgmt-Cipher 189
WLAN-RF-Band 190
Since this specification relies entirely on values assigned by IEEE 802, no registries are established for maintenance by the IANA.
由于本规范完全依赖于IEEE 802指定的值，因此IANA未建立任何用于维护的注册表。
Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in IEEE 802 networks, it is vulnerable to all of the threats that are present in other RADIUS applications. For a discussion of these threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3579], [RFC3580], and [RFC5176]. In particular, when RADIUS traffic is sent in the clear, the attributes defined in this document can be obtained by an attacker
由于本文档描述了在IEEE 802网络中使用RADIUS进行身份验证、授权和记帐，因此它容易受到其他RADIUS应用程序中存在的所有威胁的攻击。有关这些威胁的讨论，请参见[RFC2607]、[RFC2865]、[RFC3162]、[RFC3579]、[RFC3580]和[RFC5176]。特别是，当以明文形式发送RADIUS流量时，攻击者可以获得本文档中定义的属性
snooping the exchange between the RADIUS client and server. As a result, RADIUS confidentiality is desirable; for a review of RADIUS security and crypto-agility requirements, see [RFC6421].
正在侦听RADIUS客户端和服务器之间的交换。因此，RADIUS保密性是可取的；有关RADIUS安全性和加密灵活性要求的审查，请参阅[RFC6421]。
While it is possible for a RADIUS server to make decisions on whether to accept or reject an Access-Request based on the values of the WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, WLAN-Group-Mgmt-Cipher, and WLAN-RF-Band Attributes, the value of doing this is limited. In general, an Access-Reject should not be necessary, except where Access Points and Stations are misconfigured so as to enable connections to be made with unacceptable values. Rather than rejecting access on an ongoing basis, users would be better served by fixing the misconfiguration.
虽然RADIUS服务器可以根据WLAN成对密码、WLAN组密码、WLAN AKM套件、WLAN组管理密码和WLAN RF频带属性的值来决定是否接受或拒绝访问请求，但这样做的价值是有限的。一般来说，不需要拒绝访问，除非访问点和站点配置错误，从而使连接具有不可接受的值。与其持续拒绝访问，不如修复错误配置，更好地服务于用户。
Where access does need to be rejected, the user should be provided with an indication of why the problem has occurred, or else they are likely to become frustrated. For example, if the values of the WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, or WLAN-Group-Mgmt-Cipher Attributes included in the Access-Request are not acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute with a value of 29 (Requested service rejected because of service provider ciphersuite or AKM requirement) SHOULD be returned in the Access-Reject. Similarly, if the value of the WLAN-RF-Band Attribute included in the Access-Request is not acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute with a value of 11 (Disassociated because the information in the Supported Channels element is unacceptable) SHOULD be returned in the Access-Reject.
如果确实需要拒绝访问，则应向用户提供问题发生原因的指示，否则他们可能会感到沮丧。例如，如果访问请求中包含的WLAN成对密码、WLAN组密码、WLAN AKM套件或WLAN组管理密码属性的值不被RADIUS服务器接受，则值为29的WLAN原因码属性（由于服务提供商密码套件或AKM要求，请求的服务被拒绝）应在访问拒绝中返回。类似地，如果RADIUS服务器不接受访问请求中包含的WLAN RF频带属性的值，则应在访问拒绝中返回值为11的WLAN原因码属性（由于支持的通道元素中的信息不可接受而解除关联）。
[IEEE-802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture. Amendment 2: Registration of Object Identifiers", ANSI/IEEE Std 802, 2001.
[IEEE-802]IEEE，“局域网和城域网的IEEE标准：概述和体系结构。修改件2：对象标识符的注册”，ANSI/IEEE标准802，2001年。
[IEEE-802.11] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2012, 2012.
[IEEE-802.11]IEEE，“IEEE信息技术标准-系统间电信和信息交换-局域网和城域网-特定要求第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.11-2012。
[IEEE-802.11ad] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment 3: Enhancements for Very High Throughput in the 60 GHz Band", IEEE Std 802.11ad-2012, 2012.
[IEEE-802.11ad]IEEE，“IEEE信息技术标准-系统间电信和信息交换-局域网和城域网-特定要求第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范，修改件3：60GHz频段超高吞吐量的增强”，IEEE标准802.11ad-2012，2012。
[IEEE-802.1X] IEEE, "IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control", IEEE Std 802.1X-2010, February 2010.
[IEEE-802.1X]IEEE，“局域网和城域网的IEEE标准-基于端口的网络访问控制”，IEEE标准802.1X-2010，2010年2月。
[ISO-639] ISO, "Codes for the Representation of Names of Languages", ISO 639.
[ISO-639]ISO，“语言名称表示代码”，ISO 639。
[ISO-14962-1997] ISO, "Space data and information transfer systems - ASCII encoded English", 1997.
[ISO-14962-1997]ISO，“空间数据和信息传输系统——ASCII编码英语”，1997年。
[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月。
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072]Eronen，P.，Ed.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，2005年8月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247]Aboba，B.，Simon，D.，和P.Eronen，“可扩展认证协议（EAP）密钥管理框架”，RFC 5247，2008年8月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607]Aboba，B.和J.Vollbrecht，“漫游中的代理链接和策略实施”，RFC 2607，1999年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162]Aboba，B.，Zorn，G.和D.Mitton，“RADIUS和IPv6”，RFC 3162，2001年8月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580]Congdon，P.，Aboba，B.，Smith，A.，Zorn，G.，和J.Roese，“IEEE 802.1X远程认证拨入用户服务（RADIUS）使用指南”，RFC 35802003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 3748，2004年6月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5176]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 51762008年1月。
[RFC6421] Nelson, D., Ed., "Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)", RFC 6421, November 2011.
[RFC6421]Nelson，D.，Ed.“远程认证拨入用户服务（RADIUS）的加密灵活性要求”，RFC 64212011年11月。
The authors would like to acknowledge Maximilian Riegel, Dorothy Stanley, Yoshihiro Ohba, and the contributors to the IEEE 802.1 and IEEE 802.11 reviews of this document, for useful discussions.
作者希望感谢Maximilian Riegel、Dorothy Stanley、Yoshihiro Ohba以及本文件IEEE 802.1和IEEE 802.11评审的贡献者，以进行有益的讨论。
Authors' Addresses
作者地址
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
伯纳德·阿博巴微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: bernard_aboba@hotmail.com
EMail: bernard_aboba@hotmail.com
Jouni Malinen
朱尼·马利宁
EMail: j@w1.fi
EMail: j@w1.fi
Paul Congdon Tallac Networks 6528 Lonetree Blvd. Rocklin, CA 95765 US
保罗·康登·塔拉克网络公司，伦敦大道6528号。罗克林，加利福尼亚州95765美国
Phone: +19167576350
EMail: paul.congdon@tallac.com
Phone: +19167576350
EMail: paul.congdon@tallac.com
Joseph Salowey Cisco Systems
约瑟夫·萨洛维思科系统公司
EMail: jsalowey@cisco.com
EMail: jsalowey@cisco.com
Mark Jones Azuca Systems
马克·琼斯·阿祖卡系统公司
EMail: mark@azu.ca
EMail: mark@azu.ca