draft-ietf-radext-radius-extensions-08.txt   draft-ietf-radext-radius-extensions-09.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-08.txt> <draft-ietf-radext-radius-extensions-09.txt>
Expires: July 8, 2013 Expires: July 28, 2013
8 January 2013 28 January 2013
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions Extensions
draft-ietf-radext-radius-extensions-08.txt draft-ietf-radext-radius-extensions-09.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 3, line 26 skipping to change at page 3, line 26
2.3. TLV Data Type ....................................... 13 2.3. TLV Data Type ....................................... 13
2.3.1. TLV Nesting .................................... 15 2.3.1. TLV Nesting .................................... 15
2.4. EVS Data Type ....................................... 16 2.4. EVS Data Type ....................................... 16
2.5. Integer64 Data Type ................................. 17 2.5. Integer64 Data Type ................................. 17
2.6. Vendor-ID Field ..................................... 18 2.6. Vendor-ID Field ..................................... 18
2.7. Attribute Naming and Type Identifiers ............... 18 2.7. Attribute Naming and Type Identifiers ............... 18
2.7.1. Attribute and TLV Naming ....................... 18 2.7.1. Attribute and TLV Naming ....................... 18
2.7.2. Attribute Type Identifiers ..................... 19 2.7.2. Attribute Type Identifiers ..................... 19
2.7.3. TLV Identifiers ................................ 19 2.7.3. TLV Identifiers ................................ 19
2.7.4. VSA Identifiers ................................ 20 2.7.4. VSA Identifiers ................................ 20
2.8. Invalid Attributes .................................. 20 2.8. Invalid Attributes .................................. 21
3. Attribute Definitions .................................... 21 3. Attribute Definitions .................................... 21
3.1. Extended-Type-1 ..................................... 22 3.1. Extended-Type-1 ..................................... 22
3.2. Extended-Type-2 ..................................... 23 3.2. Extended-Type-2 ..................................... 23
3.3. Extended-Type-3 ..................................... 23 3.3. Extended-Type-3 ..................................... 24
3.4. Extended-Type-4 ..................................... 24 3.4. Extended-Type-4 ..................................... 25
3.5. Long-Extended-Type-1 ................................ 25 3.5. Long-Extended-Type-1 ................................ 25
3.6. Long-Extended-Type-2 ................................ 26 3.6. Long-Extended-Type-2 ................................ 27
4. Vendor Specific Attributes ............................... 28 4. Vendor Specific Attributes ............................... 28
4.1. Extended-Vendor-Specific-1 .......................... 28 4.1. Extended-Vendor-Specific-1 .......................... 28
4.2. Extended-Vendor-Specific-2 .......................... 29 4.2. Extended-Vendor-Specific-2 .......................... 29
4.3. Extended-Vendor-Specific-3 .......................... 30 4.3. Extended-Vendor-Specific-3 .......................... 31
4.4. Extended-Vendor-Specific-4 .......................... 31 4.4. Extended-Vendor-Specific-4 .......................... 32
4.5. Extended-Vendor-Specific-5 .......................... 33 4.5. Extended-Vendor-Specific-5 .......................... 33
4.6. Extended-Vendor-Specific-6 .......................... 34 4.6. Extended-Vendor-Specific-6 .......................... 34
5. Compatibility with traditional RADIUS .................... 35 5. Compatibility with traditional RADIUS .................... 36
5.1. Attribute Allocation ................................ 36 5.1. Attribute Allocation ................................ 36
5.2. Proxy Servers ....................................... 37 5.2. Proxy Servers ....................................... 37
6. Guidelines ............................................... 38 6. Guidelines ............................................... 38
6.1. Updates to RFC 6158 ................................. 38 6.1. Updates to RFC 6158 ................................. 38
6.2. Guidelines for Simple Data Types .................... 38 6.2. Guidelines for Simple Data Types .................... 38
6.3. Guidelines for Complex Data Types ................... 39 6.3. Guidelines for Complex Data Types ................... 39
6.4. Guidelines For the New Types ........................ 39 6.4. Design Guidelines For the New Types ................. 40
6.5. Allocation Request Guidelines ....................... 40 6.5. TLV Guidelines ...................................... 40
6.6. TLV Guidelines ...................................... 41 6.6. Allocation Request Guidelines ....................... 41
6.7. Implementation Guidelines ........................... 41 6.7. Allocation Requests Guidelines for TLVs ............. 42
6.8. Vendor Guidelines ................................... 42 6.8. Implementation Guidelines ........................... 42
6.9. Vendor Guidelines ................................... 43
7. Rationale for This Design ................................ 42 7. Rationale for This Design ................................ 43
7.1. Attribute Audit ..................................... 42 7.1. Attribute Audit ..................................... 43
8. Diameter Considerations .................................. 43 8. Diameter Considerations .................................. 44
9. Examples ................................................. 43 9. Examples ................................................. 44
9.1. Extended Type ....................................... 45 9.1. Extended Type ....................................... 46
9.2. Long Extended Type .................................. 46 9.2. Long Extended Type .................................. 47
10. IANA Considerations ..................................... 48 10. IANA Considerations ..................................... 49
10.1. Attribute Allocations .............................. 49 10.1. Attribute Allocations .............................. 50
10.2. RADIUS Attribute Type Tree ......................... 49 10.2. RADIUS Attribute Type Tree ......................... 50
10.3. Allocation Instructions ............................ 50 10.3. Allocation Instructions ............................ 51
10.3.1. Requested Allocation from the Standard Space .. 50 10.3.1. Requested Allocation from the Standard Space .. 51
10.3.2. Requested Allocation from the short extended sp 50 10.3.2. Requested Allocation from the short extended sp 51
10.3.3. Requested Allocation from the long extended spa 51 10.3.3. Requested Allocation from the long extended spa 52
10.3.4. Allocation Preferences ........................ 51 10.3.4. Allocation Preferences ........................ 52
10.3.5. Extending the Type Space via TLV Data Type .... 51 10.3.5. Extending the Type Space via TLV Data Type .... 52
10.3.6. Allocation within a TLV ....................... 52 10.3.6. Allocation within a TLV ....................... 53
10.3.7. Allocation of Other Data Types ................ 52 10.3.7. Allocation of Other Data Types ................ 53
11. Security Considerations ................................. 52 11. Security Considerations ................................. 53
12. References .............................................. 53 12. References .............................................. 54
12.1. Normative references ............................... 53 12.1. Normative references ............................... 54
12.2. Informative references ............................. 53 12.2. Informative references ............................. 54
Appendix A - Extended Attribute Generator Program ............ 55 Appendix A - Extended Attribute Generator Program ............ 56
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 impractical, 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
skipping to change at page 6, line 39 skipping to change at page 6, line 39
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. Caveats and Limitations 1.1. Caveats and Limitations
This section describes some caveats and limitations with the This section describes some caveats and limitations with the
proposal. proposal.
1.1.1. Failure to Meet Certain Goals 1.1.1. Failure to Meet Certain Goals
One gaol which was not met by the above modifications is to have an One goal which was not met by the above modifications is to have an
incentive for standards to use the new space. We would ideally like incentive for standards to use the new space. We would ideally like
to deprecate the "Unassigned" attributes in the standard space, which to deprecate the "Unassigned" attributes in the standard space, which
would permit allocation, but under more stringent guidelines. would permit allocation, but under more stringent guidelines.
However, [RFC5226] has no provisions for a "Deprecated" entry in an However, [RFC5226] has no provisions for a "Deprecated" entry in an
IANA managed registry. IANA managed registry.
1.1.2. Implementation Recommendations 1.1.2. Implementation Recommendations
It is RECOMMENDED that implementations support this specification. It is RECOMMENDED that implementations support this specification.
It is RECOMMENDED that new specifications use the formats defined in It is RECOMMENDED that new specifications use the formats defined in
skipping to change at page 7, line 15 skipping to change at page 7, line 15
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.
As noted earlier, the "standard space" is almost entirely allocated. As noted earlier, the "standard space" is almost entirely allocated.
Ignoring the looming crisis benefits no one. Ignoring the looming crisis benefits no one.
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
silently discard Silently discard
This means the implementation discards the packet without further This means the implementation discards the packet without further
processing. The implementation MAY provide the capability of processing. The implementation MAY provide the capability of
logging the error, including the contents of the silently discarded logging the error, including the contents of the silently discarded
packet, and SHOULD record the event in a statistics counter. packet, and SHOULD record the event in a statistics counter.
invalid attribute Invalid attribute
This means that the Length field of an Attribute is valid (as per This means that the Length field of an Attribute is valid (as per
[RFC2865], Section 5, top of page 25). However, the Value field of [RFC2865], Section 5, top of page 25). However, the Value field of
the attribute does not follow the format required by the data type the attribute does not follow the format required by the data type
defined for that Attribute. e.g. an Attribute of type "address" defined for that Attribute. e.g. an Attribute of type "address"
which encapsulates more than four, or less than four, octets of which encapsulates more than four, or less than four, octets of
data. See Section 2.8 for a more complete definition. data. See Section 2.8 for a more complete definition.
Standard space Standard space
Codes in the RADIUS Attribute Type Space that are allocated by IANA Codes in the RADIUS Attribute Type Space that are allocated by IANA
and that follow the format defined in Section 5 of [RFC2865]. and that follow the format defined in Section 5 of [RFC2865].
skipping to change at page 9, line 50 skipping to change at page 10, line 5
attribute, or forward it verbatim. attribute, or forward it verbatim.
The changes to the attribute format come about by "stealing" one or The changes to the attribute format come about by "stealing" one or
more octets from the Value field. This change has the effect that more octets from the Value field. This change has the effect that
the Value field of [RFC2865] Section 5 contains both the new octets the Value field of [RFC2865] Section 5 contains both the new octets
given here, and any attribute-specific Value. The result is that given here, and any attribute-specific Value. The result is that
Values in this specification are limited to less than 253 octets in Values in this specification are limited to less than 253 octets in
size. This limitation is overcome through the use of the "Long size. This limitation is overcome through the use of the "Long
Extended Type" format. Extended Type" format.
We reiterate that the formats given in this document do not insert
new data into an attribute. Instead, we "steal" one octet of Value,
so that the definition of the Length field remains unchanged.
2.1. Extended Type 2.1. Extended Type
This section defines a new attribute format, called "Extended Type". This section defines a new attribute format, called "Extended Type".
A summary of the Attribute format is shown below. The fields are A summary of the Attribute format 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 | Extended-Type | Value ... | Type | Length | Extended-Type | Value ...
skipping to change at page 13, line 21 skipping to change at page 13, line 21
counting various headers and overhead). Implementations SHOULD be counting various headers and overhead). Implementations SHOULD be
able to handle fragmented attributes of 4096 octets. able to handle fragmented attributes of 4096 octets.
This definition increases the RADIUS Attribute Type space as above, This definition increases the RADIUS Attribute Type space as above,
but also provides for transport of Attributes which could contain but also provides for transport of Attributes which could contain
more than 253 octets of data. more than 253 octets of data.
Note that [RFC2865] Section 5 says: Note that [RFC2865] Section 5 says:
If multiple Attributes with the same Type are present, the order If multiple Attributes with the same Type are present, the order
of of Attributes with the same Type MUST be preserved by any proxies.
Attributes with the same Type MUST be preserved by any proxies. The order of Attributes of different Types is not required to be
The
order of Attributes of different Types is not required to be
preserved. A RADIUS server or client MUST NOT have any preserved. A RADIUS server or client MUST NOT have any
dependencies dependencies on the order of attributes of different types. A
on the order of attributes of different types. A RADIUS server or RADIUS server or client MUST NOT require attributes of the same
client MUST NOT require attributes of the same type to be type to be contiguous.
contiguous.
These requirements also apply to the "Long Extended Type" attribute, These requirements also apply to the "Long Extended Type" attribute,
including fragments. Implementations MUST be able to process non- including fragments. Implementations MUST be able to process non-
contiguous fragments. That is, fragments which are mixed together contiguous fragments. That is, fragments which are mixed together
with other attributes of a different Type. with other attributes of a different Type.
2.3. TLV Data Type 2.3. TLV Data Type
We define a new data type in RADIUS, called "tlv". The "tlv" data We define a new data type in RADIUS, called "tlv". The "tlv" data
type is an encapsulation layer which permits the "Value" field of an type is an encapsulation layer which permits the "Value" field of an
skipping to change at page 14, line 6 skipping to change at page 14, line 4
more logical containers. more logical containers.
The "tlv" data type re-uses the RADIUS attribute format, as given The "tlv" data type re-uses the RADIUS attribute format, as given
below: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 according to the policies and rules described in Section specified according to the policies and rules described in Section
10. Values of zero (0) MUST NOT be used. Values 254-255 are 10. Values 254-255 are "Reserved" for use by future extensions to
"Reserved" for use by future extensions to RADIUS. The value 26 RADIUS. The value 26 has no special meaning, and MUST NOT be
has no special meaning, and MUST NOT be treated as a Vendor treated as a Vendor Specific attribute.
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 19, line 19 skipping to change at page 19, line 19
conflict with attributes from other vendors, whereas the first form conflict with attributes from other vendors, whereas the first form
cannot. cannot.
It is therefore RECOMMENDED that specifications give names to It is therefore RECOMMENDED that specifications give names to
Attributes which attempt to be globally unique across all RADIUS Attributes which attempt to be globally unique across all RADIUS
Attributes. It is RECOMMENDED that vendors use their name as a Attributes. It is RECOMMENDED that vendors use their name as a
unique prefix for attribute names, e.g. Livingston-IP-Pool instead of unique prefix for attribute names, e.g. Livingston-IP-Pool instead of
IP-Pool. It is RECOMMENDED that implementations enforce uniqueness IP-Pool. It is RECOMMENDED that implementations enforce uniqueness
on names, which would otherwise lead to ambiguity and problems. on names, which would otherwise lead to ambiguity and problems.
We recognise that these suggestion may sometimes be difficult to We recognise that these suggestions may sometimes be difficult to
implement in practice. 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.7.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, an 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.7.3. TLV Identifiers 2.7.3. TLV Identifiers
skipping to change at page 20, line 14 skipping to change at page 20, line 14
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, with TLV-Type number four (4).
2.7.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
VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended
format, a VSA can be identified as "26.Vendor-Id"."Vendor-Type". format, a VSA can be identified as "26.Vendor-Id.Vendor-Type".
For example, Livingston has Vendor-Id 307, and has defined an For example, Livingston has Vendor-Id 307, and has defined an
attribute "IP-Pool" as number 6. This VSA can be uniquely identified attribute "IP-Pool" as number 6. This VSA can be uniquely identified
as 26.307.6, but it cannot be uniquely identified by name. as 26.307.6, but it cannot be uniquely identified by name, as other
vendors may have used the same name.
Note that there is no restriction on the size of the numerical values Note that there are few restrictions on the size of the numerical
in this notation. The Vendor-Id is a 24-bit number, and the VSA may values in this notation. The Vendor-Id is a 24-bit number, and the
have been assigned from a 16-bit vendor-specific Attribute Type VSA may have been assigned from a 16-bit vendor-specific Attribute
space. Type space. Implementations SHOULD be capable of handling 32-bit
numbers at each level of the "dotted number" notation.
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, and again cannot be uniquely be uniquely identified as 26.429.32768, and again cannot be uniquely
identified by name. identified by name.
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.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3 where "TLVn" are the
values assigned by the vendor to the different nested TLVs. numerical values assigned by the vendor to the different nested TLVs.
2.8. 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 less than four, or more 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. Many other forms of an "invalid attribute" are possible, but
are not enumerated here.
While the content of these attributes is malformed, we emphasize that While the content of these attributes is malformed, we emphasize that
the encapsulating RADIUS packet (or TLV) is well formed, and can be the encapsulating RADIUS packet, or attribute, or TLV, is well
correctly decoded. The existence of an "invalid attribute" in a formed, and can be correctly decoded. The existence of an "invalid
packet MUST NOT result in the implementation discarding the entire attribute" in a packet MUST NOT result in the implementation
packet, or treating the packet as a negative acknowledgement. discarding the entire packet, or treating the packet as a negative
Instead, only the "invalid attribute" is treated differently. acknowledgement. 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 less than
four, or less than four octets of data means that the Attribute MUST four octets, or more than four octets of data means that the
NOT be treated as being of data type "address". Attribute MUST NOT be treated as being of data type "address". The
reason here is that if the attribute does not carry an IPv4 address,
the receiver has no idea what format the data is in, and it is
therefore not an IPv4 address.
For Attributes of type "Long Extended Type", an Attribute is For Attributes of type "Long Extended Type", an Attribute is
considered to be an "invalid attribute" when does not match the considered to be an "invalid attribute" when does not match the
criteria set out in Section 2.2, above. criteria set out in Section 2.2, above.
For Attributes of type "TLV", an Attribute is considered 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 allows the
Value field does not match the criteria for that Attribute. encapsulating Attribute to be parsed, but the TLV-Value field does
Implementations SHOULD NOT treat the "invalid attribute" property as not match the criteria for that TLV. Implementations SHOULD NOT
being transitive. That is, the encapsulating Attribute SHOULD NOT be treat the "invalid attribute" property as being transitive. That is,
treated as being an "invalid attribute" if it encapsulates an the Attribute encapsulating the "invalid attribute" SHOULD NOT be
"invalid attribute". treated as an "invalid attribute". That encapsulating Attribute
might contain multiple TLVs, only one of which is an "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
from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. from the "Reserved" Attribute Type codes of 241, 242, 243, and 244.
We also define two (2) attributes of "Long Extended Type", which are We also define two (2) attributes of "Long Extended Type", which are
allocated from the "Reserved" Attribute Type codes of 245 and 246. allocated from the "Reserved" Attribute Type codes of 245 and 246.
Type Name Type Name
---- ---- ---- ----
241 Extended-Type-1 241 Extended-Type-1
242 Extended-Type-2 242 Extended-Type-2
243 Extended-Type-3 243 Extended-Type-3
244 Extended-Type-4 244 Extended-Type-4
245 Long-Extended-Type-1 245 Long-Extended-Type-1
skipping to change at page 29, line 25 skipping to change at page 29, line 38
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
implementation SHOULD support the field as undistinguished octets. implementation SHOULD support the field as undistinguished octets.
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.
The length of the Value field is eight (8) less then the value of The length of the Value field is eight (8) less than the value of
the Length field. the Length field.
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.
4.2. Extended-Vendor-Specific-2 4.2. Extended-Vendor-Specific-2
Description Description
skipping to change at page 30, line 31 skipping to change at page 30, line 43
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
implementation SHOULD support the field as undistinguished octets. implementation SHOULD support the field as undistinguished octets.
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.
The length of the Value field is eight (8) less then the value of The length of the Value field is eight (8) less than the value of
the Length field. the Length field.
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.
4.3. Extended-Vendor-Specific-3 4.3. Extended-Vendor-Specific-3
Description Description
skipping to change at page 31, line 38 skipping to change at page 31, line 52
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
implementation SHOULD support the field as undistinguished octets. implementation SHOULD support the field as undistinguished octets.
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.
The length of the Value field is eight (8) less then the value of The length of the Value field is eight (8) less than the value of
the Length field. the Length field.
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.
4.4. Extended-Vendor-Specific-4 4.4. Extended-Vendor-Specific-4
Description Description
skipping to change at page 32, line 43 skipping to change at page 33, line 9
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
implementation SHOULD support the field as undistinguished octets. implementation SHOULD support the field as undistinguished octets.
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.
The length of the Value field is eight (8) less then the value of The length of the Value field is eight (8) less than the value of
the Length field. the Length field.
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.
4.5. Extended-Vendor-Specific-5 4.5. Extended-Vendor-Specific-5
Description Description
skipping to change at page 38, line 9 skipping to change at page 38, line 17
246) define them as being of data type "string", and delete all other 246) define them as being of data type "string", and delete all other
local definitions for those attributes. local definitions for those attributes.
This last change should enable wider usage of the Extended Attributes This last change should enable wider usage of the Extended Attributes
format. format.
6. Guidelines 6. Guidelines
This specification proposes a number of changes to RADIUS, and This specification proposes a number of changes to RADIUS, and
therefore requires a set of guidelines, as has been done in therefore requires a set of guidelines, as has been done in
[RFC6158]. [RFC6158]. These guidelines include suggestions around design,
interaction with IANA, usage, and implementation of attributes using
the new formats.
6.1. Updates to RFC 6158 6.1. Updates to RFC 6158
This specification updates [RFC6158] by adding the data types "evs", This specification updates [RFC6158] by adding the data types "evs",
"tlv" and "integer64"; defining them to be "basic" data types; and "tlv" and "integer64"; defining them to be "basic" data types; and
permitting their use subject to the restrictions outlined below. permitting their use subject to the restrictions outlined below.
The recommendations for the use of the new data types and attribute The recommendations for the use of the new data types and attribute
formats are given below. All other recommendations given in formats are given below.
[RFC6158] are unchanged.
6.2. Guidelines for Simple Data Types 6.2. Guidelines for Simple Data Types
[RFC6158] Section A.2.1 says in part: [RFC6158] Section A.2.1 says in part:
* Unsigned integers of size other than 32 bits. * Unsigned integers of size other than 32 bits.
SHOULD be replaced by an unsigned integer of 32 bits. There is SHOULD be replaced by an unsigned integer of 32 bits. There is
insufficient justification to define a new size of integer. insufficient justification to define a new size of integer.
We update that specification to permit unsigned integers of 64 bits, We update that specification to permit unsigned integers of 64 bits,
skipping to change at page 39, line 5 skipping to change at page 39, line 12
* Nested attribute-value pairs (AVPs). * Nested attribute-value pairs (AVPs).
Attributes should be defined in a flat typespace. Attributes should be defined in a flat typespace.
We update that specification to permit nested TLVs, as defined in We update that specification to permit nested TLVs, as defined in
this document: this document:
* Nested attribute-value pairs (AVPs) using the extended * Nested attribute-value pairs (AVPs) using the extended
attribute format MAY be used. All other nested AVP or TLV attribute format MAY be used. All other nested AVP or TLV
formats MUST NOT be used. formats MUST NOT be used.
The [RFC6158] recommendations for "basic" data types apply to the
three types listed above. All other recommendations given in
[RFC6158] for "basic" data types remain unchanged.
6.3. Guidelines for Complex Data Types 6.3. Guidelines for Complex Data Types
[RFC6158] Section 2.1 says: [RFC6158] Section 2.1 says:
Complex data types MAY be used in situations where they reduce Complex data types MAY be used in situations where they reduce
complexity in non-RADIUS systems or where using the basic data complexity in non-RADIUS systems or where using the basic data
types types
would be awkward (such as where grouping would be required in would be awkward (such as where grouping would be required in
order order
to link related attributes). to link related attributes).
Since the extended attribute format allows for grouping of complex Since the extended attribute format allows for grouping of complex
types via TLVs, the guidelines for complex data types need to be types via TLVs, the guidelines for complex data types need to be
updated as follows: updated as follows:
Complex data types MAY be used where they reduce complexity in Complex data types MAY be used where they reduce complexity in
non-RADIUS systems, though this practice is NOT RECOMMENDED. The non-RADIUS systems, though this practice is NOT RECOMMENDED. The
complex data type exceptions of [RFC6158] Section 3.2.4 still complex data type exceptions of [RFC6158] Section 3.2.4 still
apply. In all other situations, complex data types MUST NOT be apply. In all other situations, complex data types MUST NOT be
used. Instead, complex data types MUST be decomposed into TLVs, used. Instead, complex data types MUST be decomposed into TLVs.
using the extended attribute format.
The checklist in Appendix A.2.2 is similarly updated to add a new The checklist in Appendix A.2.2 is similarly updated to add a new
requirement at the top of that section, requirement at the top of that section,
Does the attribute: Does the attribute:
* define a complex type which can be represented via TLVs? * define a complex type which can be represented via TLVs?
If so, this data type MUST be represented via TLVs. If so, this data type MUST be represented via TLVs.
Note that this requirement does not over-ride Section A.1, which Note that this requirement does not over-ride Section A.1, which
permits the transport of complex types in certain situations. permits the transport of complex types in certain situations.
6.4. Guidelines For the New Types All other recommendations given in [RFC6158] for "complex" data types
remain unchanged.
We recommend the following guidelines when designing attributes using 6.4. Design Guidelines For the New Types
the new format. The items listed below are not exhaustive. As
experience is gained with the new formats, later specifications may This section gives design guidelines for specifications defining
define additional guidelines. attributes using the new format. The items listed below are not
exhaustive. As experience is gained with the new formats, later
specifications may define additional guidelines.
* The data type "evs" MUST NOT be used for standard RADIUS * The data type "evs" MUST NOT be used for standard RADIUS
Attributes, or for TLVs, or for VSAs. Attributes, or for TLVs, or for VSAs.
* The data type "tlv" SHOULD NOT be used for standard RADIUS * The data type "tlv" SHOULD NOT be used for standard RADIUS
attributes. While its use is NOT RECOMMENDED by [RFC6158], this attributes. This format was NOT RECOMMENDED by [RFC6158],
specification updates [RFC6158] to permit the "tlv" data type in but their utility is now evident.
attributes using the Extended-Type format.
* [RFC2866] "tagged" attributes MUST NOT be defined in the * [RFC2866] "tagged" attributes MUST NOT be defined in the
Extended-Type space. The "tlv" data type should be used instead to Extended-Type space. The "tlv" data type should be used instead
group attributes. to group attributes.
* The "integer64" data type MAY be used in any RADIUS attribute. * The "integer64" data type MAY be used in any RADIUS attribute.
The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but
their utility is now evident. their utility is now evident.
* Any attribute which is allocated from the Type spaces of 245.* or * Any attribute which is allocated from the "long extended space" of
246.*, of data type "text", "string", or "tlv" can end up carrying data type "text", "string", or "tlv" can potentially carry more
more than 251 octets of data, up to the maximum RADIUS packet than 251 octets of data. Specifications defining such attributes
length (~4096 octets). Specifications defining such attributes SHOULD define a maximum length to guide implementations.
SHOULD define a maximum length.
* For all other circumstances, the guidelines in [RFC6158] MUST All other recommendations given in [RFC6158] for attribute design
be followed. guidelines apply to attributes using the "short extended space" and
"long extended space".
6.5. Allocation Request Guidelines 6.5. TLV Guidelines
The following items give design guidelines for specifications using
TLVs.
* when multiple attributes are intended to be grouped or managed
together, the use of TLVs to group related attributes is
RECOMMENDED.
* more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED.
* Interpretation of an attribute depends only on its type
definition (e.g. Type.Extended-Type.TLV-Type), and
not on its encoding or location in the RADIUS packet.
* Where a group of TLVs is strictly defined, and not expected to
change, and totals less than 247 octets of data, they SHOULD
request allocation from the "short extended space".
* Where a group of TLVs is loosely defined, or is expected to change,
they SHOULD request allocation from the "long extended space".
All other recommendations given in [RFC6158] for attribute design
guidelines apply to attributes using the TLV format.
6.6. Allocation Request Guidelines
The following items give guidelines for allocation requests made in a The following items give guidelines for allocation requests made in a
RADIUS specification. RADIUS specification.
* Discretion is RECOMMENDED when requesting allocation of attributes. * Discretion is RECOMMENDED when requesting allocation of attributes.
The new space is much larger than the old one, but it is not The new space is much larger than the old one, but it is not
infinite. infinite.
* Specifications which allocate many attributes MUST NOT request that * Specifications which allocate many attributes MUST NOT request that
allocation be made from from the standard space. That space is allocation be made from the standard space. That space is under
under allocation pressure, and the extended space is more suitable allocation pressure, and the extended space is more suitable for
for large allocations. large allocations.
* Specifications which allocate many related attributes SHOULD define * Specifications which allocate many related attributes SHOULD define
one or more TLVs to contain related attributes. one or more TLVs to contain related attributes.
* Specifications should not request allocation from a specific space. * Specifications SHOULD request allocation from a specific space.
The IANA considerations given in Section 9, below, should be The IANA considerations given in Section 9, below, give instruction
sufficient for attribute allocation. to IANA, but authors should assist IANA where possible.
* Specifications of an attribute which encodes 252 octets or less * Specifications of an attribute which encodes 252 octets or less of
of data MAY request allocation from the exended space, using data MAY request allocation from the "short extended space".
format "Extended Type"
* Specifications of an attribute which always encode less than 253 * Specifications of an attribute which always encode less than 253
octets of data MUST NOT request allocation from the long extended octets of data MUST NOT request allocation from the long extended
space. The standard space, or the short extended space MUST be space. The standard space, or the short extended space MUST be
used instead. used instead.
* Specifications of an attribute which encodes 253 octets or more of * Specifications of an attribute which encodes 253 octets or more of
data MUST request allocation from the long extended space. data MUST request allocation from the "long extended space".
* When the extended space is nearing exhaustion, a new specification * When the extended space is nearing exhaustion, a new specification
SHOULD be written which requests allocation of one or more RADIUS SHOULD be written which requests allocation of one or more RADIUS
Attributes from the "Reserved" portion of the standard space, Attributes from the "Reserved" portion of the standard space,
values 247-255, using an appropriate format ("Extended Type", or values 247-255, using an appropriate format ("Short Extended Type",
"Long Extended Type") or "Long Extended Type")
6.6. TLV Guidelines An allocation request made in a specification SHOULD use one of the
following formats when allocating an attribute type code:
The following items give guidelines for specifications using TLVs. * TBDn - request allocation of an attribute from the "standard
space". The value "n" should be "1" or more, to track individual
attributes which are to be allocated.
* when multiple attributes are intended to be grouped or managed * SHORT-TBDn - request allocation of an attribute from the "short
together, the use of TLVs to group related attributes is extended space". The value "n" should be "1" or more, to track
RECOMMENDED. individual attributes which are to be allocated.
* more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. * LONG-TBDn - request allocation of an attribute from the "long
extended space". The value "n" should be "1" or more, to track
individual attributes which are to be allocated.
* Interpretation of an attribute depends only on its type These guidelines should help specification authors and IANA
definition (e.g. Type.Extended-Type.TLV-Type), and communicate effectively and clearly.
not on its encoding or location in the RADIUS packet.
* Where a group of TLVs is strictly defined, and not expected to 6.7. Allocation Requests Guidelines for TLVs
change, and and totals less than 247 octets of data, they SHOULD
request allocation from the Type spaces of 241.*, 242.*, 243.*, or
244.*.
* Where a group of TLVs is loosely defined, or is expected to change, Specifications may allocate a new attribute of type TLV, and at the
they SHOULD request allocation from the Type spaces of 245.* or same time, allocate sub-attributes within that TLV. These
246.*. specifications SHOULD request allocation of specific values for the
sub-TLV. The "dotted number" notation MUST be used.
6.7. Implementation Guidelines For example, a specification may request allocation of a TLV as
SHORT-TBD1. Within that attribute, it could request allocation of
three sub-TLVs, as SHORT-TBD1.1, SHORT-TBD1.2, and SHORT-TBD1.3.
Specifications may request allocation of additional sub-TLVs within
an existing attribute of type TLV. Those specifications SHOULD use
the "TBDn" format for every entry in the "dotted number" notation.
For example, a specification may request allocation within an
existing TLV, with "dotted number" notation MM.NN. Within that
attribute, the specification could request allocation of three sub-
TLVs, as MM.NN.TBD1, MM.NN.TBD2, and MM.NN.TBD3.
6.8. Implementation Guidelines
* RADIUS client implementations SHOULD support this specification, * RADIUS client implementations SHOULD support this specification,
in order to permit the easy deployment of specifications using in order to permit the easy deployment of specifications using
the changes defined herein. the changes defined herein.
* RADIUS server implementations SHOULD support this specification, * RADIUS server implementations SHOULD support this specification,
in order to permit the easy deployment of specifications using in order to permit the easy deployment of specifications using
the changes defined herein. the changes defined herein.
* RADIUS proxy servers MUST follow the specifications in section 5.2 * RADIUS proxy servers MUST follow the specifications in section 5.2
6.8. Vendor Guidelines 6.9. 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. The changes to * Vendors SHOULD implement this specification. The changes to
RADIUS are relatively small, and are likely to quickly be used RADIUS are relatively small, and are likely to quickly be used
in new specifications. in new specifications.
skipping to change at page 42, line 28 skipping to change at page 43, line 28
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.
The changes outlined here have the benefit of being simple, as the The changes outlined here have the benefit of being simple, as the
"Extended Type" format requires only a one octet change to the "Extended Type" format requires only a one octet change to the
Attribute format. The downside is that the "Long Extended Type" Attribute format. The downside is that the "Long Extended Type"
format is awkward, and the 7 Reserved bits will likey never be used format is awkward, and the 7 Reserved bits will likely never be used
for anything. for anything.
7.1. Attribute Audit 7.1. Attribute Audit
An audit of almost five thousand publicly available attributes An audit of almost five thousand publicly available attributes [ATTR]
[ATTR], shows the statistics summarized below. The attributes include (2010), shows the statistics summarized below. The attributes include
over 100 Vendor dictionaries, along with the IANA assigned over 100 Vendor dictionaries, along with the IANA assigned
attributes: attributes:
Count Data Type Count Data Type
----- --------- ----- ---------
2257 integer 2257 integer
1762 text 1762 text
273 IPv4 Address 273 IPv4 Address
225 string 225 string
96 other data types 96 other data types
skipping to change at page 44, line 24 skipping to change at page 45, line 24
HEXCHAR = HEXDIG HEXDIG HEXCHAR = HEXDIG HEXDIG
STRING = DQUOTE 1*CHAR DQUOTE STRING = DQUOTE 1*CHAR DQUOTE
TLV = "{" 1*DIGIT DATA "}" TLV = "{" 1*DIGIT DATA "}"
DATA = 1*HEXCHAR / 1*TLV / STRING DATA = 1*HEXCHAR / 1*TLV / STRING
LINE = Identifier DATA LINE = Identifier DATA
The progam has additional restrictions on its input that are not The program has additional restrictions on its input that are not
reflected in the above grammar. For example, the portions of the reflected in the above grammar. For example, the portions of the
Identifier which refer to Type and Extended-Type are limited to Identifier which refer to Type and Extended-Type are limited to
values between 1 and 255. We trust that the source code in Appendix values between 1 and 255. We trust that the source code in Appendix
A is clear, and that these restrictions do not negatively affect the A is clear, and that these restrictions do not negatively affect the
comprehensability of the examples. comprehensibility of the examples.
The program reads the input text, and interprets it as a set of The program reads the input text, and interprets it as a set of
instructions to create RADIUS Attributes. It then prints the hex instructions to create RADIUS Attributes. It then prints the hex
encoding of those attributes. It implements the minimum set of encoding of those attributes. It implements the minimum set of
functionality which achieves that goal. This minimalism means that functionality which achieves that goal. This minimalism means that
it does not use attribute dictionaries; it does not implement support it does not use attribute dictionaries; it does not implement support
for RADIUS data types; it can be used to encode attributes with for RADIUS data types; it can be used to encode attributes with
invalid data fields; and there is no requirement for consistency from invalid data fields; and there is no requirement for consistency from
one example to the next. For example, it can be used to encode a one example to the next. For example, it can be used to encode a
User-Name attribute which contains non-UTF8 data, or a Framed-IP- User-Name attribute which contains non-UTF8 data, or a Framed-IP-
skipping to change at page 49, line 26 skipping to change at page 50, line 26
These values serve as an encapsulation layer for the new RADIUS These values serve as an encapsulation layer for the new RADIUS
Attribute Type tree. Attribute Type tree.
10.2. RADIUS Attribute Type Tree 10.2. RADIUS Attribute Type Tree
Each of the Attribute Type values allocated above extends the "RADIUS Each of the Attribute Type values allocated above extends the "RADIUS
Attribute Types" to an N-ary tree, via a "dotted number" notation. Attribute Types" to an N-ary tree, via a "dotted number" notation.
Allocation of an Attribute Type value "TYPE" using the new Extended Allocation of an Attribute Type value "TYPE" using the new Extended
type format results in allocation of 255 new Attribute Type values, type format results in allocation of 255 new Attribute Type values,
of format "TYPE.1" through "TYPE.255". The value zero "TYPE.0" is not of format "TYPE.1" through "TYPE.255". Value twenty-six (26) is
used. Value twenty-six (26) is assigned as "Extended-Vendor- assigned as "Extended-Vendor-Specific-*". Values "TYPE.241" through
Specific-*". Values "TYPE.241" through "TYPE.255" are marked "TYPE.255" are marked "Reserved". All other values are "Unassigned".
"Reserved". All other values are "Unassigned".
The initial set of Attribute Type values and names assigned by this The initial set of Attribute Type values and names assigned by this
document is given below. document is given below.
* 241 Extended-Attribute-1 * 241 Extended-Attribute-1
* 241.{1-25} Unassigned * 241.{1-25} Unassigned
* 241.26 Extended-Vendor-Specific-1 * 241.26 Extended-Vendor-Specific-1
* 241.{27-240} Unassigned * 241.{27-240} Unassigned
* 241.{241-255} Reserved * 241.{241-255} Reserved
* 242 Extended-Attribute-2 * 242 Extended-Attribute-2
skipping to change at page 50, line 33 skipping to change at page 51, line 32
Allocation of Reserved entries in the extended space requires Allocation of Reserved entries in the extended space requires
Standards Action. Standards Action.
All other allocations in the extended space require IETF Review. All other allocations in the extended space require IETF Review.
10.3. Allocation Instructions 10.3. Allocation Instructions
This section defines what actions IANA needs to take when allocating This section defines what actions IANA needs to take when allocating
new attributes. Different actions are required when allocating new attributes. Different actions are required when allocating
attributes from the standard space, attributes of Extended Type attributes from the standard space, attributes of Extended Type
format, attributes of the "Long Extended Type" format, perferential format, attributes of the "Long Extended Type" format, preferential
allocations, attributes of data type TLV, attributes within a TLV, allocations, attributes of data type TLV, attributes within a TLV,
and attributes of other data types. and attributes of other data types.
10.3.1. Requested Allocation from the Standard Space 10.3.1. Requested Allocation from the Standard Space
Specifications can request allocation of an Attribute from within the Specifications can request allocation of an Attribute from within the
standard space (e.g. Attribute Type Codes 1 through 255), subject to standard space (e.g. Attribute Type Codes 1 through 255), subject to
the considerations of [RFC3575] and this document. the considerations of [RFC3575] and this document.
10.3.2. Requested Allocation from the short extended space 10.3.2. Requested Allocation from the short extended space
skipping to change at page 51, line 50 skipping to change at page 52, line 50
specification be allocated from one type space or another. specification be allocated from one type space or another.
Specifications can simultaneously allocate attributes from both the Specifications can simultaneously allocate attributes from both the
standard space and the extended space. standard space and the extended space.
10.3.5. Extending the Type Space via TLV Data Type 10.3.5. Extending the Type Space via TLV Data Type
When specifications request allocation of an attribute of data type When specifications request allocation of an attribute of data type
"tlv", that allocation extends the Attribute Type Tree by one more "tlv", that allocation extends the Attribute Type Tree by one more
level. Allocation of an Attribute Type value "TYPE.TLV", with Data level. Allocation of an Attribute Type value "TYPE.TLV", with Data
Type TLV, results in allocation of 255 new Attribute Type values, of Type TLV, results in allocation of 255 new Attribute Type values, of
format "TYPE.TLV.1" through "TYPE.TLV.255". The value zero "VALUE.0" format "TYPE.TLV.1" through "TYPE.TLV.255". Values 254-255 are
is not used. Values 254-255 are marked "Reserved". All other values marked "Reserved". All other values are "Unassigned". Value 26 has
are "Unassigned". Value 26 has no special meaning. no special meaning.
For example, if a new attribute "Example-TLV" of data type "tlv" is For example, if a new attribute "Example-TLV" of data type "tlv" is
assigned the identifier "245.1", then the extended tree will be assigned the identifier "245.1", then the extended tree will be
allocated as below: allocated as below:
* 245.1 Example-TLV * 245.1 Example-TLV
* 245.1.{1-253} Unassigned * 245.1.{1-253} Unassigned
* 245.1.{254-255} Reserved * 245.1.{254-255} Reserved
Note that this example does not define an "Example-TLV" attribute. Note that this example does not define an "Example-TLV" attribute.
skipping to change at page 55, line 12 skipping to change at page 56, line 12
feedback has been invaluable, and has helped to make this feedback has been invaluable, and has helped to make this
specification better. specification better.
Appendix A - Extended Attribute Generator Program Appendix A - Extended Attribute Generator Program
This section contains "C" program source which can be used for This section contains "C" program source which can be used for
testing. It reads a line-oriented text file, parses it to create testing. It reads a line-oriented text file, parses it to create
RADIUS formatted attributes, and prints the hex version of those RADIUS formatted attributes, and prints the hex version of those
attributes to standard output. attributes to standard output.
The input accepts a grammar similar to that given in Section 8, with The input accepts a grammar similar to that given in Section 9, with
some modifications for usability. For example, blank lines are some modifications for usability. For example, blank lines are
allowed, lines beginning with a '#' character are interpreted as allowed, lines beginning with a '#' character are interpreted as
comments, numbers (RADIUS Types, etc.) are checked for minimum / comments, numbers (RADIUS Types, etc.) are checked for minimum /
maximum values, and RADIUS Attribute lengths are enforced. maximum values, and RADIUS Attribute lengths are enforced.
The program is included here for demonstration purposes only, and The program is included here for demonstration purposes only, and
does not define a standard of any kind. does not define a standard of any kind.
------------------------------------------------------------ ------------------------------------------------------------
/* /*
 End of changes. 66 change blocks. 
157 lines changed or deleted 202 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/