draft-ietf-radext-radius-extensions-12.txt   draft-ietf-radext-radius-extensions-13.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 Updates: 2865, 2866, 3575, 5176, 6158
<draft-ietf-radext-radius-extensions-12.txt> <draft-ietf-radext-radius-extensions-13.txt>
Expires: August 18, 2013 Expires: August 25, 2013
18 February 2013 25 February 2013
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions Extensions
draft-ietf-radext-radius-extensions-12.txt draft-ietf-radext-radius-extensions-13.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 23 skipping to change at page 3, line 23
2. Extensions to RADIUS ..................................... 9 2. Extensions to RADIUS ..................................... 9
2.1. Extended Type ....................................... 10 2.1. Extended Type ....................................... 10
2.2. Long Extended Type .................................. 11 2.2. Long Extended Type .................................. 11
2.3. TLV Data Type ....................................... 14 2.3. TLV Data Type ....................................... 14
2.3.1. TLV Nesting .................................... 16 2.3.1. TLV Nesting .................................... 16
2.4. EVS Data Type ....................................... 16 2.4. EVS Data Type ....................................... 16
2.5. Integer64 Data Type ................................. 18 2.5. Integer64 Data Type ................................. 18
2.6. Vendor-ID Field ..................................... 18 2.6. Vendor-ID Field ..................................... 18
2.7. Attribute Naming and Type Identifiers ............... 19 2.7. Attribute Naming and Type Identifiers ............... 19
2.7.1. Attribute and TLV Naming ....................... 19 2.7.1. Attribute and TLV Naming ....................... 19
2.7.2. Attribute Type Identifiers ..................... 20 2.7.2. Attribute Type Identifiers ..................... 19
2.7.3. TLV Identifiers ................................ 20 2.7.3. TLV Identifiers ................................ 20
2.7.4. VSA Identifiers ................................ 20 2.7.4. VSA Identifiers ................................ 20
2.8. Invalid Attributes .................................. 21 2.8. Invalid Attributes .................................. 21
3. Attribute Definitions .................................... 22 3. Attribute Definitions .................................... 22
3.1. Extended-Type-1 ..................................... 23 3.1. Extended-Type-1 ..................................... 23
3.2. Extended-Type-2 ..................................... 23 3.2. Extended-Type-2 ..................................... 23
3.3. Extended-Type-3 ..................................... 24 3.3. Extended-Type-3 ..................................... 24
3.4. Extended-Type-4 ..................................... 25 3.4. Extended-Type-4 ..................................... 25
3.5. Long-Extended-Type-1 ................................ 26 3.5. Long-Extended-Type-1 ................................ 26
3.6. Long-Extended-Type-2 ................................ 27 3.6. Long-Extended-Type-2 ................................ 27
skipping to change at page 3, line 45 skipping to change at page 3, line 45
4.1. Extended-Vendor-Specific-1 .......................... 29 4.1. Extended-Vendor-Specific-1 .......................... 29
4.2. Extended-Vendor-Specific-2 .......................... 30 4.2. Extended-Vendor-Specific-2 .......................... 30
4.3. Extended-Vendor-Specific-3 .......................... 31 4.3. Extended-Vendor-Specific-3 .......................... 31
4.4. Extended-Vendor-Specific-4 .......................... 32 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 .......................... 35 4.6. Extended-Vendor-Specific-6 .......................... 35
5. Compatibility with traditional RADIUS .................... 36 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 ................................. 39 6.1. Updates to RFC 6158 ................................. 38
6.2. Guidelines for Simple Data Types .................... 39 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. Design Guidelines For the New Types ................. 40 6.4. Design Guidelines For the New Types ................. 40
6.5. TLV Guidelines ...................................... 41 6.5. TLV Guidelines ...................................... 41
6.6. Allocation Request Guidelines ....................... 41 6.6. Allocation Request Guidelines ....................... 41
6.7. Allocation Requests Guidelines for TLVs ............. 43 6.7. Allocation Requests Guidelines for TLVs ............. 42
6.8. Implementation Guidelines ........................... 43 6.8. Implementation Guidelines ........................... 43
6.9. Vendor Guidelines ................................... 43 6.9. Vendor Guidelines ................................... 43
7. Rationale for This Design ................................ 43 7. Rationale for This Design ................................ 43
7.1. Attribute Audit ..................................... 44 7.1. Attribute Audit ..................................... 44
8. Diameter Considerations .................................. 45 8. Diameter Considerations .................................. 45
9. Examples ................................................. 45 9. Examples ................................................. 45
9.1. Extended Type ....................................... 46 9.1. Extended Type ....................................... 46
9.2. Long Extended Type .................................. 47 9.2. Long Extended Type .................................. 47
10. IANA Considerations ..................................... 50 10. IANA Considerations ..................................... 50
10.1. Attribute Allocations .............................. 50 10.1. Attribute Allocations .............................. 50
10.2. RADIUS Attribute Type Tree ......................... 51 10.2. RADIUS Attribute Type Tree ......................... 50
10.3. Allocation Instructions ............................ 52 10.3. Allocation Instructions ............................ 51
10.3.1. Requested Allocation from the Standard Space .. 52 10.3.1. Requested Allocation from the Standard Space .. 52
10.3.2. Requested Allocation from the short extended sp 52 10.3.2. Requested Allocation from the short extended sp 52
10.3.3. Requested Allocation from the long extended spa 52 10.3.3. Requested Allocation from the long extended spa 52
10.3.4. Allocation Preferences ........................ 52 10.3.4. Allocation Preferences ........................ 52
10.3.5. Extending the Type Space via TLV Data Type .... 53 10.3.5. Extending the Type Space via TLV Data Type .... 53
10.3.6. Allocation within a TLV ....................... 54 10.3.6. Allocation within a TLV ....................... 53
10.3.7. Allocation of Other Data Types ................ 54 10.3.7. Allocation of Other Data Types ................ 54
11. Security Considerations ................................. 54 11. Security Considerations ................................. 54
12. References .............................................. 54 12. References .............................................. 54
12.1. Normative references ............................... 55 12.1. Normative references ............................... 54
12.2. Informative references ............................. 55 12.2. Informative references ............................. 55
Appendix A - Extended Attribute Generator Program ............ 57 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 11, line 7 skipping to change at page 11, line 7
A RADIUS client MAY ignore Attributes with an unknown A RADIUS client MAY ignore Attributes with an unknown
"Type.Extended-Type". "Type.Extended-Type".
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 MUST be a defined in [RFC2865] Section 5. The format of the data MUST be a
valid RADIUS data type. valid RADIUS data type.
The Value field is one or more octets. Implementations not The Value field is one or more octets.
supporting this specification SHOULD support the field as
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.
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 MUST be used. data, the "Long Extended Type" format MUST be used.
skipping to change at page 13, line 14 skipping to change at page 13, line 12
field. Implementations therefore MUST NOT treat this field as field. Implementations therefore MUST NOT treat this field as
invalid if it is non-zero. invalid if it is non-zero.
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. It may contain a complete set of defined in [RFC2865] Section 5. It may contain a complete set of
data (when the Length field has value less than 255), or it may data (when the Length field has value less than 255), or it may
contain a fragment of data. contain a fragment of data.
The Value field is one or more octets. Implementations not The Value field is one or more octets.
supporting this specification SHOULD support the field as
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.
Any interpretation of the resulting data MUST occur after the Any interpretation of the resulting data MUST occur after the
fragments have been reassembled. The length of the data MUST be fragments have been reassembled. The length of the data MUST be
taken as the sum of the lengths of the fragments (i.e. Value taken as the sum of the lengths of the fragments (i.e. Value
fields) from which it is constructed. The format of the data fields) from which it is constructed. The format of the data
SHOULD be a valid RADIUS data type. If the reassembled data does SHOULD be a valid RADIUS data type. If the reassembled data does
skipping to change at page 15, line 17 skipping to change at page 15, line 13
which encapsulates that TLV MUST be considered to be an "invalid which encapsulates that TLV MUST be considered to be an "invalid
attribute", and handled as per Section 2.8, below. attribute", and handled as per Section 2.8, below.
TLV-Value TLV-Value
The TLV-Value field is one or more octets and contains information The TLV-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 standard RADIUS data The TLV-Value field SHOULD encapsulate a standard RADIUS data
type. Non-standard data types SHOULD NOT be used withing TLV- type. Non-standard data types SHOULD NOT be used within TLV-Value
Value fields. We note that the TLV-Value field MAY also contain fields. We note that the TLV-Value field MAY also contain one or
one or more attributes of data type "tlv", which allows for simple more attributes of data type "tlv", which allows for simple
grouping and multiple layers of nesting. grouping and multiple layers of nesting.
The TLV-Value field is limited to containing 253 or fewer octets The TLV-Value field is limited to containing 253 or fewer octets
of data. Specifications which require a TLV to contain more than of data. Specifications which require a TLV to contain more than
253 octets of data are incompatible with RADIUS, and need to be 253 octets of data are incompatible with RADIUS, and need to be
redesigned. Specifications which require the transport of empty redesigned. Specifications which require the transport of empty
Values (i.e. Length = 2) are incompatible with RADIUS, and need to Values (i.e. Length = 2) are incompatible with RADIUS, and need to
be redesigned. be redesigned.
The TLV-Value field MUST NOT contain data using the "Extended The TLV-Value field MUST NOT contain data using the "Extended
skipping to change at page 22, line 31 skipping to change at page 22, line 27
might contain multiple TLVs, only one of which is an "invalid might contain multiple TLVs, only one of which is an "invalid
attribute". attribute".
However, a TLV definition may require particular sub-TLVs to be However, a TLV definition may require particular sub-TLVs to be
present, and/or to have specific values. If a sub-TLV is missing, or present, and/or to have specific values. If a sub-TLV is missing, or
contains incorrect value(s), or is an "invalid attribute", then the contains incorrect value(s), or is an "invalid attribute", then the
encapsulating TLV SHOULD be treated as an "invalid attribute". This encapsulating TLV SHOULD be treated as an "invalid attribute". This
requirement ensures that strongly connected TLVs are handled either requirement ensures that strongly connected TLVs are handled either
as a coherent whole, or are ignored entirely. as a coherent whole, or are ignored entirely.
It is RECOMMENDED that Attributes with unknown Type, Ext-Type, TLV-
Type, or VSA-Type are treated as "invalid attributes". This
recommendation is compatible with the suggestion in [RFC2865] Section
5, that implementations "MAY ignore Attributes with an unknown Type".
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
skipping to change at page 23, line 39 skipping to change at page 23, line 39
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 in the 241.{1-255} RADIUS Attribute Type field are specified in the 241.{1-255} RADIUS Attribute Type
Space, according to the policies and rules described in Section Space, according to the policies and rules described in Section
10. Further definition of this field is given in Section 2.1, 10. Further definition of this field is given in Section 2.1,
above. above.
Value Value
The Value field is one or more octets. Implementations not The Value field is one or more octets.
supporting this specification SHOULD support the field as
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.2. Extended-Type-2 3.2. Extended-Type-2
Description Description
This attribute encapsulates attributes of the "Extended Type" This attribute encapsulates attributes of the "Extended Type"
skipping to change at page 24, line 33 skipping to change at page 24, line 32
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 in the 242.{1-255} RADIUS Attribute Type field are specified in the 242.{1-255} RADIUS Attribute Type
Space, according to the policies and rules described in Section Space, according to the policies and rules described in Section
10. Further definition of this field is given in Section 2.1, 10. Further definition of this field is given in Section 2.1,
above. above.
Value Value
The Value field is one or more octets. Implementations not The Value field is one or more octets.
supporting this specification SHOULD support the field as
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
Description Description
This attribute encapsulates attributes of the "Extended Type" This attribute encapsulates attributes of the "Extended Type"
skipping to change at page 25, line 29 skipping to change at page 25, line 25
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 in the 243.{1-255} RADIUS Attribute Type field are specified in the 243.{1-255} RADIUS Attribute Type
Space, according to the policies and rules described in Section Space, according to the policies and rules described in Section
10. Further definition of this field is given in Section 2.1, 10. Further definition of this field is given in Section 2.1,
above. above.
Value Value
The Value field is one or more octets. Implementations not The Value field is one or more octets.
supporting this specification SHOULD support the field as
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.4. Extended-Type-4 3.4. Extended-Type-4
Description Description
This attribute encapsulates attributes of the "Extended Type" This attribute encapsulates attributes of the "Extended Type"
skipping to change at page 26, line 22 skipping to change at page 26, line 16
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 in the 244.{1-255} RADIUS Attribute Type field are specified in the 244.{1-255} RADIUS Attribute Type
Space, according to the policies and rules described in Section Space, according to the policies and rules described in Section
10. Further definition of this field is given in Section 2.1, 10. Further definition of this field is given in Section 2.1,
above. above.
Value Value
The Value field is one or more octets. Implementations not The Value field is one or more octets.
supporting this specification SHOULD support the field as
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.5. Long-Extended-Type-1 3.5. Long-Extended-Type-1
Description Description
This attribute encapsulates attributes of the "Long Extended Type" This attribute encapsulates attributes of the "Long Extended Type"
skipping to change at page 27, line 32 skipping to change at page 27, line 24
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.
Value Value
The Value field is one or more octets. Implementations not The Value field is one or more octets.
supporting this specification SHOULD support the field as
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.6. Long-Extended-Type-2 3.6. Long-Extended-Type-2
Description Description
This attribute encapsulates attributes of the "Long Extended Type" This attribute encapsulates attributes of the "Long Extended Type"
skipping to change at page 28, line 40 skipping to change at page 28, line 32
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.
Value Value
The Value field is one or more octets. Implementations not The Value field is one or more octets.
supporting this specification SHOULD support the field as
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.
4. Vendor Specific Attributes 4. Vendor Specific Attributes
We define six new attributes which can carry Vendor Specific We define six new attributes which can carry Vendor Specific
information. We define four (4) attributes of the "Extended Type" information. We define four (4) attributes of the "Extended Type"
format, with Type codes (241.26, 242.26, 243.26, 244.26), using the format, with Type codes (241.26, 242.26, 243.26, 244.26), using the
skipping to change at page 37, line 46 skipping to change at page 37, line 35
Existing clients that send these improperly defined attributes Existing clients that send these improperly defined attributes
usually have a configuration setting which can disable this behavior. usually have a configuration setting which can disable this behavior.
We RECOMMEND that vendors ship products with the default set to We RECOMMEND that vendors ship products with the default set to
"disabled". We RECOMMEND that administrators set this flag to "disabled". We RECOMMEND that administrators set this flag to
"disabled" on all equipment that they manage. "disabled" on all equipment that they manage.
5.2. Proxy Servers 5.2. Proxy Servers
RADIUS Proxy servers will need to forward Attributes having the new RADIUS Proxy servers will need to forward Attributes having the new
format, even if they do not implement support for the encoding and format, even if they do not implement support for the encoding and
decoding of those attributes. We remind implementors of the decoding of those attributes. We remind implementers of the
following text in [RFC2865] Section 2.3: following text in [RFC2865] Section 2.3:
The forwarding server MUST NOT change the order of any attributes The forwarding server MUST NOT change the order of any attributes
of the same type, including Proxy-State. of the same type, including Proxy-State.
This requirement solves some of the issues related to proxying of the This requirement solves some of the issues related to proxying of the
new format, but not all. The reason is that proxy servers are new format, but not all. The reason is that proxy servers are
permitted to examine the contents of the packets that they forward. permitted to examine the contents of the packets that they forward.
Many proxy implementations not only examine the attributes, but they Many proxy implementations not only examine the attributes, but they
refuse to forward attributes which they do not understand (i.e. refuse to forward attributes which they do not understand (i.e.
skipping to change at page 41, line 6 skipping to change at page 40, line 39
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. attributes.
* [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 Extended-Type space. The "tlv" data type should be used instead
to 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 was not recommended in [RFC6158],
their utility is now evident. but their utility is now evident.
* Any attribute which is allocated from the "long extended space" of * Any attribute which is allocated from the "long extended space" of
data type "text", "string", or "tlv" can potentially carry more data type "text", "string", or "tlv" can potentially carry more
than 251 octets of data. Specifications defining such attributes than 251 octets of data. Specifications defining such attributes
SHOULD define a maximum length to guide implementations. SHOULD define a maximum length to guide implementations.
All other recommendations given in [RFC6158] for attribute design All other recommendations given in [RFC6158] for attribute design
guidelines apply to attributes using the "short extended space" and guidelines apply to attributes using the "short extended space" and
"long extended space". "long extended space".
skipping to change at page 41, line 48 skipping to change at page 41, line 35
they SHOULD request allocation from the "long extended space". they SHOULD request allocation from the "long extended space".
All other recommendations given in [RFC6158] for attribute design All other recommendations given in [RFC6158] for attribute design
guidelines apply to attributes using the TLV format. guidelines apply to attributes using the TLV format.
6.6. Allocation Request Guidelines 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 the standard space. That space is under allocation be made from the standard space. That space is under
allocation pressure, and the extended space is more suitable for allocation pressure, and the extended space is more suitable for
large allocations. large allocations. As a guideline, we suggest that one
specification allocating twenty percent (20%) or more of the
standard space would meet the above criteria.
* 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 request allocation from a specific space. * Specifications SHOULD request allocation from a specific space.
The IANA considerations given in Section 9, below, give instruction The IANA considerations given in Section 9, below, give instruction
to IANA, but authors should assist IANA where possible. to IANA, but authors should assist IANA where possible.
* Specifications of an attribute which encodes 252 octets or less of * Specifications of an attribute which encodes 252 octets or less of
data MAY request allocation from the "short extended space". data MAY request allocation from the "short extended space".
 End of changes. 23 change blocks. 
45 lines changed or deleted 36 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/