draft-ietf-radext-radius-extensions-05.txt   draft-ietf-radext-radius-extensions-06.txt 
Network Working Group Alan DeKok Network Working Group Alan DeKok
INTERNET-DRAFT Network RADIUS INTERNET-DRAFT Network RADIUS
Category: Proposed Standard Avi Lior Category: Proposed Standard Avi Lior
Updates: 2865, 2866, 3575, 5176, 6158 BWS Updates: 2865, 2866, 3575, 5176, 6158 BWS
<draft-ietf-radext-radius-extensions-05.txt> <draft-ietf-radext-radius-extensions-06.txt>
Expires: October 26, 2012 Expires: January 27, 2013
26 April 2012 27 June 2012
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions Extensions
draft-ietf-radext-radius-extensions-05.txt draft-ietf-radext-radius-extensions-06.txt
Abstract Abstract
The Remote Authentication Dial In User Service (RADIUS) protocol is The Remote Authentication Dial In User Service (RADIUS) protocol is
nearing exhaustion of its current 8-bit Attribute Type space. In nearing exhaustion of its current 8-bit Attribute Type space. In
addition, experience shows a growing need for complex grouping, along addition, experience shows a growing need for complex grouping, along
with attributes which can carry more than 253 octets of data. This with attributes which can carry more than 253 octets of data. This
document defines changes to RADIUS which address all of the above document defines changes to RADIUS which address all of the above
problems. problems.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 26, 2012. This Internet-Draft will expire on January 27, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 11 skipping to change at page 3, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ............................................. 5 1. Introduction ............................................. 5
1.1. Unmet Requirements .................................. 6 1.1. Unmet Requirements .................................. 6
1.2. Terminology ......................................... 6 1.2. Terminology ......................................... 6
1.3. Requirements Language ............................... 7 1.3. Requirements Language ............................... 7
2. Extensions to RADIUS ..................................... 9 2. Extensions to RADIUS ..................................... 8
2.1. Extended Type ....................................... 9 2.1. Extended Type ....................................... 8
2.2. Long Extended Type .................................. 10 2.2. Long Extended Type .................................. 9
2.3. TLV Data Type ....................................... 12 2.3. TLV Data Type ....................................... 11
2.3.1. TLV Nesting .................................... 14 2.3.1. TLV Nesting .................................... 13
2.4. EVS Data Type ....................................... 14 2.4. EVS Data Type ....................................... 13
2.5. Integer64 Data Type ................................. 16 2.5. Integer64 Data Type ................................. 15
2.6. Attribute Naming and Type Identifiers ............... 16 2.6. Vendor-ID Field ..................................... 15
2.6.1. Attribute and TLV Naming ....................... 17 2.7. Attribute Naming and Type Identifiers ............... 16
2.6.2. Attribute Type Identifiers ..................... 17 2.7.1. Attribute and TLV Naming ....................... 16
2.6.3. TLV Identifiers ................................ 17 2.7.2. Attribute Type Identifiers ..................... 16
2.6.4. VSA Identifiers ................................ 18 2.7.3. TLV Identifiers ................................ 17
2.7. Invalid Attributes .................................. 19 2.7.4. VSA Identifiers ................................ 17
2.8. Invalid Attributes .................................. 18
3. Attribute Definitions .................................... 19 3. Attribute Definitions .................................... 19
3.1. Extended-Type-1 ..................................... 20 3.1. Extended-Type-1 ..................................... 19
3.2. Extended-Type-2 ..................................... 21 3.2. Extended-Type-2 ..................................... 20
3.3. Extended-Type-3 ..................................... 22 3.3. Extended-Type-3 ..................................... 21
3.4. Extended-Type-4 ..................................... 22 3.4. Extended-Type-4 ..................................... 22
3.5. Long-Extended-Type-1 ................................ 23 3.5. Long-Extended-Type-1 ................................ 23
3.6. Long-Extended-Type-2 ................................ 24 3.6. Long-Extended-Type-2 ................................ 24
4. Vendor Specific Attributes ............................... 26 4. Vendor Specific Attributes ............................... 25
4.1. Extended-Vendor-Specific-1 .......................... 26 4.1. Extended-Vendor-Specific-1 .......................... 25
4.2. Extended-Vendor-Specific-2 .......................... 27 4.2. Extended-Vendor-Specific-2 .......................... 26
4.3. Extended-Vendor-Specific-3 .......................... 28 4.3. Extended-Vendor-Specific-3 .......................... 28
4.4. Extended-Vendor-Specific-4 .......................... 30 4.4. Extended-Vendor-Specific-4 .......................... 29
4.5. Extended-Vendor-Specific-5 .......................... 31 4.5. Extended-Vendor-Specific-5 .......................... 30
4.6. Extended-Vendor-Specific-6 .......................... 32 4.6. Extended-Vendor-Specific-6 .......................... 31
5. Compatibility with traditional RADIUS .................... 34 5. Compatibility with traditional RADIUS .................... 33
5.1. Attribute Allocation ................................ 34 5.1. Attribute Allocation ................................ 33
5.2. Proxy Servers ....................................... 35 5.2. Proxy Servers ....................................... 34
6. Guidelines ............................................... 36 6. Guidelines ............................................... 35
6.1. Updates to RFC 6158 ................................. 36 6.1. Updates to RFC 6158 ................................. 35
6.2. Guidelines for Simple Data Types .................... 36 6.2. Guidelines for Simple Data Types .................... 35
6.3. Guidelines for Complex Data Types ................... 37 6.3. Guidelines for Complex Data Types ................... 36
6.4. Guidelines For the New Types ........................ 37 6.4. Guidelines For the New Types ........................ 36
6.5. Allocation Request Guidelines ....................... 38 6.5. Allocation Request Guidelines ....................... 37
6.6. TLV Guidelines ...................................... 39 6.6. TLV Guidelines ...................................... 38
6.7. Implementation Guidelines ........................... 39 6.7. Implementation Guidelines ........................... 38
6.8. Vendor Guidelines ................................... 40 6.8. Vendor Guidelines ................................... 39
7. Rationale ................................................ 40 7. Rationale ................................................ 39
7.1. Attribute Audit ..................................... 40 7.1. Attribute Audit ..................................... 39
8. Diameter Considerations .................................. 41
9. Examples ................................................. 42 8. Diameter Considerations .................................. 40
9.1. Extended Type ....................................... 43 9. Examples ................................................. 41
9.2. Long Extended Type .................................. 44 9.1. Extended Type ....................................... 42
9.2. Long Extended Type .................................. 43
10. IANA Considerations ..................................... 46 10. IANA Considerations ..................................... 46
10.1. Attribute Allocations .............................. 47 10.1. Attribute Allocations .............................. 46
10.2. RADIUS Attribute Type Tree ......................... 47 10.2. RADIUS Attribute Type Tree ......................... 46
10.3. Allocation Instructions ............................ 48 10.3. Allocation Instructions ............................ 47
10.3.1. Requested Allocation from the Standard Space .. 48 10.3.1. Requested Allocation from the Standard Space .. 48
10.3.2. Requested Allocation from the short extended sp 48 10.3.2. Requested Allocation from the short extended sp 48
10.3.3. Requested Allocation from the long extended spa 49 10.3.3. Requested Allocation from the long extended spa 48
10.3.4. Allocation Preferences ........................ 49 10.3.4. Allocation Preferences ........................ 48
10.3.5. Extending the Type Space via TLV Data Type .... 49 10.3.5. Extending the Type Space via TLV Data Type .... 49
10.3.6. Allocation within a TLV ....................... 50 10.3.6. Allocation within a TLV ....................... 49
10.3.7. Allocation of Other Data Types ................ 50 10.3.7. Allocation of Other Data Types ................ 50
11. Security Considerations ................................. 50 11. Security Considerations ................................. 50
12. References .............................................. 51 12. References .............................................. 50
12.1. Normative references ............................... 51 12.1. Normative references ............................... 50
12.2. Informative references ............................. 51 12.2. Informative references ............................. 50
Appendix A - Extended Attribute Generator Program ............ 53 Appendix A - Extended Attribute Generator Program ............ 52
1. Introduction 1. Introduction
Under current allocation pressure, we expect that the RADIUS Under current allocation pressure, we expect that the RADIUS
Attribute Type space will be exhausted by 2014 or 2015. We therefore Attribute Type space will be exhausted by 2014 or 2015. We therefore
need a way to extend the type space, so that new specifications may need a way to extend the type space, so that new specifications may
continue to be developed. Other issues have also been shown with continue to be developed. Other issues have also been shown with
RADIUS. The attribute grouping method defined in [RFC2868] has been RADIUS. The attribute grouping method defined in [RFC2868] has been
shown to be imnpractical, and a more powerful mechanism is needed. shown to be impractical, and a more powerful mechanism is needed.
Multiple attributes have been defined which transport more than the Multiple attributes have been defined which transport more than the
253 octets of data originally envisioned with the protocol. Each of 253 octets of data originally envisioned with the protocol. Each of
these attributes is handled as a "special case" inside of RADIUS these attributes is handled as a "special case" inside of RADIUS
implementations, instead of as a general method. We therefore also implementations, instead of as a general method. We therefore also
need a standardized method of transporting large quantities of data. need a standardized method of transporting large quantities of data.
Finally, some vendors are close to allocating all of the Attributes Finally, some vendors are close to allocating all of the Attributes
within their Vendor-Specific Attribute space. It would be useful to within their Vendor-Specific Attribute space. It would be useful to
leverage changes to the base protocol for extending the Vendor- leverage changes to the base protocol for extending the Vendor-
Specific Attribute space. Specific Attribute space.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
data type allows an attribute to carry Vendor-Specific Attributes data type allows an attribute to carry Vendor-Specific Attributes
(VSAs) inside of the new attribute formats. (VSAs) inside of the new attribute formats.
* defining a new "integer64" data type. The data type allows * defining a new "integer64" data type. The data type allows
counters which track more than 2^32 octets of data. counters which track more than 2^32 octets of data.
* allocating 6 attributes using the new EVS data type. This * allocating 6 attributes using the new EVS data type. This
allocation extends the Vendor-Specific Attribute Type space by allocation extends the Vendor-Specific Attribute Type space by
over 1500 values. over 1500 values.
* Define the "Vendor-ID" for Vendor-Specific attributes to
encompass the entire 4 octets of the Vendor field. [RFC2865]
Section 5.26 defined it to be 3 octets, with the high octet
being zero.
As with any protocol change, the changes defined here are the result As with any protocol change, the changes defined here are the result
of a series of compromises. We have tried to find a balance between of a series of compromises. We have tried to find a balance between
flexibility, space in the RADIUS message, compatibility with existing flexibility, space in the RADIUS message, compatibility with existing
deployments, and implementation difficulty. deployments, and implementation difficulty.
1.1. Unmet Requirements 1.1. Unmet Requirements
One requirement which was not met by the above modifications is to One requirement which was not met by the above modifications is to
have an incentive for standards to use the new space. We would have an incentive for standards to use the new space. We would
ideally like to deprecate the "Unassigned" attributes in the standard ideally like to deprecate the "Unassigned" attributes in the standard
space, which would permit allocation, but under more stringent space, which would permit allocation, but under more stringent
guidelines. However, [RFC5226] has no provisions for a "Deprecated" guidelines. However, [RFC5226] has no provisions for a "Deprecated"
entry in an IANA managed registry. entry in an IANA managed registry.
It is RECOMMENDED that implementations support this specification as It is RECOMMENDED that implementations support this specification.
soon as possible. It is RECOMMENDED that new specifications use the It is RECOMMENDED that new specifications use the formats defined in
formats defined in this specification. this specification.
The alternative to the above recommendations is a circular argument The alternative to the above recommendations is a circular argument
of not implementing this specification because no other standards of not implementing this specification because no other standards
reference it, and also not defining new standards referencing this reference it, and also not defining new standards referencing this
specification because no implementations exist. specification because no implementations exist.
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
skipping to change at page 7, line 28 skipping to change at page 7, line 32
space. space.
Short extended space Short extended space
Codes in the extended space which use the "Extended Type" format. Codes in the extended space which use the "Extended Type" format.
Long extended space Long extended space
Codes in the extended space which use the "Long Extended Type" Codes in the extended space which use the "Long Extended Type"
format. format.
The following terms are used here with the meanings defined in BCP The following terms are used here with the meanings defined in BCP
26: "name space", "assigned value", "registration". 26 [RFC5226]: "name space", "assigned value", "registration",
"Private Use", "Reserved", "Unassigned", "IETF Review", and
The following terms are used here with the meanings defined in BCP "Standards Action".
26: "Private Use", "Reserved", "Unassigned".
The following policies are used here with the meanings defined in
BCP 26: "Private Use", "IETF Review", "Standards Action".
1.3. Requirements Language 1.3. Requirements Language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
An implementation is not compliant if it fails to satisfy one or more
of the must or must not requirements for the protocols it implements.
An implementation that satisfies all the MUST, MUST NOT, SHOULD, and
SHOULD NOT requirements for its protocols is said to be
"unconditionally compliant"; one that satisfies all the MUST and MUST
NOT requirements but not all the SHOULD or SHOULD NOT requirements
for its protocols is said to be "conditionally compliant".
2. Extensions to RADIUS 2. Extensions to RADIUS
This section defines two new attribute formats; "Extended Type"; and This section defines two new attribute formats; "Extended Type"; and
"Long Extended Type". It defines a new Type-Length-Value (TLV) data "Long Extended Type". It defines a new Type-Length-Value (TLV) data
type, an Extended-Vendor-Specific (EVS) data type, and an Integer64 type, an Extended-Vendor-Specific (EVS) data type, and an Integer64
data type. It defines a new method for naming attributes and data type. It defines a new method for naming attributes and
identifying Attributes using the new attribute formats. It finally identifying Attributes using the new attribute formats. It finally
defines the new term "invalid attribute", and describes how it defines the new term "invalid attribute", and describes how it
affects implementations. affects implementations.
skipping to change at page 9, line 38 skipping to change at page 8, line 38
This field is identical to the Type field of the Attribute format This field is identical to the Type field of the Attribute format
defined in [RFC2865] Section 5. defined in [RFC2865] Section 5.
Length Length
This field is identical to the Length field of the Attribute This field is identical to the Length field of the Attribute
format defined in [RFC2865] Section 5. Permitted values are format defined in [RFC2865] Section 5. Permitted values are
between 4 and 255. If a client or server receives an Extended between 4 and 255. If a client or server receives an Extended
Attribute with a Length of 2 or 3, then that Attribute MUST be Attribute with a Length of 2 or 3, then that Attribute MUST be
deemed to be an "invalid attribute", and handled as per Section considered to be an "invalid attribute", and handled as per
2.7, below. Section 2.7, below.
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified by IANA. Unlike the Type field defined in field are specified according to the policies and rules described
[RFC2865] Section 5, no values are allocated for experimental or in Section 10. Unlike the Type field defined in [RFC2865] Section
implementation-specific use. Values 241-255 are reserved and 5, no values are allocated for experimental or implementation-
SHOULD NOT be used. specific use. Values 241-255 are reserved and SHOULD NOT be used.
The Extended-Type is meaningful only within a context defined by The Extended-Type is meaningful only within a context defined by
the Type field. That is, this field may be thought of as defining the Type field. That is, this field may be thought of as defining
a new type space of the form "Type.Extended-Type". See Section a new type space of the form "Type.Extended-Type". See Section
2.5, below, for additional discussion. 2.5, below, for additional discussion.
A RADIUS server MAY ignore Attributes with an unknown A RADIUS server MAY ignore Attributes with an unknown
"Type.Extended-Type". "Type.Extended-Type".
A RADIUS client MAY ignore Attributes with an unknown A RADIUS client MAY ignore Attributes with an unknown
skipping to change at page 10, line 20 skipping to change at page 9, line 20
Value Value
This field is similar to the Value field of the Attribute format This field is similar to the Value field of the Attribute format
defined in [RFC2865] Section 5. The format of the data SHOULD be defined in [RFC2865] Section 5. The format of the data SHOULD be
a valid RADIUS data type. a valid RADIUS data type.
The addition of the Extended-Type field decreases the maximum The addition of the Extended-Type field decreases the maximum
length for attributes of type "text" or "string" from 253 to 252 length for attributes of type "text" or "string" from 253 to 252
octets. Where an Attribute needs to carry more than 252 octets of octets. Where an Attribute needs to carry more than 252 octets of
data, the "Long Extended Type" format should be used. data, the "Long Extended Type" format SHOULD be used.
Experience has shown that the "experimental" and "implementation Experience has shown that the "experimental" and "implementation
specific" attributes defined in [RFC2865] Section 5 have had little specific" attributes defined in [RFC2865] Section 5 have had little
practical value. We therefore do not continue that practice here practical value. We therefore do not continue that practice here
with the Extended-Type field. with the Extended-Type field.
2.2. Long Extended Type 2.2. Long Extended Type
This section defines a new attribute format, called "Long Extended This section defines a new attribute format, called "Long Extended
Type". It leverages the "Extended Type" format in order to permit Type". It leverages the "Extended Type" format in order to permit
skipping to change at page 11, line 5 skipping to change at page 10, line 5
This field is identical to the Type field of the Attribute format This field is identical to the Type field of the Attribute format
defined in [RFC2865] Section 5. defined in [RFC2865] Section 5.
Length Length
This field is identical to the Length field of the Attribute This field is identical to the Length field of the Attribute
format defined in [RFC2865] Section 5. Permitted values are format defined in [RFC2865] Section 5. Permitted values are
between 5 and 255. If a client or server receives a "Long between 5 and 255. If a client or server receives a "Long
Extended Attribute" with a Length of 2, 3, or 4, then that Extended Attribute" with a Length of 2, 3, or 4, then that
Attribute MUST be deemed to be an "invalid attribute", and be Attribute MUST be considered to be an "invalid attribute", and be
handled as per Section 2.7, below. handled as per Section 2.7, below.
Extended-Type Extended-Type
This field is identical to the Extended-Type field defined above This field is identical to the Extended-Type field defined above
in Section 2.1. in Section 2.1.
M (More) M (More)
The More field is one (1) bit in length, and indicates whether or The More field is one (1) bit in length, and indicates whether or
skipping to change at page 11, line 36 skipping to change at page 10, line 36
have both the same Type and Extended Type. That is, multiple have both the same Type and Extended Type. That is, multiple
fragments of the same value MUST be in order and MUST be fragments of the same value MUST be in order and MUST be
consecutive attributes in the packet, and the last attribute in a consecutive attributes in the packet, and the last attribute in a
packet MUST NOT have the More field set (1). packet MUST NOT have the More field set (1).
When the Length field of an attribute has value less than 255, the When the Length field of an attribute has value less than 255, the
More field SHOULD be clear (0). More field SHOULD be clear (0).
If a client or server receives an attribute fragment with the If a client or server receives an attribute fragment with the
"More" field set (1), but for which no subsequent fragment can be "More" field set (1), but for which no subsequent fragment can be
found, then the fragmented attribute is deemed to be an "invalid found, then the fragmented attribute is considered to be an
attribute", and handled as per Section 2.7, below. "invalid attribute", and handled as per Section 2.7, below.
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long, and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Future specifications may define additional meaning for this Future specifications may define additional meaning for this
field. Implementations therefore MUST NOT treat this field as field. Implementations therefore MUST NOT treat this field as
skipping to change at page 12, line 41 skipping to change at page 11, line 41
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-Type | TLV-Length | TLV-Value ... | TLV-Type | TLV-Length | TLV-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV-Type TLV-Type
The Type field is one octet. Up-to-date values of this field are The Type field is one octet. Up-to-date values of this field are
specified by IANA. Values of zero (0) MUST NOT be used. Values specified according to the policies and rules described in Section
254-255 are "Reserved" for use by future extensions to RADIUS. 10. Values of zero (0) MUST NOT be used. Values 254-255 are
The value 26 has no special meaning, and MUST NOT be treated as a "Reserved" for use by future extensions to RADIUS. The value 26
Vendor Specific attribute. has no special meaning, and MUST NOT be treated as a Vendor
Specific attribute.
As with Extended-Type above, the TLV-Type is meaningful only As with Extended-Type above, the TLV-Type is meaningful only
within the context defined by "Type" fields of the encapsulating within the context defined by "Type" fields of the encapsulating
Attributes. That is, the field may be thought of as defining a Attributes. That is, the field may be thought of as defining a
new type space of the form "Type.Extended-Type.TLV-Type". Where new type space of the form "Type.Extended-Type.TLV-Type". Where
TLVs are nested, the type space is of the form "Type.Extended- TLVs are nested, the type space is of the form "Type.Extended-
Type.TLV-Type.TLV-Type", etc. Type.TLV-Type.TLV-Type", etc.
A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". A RADIUS server MAY ignore Attributes with an unknown "TLV-Type".
skipping to change at page 13, line 18 skipping to change at page 12, line 19
A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- A RADIUS proxy SHOULD forward Attributes with an unknown "TLV-
Type" verbatim. Type" verbatim.
TLV-Length TLV-Length
The TLV-Length field is one octet, and indicates the length of The TLV-Length field is one octet, and indicates the length of
this TLV including the TLV-Type, TLV-Length and TLV-Value fields. this TLV including the TLV-Type, TLV-Length and TLV-Value fields.
It MUST have a value between 3 and 255. If a client or server It MUST have a value between 3 and 255. If a client or server
receives a TLV with an invalid TLV-Length, then the attribute receives a TLV with an invalid TLV-Length, then the attribute
which encapsulates that TLV MUST be deemed to be an "invalid which encapsulates that TLV MUST be considered to be an "invalid
attribute", and handled as per Section 2.7, below. attribute", and handled as per Section 2.7, below.
TLV-Value TLV-Value
The Value field is one or more octets and contains information The Value field is one or more octets and contains information
specific to the Attribute. The format and length of the TLV-Value specific to the Attribute. The format and length of the TLV-Value
field is determined by the TLV-Type and TLV-Length fields. field is determined by the TLV-Type and TLV-Length fields.
The TLV-Value field SHOULD encapsulate a previously defined RADIUS The TLV-Value field SHOULD encapsulate a previously defined RADIUS
data type. Using non-standard data types is NOT RECOMMENDED. We data type. Using non-standard data types is NOT RECOMMENDED. We
skipping to change at page 15, line 11 skipping to change at page 14, line 15
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id | | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | String .... | Vendor-Type | String ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id Vendor-Id
The high-order octet is 0 and the low-order 3 octets are the SMI The 4 octets are the SMI Network Management Private Enterprise
Network Management Private Enterprise Code of the Vendor in Code of the Vendor in network byte order.
network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. It SHOULD encapsulate a The Value field is one or more octets. It SHOULD encapsulate a
previously defined RADIUS data type. Using non-standard data previously defined RADIUS data type. Using non-standard data
skipping to change at page 16, line 37 skipping to change at page 15, line 37
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attributes having data type "integer64" MUST have the relevant Length Attributes having data type "integer64" MUST have the relevant Length
field set to eight more than the length of the Attribute header. For field set to eight more than the length of the Attribute header. For
standard space Attributes and TLVs, this means that the Length field standard space Attributes and TLVs, this means that the Length field
MUST be set to ten (10). For "Extended Type" Attributes, the Length MUST be set to ten (10). For "Extended Type" Attributes, the Length
field MUST be set to eleven (11). For "Long Extended Type" field MUST be set to eleven (11). For "Long Extended Type"
Attributes, the Length field MUST be set to twelve (12). Attributes, the Length field MUST be set to twelve (12).
2.6. Attribute Naming and Type Identifiers 2.6. Vendor-ID Field
We define the Vendor-ID field of Vendor-Specific Attributes to
encompass the entire 4 octets of the Vendor field. [RFC2865] Section
5.26 defined it to be 3 octets, with the high octet being zero. This
change has no immediate impact on RADIUS, as the maximum Private
Enterprise Code defined is still within 16 bits.
However, it is best to make advance preparations for changes in the
protocol. As such, it is RECOMMENDED that all implementations
support four (4) octets for the Vendor-ID field, instead of three
(3).
2.7. Attribute Naming and Type Identifiers
Attributes have traditionally been identified by a unique name and Attributes have traditionally been identified by a unique name and
number. For example, the attribute named "User-Name" has been number. For example, the attribute named "User-Name" has been
allocated number one (1). This scheme needs to be extended in order allocated number one (1). This scheme needs to be extended in order
to be able to refer to attributes of Extended Type, and to TLVs. It to be able to refer to attributes of Extended Type, and to TLVs. It
will also be used by IANA for allocating RADIUS Attribute Type will also be used by IANA for allocating RADIUS Attribute Type
values. values.
The names and identifiers given here are intended to be used only in The names and identifiers given here are intended to be used only in
specifications. The system presented here may not be useful when specifications. The system presented here may not be useful when
referring to the contents of a RADIUS packet. It imposes no referring to the contents of a RADIUS packet. It imposes no
requirements on implementations, as implementations are free to requirements on implementations, as implementations are free to
reference RADIUS Attributes via any method they choose. reference RADIUS Attributes via any method they choose.
2.6.1. Attribute and TLV Naming 2.7.1. Attribute and TLV Naming
RADIUS specifications traditionally use names consisting of one or RADIUS specifications traditionally use names consisting of one or
more words, separated by hyphens, e.g. "User-Name". However, these more words, separated by hyphens, e.g. "User-Name". However, these
names are not allocated from a registry, and there is no restriction names are not allocated from a registry, and there is no restriction
other than convention on their global uniqueness. other than convention on their global uniqueness.
Similarly, vendors have often used their company name as the prefix Similarly, vendors have often used their company name as the prefix
for VSA names, though this practice is not universal. For example, for VSA names, though this practice is not universal. For example,
for a vendor named "Example", the name "Example-Attribute-Name" for a vendor named "Example", the name "Example-Attribute-Name"
SHOULD be used instead of "Attribute-Name". The second form can SHOULD be used instead of "Attribute-Name". The second form can
skipping to change at page 17, line 30 skipping to change at page 16, line 45
which attempt to be globally unique across all RADIUS Attributes. We which attempt to be globally unique across all RADIUS Attributes. We
RECOMMEND that vendors use their name as a unique prefix for RECOMMEND that vendors use their name as a unique prefix for
attribute names. We recognise that these suggestion may sometimes be attribute names. We recognise that these suggestion may sometimes be
difficult to implement in practice. difficult to implement in practice.
TLVs SHOULD be named with a unique prefix that is shared among TLVs SHOULD be named with a unique prefix that is shared among
related attributes. For example, a specification that defines a set related attributes. For example, a specification that defines a set
of TLVs related to time could create attributes named "Time-Zone", of TLVs related to time could create attributes named "Time-Zone",
"Time-Day", "Time-Hour", "Time-Minute", etc. "Time-Day", "Time-Hour", "Time-Minute", etc.
2.6.2. Attribute Type Identifiers 2.7.2. Attribute Type Identifiers
The RADIUS Attribute Type space defines a context for a particular The RADIUS Attribute Type space defines a context for a particular
"Extended-Type" field. The "Extended-Type" field allows for 256 "Extended-Type" field. The "Extended-Type" field allows for 256
possible type code values, with values 1 through 240 available for possible type code values, with values 1 through 240 available for
allocation. We define here an identification method that uses a allocation. We define here an identification method that uses a
"dotted number" notation similar to that used for Object Identifiers "dotted number" notation similar to that used for Object Identifiers
(OIDs), formatted as "Type.Extended-Type". (OIDs), formatted as "Type.Extended-Type".
For example, and attribute within the Type space of 241, having For example, and attribute within the Type space of 241, having
Extended-Type of one (1), is uniquely identified as "241.1". Extended-Type of one (1), is uniquely identified as "241.1".
Similarly, an attribute within the Type space of 246, having Similarly, an attribute within the Type space of 246, having
Extended-Type of ten (10), is uniquely identified as "246.10". Extended-Type of ten (10), is uniquely identified as "246.10".
The algorithm used to create the Attribute Identifier is simply to The algorithm used to create the Attribute Identifier is simply to
concatenate all of the various identification fields (e.g. Type, concatenate all of the various identification fields (e.g. Type,
Extended-Type, etc.), starting from the encapsulating attribute, down Extended-Type, etc.), starting from the encapsulating attribute, down
to the final encapsulated TLV, separated by a '.' character. to the final encapsulated TLV, separated by a '.' character.
2.6.3. TLV Identifiers 2.7.3. TLV Identifiers
We can extend the Attribute reference scheme defined above for TLVs. We can extend the Attribute reference scheme defined above for TLVs.
This is done by leveraging the "dotted number" notation. As above, This is done by leveraging the "dotted number" notation. As above,
we define an additional TLV type space, within the "Extended Type" we define an additional TLV type space, within the "Extended Type"
space, by appending another "dotted number" in order to identify the space, by appending another "dotted number" in order to identify the
TLV. This method can be replied in sequence for nested TLVs. TLV. This method can be replied in sequence for nested TLVs.
For example, let us say that "245.1" identifies RADIUS Attribute Type For example, let us say that "245.1" identifies RADIUS Attribute Type
245, containing an "Extended Type" of one (1), which is of type 245, containing an "Extended Type" of one (1), which is of type
"tlv". That attribute will contain 256 possible TLVs, one for each "tlv". That attribute will contain 256 possible TLVs, one for each
value of the TLV-Type field. The first TLV-Type value of one (1) can value of the TLV-Type field. The first TLV-Type value of one (1) can
then be identified by appending a ".1" to the number of the then be identified by appending a ".1" to the number of the
encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, encapsulating attribute ("241.1"), to yield "241.1.1". Similarly,
the sequence "245.2.3.4" identifies RADIUS attribute 245, containing the sequence "245.2.3.4" identifies RADIUS attribute 245, containing
an "Extended Type" of two (2) which is of type "tlv", which in turn an "Extended Type" of two (2) which is of type "tlv", which in turn
contains a TLV with TLV-Type number three (3), which in turn contains contains a TLV with TLV-Type number three (3), which in turn contains
another TLV, wth TLV-Type number four (4). another TLV, wth TLV-Type number four (4).
2.6.4. VSA Identifiers 2.7.4. VSA Identifiers
There has historically been no method for numerically addressing There has historically been no method for numerically addressing
VSAs. The "dotted number" method defined here can also be leveraged VSAs. The "dotted number" method defined here can also be leveraged
to create such an addressing scheme. However, as the VSAs are to create such an addressing scheme. However, as the VSAs are
completely under the control of each individual vendor, this section completely under the control of each individual vendor, this section
provides a suggested practice, but does not define a standard of any provides a suggested practice, but does not define a standard of any
kind. kind.
The Vendor-Specific Attribute has been assigned the Attribute number The Vendor-Specific Attribute has been assigned the Attribute number
26. It in turn carries a 24-bit Vendor-Id, and possibly additional 26. It in turn carries a 24-bit Vendor-Id, and possibly additional
skipping to change at page 19, line 5 skipping to change at page 18, line 16
space. space.
For example, the company USR has been allocated Vendor-Id 429, and For example, the company USR has been allocated Vendor-Id 429, and
has defined a "Version-Id" attribute as number 32768. This VSA can has defined a "Version-Id" attribute as number 32768. This VSA can
be uniquely identified as 26.429.32768. be uniquely identified as 26.429.32768.
Where a VSA is a TLV, the "dotted number" notation can be used as Where a VSA is a TLV, the "dotted number" notation can be used as
above: 26.VID.VSA.TLV1.TLV2.TLV3 where "TLVn" are the numerical above: 26.VID.VSA.TLV1.TLV2.TLV3 where "TLVn" are the numerical
values assigned by the vendor to the different nested TLVs. values assigned by the vendor to the different nested TLVs.
2.7. Invalid Attributes 2.8. Invalid Attributes
The term "invalid attribute" is new to this specification. It is The term "invalid attribute" is new to this specification. It is
defined to mean that the Length field of an Attribute is valid (as defined to mean that the Length field of an Attribute is valid (as
per [RFC2865], Section 5, top of page 25). However, the Value field per [RFC2865], Section 5, top of page 25). However, the Value field
of the attribute does not follow the format required by the data type of the attribute does not follow the format required by the data type
defined for that Attribute. e.g. an Attribute of data type "address" defined for that Attribute. e.g. an Attribute of data type "address"
which encapsulates more than four, or less than four, octets of data. which encapsulates more than four, or less than four, octets of data.
Or, an IPV6 Prefix attribute which has a Prefix value of more than Or, an IPV6 Prefix attribute which has a Prefix value of more than
128. 128.
skipping to change at page 19, line 30 skipping to change at page 18, line 41
packet, or treating the packet as a negative acknowledgement. packet, or treating the packet as a negative acknowledgement.
Instead, only the "invalid attribute" is treated differently. Instead, only the "invalid attribute" is treated differently.
When an implementation receives an "invalid attribute", it SHOULD be When an implementation receives an "invalid attribute", it SHOULD be
silently discarded. If it is not discarded, it MUST NOT be handled silently discarded. If it is not discarded, it MUST NOT be handled
in the same manner as a well-formed attribute. For example, in the same manner as a well-formed attribute. For example,
receiving an Attribute of data type "address" containing more than receiving an Attribute of data type "address" containing more than
four, or less than four octets of data means that the Attribute MUST four, or less than four octets of data means that the Attribute MUST
NOT be treated as being of data type "address". NOT be treated as being of data type "address".
For Attributes of type "Long Extended Type", an Attribute is deemed For Attributes of type "Long Extended Type", an Attribute is
to be an "invalid attribute" when does not match the criteria set out considered to be an "invalid attribute" when does not match the
in Section 2.2, above. criteria set out in Section 2.2, above.
For Attributes of type "TLV", an Attribute is deemed to be an For Attributes of type "TLV", an Attribute is considered to be an
"invalid attribute" when the TLV-Length field is valid, but the TLV- "invalid attribute" when the TLV-Length field is valid, but the TLV-
Value field does not match the criteria for that Attribute. Value field does not match the criteria for that Attribute.
Implementations SHOULD NOT treat the "invalid attribute" property as Implementations SHOULD NOT treat the "invalid attribute" property as
being transitive. That is, the encapsulating Attribute SHOULD NOT be being transitive. That is, the encapsulating Attribute SHOULD NOT be
treated as being an "invalid attribute" if it encapsulates an treated as being an "invalid attribute" if it encapsulates an
"invalid attribute". "invalid attribute".
3. Attribute Definitions 3. Attribute Definitions
We define four (4) attributes of "Extended Type", which are allocated We define four (4) attributes of "Extended Type", which are allocated
skipping to change at page 20, line 40 skipping to change at page 19, line 51
241 for Extended-Type-1. 241 for Extended-Type-1.
Length Length
>= 4 >= 4
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified by IANA, in the 241.{1-255} RADIUS Attribute field are specified in the 241.{1-255} RADIUS Attribute Type
Type Space. Further definition of this field is given in Section Space, according to the policies and rules described in Section
2.1, above. 10. Further definition of this field is given in Section 2.1,
above.
Value Value
The Value field is one or more octets. Implementations not The Value field is one or more octets. Implementations not
supporting this specification SHOULD support the field as supporting this specification SHOULD support the field as
undistinguished octets. undistinguished octets.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the interpretation Identifier of "Type.Extended-Type" to determine the interpretation
of the Value field. of the Value field.
skipping to change at page 21, line 33 skipping to change at page 20, line 44
242 for Extended-Type-2. 242 for Extended-Type-2.
Length Length
>= 4 >= 4
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified by IANA, in the 242.{1-255} RADIUS Attribute field are specified in the 242.{1-255} RADIUS Attribute Type
Type Space. Further definition of this field is given in Section Space, according to the policies and rules described in Section
2.1, above. 10. Further definition of this field is given in Section 2.1,
above.
Value Value
The Value field is one or more octets. Implementations not The Value field is one or more octets. Implementations not
supporting this specification SHOULD support the field as supporting this specification SHOULD support the field as
undistinguished octets. undistinguished octets.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the interpretation Identifier of "Type.Extended-Type" to determine the interpretation
of the Value field of the Value field
3.3. Extended-Type-3 3.3. Extended-Type-3
skipping to change at page 22, line 32 skipping to change at page 21, line 39
243 for Extended-Type-3. 243 for Extended-Type-3.
Length Length
>= 4 >= 4
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified by IANA, in the 243.{1-255} RADIUS Attribute field are specified in the 243.{1-255} RADIUS Attribute Type
Type Space. Further definition of this field is given in Section Space, according to the policies and rules described in Section
2.1, above. 10. Further definition of this field is given in Section 2.1,
above.
Value Value
The Value field is one or more octets. Implementations not The Value field is one or more octets. Implementations not
supporting this specification SHOULD support the field as supporting this specification SHOULD support the field as
undistinguished octets. undistinguished octets.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the interpretation Identifier of "Type.Extended-Type" to determine the interpretation
of the Value field. of the Value field.
skipping to change at page 23, line 25 skipping to change at page 22, line 34
244 for Extended-Type-4. 244 for Extended-Type-4.
Length Length
>= 4 >= 4
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified by IANA, in the 244.{1-255} RADIUS Attribute field are specified in the 244.{1-255} RADIUS Attribute Type
Type Space. Further definition of this field is given in Section Space, according to the policies and rules described in Section
2.1, above. 10. Further definition of this field is given in Section 2.1,
above.
Value Value
The Value field is one or more octets. Implementations not The Value field is one or more octets. Implementations not
supporting this specification SHOULD support the field as supporting this specification SHOULD support the field as
undistinguished octets. undistinguished octets.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the interpretation Identifier of "Type.Extended-Type" to determine the interpretation
of the Value Field. of the Value Field.
skipping to change at page 24, line 20 skipping to change at page 23, line 34
245 for Long-Extended-Type-1 245 for Long-Extended-Type-1
Length Length
>= 5 >= 5
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified by IANA, in the 245.{1-255} RADIUS Attribute field are specified in the 245.{1-255} RADIUS Attribute Type
Type Space. Further definition of this field is given in Section Space, according to the policies and rules described in Section
2.1, above. 10. Further definition of this field is given in Section 2.1,
above.
M (More) M (More)
The More field is one (1) bit in length, and indicates whether or The More field is one (1) bit in length, and indicates whether or
not the current attribute contains "more" than 251 octets of data. not the current attribute contains "more" than 251 octets of data.
Further definition of this field is given in Section 2.2, above. Further definition of this field is given in Section 2.2, above.
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long, and is reserved for future use.
skipping to change at page 25, line 28 skipping to change at page 24, line 41
246 for Long-Extended-Type-2 246 for Long-Extended-Type-2
Length Length
>= 5 >= 5
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified by IANA, in the 246.{1-255} RADIUS Attribute field are specified in the 246.{1-255} RADIUS Attribute Type
Type Space. Further definition of this field is given in Section Space, according to the policies and rules described in Section
2.1, above. 10. Further definition of this field is given in Section 2.1,
above.
M (More) M (More)
The More field is one (1) bit in length, and indicates whether or The More field is one (1) bit in length, and indicates whether or
not the current attribute contains "more" than 251 octets of data. not the current attribute contains "more" than 251 octets of data.
Further definition of this field is given in Section 2.2, above. Further definition of this field is given in Section 2.2, above.
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long, and is reserved for future use.
skipping to change at page 27, line 11 skipping to change at page 26, line 25
Type.Extended-Type Type.Extended-Type
241.26 for Extended-Vendor-Specific-1 241.26 for Extended-Vendor-Specific-1
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The high-order octet is 0 and the low-order 3 octets are the SMI The 4 octets are the SMI Network Management Private Enterprise
Network Management Private Enterprise Code of the Vendor in Code of the Vendor in network byte order.
network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 28, line 17 skipping to change at page 27, line 30
Type.Extended-Type Type.Extended-Type
242.26 for Extended-Vendor-Specific-2 242.26 for Extended-Vendor-Specific-2
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The high-order octet is 0 and the low-order 3 octets are the SMI The 4 octets are the SMI Network Management Private Enterprise
Network Management Private Enterprise Code of the Vendor in Code of the Vendor in network byte order.
network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 29, line 25 skipping to change at page 28, line 36
Type.Extended-Type Type.Extended-Type
243.26 for Extended-Vendor-Specific-3 243.26 for Extended-Vendor-Specific-3
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The high-order octet is 0 and the low-order 3 octets are the SMI The 4 octets are the SMI Network Management Private Enterprise
Network Management Private Enterprise Code of the Vendor in Code of the Vendor in network byte order.
network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 30, line 35 skipping to change at page 29, line 42
Type.Extended-Type Type.Extended-Type
244.26 for Extended-Vendor-Specific-4 244.26 for Extended-Vendor-Specific-4
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The high-order octet is 0 and the low-order 3 octets are the SMI The 4 octets are the SMI Network Management Private Enterprise
Network Management Private Enterprise Code of the Vendor in Code of the Vendor in network byte order.
network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 31, line 46 skipping to change at page 31, line 4
Length Length
>= 10 (first fragment) >= 10 (first fragment)
>= 5 (subsequent fragments) >= 5 (subsequent fragments)
When a VSA is fragmented across multiple Attributes, only the When a VSA is fragmented across multiple Attributes, only the
first Attribute contains the Vendor-Id and Vendor-Type fields. first Attribute contains the Vendor-Id and Vendor-Type fields.
Subsequent Attributes contain fragments of the Value field only. Subsequent Attributes contain fragments of the Value field only.
M (More) M (More)
The More field is one (1) bit in length, and indicates whether or The More field is one (1) bit in length, and indicates whether or
not the current attribute contains "more" than 251 octets of data. not the current attribute contains "more" than 251 octets of data.
Further definition of this field is given in Section 2.2, above. Further definition of this field is given in Section 2.2, above.
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long, and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Vendor-Id Vendor-Id
The high-order octet is 0 and the low-order 3 octets are the SMI The 4 octets are the SMI Network Management Private Enterprise
Network Management Private Enterprise Code of the Vendor in Code of the Vendor in network byte order.
network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 33, line 32 skipping to change at page 32, line 38
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long, and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Vendor-Id Vendor-Id
The high-order octet is 0 and the low-order 3 octets are the SMI The 4 octets are the SMI Network Management Private Enterprise
Network Management Private Enterprise Code of the Vendor in Code of the Vendor in network byte order.
network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 34, line 9 skipping to change at page 33, line 15
The codification of the range of allowed usage of this field is The codification of the range of allowed usage of this field is
outside the scope of this specification. outside the scope of this specification.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to
determine the interpretation of the Value field. determine the interpretation of the Value field.
5. Compatibility with traditional RADIUS 5. Compatibility with traditional RADIUS
There are a number of potential compatibility issues with traditional There are a number of potential compatibility issues with traditional
RADIUS. This section describes them. RADIUS, as defined in [RFC6158] and earlier. This section describes
them.
5.1. Attribute Allocation 5.1. Attribute Allocation
Some vendors have used Attribute Type codes from the "Reserved" Some vendors have used Attribute Type codes from the "Reserved"
space, as part of vendor-defined dictionaries. This practice is space, as part of vendor-defined dictionaries. This practice is
considered anti-social behavior, as noted in [RFC6158]. These vendor considered anti-social behavior, as noted in [RFC6158]. These vendor
definitions conflict with the attributes in the RADIUS Attribute Type definitions conflict with the attributes in the RADIUS Attribute Type
space. The conflicting definitions may make it difficult for space. The conflicting definitions may make it difficult for
implementations to support both those Vendor Attributes, and the new implementations to support both those Vendor Attributes, and the new
Extended Attribute formats. Extended Attribute formats.
We RECOMMEND that RADIUS client and server implementations delete all We RECOMMEND that RADIUS client and server implementations delete all
references to these improperly defined attributes. Failing that, we references to these improperly defined attributes. Failing that, we
RECOMMEND that RADIUS server implementations have a per-client RECOMMEND that RADIUS server implementations have a per-client
configurable flag which indicates which type of attributes are being configurable flag which indicates which type of attributes are being
sent from the client. If the flag is set one way, the conflicting sent from the client. If the flag is set to "Non-Standard
attributes can be interpreted as being improperly defined Vendor Attributes", the conflicting attributes can be interpreted as being
Specific Attributes. If the flag is set the other way, the attributes improperly defined Vendor Specific Attributes. If the flag is set the
MUST be interpreted as being of the Extended Attributes format. The "IETF Attributes", the attributes MUST be interpreted as being of the
default SHOULD be to interpret the attributes as being of the Extended Attributes format. The default SHOULD be to interpret the
Extended Attributes format. attributes as being of the Extended Attributes format.
Other methods of determining how to decode the attributes into a Other methods of determining how to decode the attributes into a
"correct" form are NOT RECOMMENDED. Those methods are likely to be "correct" form are NOT RECOMMENDED. Those methods are likely to be
fragile and prone to error. fragile and prone to error.
We RECOMMEND that RADIUS server implementations re-use the above flag We RECOMMEND that RADIUS server implementations re-use the above flag
to determine which type of attributes to send in a reply message. If to determine which type of attributes to send in a reply message. If
the request is expected to contain the improperly defined attributes, the request is expected to contain the improperly defined attributes,
the reply SHOULD NOT contain Extended Attributes. If the request is the reply SHOULD NOT contain Extended Attributes. If the request is
expected to contain Extended Attributes, the reply MUST NOT contain expected to contain Extended Attributes, the reply MUST NOT contain
skipping to change at page 39, line 41 skipping to change at page 38, line 46
change, and and totals less than 247 octets of data, they SHOULD change, and and totals less than 247 octets of data, they SHOULD
request allocation from the Type spaces of 241.*, 242.*, 243.*, or request allocation from the Type spaces of 241.*, 242.*, 243.*, or
244.*. 244.*.
* Where a group of TLVs is loosely defined, or is expected to change, * Where a group of TLVs is loosely defined, or is expected to change,
they SHOULD request allocation from the Type spaces of 245.* or they SHOULD request allocation from the Type spaces of 245.* or
246.*. 246.*.
6.7. Implementation Guidelines 6.7. Implementation Guidelines
* RADIUS client implementations SHOULD support this specification * RADIUS client implementations SHOULD support this specification,
as soon as possible. in order to permit the easy deployment of specifications using
the changes defined herein.
* RADIUS server implementations SHOULD support this specification * RADIUS server implementations SHOULD support this specification,
as soon as possible. in order to permit the easy deployment of specifications using
the changes defined herein.
* RADIUS proxy servers SHOULD forward all attributes, even ones * RADIUS proxy servers SHOULD forward all attributes, even ones
which they do not understand, or which are not in a local which they do not understand, or which are not in a local
dictionary. These attributes SHOULD be forwarded verbatim, with dictionary. These attributes SHOULD be forwarded verbatim, with
no modifications or changes. no modifications or changes.
* When forwarding attributes, RADIUS proxy servers SHOULD forward * When forwarding attributes, RADIUS proxy servers SHOULD forward
the "Reserved" field unchanged. That is, they SHOULD NOT assume the "Reserved" field unchanged. That is, they SHOULD NOT assume
that the "Reserved" field can always be set to zero. that the "Reserved" field can always be set to zero.
6.8. Vendor Guidelines 6.8. Vendor Guidelines
* Vendors SHOULD use the existing Vendor-Specific Attribute Type * Vendors SHOULD use the existing Vendor-Specific Attribute Type
space in preference to the new Extended-Vendor-Specific space in preference to the new Extended-Vendor-Specific
attributes, as this specification may take time to become widely attributes, as this specification may take time to become widely
deployed. deployed.
* Vendors SHOULD implement this specification as soon as * Vendors SHOULD implement this specification. The changes to
possible. The changes to RADIUS are relatively small, and are RADIUS are relatively small, and are likely to quickly be used
likely to quickly be used in new specifications. in new specifications.
7. Rationale 7. Rationale
The path to extending the RADIUS protocol has been long and arduous. The path to extending the RADIUS protocol has been long and arduous.
A number of proposals have been made and discarded by the RADEXT A number of proposals have been made and discarded by the RADEXT
working group. These proposals have been judged to be either too working group. These proposals have been judged to be either too
bulky, too complex, too simple, or to be unworkable in practice. We bulky, too complex, too simple, or to be unworkable in practice. We
do not otherwise explain here why earlier proposals did not obtain do not otherwise explain here why earlier proposals did not obtain
working group consensus. working group consensus.
 End of changes. 52 change blocks. 
154 lines changed or deleted 164 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/