Network Working Group P. Congdon
Request for Comments: 4675 M. Sanchez
Category: Standards Track Hewlett-Packard Company
B. Aboba
Microsoft Corporation
September 2006
Network Working Group P. Congdon
Request for Comments: 4675 M. Sanchez
Category: Standards Track Hewlett-Packard Company
B. Aboba
Microsoft Corporation
September 2006
RADIUS Attributes for Virtual LAN and Priority Support
用于虚拟LAN和优先级支持的RADIUS属性
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document proposes additional Remote Authentication Dial-In User Service (RADIUS) attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks. These attributes are usable within either RADIUS or Diameter.
本文档提出了用于动态虚拟LAN分配和优先级排序的附加远程身份验证拨入用户服务（RADIUS）属性，用于提供对IEEE 802局域网的访问。这些属性在半径或直径范围内都可用。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Requirements Language ......................................3
1.3. Attribute Interpretation ...................................3
2. Attributes ......................................................4
2.1. Egress-VLANID ..............................................4
2.2. Ingress-Filters ............................................6
2.3. Egress-VLAN-Name ...........................................7
2.4. User-Priority-Table ........................................8
3. Table of Attributes ............................................10
4. Diameter Considerations ........................................10
5. IANA Considerations ............................................11
6. Security Considerations ........................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................13
8. Acknowledgements ...............................................13
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Requirements Language ......................................3
1.3. Attribute Interpretation ...................................3
2. Attributes ......................................................4
2.1. Egress-VLANID ..............................................4
2.2. Ingress-Filters ............................................6
2.3. Egress-VLAN-Name ...........................................7
2.4. User-Priority-Table ........................................8
3. Table of Attributes ............................................10
4. Diameter Considerations ........................................10
5. IANA Considerations ............................................11
6. Security Considerations ........................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................13
8. Acknowledgements ...............................................13
This document describes Virtual LAN (VLAN) and re-prioritization attributes that may prove useful for provisioning of access to IEEE 802 local area networks [IEEE-802] with the Remote Authentication Dial-In User Service (RADIUS) or Diameter.
本文档描述了虚拟LAN（VLAN）和重排序属性，这些属性可能被证明对通过远程身份验证拨入用户服务（RADIUS）或Diameter提供对IEEE 802局域网[IEEE-802]的访问非常有用。
While [RFC3580] enables support for VLAN assignment based on the tunnel attributes defined in [RFC2868], it does not provide support for a more complete set of VLAN functionality as defined by [IEEE-802.1Q]. The attributes defined in this document provide support within RADIUS and Diameter analogous to the management variables supported in [IEEE-802.1Q] and MIB objects defined in [RFC4363]. In addition, this document enables support for a wider range of [IEEE-802.1X] configurations.
虽然[RFC3580]支持基于[RFC2868]中定义的隧道属性的VLAN分配，但它不支持[IEEE-802.1Q]中定义的更完整的VLAN功能集。本文档中定义的属性在半径和直径范围内提供支持，类似于[IEEE-802.1Q]中支持的管理变量和[RFC4363]中定义的MIB对象。此外，本文档支持更广泛的[IEEE-802.1X]配置。
This document uses the following terms:
本文件使用以下术语：
Network Access Server (NAS) A device that provides an access service for a user to a network. Also known as a RADIUS client.
网络访问服务器（NAS）为用户提供网络访问服务的设备。也称为RADIUS客户端。
RADIUS server A RADIUS authentication server is an entity that provides an authentication service to a NAS.
RADIUS服务器RADIUS身份验证服务器是向NAS提供身份验证服务的实体。
RADIUS proxy A RADIUS proxy acts as an authentication server to the NAS, and a RADIUS client to the RADIUS server.
RADIUS代理RADIUS代理充当NAS的身份验证服务器，以及RADIUS服务器的RADIUS客户端。
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 attributes described in this document apply to a single instance of a NAS port, or more specifically an IEEE 802.1Q bridge port. [IEEE-802.1Q], [IEEE-802.1D], and [IEEE-802.1X] do not recognize finer management granularity than "per port". In some cases, such as with IEEE 802.11 wireless LANs, the concept of a "virtual port" is used in place of the physical port. Such virtual ports are typically based on security associations and scoped by station, or Media Access Control (MAC) address.
本文档中描述的属性适用于NAS端口的单个实例，或者更具体地说，适用于IEEE 802.1Q网桥端口。[IEEE-802.1Q]、[IEEE-802.1D]和[IEEE-802.1X]无法识别比“每个端口”更精细的管理粒度。在某些情况下，如IEEE 802.11无线局域网，使用“虚拟端口”的概念代替物理端口。此类虚拟端口通常基于安全关联，并根据站点或媒体访问控制（MAC）地址确定范围。
The attributes defined in this document are applied on a per-user basis and it is expected that there is a single user per port; however, in some cases that port may be a "virtual port". If a NAS implementation conforming to this document supports "virtual ports", it may be possible to provision those "virtual ports" with unique values of the attributes described in this document, allowing multiple users sharing the same physical port to each have a unique set of authorization parameters.
本文件中定义的属性以每个用户为基础应用，预计每个端口只有一个用户；但是，在某些情况下，该端口可能是“虚拟端口”。如果符合本文档要求的NAS实施支持“虚拟端口”，则可以为这些“虚拟端口”提供本文档中所述属性的唯一值，从而允许共享同一物理端口的多个用户各自拥有一组唯一的授权参数。
If a NAS conforming to this specification receives an Access-Accept packet containing an attribute defined in this document that it cannot apply, it MUST act as though it had received an Access-Reject. [RFC3576] requires that a NAS receiving a Change of Authorization Request (CoA-Request) reply with a CoA-NAK if the Request contains an unsupported attribute. It is recommended that an Error-Cause attribute with the value set to "Unsupported Attribute" (401) be included in the CoA-NAK. As noted in [RFC3576], authorization changes are atomic so that this situation does not result in session termination and the preexisting configuration remains unchanged. As a result, no accounting packets should be generated.
如果符合本规范的NAS接收到一个访问接受数据包，该数据包包含本文档中定义的一个它无法应用的属性，则它必须像接收到访问拒绝一样工作。[RFC3576]要求接收授权变更请求（CoA请求）的NAS在请求包含不受支持的属性时使用CoA NAK进行回复。建议在CoA NAK中包含一个值设置为“Unsupported attribute”（401）的错误原因属性。如[RFC3576]所述，授权更改是原子性的，因此这种情况不会导致会话终止，并且先前存在的配置保持不变。因此，不应生成记帐数据包。
Description
描述
The Egress-VLANID attribute represents an allowed IEEE 802 Egress VLANID for this port, indicating if the VLANID is allowed for tagged or untagged frames as well as the VLANID.
出口VLANID属性表示此端口允许的IEEE 802出口VLANID，指示VLANID是否允许用于标记或未标记的帧以及VLANID。
As defined in [RFC3580], the VLAN assigned via tunnel attributes applies both to the ingress VLANID for untagged packets (known as the PVID) and the egress VLANID for untagged packets. In contrast, the Egress-VLANID attribute configures only the egress VLANID for either tagged or untagged packets. The Egress-VLANID attribute MAY be included in the same RADIUS packet as [RFC3580] tunnel attributes; however, the Egress-VLANID attribute is not necessary if it is being used to configure the same untagged VLANID included in tunnel attributes. To configure an untagged VLAN for both ingress and egress, the tunnel attributes of [RFC3580] MUST be used.
如[RFC3580]中所定义，通过隧道属性分配的VLAN既适用于未标记数据包的入口VLANID（称为PVID），也适用于未标记数据包的出口VLANID。相反，出口VLANID属性仅为标记或未标记的数据包配置出口VLANID。出口VLANID属性可以包括在与[RFC3580]隧道属性相同的RADIUS分组中；但是，如果使用出口VLANID属性配置隧道属性中包含的相同未标记VLANID，则不需要出口VLANID属性。要为入口和出口配置未标记的VLAN，必须使用[RFC3580]的隧道属性。
Multiple Egress-VLANID attributes MAY be included in Access-Request, Access-Accept, CoA-Request, or Accounting-Request packets; this attribute MUST NOT be sent within an Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK,
多个出口VLANID属性可包括在接入请求、接入接受、CoA请求或记帐请求分组中；此属性不得在访问质询、访问拒绝、断开连接请求、断开连接确认、，
Disconnect-NAK, CoA-ACK, or CoA-NAK. Each attribute adds the specified VLAN to the list of allowed egress VLANs for the port.
断开NAK、CoA ACK或CoA NAK。每个属性都将指定的VLAN添加到端口的允许出口VLAN列表中。
The Egress-VLANID attribute is shown below. The fields are transmitted from left to right:
出口VLANID属性如下所示。字段从左向右传输：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
类型
56
56
Length
长
6
6.
Value
价值
The Value field is four octets. The format is described below:
值字段是四个八位字节。格式描述如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Indic. | Pad | VLANID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Indic. | Pad | VLANID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tag Indication field is one octet in length and indicates whether the frames on the VLAN are tagged (0x31) or untagged (0x32). The Pad field is 12 bits in length and MUST be 0 (zero). The VLANID is 12 bits in length and contains the [IEEE-802.1Q] VLAN VID value.
标记指示字段的长度为一个八位字节，指示VLAN上的帧是标记的（0x31）还是未标记的（0x32）。Pad字段的长度为12位，必须为0（零）。VLANID的长度为12位，包含[IEEE-802.1Q]VLAN VID值。
Description
描述
The Ingress-Filters attribute corresponds to the Ingress Filter per-port variable defined in [IEEE-802.1Q] clause 8.4.5. When the attribute has the value "Enabled", the set of VLANs that are allowed to ingress a port must match the set of VLANs that are allowed to egress a port. Only a single Ingress-Filters attribute MAY be sent within an Access-Request, Access-Accept, CoA-Request, or Accounting-Request packet; this attribute MUST NOT be sent within an Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK.
入口过滤器属性对应于[IEEE-802.1Q]第8.4.5条中定义的每个端口的入口过滤器变量。当该属性的值为“Enabled”时，允许进入端口的VLAN集必须与允许离开端口的VLAN集匹配。在访问请求、访问接受、CoA请求或记帐请求包中只能发送单个入口过滤器属性；此属性不得在访问质询、访问拒绝、断开连接请求、断开连接确认、断开连接NAK、CoA确认或CoA NAK内发送。
The Ingress-Filters attribute is shown below. The fields are transmitted from left to right:
入口过滤器属性如下所示。字段从左向右传输：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | 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
类型
57
57
Length
长
6
6.
Value
价值
The Value field is four octets. Supported values include:
值字段是四个八位字节。支持的值包括：
1 - Enabled 2 - Disabled
1-启用2-禁用
Description
描述
Clause 12.10.2.1.3 (a) in [IEEE-802.1Q] describes the administratively assigned VLAN Name associated with a VLAN-ID defined within an IEEE 802.1Q bridge. The Egress-VLAN-Name attribute represents an allowed VLAN for this port. It is similar to the Egress-VLANID attribute, except that the VLAN-ID itself is not specified or known; rather, the VLAN name is used to identify the VLAN within the system.
[IEEE-802.1Q]中的第12.10.2.1.3（a）条描述了与IEEE 802.1Q网桥中定义的VLAN-ID相关联的管理分配VLAN名称。出口VLAN名称属性表示此端口允许的VLAN。它类似于出口VLANID属性，只是VLAN-ID本身未指定或未知；相反，VLAN名称用于标识系统内的VLAN。
The tunnel attributes described in [RFC3580] and the Egress-VLAN-Name attribute both can be used to configure the egress VLAN for untagged packets. These attributes can be used concurrently and MAY appear in the same RADIUS packet. When they do appear concurrently, the list of allowed VLANs is the concatenation of the Egress-VLAN-Name and the Tunnel-Private-Group-ID (81) attributes. The Egress-VLAN-Name attribute does not alter the ingress VLAN for untagged traffic on a port (also known as the PVID). The tunnel attributes from [RFC3580] should be relied upon instead to set the PVID.
[RFC3580]中描述的隧道属性和出口VLAN名称属性都可用于为未标记的数据包配置出口VLAN。这些属性可以同时使用，并且可能出现在相同的RADIUS数据包中。当它们同时出现时，允许的VLAN列表是出口VLAN名称和隧道专用组ID（81）属性的串联。出口VLAN名称属性不会更改端口（也称为PVID）上未标记流量的入口VLAN。应该依赖[RFC3580]中的隧道属性来设置PVID。
The Egress-VLAN-Name attribute contains two parts; the first part indicates if frames on the VLAN for this port are to be represented in tagged or untagged format, the second part is the VLAN name.
出口VLAN名称属性包含两部分；第一部分指示此端口的VLAN上的帧是否以标记或未标记格式表示，第二部分是VLAN名称。
Multiple Egress-VLAN-Name attributes MAY be included within an Access-Request, Access-Accept, CoA-Request, or Accounting-Request packet; this attribute MUST NOT be sent within an Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK. Each attribute adds the named VLAN to the list of allowed egress VLANs for the port. The Egress-VLAN-Name attribute is shown below. The fields are transmitted from left to right:
多个出口VLAN名称属性可包括在接入请求、接入接受、CoA请求或记帐请求分组中；此属性不得在访问质询、访问拒绝、断开连接请求、断开连接确认、断开连接NAK、CoA确认或CoA NAK内发送。每个属性都将命名的VLAN添加到端口的允许出口VLAN列表中。出口VLAN名称属性如下所示。字段从左向右传输：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag Indic. | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag Indic. | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
58
58
Length
长
>=4
>=4
Tag Indication
标签指示
The Tag Indication field is one octet in length and indicates whether the frames on the VLAN are tagged (0x31, ASCII '1') or untagged (0x32, ASCII '2'). These values were chosen so as to make them easier for users to enter.
标记指示字段的长度为一个八位字节，指示VLAN上的帧是标记的（0x31，ASCII“1”）还是未标记的（0x32，ASCII“2”）。选择这些值是为了方便用户输入。
String
一串
The String field is at least one octet in length and contains the VLAN Name as defined in [IEEE-802.1Q] clause 12.10.2.1.3 (a). [RFC3629] UTF-8 encoded 10646 characters are RECOMMENDED, but a robust implementation SHOULD support the field as undistinguished octets.
字符串字段的长度至少为一个八位字节，包含[IEEE-802.1Q]第12.10.2.1.3（a）条中定义的VLAN名称。[RFC3629]建议使用UTF-8编码的10646个字符，但稳健的实现应支持字段为无差别的八位字节。
Description
描述
[IEEE-802.1D] clause 7.5.1 discusses how to regenerate (or re-map) user priority on frames received at a port. This per-port configuration enables a bridge to cause the priority of received traffic at a port to be mapped to a particular priority. [IEEE-802.1D] clause 6.3.9 describes the use of remapping:
[IEEE-802.1D]第7.5.1条讨论了如何在端口接收的帧上重新生成（或重新映射）用户优先级。这种每端口配置使网桥能够使端口处接收的流量的优先级映射到特定优先级。[IEEE-802.1D]第6.3.9条描述了重映射的使用：
The ability to signal user priority in IEEE 802 LANs allows user priority to be carried with end-to-end significance across a Bridged Local Area Network. This, coupled with a consistent approach to the mapping of user priority to traffic classes and of user priority to access_priority, allows consistent use of priority information, according to the capabilities of the Bridges and MACs in the transmission path...
IEEE 802 LAN中的用户优先级信号功能允许用户优先级在桥接局域网中具有端到端的重要性。这与将用户优先级映射到流量类别以及将用户优先级映射到访问优先级的一致性方法相结合，允许根据传输路径中网桥和MAC的能力一致地使用优先级信息。。。
Under normal circumstances, user priority is not modified in transit through the relay function of a Bridge; however, network management can control how user priority is propagated. Table 7-1 provides the ability to map incoming user priority values on a per-Port basis. By default, the regenerated user priority is identical to the incoming user priority.
在正常情况下，用户优先级不会在传输过程中通过网桥的中继功能进行修改；但是，网络管理可以控制用户优先级的传播方式。表7-1提供了基于每个端口映射传入用户优先级值的能力。默认情况下，重新生成的用户优先级与传入的用户优先级相同。
This attribute represents the IEEE 802 prioritization that will be applied to frames arriving at this port. There are eight possible user priorities, according to the [IEEE-802] standard. [IEEE-802.1D] clause 14.6.2.3.3 specifies the regeneration table
此属性表示将应用于到达此端口的帧的IEEE 802优先级。根据[IEEE-802]标准，有八种可能的用户优先级。[IEEE-802.1D]第14.6.2.3.3条规定了再生表
as 8 values, each an integer in the range 0-7. The management variables are described in clause 14.6.2.2.
作为8个值，每个值都是0-7范围内的整数。管理变量见第14.6.2.2条。
A single User-Priority-Table attribute MAY be included in an Access-Accept or CoA-Request packet; this attribute MUST NOT be sent within an Access-Request, Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, CoA-NAK or Accounting-Request. Since the regeneration table is only maintained by a bridge conforming to [IEEE-802.1D], this attribute should only be sent to a RADIUS client supporting that specification.
单个用户优先级表属性可包括在接入接受或CoA请求分组中；此属性不得在访问请求、访问质询、访问拒绝、断开连接请求、断开连接确认、断开连接NAK、CoA确认、CoA NAK或记帐请求中发送。由于再生表仅由符合[IEEE-802.1D]的网桥维护，因此该属性应仅发送给支持该规范的RADIUS客户端。
The User-Priority-Table attribute is shown below. The fields are transmitted from left to right:
用户优先级表属性如下所示。字段从左向右传输：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
59
59
Length
长
10
10
String
一串
The String field is 8 octets in length and includes a table that maps the incoming priority (if it is set -- the default is 0) into one of eight regenerated priorities. The first octet maps to incoming priority 0, the second octet to incoming priority 1, etc. The values in each octet represent the regenerated priority of the frame.
字符串字段的长度为8个八位字节，并包含一个表，该表将传入优先级（如果设置了-默认值为0）映射到八个重新生成的优先级中的一个。第一个八位组映射到传入优先级0，第二个八位组映射到传入优先级1，等等。每个八位组中的值表示帧的重新生成优先级。
It is thus possible to either remap incoming priorities to more appropriate values; to honor the incoming priorities; or to override any incoming priorities, forcing them to all map to a single chosen priority.
因此，可以将传入的优先级重新映射到更合适的值；尊重即将到来的优先事项；或者覆盖任何传入的优先级，强制它们全部映射到一个选定的优先级。
The [IEEE-802.1D] specification, Annex G, provides a useful description of traffic type - traffic class mappings.
[IEEE-802.1D]规范附录G提供了流量类型-流量类别映射的有用描述。
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- CoA- Acct-
Request Accept Reject Challenge Req Req # Attribute
0+ 0+ 0 0 0+ 0+ 56 Egress-VLANID
0-1 0-1 0 0 0-1 0-1 57 Ingress-Filters
0+ 0+ 0 0 0+ 0+ 58 Egress-VLAN-Name
0 0-1 0 0 0-1 0 59 User-Priority-Table
Access- Access- Access- Access- CoA- Acct-
Request Accept Reject Challenge Req Req # Attribute
0+ 0+ 0 0 0+ 0+ 56 Egress-VLANID
0-1 0-1 0 0 0-1 0-1 57 Ingress-Filters
0+ 0+ 0 0 0+ 0+ 58 Egress-VLAN-Name
0 0-1 0 0 0-1 0 59 User-Priority-Table
The following table defines the meaning of the above table entries.
下表定义了上述表格条目的含义。
0 This attribute MUST NOT be present in the 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数据包中可能存在该属性的零个或一个实例。
When used in Diameter, the attributes defined in this specification can be used as Diameter attribute-value pair (AVPs) from the Code space 1-255 (RADIUS attribute compatibility space). No additional Diameter Code values are therefore allocated. The data types and flag rules for the attributes are as follows:
在Diameter中使用时，本规范中定义的属性可以用作代码空间1-255（RADIUS属性兼容空间）中的Diameter属性值对（AVPs）。因此，不分配其他直径代码值。属性的数据类型和标记规则如下所示：
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
| | |SHLD| MUST| |
Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr|
-------------------------------|----+-----+----+-----|----|
Egress-VLANID OctetString| M | P | | V | Y |
Ingress-Filters Enumerated | M | P | | V | Y |
Egress-VLAN-Name UTF8String | M | P | | V | Y |
User-Priority-Table OctetString| M | P | | V | Y |
-------------------------------|----+-----+----+-----|----|
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
| | |SHLD| MUST| |
Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr|
-------------------------------|----+-----+----+-----|----|
Egress-VLANID OctetString| M | P | | V | Y |
Ingress-Filters Enumerated | M | P | | V | Y |
Egress-VLAN-Name UTF8String | M | P | | V | Y |
User-Priority-Table OctetString| M | P | | V | Y |
-------------------------------|----+-----+----+-----|----|
The attributes in this specification have no special translation requirements for Diameter to RADIUS or RADIUS to Diameter gateways; they are copied as is, except for changes relating to headers, alignment, and padding. See also [RFC3588] Section 4.1 and [RFC4005] Section 9.
本规范中的属性对于直径到半径或半径到直径网关没有特殊的转换要求；它们按原样复制，但与标题、对齐和填充相关的更改除外。另见[RFC3588]第4.1节和[RFC4005]第9节。
What this specification says about the applicability of the attributes for RADIUS Access-Request packets applies in Diameter to AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072]. What is said about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or Diameter-EAP-Answer [RFC4072] with Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH.
本规范所述的RADIUS访问请求数据包属性的适用性适用于Diameter中的AA请求[RFC4005]或Diameter EAP请求[RFC4072]。关于访问质询的内容在Diameter中适用于AA应答[RFC4005]或Diameter EAP应答[RFC4072]，结果代码AVP设置为Diameter\U MULTI\U ROUND\U AUTH。
What is said about Access-Accept applies in Diameter to AA-Answer or Diameter-EAP-Answer messages that indicate success. Similarly, what is said about RADIUS Access-Reject packets applies in Diameter to AA-Answer or Diameter-EAP-Answer messages that indicate failure.
关于Access Accept的内容在Diameter中适用于表示成功的AA应答或Diameter EAP应答消息。类似地，关于RADIUS访问拒绝数据包的内容在Diameter中适用于指示失败的AA应答或Diameter EAP应答消息。
What is said about COA-Request applies in Diameter to Re-Auth-Request [RFC4005].
有关COA请求的说明适用于重新验证请求[RFC4005]。
What is said about Accounting-Request applies to Diameter Accounting-Request [RFC4005] as well.
关于记帐请求的内容也适用于Diameter记帐请求[RFC4005]。
This specification does not create any new registries.
本规范不创建任何新的注册表。
This document uses the RADIUS [RFC2865] namespace; see <http://www.iana.org/assignments/radius-types>. Allocation of four updates for the section "RADIUS Attribute Types" has been made by the IANA. The RADIUS attributes are:
本文档使用RADIUS[RFC2865]名称空间；看<http://www.iana.org/assignments/radius-types>. IANA为“半径属性类型”部分分配了四次更新。半径属性包括：
56 - Egress-VLANID 57 - Ingress-Filters 58 - Egress-VLAN-Name 59 - User-Priority-Table
56-出口VLANID 57-入口过滤器58-出口VLAN名称59-用户优先级表
This specification describes the use of RADIUS and Diameter for purposes of authentication, authorization, and accounting in IEEE 802 local area networks. RADIUS threats and security issues for this application are described in [RFC3579] and [RFC3580]; security issues encountered in roaming are described in [RFC2607]. For Diameter, the security issues relating to this application are described in [RFC4005] and [RFC4072].
本规范描述了在IEEE 802局域网中使用半径和直径进行身份验证、授权和计费。[RFC3579]和[RFC3580]中描述了此应用程序的RADIUS威胁和安全问题；[RFC2607]中描述了漫游中遇到的安全问题。对于Diameter，与此应用程序相关的安全问题在[RFC4005]和[RFC4072]中进行了描述。
This document specifies new attributes that can be included in existing RADIUS packets, which are protected as described in [RFC3579] and [RFC3576]. In Diameter, the attributes are protected as specified in [RFC3588]. See those documents for a more detailed description.
本文档指定了可包含在现有RADIUS数据包中的新属性，这些数据包受[RFC3579]和[RFC3576]中所述的保护。按照[RFC3588]中的规定，在直径方面，属性受到保护。有关更详细的说明，请参阅这些文档。
The security mechanisms supported in RADIUS and Diameter are focused on preventing an attacker from spoofing packets or modifying packets in transit. They do not prevent an authorized RADIUS/Diameter server or proxy from inserting attributes with malicious intent.
RADIUS和Diameter中支持的安全机制主要用于防止攻击者欺骗数据包或修改传输中的数据包。它们不能防止授权的RADIUS/Diameter服务器或代理插入恶意属性。
VLAN attributes sent by a RADIUS/Diameter server or proxy may enable access to unauthorized VLANs. These vulnerabilities can be limited by performing authorization checks at the NAS. For example, a NAS can be configured to accept only certain VLANIDs from a given RADIUS/Diameter server/proxy.
RADIUS/Diameter服务器或代理发送的VLAN属性可能允许访问未经授权的VLAN。可以通过在NAS上执行授权检查来限制这些漏洞。例如，NAS可以配置为仅接受来自给定RADIUS/Diameter服务器/代理的特定VLANID。
Similarly, an attacker gaining control of a RADIUS/Diameter server or proxy can modify the user priority table, causing either degradation of quality of service (by downgrading user priority of frames arriving at a port), or denial of service (by raising the level of priority of traffic at multiple ports of a device, oversubscribing the switch or link capabilities).
类似地，获得RADIUS/Diameter服务器或代理控制权的攻击者可以修改用户优先级表，从而导致服务质量下降（通过降低到达端口的帧的用户优先级）或拒绝服务（通过提高设备多个端口的流量优先级，超额订阅交换机或链路功能）。
[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月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4363] Levi, D. and D. Harrington, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions", RFC 4363, January 2006.
[RFC4363]Levi，D.和D.Harrington，“具有流量类、多播过滤和虚拟LAN扩展的网桥的托管对象定义”，RFC 4363，2006年1月。
[IEEE-802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE-802]IEEE局域网和城域网标准：概述和体系结构，ANSI/IEEE标准802，1990年。
[IEEE-802.1D] IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges, IEEE Std 802.1D-2004, June 2004.
[IEEE-802.1D]IEEE局域网和城域网标准：媒体访问控制（MAC）网桥，IEEE标准802.1D-2004，2004年6月。
[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q-2003, January 2003.
[IEEE-802.1Q]IEEE局域网和城域网标准：虚拟桥接局域网标准草案，P802.1Q-2003，2003年1月。
[IEEE-802.1X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2004, December 2004.
[IEEE-802.1X]IEEE局域网和城域网标准：基于端口的网络访问控制，IEEE标准802.1X-2004，2004年12月。
[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月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868]Zorn，G.，Leifer，D.，Rubens，A.，Shriver，J.，Holdrege，M.，和I.Goyret，“隧道协议支持的半径属性”，RFC 28682000年6月。
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
[RFC3576]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 35762003年7月。
[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月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005]Calhoun，P.，Zorn，G.，Spence，D.，和D.Mitton，“Diameter网络访问服务器应用”，RFC 4005，2005年8月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072]Eronen，P.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，2005年8月。
The authors would like to acknowledge Joseph Salowey of Cisco, David Nelson of Enterasys, Chuck Black of Hewlett-Packard, and Ashwin Palekar of Microsoft.
作者要感谢思科的约瑟夫·萨洛维、Enterasys的大卫·纳尔逊、惠普的查克·布莱克和微软的阿什温·帕莱卡。
Authors' Addresses
作者地址
Paul Congdon Hewlett-Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747
保罗·康登惠普公司惠普ProCurve Networking 8000 Foothills Blvd，加利福尼亚州罗斯维尔市南5662号，邮编95747
Phone: +1 916 785 5753
Fax: +1 916 785 8478
EMail: paul.congdon@hp.com
Phone: +1 916 785 5753
Fax: +1 916 785 8478
EMail: paul.congdon@hp.com
Mauricio Sanchez Hewlett-Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5559 Roseville, CA 95747
莫里西奥·桑切斯·惠普公司惠普ProCurve Networking 8000 Foothills Blvd，加利福尼亚州罗斯维尔市南5559号，邮编95747
Phone: +1 916 785 1910
Fax: +1 916 785 1815
EMail: mauricio.sanchez@hp.com
Phone: +1 916 785 1910
Fax: +1 916 785 1815
EMail: mauricio.sanchez@hp.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。