draft-ietf-radext-vlan-06.txt		rfc4675.txt
	Network Working Group Paul Congdon		Network Working Group P. Congdon
	INTERNET-DRAFT Mauricio Sanchez		Request for Comments: 4675 M. Sanchez
	Category: Proposed Standard Hewlett-Packard Company		Category: Standards Track Hewlett-Packard Company
	<draft-ietf-radext-vlan-06.txt> Bernard Aboba		B. Aboba
	11 June 2006 Microsoft Corporation		Microsoft Corporation
			September 2006
	RADIUS Attributes for Virtual LAN and Priority Support		RADIUS Attributes for Virtual LAN and Priority Support
	By submitting this Internet-Draft, each author represents that any		Status of This Memo
	applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 10, 2006.		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.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society 2006.		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document proposes additional RADIUS (Remote Authentication Dial		This document proposes additional Remote Authentication Dial-In User
	In User Service) attributes for dynamic Virtual LAN assignment and		Service (RADIUS) attributes for dynamic Virtual LAN assignment and
	prioritization, for use in provisioning of access to IEEE 802 local		prioritization, for use in provisioning of access to IEEE 802 local
	area networks. These attributes are usable within either RADIUS or		area networks. These attributes are usable within either RADIUS or
	Diameter.		Diameter.
	Table of Contents		Table of Contents
	1. Introduction .......................................... 3		1. Introduction ....................................................3
	1.1 Terminology ..................................... 3		1.1. Terminology ................................................3
	1.2 Requirements Language ........................... 3		1.2. Requirements Language ......................................3
	1.3 Attribute Interpretation ........................ 3		1.3. Attribute Interpretation ...................................3
	2. Attributes ............................................ 4		2. Attributes ......................................................4
	2.1 Egress-VLANID ................................... 4		2.1. Egress-VLANID ..............................................4
	2.2 Ingress-Filters ................................. 5		2.2. Ingress-Filters ............................................6
	2.3 Egress-VLAN-Name ................................ 6		2.3. Egress-VLAN-Name ...........................................7
	2.4 User-Priority-Table ............................. 8		2.4. User-Priority-Table ........................................8
	3. Table of Attributes ................................... 9		3. Table of Attributes ............................................10
	4. Diameter Considerations ............................... 10		4. Diameter Considerations ........................................10
	5. IANA Considerations ................................... 10		5. IANA Considerations ............................................11
	6. Security Considerations ............................... 11		6. Security Considerations ........................................11
	7. References ............................................ 12		7. References .....................................................12
	7.1 Normative References ............................ 12		7.1. Normative References ......................................12
	7.2 Informative References .......................... 12		7.2. Informative References ....................................13
	ACKNOWLEDGMENTS .............................................. 13		8. Acknowledgements ...............................................13
	AUTHORS' ADDRESSES ........................................... 13
	Intellectual Property Statement............................... 14
	Disclaimer of Validity........................................ 14
	Full Copyright Statement ..................................... 14
	1. Introduction		1. Introduction
	This document describes Virtual LAN (VLAN) and re-prioritization		This document describes Virtual LAN (VLAN) and re-prioritization
	attributes that may prove useful for provisioning of access to IEEE		attributes that may prove useful for provisioning of access to IEEE
	802 local area networks [IEEE-802] with the Remote Authentication		802 local area networks [IEEE-802] with the Remote Authentication
	Dialin User Service (RADIUS) or Diameter.		Dial-In User Service (RADIUS) or Diameter.
	While [RFC3580] enables support for VLAN assignment based on the		While [RFC3580] enables support for VLAN assignment based on the
	tunnel attributes defined in [RFC2868], it does not provide support		tunnel attributes defined in [RFC2868], it does not provide support
	for a more complete set of VLAN functionality as defined by		for a more complete set of VLAN functionality as defined by
	[IEEE-802.1Q]. The attributes defined in this document provide		[IEEE-802.1Q]. The attributes defined in this document provide
	support within RADIUS and Diameter analogous to the management		support within RADIUS and Diameter analogous to the management
	variables supported in [IEEE-802.1Q] and MIB objects defined in		variables supported in [IEEE-802.1Q] and MIB objects defined in
	[RFC4363]. In addition, this document enables support for a wider		[RFC4363]. In addition, this document enables support for a wider
	range of [IEEE-802.1X] configurations.		range of [IEEE-802.1X] configurations.
	1.1. Terminology		1.1. Terminology
	This document uses the following terms:		This document uses the following terms:
	Network Access Server (NAS)		Network Access Server (NAS)
	A device that provides an access service for a user to a network.		A device that provides an access service for a user to a
	Also known as a RADIUS client.		network. Also known as a RADIUS client.
	RADIUS server		RADIUS server
	A RADIUS authentication server is an entity that provides an		A RADIUS authentication server is an entity that provides an
	authentication service to a NAS.		authentication service to a NAS.
	RADIUS proxy		RADIUS proxy
	A RADIUS proxy acts as an authentication server to the NAS, and a		A RADIUS proxy acts as an authentication server to the NAS, and
	RADIUS client to the RADIUS server.		a RADIUS client to the RADIUS server.
	1.2. Requirements Language		1.2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.3. Attribute Interpretation		1.3. Attribute Interpretation
	The attributes described in this document apply to a single instance		The attributes described in this document apply to a single instance
	of a NAS port, or more specifically an IEEE 802.1Q bridge port.		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		[IEEE-802.1Q], [IEEE-802.1D], and [IEEE-802.1X] do not recognize
	management granularity than "per port". In some cases, such as with		finer management granularity than "per port". In some cases, such as
	IEEE 802.11 wireless LANs, the concept of a "virtual port" is used in		with IEEE 802.11 wireless LANs, the concept of a "virtual port" is
	place of the physical port. Such virtual ports are typically based		used in place of the physical port. Such virtual ports are typically
	on security associations and scoped by station, or MAC address.		based on security associations and scoped by station, or Media Access
			Control (MAC) address.
	The attributes defined in this document are applied on per user basis		The attributes defined in this document are applied on a per-user
	and it is expected that there is a single user per port; however in		basis and it is expected that there is a single user per port;
	some cases that port may be a "virtual port". If a NAS		however, in some cases that port may be a "virtual port". If a NAS
	implementation conforming to this document supports "virtual ports",		implementation conforming to this document supports "virtual ports",
	it may be possible to provision those "virtual ports" with unique		it may be possible to provision those "virtual ports" with unique
	values of the attributes described in this document, allowing		values of the attributes described in this document, allowing
	multiple users sharing the same physical port to each have a unique		multiple users sharing the same physical port to each have a unique
	set of authorization parameters.		set of authorization parameters.
	If a NAS conforming to this specification receives an Access-Accept		If a NAS conforming to this specification receives an Access-Accept
	packet containing an attribute defined in this document which it		packet containing an attribute defined in this document that it
	cannot apply, it MUST act as though it had received an Access-Reject.		cannot apply, it MUST act as though it had received an Access-Reject.
	[RFC3576] requires that a NAS receiving a Change of Authorization		[RFC3576] requires that a NAS receiving a Change of Authorization
	Request (CoA-Request) reply with a CoA-NAK if the Request contains an		Request (CoA-Request) reply with a CoA-NAK if the Request contains an
	unsupported attribute. It is recommended that an Error-Cause		unsupported attribute. It is recommended that an Error-Cause
	attribute with value set to "Unsupported Attribute" (401) be included		attribute with the value set to "Unsupported Attribute" (401) be
	in the CoA-NAK. As noted in [RFC3576], authorization changes are		included in the CoA-NAK. As noted in [RFC3576], authorization
	atomic so that this situation does not result in session termination		changes are atomic so that this situation does not result in session
	and the pre-existing configuration remains unchanged. As a result,		termination and the preexisting configuration remains unchanged. As
	no accounting packets should be generated.		a result, no accounting packets should be generated.
	2. Attributes		2. Attributes
	2.1. Egress-VLANID		2.1. Egress-VLANID
	Description		Description
	The Egress-VLANID attribute represents an allowed IEEE 802 Egress		The Egress-VLANID attribute represents an allowed IEEE 802 Egress
	VLANID for this port, indicating if the VLANID is allowed for		VLANID for this port, indicating if the VLANID is allowed for
	tagged or untagged frames as well as the VLANID.		tagged or untagged frames as well as the VLANID.
	As defined in [RFC3580], the VLAN assigned via tunnel attributes		As defined in [RFC3580], the VLAN assigned via tunnel attributes
	applies both to the ingress VLANID for untagged packets (known as		applies both to the ingress VLANID for untagged packets (known as
	the PVID) and the egress VLANID for untagged packets. In		the PVID) and the egress VLANID for untagged packets. In
	contrast, the Egress-VLANID attribute configures only the egress		contrast, the Egress-VLANID attribute configures only the egress
	VLANID for either tagged or untagged packets. The Egress-VLANID		VLANID for either tagged or untagged packets. The Egress-VLANID
	attribute MAY be included in the same RADIUS packet as [RFC3580]		attribute MAY be included in the same RADIUS packet as [RFC3580]
	tunnel attributes; however, the Egress-VLANID attribute is not		tunnel attributes; however, the Egress-VLANID attribute is not
	necessary if it is being used to configure the same untagged		necessary if it is being used to configure the same untagged
	VLANID included in tunnel attributes. To configure an untagged		VLANID included in tunnel attributes. To configure an untagged
	VLAN for both ingress and egress, the tunnel attrubutes of		VLAN for both ingress and egress, the tunnel attributes of
	[RFC3580] MUST be used.		[RFC3580] MUST be used.
	Multiple Egress-VLANID attributes MAY be included in Access-		Multiple Egress-VLANID attributes MAY be included in Access-
	Request, Access-Accept, CoA-Request or Accounting-Request packets;		Request, Access-Accept, CoA-Request, or Accounting-Request
	this attribute MUST NOT be sent within an Access-Challenge,		packets; this attribute MUST NOT be sent within an Access-
	Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK,		Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK,
	CoA-ACK or CoA-NAK. Each attribute adds the specified VLAN to the		Disconnect-NAK, CoA-ACK, or CoA-NAK. Each attribute adds the
	list of allowed egress VLANs for the port.		specified VLAN to the list of allowed egress VLANs for the port.
	The Egress-VLANID attribute is shown below. The fields are		The Egress-VLANID attribute is shown below. The fields are
	transmitted from left to right:		transmitted from left to right:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		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		| Type | Length | Value
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Value (cont) |		Value (cont) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	TBD		56
	Length		Length
	6		6
	Value		Value
	The Value field is four octets. The format is described below:		The Value field is four octets. The format is described below:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		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 |		| Tag Indic. | Pad | VLANID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Tag Indication field is one octet in length, and indicates		The Tag Indication field is one octet in length and indicates
	whether the frames on the VLAN are tagged (0x31) or untagged		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).		(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]		The VLANID is 12 bits in length and contains the [IEEE-802.1Q]
	VLAN VID value.		VLAN VID value.
	2.2. Ingress-Filters		2.2. Ingress-Filters
	Description		Description
	The Ingress-Filters attribute corresponds to the Ingress Filter		The Ingress-Filters attribute corresponds to the Ingress Filter
	per-port variable defined in [IEEE-802.1Q] clause 8.4.5. When the		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		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 ingress a port must match the set of VLANs that are
	allowed to egress a port. Only a single Ingress-Filters attribute		allowed to egress a port. Only a single Ingress-Filters attribute
	MAY be sent within an Access-Request, Access-Accept, CoA-Request		MAY be sent within an Access-Request, Access-Accept, CoA-Request,
	or Accounting-Request packet; this attribute MUST NOT be sent		or Accounting-Request packet; this attribute MUST NOT be sent
	within an Access-Challenge, Access-Reject, Disconnect-Request,		within an Access-Challenge, Access-Reject, Disconnect-Request,
	Disconnect-ACK, Disconnect-NAK, CoA-ACK or CoA-NAK.		Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK.
	The Ingress-Filters attribute is shown below. The fields are		The Ingress-Filters attribute is shown below. The fields are
	transmitted from left to right:		transmitted from left to right:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		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		| Type | Length | Value
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Value (cont) |		Value (cont) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	TBD		57
	Length		Length
	6		6
	Value		Value
	The Value field is four octets. Supported values include:		The Value field is four octets. Supported values include:
	1 - Enabled		1 - Enabled
	2 - Disabled		2 - Disabled
	2.3. Egress-VLAN-Name		2.3. Egress-VLAN-Name
	Description		Description
	Clause 12.10.2.1.3 (a) in [IEEE-8021.Q] describes the		Clause 12.10.2.1.3 (a) in [IEEE-802.1Q] describes the
	administratively assigned VLAN Name associated with a VLAN-ID		administratively assigned VLAN Name associated with a VLAN-ID
	defined within an IEEE 802.1Q bridge. The Egress-VLAN-Name		defined within an IEEE 802.1Q bridge. The Egress-VLAN-Name
	attribute represents an allowed VLAN for this port. It is similar		attribute represents an allowed VLAN for this port. It is similar
	to the Egress-VLANID attribute, except that the VLAN-ID itself is		to the Egress-VLANID attribute, except that the VLAN-ID itself is
	not specified or known; rather the VLAN name is used to identify		not specified or known; rather, the VLAN name is used to identify
	the VLAN within the system.		the VLAN within the system.
	The tunnel attributes described in [RFC3580] and the Egress-VLAN-		The tunnel attributes described in [RFC3580] and the Egress-VLAN-
	Name attribute both can be used to configure the egress VLAN for		Name attribute both can be used to configure the egress VLAN for
	untagged packets. These attributes can be used concurrently and		untagged packets. These attributes can be used concurrently and
	MAY appear in the same RADIUS packet. When they do appear		MAY appear in the same RADIUS packet. When they do appear
	concurrently, the list of allowed VLANs is the concatenation of		concurrently, the list of allowed VLANs is the concatenation of
	the Egress-VLAN-Name and the Tunnel-Private-Group-ID (81)		the Egress-VLAN-Name and the Tunnel-Private-Group-ID (81)
	attributes. The Egress-VLAN-Name attribute does not alter the		attributes. The Egress-VLAN-Name attribute does not alter the
	ingress VLAN for untagged traffic on a port (also known as the		ingress VLAN for untagged traffic on a port (also known as the
	PVID). The tunnel attributes from [RFC3580] should be relied upon		PVID). The tunnel attributes from [RFC3580] should be relied upon
	instead to set the PVID.		instead to set the PVID.
	The Egress-VLAN-Name attribute contains two parts; the first part		The Egress-VLAN-Name attribute contains two parts; the first part
	indicates if frames on the VLAN for this port are to be		indicates if frames on the VLAN for this port are to be
	represented in tagged or untagged format, the second part is the		represented in tagged or untagged format, the second part is the
	VLAN name.		VLAN name.
	Multiple Egress-VLAN-Name attributes MAY be included within an		Multiple Egress-VLAN-Name attributes MAY be included within an
	Access-Request, Access-Accept, CoA-Request or Accounting-Request		Access-Request, Access-Accept, CoA-Request, or Accounting-Request
	packet; this attribute MUST NOT be sent within an Access-		packet; this attribute MUST NOT be sent within an Access-
	Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK,		Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK,
	Disconnect-NAK, CoA-ACK or CoA-NAK. Each attribute adds the named		Disconnect-NAK, CoA-ACK, or CoA-NAK. Each attribute adds the
	VLAN to the list of allowed egress VLANs for the port. The		named VLAN to the list of allowed egress VLANs for the port. The
	Egress-VLAN-Name attribute is shown below. The fields are		Egress-VLAN-Name attribute is shown below. The fields are
	transmitted from left to right:		transmitted from left to right:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		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 | Length | Tag Indic. | String...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	TBD		58
	Length		Length
	>=4		>=4
	Tag Indication		Tag Indication
	The Tag Indication field is one octet in length, and indicates		The Tag Indication field is one octet in length and indicates
	whether the frames on the VLAN are tagged (0x31, ASCII '1') or		whether the frames on the VLAN are tagged (0x31, ASCII '1') or
	untagged (0x32, ASCII '2'). These values were chosen so as to		untagged (0x32, ASCII '2'). These values were chosen so as to
	make them easier for users to enter.		make them easier for users to enter.
	String		String
	The String field is at least one octet in length, and contains the		The String field is at least one octet in length and contains the
	the VLAN Name as defined in [IEEE-802.1Q] clause 12.10.2.1.3 (a).		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		[RFC3629] UTF-8 encoded 10646 characters are RECOMMENDED, but a
	robust implementation SHOULD support the field as undistinguished		robust implementation SHOULD support the field as undistinguished
	octets.		octets.
	2.4. User-Priority-Table		2.4. User-Priority-Table
	Description		Description
	[IEEE-802.1D] clause 7.5.1 discusses how to regenerate (or re-map)		[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		user priority on frames received at a port. This per-port
	skipping to change at page 9, line 17		skipping to change at page 9, line 31
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | String		| Type | Length | String
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	String		String
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	String |		String |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	TBD		59
	Length		Length
	10		10
	String		String
	The String field is 8 octets in length, and includes a table which		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		maps the incoming priority (if it is set -- the default is 0) into
	one of eight regenerated priorities. The first octet maps to		one of eight regenerated priorities. The first octet maps to
	incoming priority 0, the second octet to incoming priority 1, etc.		incoming priority 0, the second octet to incoming priority 1, etc.
	The values in each octet represent the regenerated priority of the		The values in each octet represent the regenerated priority of the
	frame.		frame.
	It is thus possible to either remap incoming priorities to more		It is thus possible to either remap incoming priorities to more
	appropriate values; to honor the incoming priorities; or to		appropriate values; to honor the incoming priorities; or to
	override any incoming priorities, forcing them to all map to a		override any incoming priorities, forcing them to all map to a
	single chosen priority.		single chosen priority.
	The [IEEE-8021.D] specification, Annex G, provides a useful		The [IEEE-802.1D] specification, Annex G, provides a useful
	description of traffic type - traffic class mappings.		description of traffic type - traffic class mappings.
	3. Table of Attributes		3. Table of Attributes
	The following table provides a guide to which attributes may be found		The following table provides a guide to which attributes may be found
	in which kinds of packets, and in what quantity.		in which kinds of packets, and in what quantity.
	Access- Access- Access- Access- CoA- Acct-		Access- Access- Access- Access- CoA- Acct-
	Request Accept Reject Challenge Req Req # Attribute		Request Accept Reject Challenge Req Req # Attribute
	0+ 0+ 0 0 0+ 0+ TBD Egress-VLANID		0+ 0+ 0 0 0+ 0+ 56 Egress-VLANID
	0-1 0-1 0 0 0-1 0-1 TBD Ingress-Filters		0-1 0-1 0 0 0-1 0-1 57 Ingress-Filters
	0+ 0+ 0 0 0+ 0+ TBD Egress-VLAN-Name		0+ 0+ 0 0 0+ 0+ 58 Egress-VLAN-Name
	0 0-1 0 0 0-1 0 TBD User-Priority-Table		0 0-1 0 0 0-1 0 59 User-Priority-Table
	The following table defines the meaning of the above table entries.		The following table defines the meaning of the above table entries.
	0 This attribute MUST NOT be present in the packet.		0 This attribute MUST NOT be present in the packet.
	0+ Zero or more instances of this attribute MAY be		0+ Zero or more instances of this attribute MAY be
	present in the packet.		present in the packet.
	0-1 Zero or one instance of this attribute MAY be		0-1 Zero or one instance of this attribute MAY be
	present in the packet.		present in the packet.
	4. Diameter Considerations		4. Diameter Considerations
	When used in Diameter, the attributes defined in this specification		When used in Diameter, the attributes defined in this specification
	can be used as Diameter AVPs from the Code space 1-255 (RADIUS		can be used as Diameter attribute-value pair (AVPs) from the Code
	attribute compatibility space). No additional Diameter Code values		space 1-255 (RADIUS attribute compatibility space). No additional
	are therefore allocated. The data types and flag rules for the		Diameter Code values are therefore allocated. The data types and
	attributes are as follows:		flag rules for the attributes are as follows:
	+---------------------+		+---------------------+
	| AVP Flag rules |		| AVP Flag rules |
	|----+-----+----+-----|----+		|----+-----+----+-----|----+
	| | |SHLD| MUST| |		| | |SHLD| MUST| |
	Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr|		Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr|
	-------------------------------|----+-----+----+-----|----|		-------------------------------|----+-----+----+-----|----|
	Egress-VLANID OctetString| M | P | | V | Y |		Egress-VLANID OctetString| M | P | | V | Y |
	Ingress-Filters Enumerated | M | P | | V | Y |		Ingress-Filters Enumerated | M | P | | V | Y |
	Egress-VLAN-Name UTF8String | M | P | | V | Y |		Egress-VLAN-Name UTF8String | M | P | | V | Y |
	User-Priority-Table OctetString| M | P | | V | Y |		User-Priority-Table OctetString| M | P | | V | Y |
	-------------------------------|----+-----+----+-----|----|		-------------------------------|----+-----+----+-----|----|
	The attributes in this specification have no special translation		The attributes in this specification have no special translation
	requirements for Diameter to RADIUS or RADIUS to Diameter gateways;		requirements for Diameter to RADIUS or RADIUS to Diameter gateways;
	they are copied as is, except for changes relating to headers,		they are copied as is, except for changes relating to headers,
	alignment, and padding. See also [RFC 3588] Section 4.1 and [RFC		alignment, and padding. See also [RFC3588] Section 4.1 and [RFC4005]
	4005] Section 9.		Section 9.
	What this specification says about the applicability of the		What this specification says about the applicability of the
	attributes for RADIUS Access-Request packets applies in Diameter to		attributes for RADIUS Access-Request packets applies in Diameter to
	AA-Request [RFC 4005] or Diameter-EAP-Request [RFC 4072]. What is		AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072]. What is said
	said about Access-Challenge applies in Diameter to AA-Answer [RFC		about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or
	4005] or Diameter-EAP-Answer [RFC 4072] with Result-Code AVP set to		Diameter-EAP-Answer [RFC4072] with Result-Code AVP set to
	DIAMETER_MULTI_ROUND_AUTH.		DIAMETER_MULTI_ROUND_AUTH.
	What is said about Access-Accept applies in Diameter to AA-Answer or		What is said about Access-Accept applies in Diameter to AA-Answer or
	Diameter-EAP-Answer messages that indicate success. Similarly, what		Diameter-EAP-Answer messages that indicate success. Similarly, what
	is said about RADIUS Access-Reject packets applies in Diameter to AA-		is said about RADIUS Access-Reject packets applies in Diameter to
	Answer or Diameter-EAP-Answer messages that indicate failure.		AA-Answer or Diameter-EAP-Answer messages that indicate failure.
	What is said about COA-Request applies in Diameter to Re-Auth-Request		What is said about COA-Request applies in Diameter to Re-Auth-Request
	[RFC 4005].		[RFC 4005].
	What is said about Accounting-Request applies to Diameter Accounting-		What is said about Accounting-Request applies to Diameter
	Request [RFC 4005] as well.		Accounting-Request [RFC4005] as well.
	5. IANA Considerations		5. IANA Considerations
	This specification does not create any new registries.		This specification does not create any new registries.
	This document uses the RADIUS [RFC2865] namespace, see		This document uses the RADIUS [RFC2865] namespace; see
	<http://www.iana.org/assignments/radius-types>. Allocation of four		<http://www.iana.org/assignments/radius-types>. Allocation of four
	updates for the section "RADIUS Attribute Types" is requested. The		updates for the section "RADIUS Attribute Types" has been made by the
	RADIUS attributes for which values are requested are:		IANA. The RADIUS attributes are:
	TBD - Egress-VLANID		56 - Egress-VLANID
	TBD - Ingress-Filters		57 - Ingress-Filters
	TBD - Egress-VLAN-Name		58 - Egress-VLAN-Name
	TBD - User-Priority-Table		59 - User-Priority-Table
	6. Security Considerations		6. Security Considerations
	This specification describes the use of RADIUS and Diameter for		This specification describes the use of RADIUS and Diameter for
	purposes of authentication, authorization and accounting in IEEE 802		purposes of authentication, authorization, and accounting in IEEE 802
	local area networks. RADIUS threats and security issues for this		local area networks. RADIUS threats and security issues for this
	application are described in [RFC3579] and [RFC3580]; security issues		application are described in [RFC3579] and [RFC3580]; security issues
	encountered in roaming are described in [RFC2607]. For Diameter, the		encountered in roaming are described in [RFC2607]. For Diameter, the
	security issues relating to this application are described in		security issues relating to this application are described in
	[RFC4005] and [RFC4072].		[RFC4005] and [RFC4072].
	This document specifies new attributes that can be included in		This document specifies new attributes that can be included in
	existing RADIUS packets, which are protected as described in		existing RADIUS packets, which are protected as described in
	[RFC3579] and [RFC3576]. In Diameter, the attributes are protected		[RFC3579] and [RFC3576]. In Diameter, the attributes are protected
	as specified in [RFC3588]. See those documents for a more detailed		as specified in [RFC3588]. See those documents for a more detailed
	skipping to change at page 12, line 8		skipping to change at page 12, line 25
	Similarly, an attacker gaining control of a RADIUS/Diameter server or		Similarly, an attacker gaining control of a RADIUS/Diameter server or
	proxy can modify the user priority table, causing either degradation		proxy can modify the user priority table, causing either degradation
	of quality of service (by downgrading user priority of frames		of quality of service (by downgrading user priority of frames
	arriving at a port), or denial of service (by raising the level of		arriving at a port), or denial of service (by raising the level of
	priority of traffic at multiple ports of a device, oversubscribing		priority of traffic at multiple ports of a device, oversubscribing
	the switch or link capabilities).		the switch or link capabilities).
	7. References		7. References
	7.1. Normative references		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March, 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote		[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
	Authentication Dial In User Service (RADIUS)", RFC 2865, June		"Remote Authentication Dial In User Service (RADIUS)",
	2000.		RFC 2865, June 2000.
	[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,		[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
	"Diameter Base Protocol", RFC 3588, September 2003.		J. Arkko, "Diameter Base Protocol", RFC 3588, September
			2003.
	[RFC3629] Yergeau, F., "UTF-8, a transformation of ISO 10646", RFC 3629,		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	November 2003.		10646", STD 63, RFC 3629, November 2003.
	[RFC4363] Levi, D. and D. Harrington, "Definitions of Managed Objects		[RFC4363] Levi, D. and D. Harrington, "Definitions of Managed
	for Bridges with Traffic Classes, Multicast Filtering and		Objects for Bridges with Traffic Classes, Multicast
	Virtual LAN Extensions", RFC 4363, January 2006.		Filtering, and Virtual LAN Extensions", RFC 4363,
			January 2006.
	[IEEE-802]		[IEEE-802] IEEE Standards for Local and Metropolitan Area
	IEEE Standards for Local and Metropolitan Area Networks:		Networks: Overview and Architecture, ANSI/IEEE Std
	Overview and Architecture, ANSI/IEEE Std 802, 1990.		802, 1990.
	[IEEE-802.1D]		[IEEE-802.1D] IEEE Standards for Local and Metropolitan Area
	IEEE Standards for Local and Metropolitan Area Networks: Media		Networks: Media Access Control (MAC) Bridges, IEEE Std
	Access Control (MAC) Bridges, IEEE Std 802.1D-2004, June 2004.		802.1D-2004, June 2004.
	[IEEE-802.1Q]		[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area
	IEEE Standards for Local and Metropolitan Area Networks: Draft		Networks: Draft Standard for Virtual Bridged Local Area
	Standard for Virtual Bridged Local Area Networks,		Networks, P802.1Q-2003, January 2003.
	P802.1Q-2003, January 2003.
	7.2. Informative references		7.2. Informative References
	[IEEE-802.1X]		[IEEE-802.1X] IEEE Standards for Local and Metropolitan Area
	IEEE Standards for Local and Metropolitan Area Networks: Port		Networks: Port based Network Access Control, IEEE Std
	based Network Access Control, IEEE Std 802.1X-2004, December		802.1X-2004, December 2004.
	2004.
	[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy		[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
	Implementation in Roaming", RFC 2607, June 1999.		Implementation in Roaming", RFC 2607, June 1999.
	[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.		[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
	and I. Goyret, "RADIUS Attributes for Tunnel Protocol		Holdrege, M., and I. Goyret, "RADIUS Attributes for
	Support", RFC 2868, June 2000.		Tunnel Protocol Support", RFC 2868, June 2000.
	[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba,		[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
	"Dynamic Authorization Extensions to Remote Authentication		Aboba, "Dynamic Authorization Extensions to Remote
	Dial In User Service (RADIUS)", RFC 3576, July 2003.		Authentication Dial In User Service (RADIUS)", RFC
			3576, July 2003.
	[RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible		[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
	Authentication Protocol (EAP)", RFC 3579, September 2003.		Authentication Dial In User Service) Support For
			Extensible Authentication Protocol (EAP)", RFC 3579,
			September 2003.
	[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE		[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
	802.1X Remote Authentication Dial In User Service (RADIUS)		Roese, "IEEE 802.1X Remote Authentication Dial In User
	Usage Guidelines", RFC3580, September 2003.		Service (RADIUS) Usage Guidelines", RFC 3580, September
			2003.
	[RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter		[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
	Network Access Server Application", RFC 4005, August 2005.		"Diameter Network Access Server Application", RFC 4005,
			August 2005.
	[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible		[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter
	Authentication Protocol (EAP) Application", RFC 4072, August		Extensible Authentication Protocol (EAP) Application",
	2005.		RFC 4072, August 2005.
	Acknowledgments		8. Acknowledgements
	The authors would like to acknowledge Joseph Salowey of Cisco, David		The authors would like to acknowledge Joseph Salowey of Cisco, David
	Nelson of Enterasys, Chuck Black of Hewlett Packard, and Ashwin		Nelson of Enterasys, Chuck Black of Hewlett-Packard, and Ashwin
	Palekar of Microsoft.		Palekar of Microsoft.
	Authors' Addresses		Authors' Addresses
	Paul Congdon		Paul Congdon
	Hewlett Packard Company		Hewlett-Packard Company
	HP ProCurve Networking		HP ProCurve Networking
	8000 Foothills Blvd, M/S 5662		8000 Foothills Blvd, M/S 5662
	Roseville, CA 95747		Roseville, CA 95747
	EMail: paul.congdon@hp.com
	Phone: +1 916 785 5753		Phone: +1 916 785 5753
	Fax: +1 916 785 8478		Fax: +1 916 785 8478
			EMail: paul.congdon@hp.com
	Mauricio Sanchez		Mauricio Sanchez
	Hewlett Packard Company		Hewlett-Packard Company
	HP ProCurve Networking		HP ProCurve Networking
	8000 Foothills Blvd, M/S 5559		8000 Foothills Blvd, M/S 5559
	Roseville, CA 95747		Roseville, CA 95747
	EMail: mauricio.sanchez@hp.com
	Phone: +1 916 785 1910		Phone: +1 916 785 1910
	Fax: +1 916 785 1815		Fax: +1 916 785 1815
			EMail: mauricio.sanchez@hp.com
	Bernard Aboba		Bernard Aboba
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	EMail: bernarda@microsoft.com
	Phone: +1 425 706 6605		Phone: +1 425 706 6605
	Fax: +1 425 936 7329		Fax: +1 425 936 7329
			EMail: bernarda@microsoft.com
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The Internet Society (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.
			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		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		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		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at
	ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity
	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.
	Copyright Statement
	Copyright (C) The Internet Society (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.
	Acknowledgment
	Funding for the RFC Editor function is currently provided by the
	Internet Society.
	Open issues
	Open issues relating to this specification are tracked on the		Acknowledgement
	following web site:
	http://www.drizzle.com/~aboba/RADEXT/		Funding for the RFC Editor function is provided by the IETF
			Administrative Support Activity (IASA).
End of changes. 72 change blocks.
	199 lines changed or deleted		179 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/