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
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for
improvements. Plea 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.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document propos additional Remote Authentication Dial-In Ur Service (RADIUS) attributes for dynamic Virtual LAN assignment and
prioritization, for u in provisioning of access to IEEE 802 local软件管家哪个好用
area networks. The attributes are usable within either RADIUS or
Diameter.
Congdon, et al. Standards Track [Page 1]
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. Ur-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)
Congdon, et al. Standards Track [Page 2]
1. Introduction
This document describes Virtual LAN (VLAN) and re-prioritization
attributes that may prove uful for provisioning of access to IEEE
802 local area networks [IEEE-802] with the Remote Authentication国防科技大学
Dial-In Ur Service (RADIUS) or Diameter.
While [RFC3580] enables support for VLAN assignment bad on the
tunnel attributes defined in [RFC2868], it does not provide support
for a more complete t 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.
1.1. Terminology
This document us the following terms:
Network Access Server (NAS)
A device that provides an access rvice for a ur to a
network. Also known as a RADIUS client.
RADIUS rver
A RADIUS authentication rver is an entity that provides an
authentication rvice to a NAS.
RADIUS proxy
A RADIUS proxy acts as an authentication rver to the NAS, and
a RADIUS client to the RADIUS rver.
1.2. Requirements Language
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].
1.3. Attribute Interpretation
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 cas, such as with IEEE 802.11 wireless LANs, the concept of a "virtual port" is
ud in place of the physical port. Such virtual ports are typically bad on curity associations and scoped by station, or Media Access Control (MAC) address.
资产评估师报考条件Congdon, et al. Standards Track [Page 3]
The attributes defined in this document are applied on a per-ur
basis and it is expected that there is a single ur per port;
however, in some cas that port may be a "virtual port". If a NAS
implementation conforming to this document supports "virtual ports", it may be possible to provision tho "virtual ports" with unique
values of the attributes described in this document, allowing
multiple urs sharing the same physical port to each have a unique
t of authorization parameters.
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-Cau
attribute with the value t 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 ssion termination and the preexisting configuration remains unchanged. As
a result, no accounting packets should be generated.
2. Attributes
2.1. Egress-VLANID
Description
The Egress-VLANID attribute reprents 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.
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 ud 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 ud.
Multiple Egress-VLANID attributes MAY be included in Access-
Request, Access-Accept, CoA-Request, or Accounting-Request
packets; this attribute MUST NOT be nt within an Access-
Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Congdon, et al. Standards Track [Page 4]
Disconnect-NAK, CoA-ACK, or CoA-NAK. Each attribute adds the
specified VLAN to the list of allowed egress VLANs for the port.
The Egress-VLANID 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
56
Length
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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.
Congdon, et al. Standards Track [Page 5]
2.2. Ingress-Filters
Description
The Ingress-Filters attribute corresponds to the Ingress Filter
per-port variable defined in [IEEE-802.1Q] clau 8.4.5. When the attribute has the value "Enabled", the t of VLANs that are
allowed to ingress a port must match the t of VLANs that are
allowed to egress a port. Only a single Ingress-Filters attribute MAY be nt within an Access-Request, Access-Accept, CoA-Request, or Accounting-Request packet; this attribute MUST NOT be nt
within an Access-Challenge, Access-Reject, Disconnect-Request,
Disconnect-ACK, Disconnect-NAK, CoA-ACK, or 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
57
Length
6
Value
The Value field is four octets. Supported values include:
1 - Enabled
2 - Disabled
Congdon, et al. Standards Track [Page 6]
