draft-ietf-radext-datatypes-08.txt   rfc8044.txt 
Network Working Group DeKok, Alan Internet Engineering Task Force (IETF) A. DeKok
INTERNET-DRAFT FreeRADIUS Request for Comments: 8044 FreeRADIUS
Updates: 2865,3162,6158,6572 Updates: 2865, 3162, 4072, 6158, 6572, 7268 January 2017
Category: Standards Track Category: Standards Track
<draft-ietf-radext-datatypes-08.txt> ISSN: 2070-1721
18 October 2016
Data Types in the Remote Authentication Data Types in RADIUS
Dial-In User Service Protocol (RADIUS)
Abstract Abstract
RADIUS specifications have used data types for two decades without RADIUS specifications have used data types for two decades without
defining them as managed entities. During this time, RADIUS defining them as managed entities. During this time, RADIUS
implementations have named the data types, and have used them in implementations have named the data types and have used them in
attribute definitions. This document updates the specifications to attribute definitions. This document updates the specifications to
better follow established practice. We do this by naming the data better follow established practice. We do this by naming the data
types defined in RFC 6158, which have been used since at least the types defined in RFC 6158, which have been used since at least the
publication of RFC 2865. We provide an IANA registry for the data publication of RFC 2865. We provide an IANA registry for the data
types, and update the RADIUS Attribute Type registry to include a types and update the "RADIUS Attribute Types" registry to include a
"Data Type" field for each attribute. Finally, we recommend that Data Type field for each attribute. Finally, we recommend that
authors of RADIUS specifications use these types in preference to authors of RADIUS specifications use these types in preference to
existing practice. This document updates RFC 2865, 3162, 6158, and existing practice. This document updates RFCs 2865, 3162, 4072,
6572. 6158, 6572, and 7268.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on May 18, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8044.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ............................................. 4 1. Introduction ....................................................4
1.1. Specification Problems with Data Types .............. 4 1.1. Specification Problems with Data Types .....................4
1.2. Implementation Problems with Data Types ............. 5 1.2. Implementation Problems with Data Types ....................5
1.3. No Mandated Changes ................................. 5 1.3. No Mandated Changes ........................................5
1.4. Requirements Language ............................... 5 1.4. Requirements Language ......................................5
2. Use of Data Types ........................................ 6 2. Use of Data Types ...............................................6
2.1. Specification Use of Data Types ..................... 6 2.1. Specification Use of Data Types ............................6
2.1.1. Field Names for Attribute Values ............... 6 2.1.1. Field Names for Attribute Values ....................6
2.1.2. Attribute Definitions using Data Types ......... 7 2.1.2. Attribute Definitions Using Data Types ..............7
2.1.3. Format of Attribute Definitions ................ 7 2.1.3. Format of Attribute Definitions .....................8
2.1.4. Defining a New Data Type ....................... 8 2.1.4. Defining a New Data Type ............................9
2.2. Implementation Use of Data Types .................... 9 2.2. Implementation Use of Data Types ...........................9
3. Data Type Definitions .................................... 11 3. Data Type Definitions ..........................................10
3.1. integer ............................................. 12 3.1. integer ...................................................12
3.2. enum ................................................ 12 3.2. enum ......................................................12
3.3. time ................................................ 13 3.3. time ......................................................13
3.4. text ................................................ 13 3.4. text ......................................................14
3.5. string .............................................. 14 3.5. string ....................................................15
3.6. concat .............................................. 16 3.6. concat ....................................................16
3.7. ifid ................................................ 16 3.7. ifid ......................................................17
3.8. ipv4addr ............................................ 17 3.8. ipv4addr ..................................................18
3.9. ipv6addr ............................................ 18 3.9. ipv6addr ..................................................18
3.10. ipv6prefix ......................................... 18 3.10. ipv6prefix ...............................................19
3.11. ipv4prefix ......................................... 20 3.11. ipv4prefix ...............................................20
3.12. integer64 .......................................... 21 3.12. integer64 ................................................22
3.13. tlv ................................................ 22 3.13. tlv ......................................................23
3.14. vsa ................................................ 23 3.14. vsa ......................................................24
3.15. extended ........................................... 24 3.15. extended .................................................26
3.16. long-extended ...................................... 26 3.16. long-extended ............................................27
3.17. evs ................................................ 29 3.17. evs ......................................................30
4. Updated Registries ....................................... 30 4. Updated Registries .............................................31
4.1. Create a Data Type Registry ......................... 30 4.1. New "Data Type" Registry ..................................31
4.2. Updates to the Attribute Type Registry .............. 31 4.2. Updates to the "RADIUS Attribute Types" Registry ..........32
5. Security Considerations .................................. 36 5. Security Considerations ........................................32
6. IANA Considerations ...................................... 37 6. IANA Considerations ............................................33
7. References ............................................... 37 7. References .....................................................33
7.1. Normative References ................................ 37 7.1. Normative References ......................................33
7.2. Informative References .............................. 38 7.2. Informative References ....................................34
Acknowledgments ...................................................35
Author's Address ..................................................35
1. Introduction 1. Introduction
RADIUS specifications have historically defined attributes in terms RADIUS specifications have historically defined attributes in terms
of name, value, and data type. Of these three pieces of information, of name, value, and data type. Of these three pieces of information,
the name is recorded by IANA in the RADIUS Attribute Type registry, the name is recorded by IANA in the "RADIUS Attribute Types" registry
but not otherwise managed or restricted, as discussed in [RFC6929] but is not otherwise managed or restricted, as discussed in
Section 2.7.1. The value is managed by IANA, and recorded in that [RFC6929], Section 2.7.1. The value is managed by IANA and recorded
registry. The data type is not managed or recorded in the RADIUS in that registry. The data type is not managed or recorded in the
Attribute Type registry. Experience has shown that there is a need "RADIUS Attribute Types" registry. Experience has shown that there
to create well known data types, and have them managed by IANA. is a need to create well-known data types and have them managed
by IANA.
This document defines an IANA RADIUS Data Type registry, and updates This document defines an IANA RADIUS "Data Type" registry and updates
the RADIUS Attribute Type registry to use those newly defined data the "RADIUS Attribute Types" registry to use those newly defined
types. It recommends how both specifications and implementations data types. It recommends how both specifications and
should use the data types. It extends the RADIUS Attribute Type implementations should use the data types. It extends the "RADIUS
registry to have a data type for each assigned attribute. Attribute Types" registry to have a data type for each assigned
attribute.
In this section, we review the use of data types in specifications In this section, we review the use of data types in specifications
and implementations. Whe highlight ambiguities and inconsistencies. and implementations. We highlight ambiguities and inconsistencies.
The rest of this document is devoted to resolving those problems. The rest of this document is devoted to resolving those problems.
1.1. Specification Problems with Data Types 1.1. Specification Problems with Data Types
When attributes are defined in the specifications, the terms "Value" When attributes are defined in the specifications, the terms "Value"
and "String" are used to refer to the contents of an attribute. and "String" are used to refer to the contents of an attribute.
However, these names are used recursively and inconsistently. We However, these names are used recursively and inconsistently. We
suggest that defining a field to recursively contain itself is suggest that defining a field to recursively contain itself is
problematic. problematic.
A number of data type names and definitions are given in [RFC2865] A number of data type names and definitions are given in
Section 5, at the bottom of page 25. These data types are named and [RFC2865], Section 5, at the bottom of page 25. These data types are
clearly defined. However, this practice was not continued in later named and clearly defined. However, this practice was not continued
specifications. in later specifications.
Specifically, [RFC2865] defines attributes of data type "address" to Specifically, [RFC2865] defines attributes of data type "address" to
carry IPv4 addresses. Despite this definition, [RFC3162] defines carry IPv4 addresses. Despite this definition, [RFC3162] defines
attributes of data type "Address" to carry IPv6 addresses. We attributes of data type "Address" to carry IPv6 addresses. We
suggest that the use of the word "address" to refer to disparate data suggest that the use of the word "address" to refer to disparate
types is problematic. data types is problematic.
Other failures are that [RFC3162] does not give a data type name and Other failures are that [RFC3162] does not give a data type name and
definition for the data types IPv6 address, Interface-Id, or IPv6 definition for the data types IPv6 address, Interface-Id, or IPv6
prefix. [RFC2869] defines Event-Timestamp to carry a time, but does prefix. [RFC2869] defines Event-Timestamp to carry a time but does
not re-use the "time" data type defined in [RFC2865]. Instead, it not reuse the "time" data type defined in [RFC2865]. Instead, it
just repeats the "time" definition. [RFC6572] defines multiple just repeats the "time" definition. [RFC6572] defines multiple
attributes which carry IPv4 prefixes. However, an "IPv4 prefix" data attributes that carry IPv4 prefixes. However, an "IPv4 prefix" data
type is not named, defined as a data type, or called out as an type is not named, defined as a data type, or called out as an
addition to RADIUS. Further, [RFC6572] does not follow the addition to RADIUS. Further, [RFC6572] does not follow the
recommendations of [RFC6158], and does not explain why it fails to recommendations of [RFC6158] and does not explain why it fails to
follow those recommendations. follow those recommendations.
These ambiguities and inconsistencies need to be resolved. These ambiguities and inconsistencies need to be resolved.
1.2. Implementation Problems with Data Types 1.2. Implementation Problems with Data Types
RADIUS implementations often use "dictionaries" to map attribute RADIUS implementations often use "dictionaries" to map attribute
names to type values, and to define data types for each attribute. names to type values and define data types for each attribute. The
The data types in the dictionaries are defined by each data types in the dictionaries are defined by each implementation but
implementation, but correspond to the "ad hoc" data types used in the correspond to the "ad hoc" data types used in the specifications.
specifications.
In effect, implementations have seen the need for well-defined data In effect, implementations have seen the need for well-defined
types, and have created them. It is time for RADIUS specifications data types and have created them. It is time for RADIUS
to follow this practice. specifications to follow this practice.
1.3. No Mandated Changes 1.3. No Mandated Changes
This document mandates no changes to any RADIUS implementation, past, This document mandates no changes to any past, present, or future
present, or future. It instead documents existing practice, in order RADIUS implementation. It instead documents existing practice in
to simplify the process of writing RADIUS specifications, to clarify order to simplify the process of writing RADIUS specifications,
the interpretation of RADIUS standards, and to improve the clarify the interpretation of RADIUS standards, and improve the
communication between specification authors and IANA. communication between specification authors and IANA.
This document suggests that implementations SHOULD use the data types This document suggests that implementations SHOULD use the data types
defined here, in preference to any "ad hoc" data types currently in defined here, in preference to any ad hoc data types currently in
use. This suggestion should have minimal effect on implementations, use. This suggestion should have a minimal effect on
as most "ad hoc" data types are compatible with the ones defined implementations, as most ad hoc data types are compatible with the
here. Any difference will typically be limited to the name of the ones defined here. Any difference will typically be limited to the
data type. name of the data type.
This document updates [RFC6158] to permit the data types defined in This document updates [RFC6158] to permit the data types defined in
the "Data Type registry" as "basic data types", as per Section 2.1 of the "Data Type" registry as "basic data types", as per Section 2.1 of
that document. The recommendations of [RFC6158] are otherwise [RFC6158]. The recommendations of [RFC6158] are otherwise unchanged.
unchanged.
1.4. Requirements Language 1.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Use of Data Types 2. Use of Data Types
The Data Types can be used in two places: specifications, and The data types can be used in two places: specifications and
implementations. This section discusses both uses, and gives implementations. This section discusses both uses and gives guidance
guidance on using the data types. on using the data types.
2.1. Specification Use of Data Types 2.1. Specification Use of Data Types
In this section, we give recommendations for how specifications In this section, we give recommendations for how specifications
should be written using data types. We first describe how attribute should be written using data types. We first describe how attribute
field names can be consistently named. We then describe how field names can be consistently named. We then describe how
attribute definitions should use the data types, and deprecate the attribute definitions should use the data types and deprecate the use
use of "ASCII art" for attribute definitions. We suggest a format of "ASCII art" for attribute definitions. We suggest a format for
for new attribute definitions. This format includes recommended new attribute definitions. This format includes recommended fields
fields, and suggestions for how those fields should be described. and suggestions for how those fields should be described.
Finally, we make recommendations for how new data types should be Finally, we make recommendations for how new data types should be
defined. defined.
2.1.1. Field Names for Attribute Values 2.1.1. Field Names for Attribute Values
Previous specifications used inconsistent and conflicting names for Previous specifications used inconsistent and conflicting names for
the contents of RADIUS attributes. For example, the term "Value" is the contents of RADIUS attributes. For example, the term "Value" is
used in [RFC2865] Section 5 to define a field which carries the used in [RFC2865], Section 5 to define a field that carries the
contents of attribute. It is then used in later sections as the sub- contents of an attribute. It is then used in later sections as the
field of attribute contents. The result is that the field is defined subfield of attribute contents. The result is that the field is
as recursively containing itself. Similarly, "String" is used both defined as recursively containing itself. Similarly, "String" is
as a data type, and as a sub-field of other data types. used both as a data type and as a subfield of other data types.
We correct this ambiguity by using context-specific names for various We correct this ambiguity by using context-specific names for various
fields of attributes and data types. It then becomes clear that, for fields of attributes and data types. It then becomes clear that, for
example, that a field called "VSA-Data" must contain different data example, a field called "VSA-Data" must contain different data than a
than a field called "EVS-Data". Each new name is defined where it is field called "EVS-Data". Each new name is defined where it is used.
used.
We also define the following term: We also define the following term:
Attr-Data Attr-Data
The "Value" field of an Attribute as defined in [RFC2865] The Value field of an Attribute as defined in
Section 5. The contents of this field MUST be of a valid data [RFC2865], Section 5. The contents of this field MUST be of a
type as defined in the RADIUS Data Type registry. valid data type as defined in the RADIUS "Data Type" registry.
We consistently use "Attr-Data" to refer to the contents of an We consistently use "Attr-Data" to refer to the contents of an
attribute, instead of the more ambiguous name "Value". It is attribute, instead of the more ambiguous name "Value". It is
RECOMMENDED that new specifications follow this practice. RECOMMENDED that new specifications follow this practice.
We consistently use "Value" to refer to the contents of a data type, We consistently use "Value" to refer to the contents of a data type,
where that data type is simple. For example, an "integer" can have a where that data type is simple. For example, an "integer" can have a
"Value". In contrast, a Vendor-Specific attribute carries complex "Value". In contrast, a Vendor-Specific Attribute carries complex
information, and thus cannot have a "Value". information and thus cannot have a "Value".
For data types which carry complex information, we name the fields For data types that carry complex information, we name the fields
based on the data type. For example, a Vendor-Specific attribute is based on the data type. For example, a Vendor-Specific Attribute is
defined to carry a "vsa" data type, and the contents of that data defined to carry a "vsa" data type, and the contents of that
type are described herein as "VSA-Data". data type are described herein as "VSA-Data".
These terms are used in preference to the term "String", which was These terms are used in preference to the term "String", which was
previously used in ambiguous ways. It is RECOMMENDED that future previously used in ambiguous ways. It is RECOMMENDED that future
specifications use type-specific names, and the same naming scheme specifications use type-specific names and the same naming scheme for
for new types. This use will maintain consistent definitions, and new types. This use will maintain consistent definitions and help to
help to avoid ambiguities. avoid ambiguities.
2.1.2. Attribute Definitions using Data Types 2.1.2. Attribute Definitions Using Data Types
New RADIUS specifications MUST define attributes using data types New RADIUS specifications MUST define attributes using data types
from the RADIUS Data Type registry. The specification may, of from the RADIUS "Data Type" registry. The specification may, of
course, define a new data type update the "Data Types" registry, and course, define a new data type, update the "Data Type" registry, and
use the new data type, all in the same document. The guidelines use the new data type, all in the same document. The guidelines
given in [RFC6929] MUST be followed when defining a new data type. given in [RFC6929] MUST be followed when defining a new data type.
Attributes can usually be completely described via the Attribute Type Attributes can usually be completely described via the Attribute Type
value, name, and data type. The use of "ASCII art" is then limited value, name, and data type. The use of ASCII art is then limited
only to the definition of new data types, and for complex data types. only to the definition of new data types and for complex data types.
Use of the new extended attributes [RFC6929] makes ASCII art even Use of the new extended attributes [RFC6929] makes ASCII art even
more problematic. An attribute can be allocated from any of the more problematic. An attribute can be allocated from any of the
extended spaces, with more than one option for attribute header extended spaces, with more than one option for the attribute header
format. This allocation decision is made after the specification has format. This allocation decision is made after the specification has
been accepted for publication. As the allocation affects the format been accepted for publication. As the allocation affects the format
of the attribute header, it is essentially impossible to create the of the attribute header, it is essentially impossible to create the
correct ASCII art prior to final publication. Allocation from the correct ASCII art prior to final publication. Allocation from the
different spaces also changes the value of the Length field, also different spaces also changes the value of the Length field, making
making it difficult to define it correctly prior to final publication it difficult to define it correctly prior to final publication of the
of the document. document.
It is therefore RECOMMENDED that "ASCII art" diagrams not be used for It is therefore RECOMMENDED that ASCII art diagrams not be used for
new RADIUS attribute specifications. new RADIUS attribute specifications.
2.1.3. Format of Attribute Definitions 2.1.3. Format of Attribute Definitions
When defining a new attribute, the following fields SHOULD be given: When defining a new attribute, the following fields SHOULD be given:
Description Description
A description of the meaning and interpretation of the A description of the meaning and interpretation of the
attribute. attribute.
Type Type
The Attribute Type value, given in the "dotted number" notation The Attribute Type value, given in the "dotted number" notation
from [RFC6929]. Specifications can often leave this as "TBD", from [RFC6929]. Specifications can often leave this as "TBD"
and request that IANA fill in the allocated values. (to be determined) and request that IANA fill in the allocated
values.
Length Length
A description of the length of the attribute. For attributes A description of the length of the attribute. For attributes
of variable length, a maximum length SHOULD be given. Since of variable length, a maximum length SHOULD be given. Since
the Length may depend on the Type, the definition of Length may the Length value may depend on the Type value, the definition
be affected by IANA allocations. of Length may be affected by IANA allocations.
Data Type Data Type
One of the named data types from the RADIUS Data Type registry. One of the named data types from the RADIUS "Data Type"
registry.
Value Value
A description of any attribute-specific limitations on the A description of any attribute-specific limitations on the
values carried by the specified data type. If there are no values carried by the specified data type. If there are no
attribute-specific limitations, then the description of this attribute-specific limitations, then the description of this
field can be omitted, so long as the Description field is field can be omitted, so long as the Description field is
sufficiently explanatory. sufficiently explanatory.
Where the values are limited to a subset of the possible range, Where the values are limited to a subset of the possible range,
valid range(s) MUST be defined. valid range(s) MUST be defined.
For attributes of data type "enum", a list of enumerated values For attributes of data type "enum", a list of enumerated values
and names MUST be given, as with [RFC2865] Section 5.6. and names MUST be given, as shown in [RFC2865], Section 5.6.
Using a consistent format for attribute definitions helps to make the Using a consistent format for attribute definitions helps to make the
definitions clearer. definitions clearer.
2.1.4. Defining a New Data Type 2.1.4. Defining a New Data Type
When a specification needs to define a new data type, it SHOULD When a specification needs to define a new data type, it SHOULD
follow the format used by the definitions in Section 3 of this follow the format used by the definitions in Section 3 of this
document. The text at the start of the data type definition MUST document. The text at the start of the data type definition MUST
describe the data type, including the expected use, and why a new describe the data type, including the expected use, and why a new
data type is required. That text SHOULD include limits on expected data type is required. That text SHOULD include limits on expected
values, and why those limits exist. The field's "Name", "Value", values and why those limits exist. The fields "Name", "Value",
"Length", and "Format", MUST be given, along with values. "Length", and "Format" MUST be given, along with values.
The "Name" field SHOULD be a single name, all lower-case. The Name field SHOULD be a single name, all lowercase.
Contractions such as "ipv4addr" are RECOMMENDED where they add Contractions such as "ipv4addr" are RECOMMENDED where they add
clarity. clarity.
We note that the use of "Value" in the RADIUS Data Type registry can We note that the use of "Value" in the RADIUS "Data Type" registry
be confusing. That name is also used in attribute definitions, but can be confusing. That name is also used in attribute definitions,
with a different meaning. We trust that the meaning here is clear but with a different meaning. We trust that the meaning here is
from the context. clear from the context.
The "Value" field SHOULD be given as to be determined or "TBD" in The Value field SHOULD be given as "TBD" in specifications. That
specifications. That number is assigned by IANA. number is assigned by IANA.
The "Format" field SHOULD be defined with "ASCII art" in order to The Format field SHOULD be defined with ASCII art in order to have a
have a precise definition. Machine-readable formats are also precise definition. Machine-readable formats are also RECOMMENDED.
RECOMMENDED.
The definition of a new data type should be done only when absolutely The definition of a new data type should be done only when absolutely
necessary. We do not expect a need for a large number of new data necessary. We do not expect a need for a large number of new
types. When defining a new data type, the guideliness of [RFC6929] data types. When defining a new data type, the guidelines of
with respect to data types MUST be followed. [RFC6929] with respect to data types MUST be followed.
It is RECOMMENDED that vendors not define "vendor specific" data It is RECOMMENDED that vendors not define "vendor-specific"
types. As discussed in [RFC6929], those data types are rarely data types. As discussed in [RFC6929], those data types are rarely
necessary, and can cause interoperability problems. necessary and can cause interoperability problems.
Any new data type MUST have unique name in the RADIUS Data Type Any new data type MUST have a unique name in the RADIUS "Data Type"
registry. The number of the data type will be assigned by IANA. registry. The number of the data type will be assigned by IANA.
2.2. Implementation Use of Data Types 2.2. Implementation Use of Data Types
Implementations not supporting a particular data type MUST treat Implementations not supporting a particular data type MUST treat
attributes of that data type as being of data type "string", as attributes of that data type as being of data type "string", as
defined in Section 3.6. It is RECOMMENDED that such attributes be defined in Section 3.5. It is RECOMMENDED that such attributes
treated as "invalid attributes", as defined in [RFC6929] Section 2.8. be treated as "invalid attributes", as defined in
[RFC6929], Section 2.8.
Where the contents of a data type do not match the definition, Where the contents of a data type do not match the definition,
implementations MUST treat the the enclosing attribute as being an implementations MUST treat the enclosing attribute as being an
"invalid attribute". This requirement includes, but is not limited invalid attribute. This requirement includes, but is not limited to,
to, the following situations: the following situations:
* Attributes with values outside of the allowed range(s) for the * Attributes with values outside of the allowed range(s) for the
data type, e.g. as given in the data types "integer", "ipv4addr", data type, e.g., as given in the data types "integer", "ipv4addr",
"ipv6addr", "ipv4prefix", "ipv6prefix", or "enum". "ipv6addr", "ipv4prefix", "ipv6prefix", or "enum".
* "text" attributes where the contents do not match the required * "text" attributes where the contents do not match the required
format, format.
* Attributes where the length is shorter or longer than the allowed * Attributes where the length is shorter or longer than the allowed
length(s) for the given data type, length(s) for the given data type.
The requirements for "reserved" fields are more difficult to The requirements for Reserved fields are more difficult to quantify.
quantify. Implementations SHOULD be able to receive and process Implementations SHOULD be able to receive and process attributes
attributes where "reserved" fields are non-zero. We do not, however, where Reserved fields are non-zero. We do not, however, define any
define any "correct" processing of such attributes. Instead, "correct" processing of such attributes. Instead, specifications
specifications which define new meaning for "reserved" fields SHOULD that define one or more new meanings for Reserved fields SHOULD
describe how the new meaning is compatible with older describe how each new meaning is compatible with older
implementations. We expect that such descriptions are derived from implementations. We expect that such descriptions are derived from
practice. Implementations MUST set "reserved" fields to zero when practical experience with implementations. Implementations MUST set
creating attributes. Reserved fields to zero when creating attributes.
3. Data Type Definitions 3. Data Type Definitions
This section defines the new data types. For each data type, it This section defines the new data types. For each data type, it
gives a definition, a name, a number, a length, and an encoding gives a definition, a name, a number, a length, and an encoding
format. Where relevant, it describes subfields contained within the format. Where relevant, it describes subfields contained within the
data type. These definitions have no impact on existing RADIUS data type. These definitions have no impact on existing RADIUS
implementations. There is no requirement that implementations use implementations. There is no requirement that implementations use
these names. these names.
Where possible, the name of each data type has been taken from Where possible, the name of each data type has been taken from
previous specifications. In some cases, a different name has been previous specifications. In some cases, a different name has been
chosen. The change of name is sometimes required to avoid ambiguity chosen. The change of name is sometimes required to avoid ambiguity
(i.e. "address" versus "Address"). Otherwise, the new name has been (i.e., "address" versus "Address"). Otherwise, the new name has been
chosen to be compatible with [RFC2865], or with use in common chosen to be compatible with [RFC2865] or with usage in common
implementations. In some cases, new names are chosen to clarify the implementations. In some cases, new names are chosen to clarify the
interpretation of the data type. interpretation of the data type.
The numbers assigned herein for the data types have no meaning other The numbers assigned herein for the data types have no meaning other
than to permit them to be tracked by IANA. As RADIUS does not encode than to permit them to be tracked by IANA. As RADIUS does not encode
information about data types in a packet, the numbers assigned to a information about data types in a packet, the numbers assigned to a
data type will never occur in a packet. It is RECOMMENDED that new data type will never occur in a packet. It is RECOMMENDED that new
implementations use the names defined in this document, in order to implementations use the names defined in this document in order to
avoid confusion. Existing implementations may choose to use the avoid confusion. Existing implementations may choose to use the
names defined here, but that is not required. names defined here, but that is not required.
The encoding of each data type is taken from previous specifications. The encoding of each data type is taken from previous specifications.
The fields are transmitted from left to right. The fields are transmitted from left to right.
Where the data types have inter-dependencies, the simplest data type Where the data types have interdependencies, the simplest data type
is given first, and dependent ones are given later. is given first, and dependent ones are given later.
We do not create specific data types for the "tagged" attributes We do not create specific data types for the "tagged" attributes
defined in [RFC2868]. That specification defines the "tagged" (i.e., attributes containing a Tag field) defined in [RFC2868]. That
attributes as being backwards compatible with pre-existing data specification defines the tagged attributes as being backwards
types. In addition, [RFC6158] Section 2.1 says that "tagged" compatible with pre-existing data types. In addition,
attributes should not be used. There is therefore no benefit to [RFC6158], Section 2.1 says that tagged attributes should not be
defining additional data types for these attributes. We trust that used. There is therefore no benefit to defining additional
implementors will be aware that tagged attributes must be treated data types for these attributes. We trust that implementors will be
differently from non-tagged attributes of the same data type. aware that tagged attributes must be treated differently from
non-tagged attributes of the same data type.
Similarly, we do not create data types for some attributes having Similarly, we do not create data types for some attributes having a
complex structure, such as CHAP-Password, ARAP-Features, or Location- complex structure, such as CHAP-Password, ARAP-Features, or
Information. We need to strike a balance between correcting earlier Location-Information. ("CHAP" refers to the Challenge Handshake
mistakes, and making this document more complex. In some cases, it Authentication Protocol, and "ARAP" refers to the Apple Remote Access
is better to treat complex attributes as being of type "string", even Protocol.) We need to strike a balance between correcting earlier
mistakes and making this document more complex. In some cases, it is
better to treat complex attributes as being of type "string", even
though they need to be interpreted by RADIUS implementations. The though they need to be interpreted by RADIUS implementations. The
guidelines given in Section 6.3 of [RFC6929] were used to make this guidelines given in Section 6.3 of [RFC6929] were used to make this
determination. determination.
3.1. integer 3.1. integer
The "integer" data type encodes a 32-bit unsigned integer in network The "integer" data type encodes a 32-bit unsigned integer in network
byte order. Where the range of values for a particular attribute is byte order. Where the range of values for a particular attribute is
limited to a sub-set of the values, specifications MUST define the limited to a subset of the values, specifications MUST define the
valid range. Attributes with Values outside of the allowed ranges valid range. Attributes with Values outside of the allowed ranges
SHOULD be treated as "invalid attributes". SHOULD be treated as invalid attributes.
Name Name
integer integer
Value Value
1 1
Length Length
skipping to change at page 12, line 41 skipping to change at page 12, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2. enum 3.2. enum
The "enum" data type encodes a 32-bit unsigned integer in network The "enum" data type encodes a 32-bit unsigned integer in network
byte order. It differs from the "integer" data type only in that it byte order. It differs from the "integer" data type only in that it
is used to define enumerated types, such as Service-Type (Section 5.6 is used to define enumerated types, such as Service-Type (Section 5.6
of [RFC2865]). Specifications MUST define a valid set of enumerated of [RFC2865]). Specifications MUST define a valid set of enumerated
values, along with a unique name for each value. Attributes with values, along with a unique name for each value. Attributes with
Values outside of the allowed enumerations SHOULD be treated as Values outside of the allowed enumerations SHOULD be treated as
"invalid attributes". invalid attributes.
Name Name
enum enum
Value Value
2 2
Length Length
skipping to change at page 13, line 18 skipping to change at page 13, line 21
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3. time 3.3. time
The "time" data type encodes time as a 32-bit unsigned value in The "time" data type encodes time as a 32-bit unsigned value in
network byte order and in seconds since 00:00:00 UTC, January 1, network byte order and in seconds since 00:00:00 UTC, January 1,
1970. We note that dates before the year 2016 are likely to indicate 1970. We note that dates before the year 2017 are likely to indicate
configuration errors, or lack of access to the correct time. configuration errors or lack of access to the correct time.
Note that the "time" attribute is defined to be unsigned, which means Note that the "time" attribute is defined to be unsigned, which means
it is not subject to a signed integer overflow in the year 2038. that it is not subject to a signed integer overflow in the year 2038.
Name Name
time time
Value Value
3 3
Length Length
skipping to change at page 13, line 48 skipping to change at page 14, line 9
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time | | Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.4. text 3.4. text
The "text" data type encodes UTF-8 text [RFC3629]. The maximum The "text" data type encodes UTF-8 text [RFC3629]. The maximum
length of the text is given by the encapsulating attribute. Where length of the text is given by the encapsulating attribute. Where
the range of lengths for a particular attribute is limited to a sub- the range of lengths for a particular attribute is limited to a
set of possible lengths, specifications MUST define the valid subset of possible lengths, specifications MUST define the valid
range(s). Attributes with length outside of the allowed values range(s). Attributes with lengths outside of the allowed values
SHOULD be treated as "invalid attributes". SHOULD be treated as invalid attributes.
Attributes of type "text" which are allocated in the standard space Attributes of type "text" that are allocated in the standard space
(Section 1.2 of [RFC6929]) are limited to no more than 253 octets of (Section 1.2 of [RFC6929]) are limited to no more than 253 octets of
data. Attributes of type "text" which are allocated in the extended data. Attributes of type "text" that are allocated in the extended
space can be longer. In both cases, these limits are reduced when space can be longer. In both cases, these limits are reduced when
the data is encapsulated inside of an another attribute. the data is encapsulated inside of another attribute.
Where the text is intended to carry data in a particular format, Where the text is intended to carry data in a particular format
(e.g. Framed-Route), the format MUST be given. The specification (e.g., Framed-Route), the format MUST be given. The specification
SHOULD describe the format in a machine-readable way, such as via SHOULD describe the format in a machine-readable way, such as via the
Augmented Backus-Naur Form (ABNF) [RFC5234]. Attributes with values Augmented Backus-Naur Form (ABNF) [RFC5234]. Attributes with
not matching the defined format SHOULD be treated as "invalid Values not matching the defined format SHOULD be treated as
attributes". invalid attributes.
Note that the "text" data type does not terminate with a NUL octet Note that the "text" data type does not terminate with a NUL octet
(hex 00). The Attribute has a Length field and does not use a (hex 00). The Attribute has a Length field and does not use a
terminator. Texts of length zero (0) MUST NOT be sent; omit the terminator. Texts of length zero (0) MUST NOT be sent; omit the
entire attribute instead. entire attribute instead.
Name Name
text text
Value Value
4 4
Length Length
One or more octets. One or more octets
Format Format
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
| Value ... | Value ...
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
3.5. string 3.5. string
The "string" data type encodes binary data, as a sequence of The "string" data type encodes binary data as a sequence of
undistinguished octets. Where the range of lengths for a particular undistinguished octets. Where the range of lengths for a particular
attribute is limited to a sub-set of possible lengths, specifications attribute is limited to a subset of possible lengths, specifications
MUST define the valid range(s). Attributes with length outside of MUST define the valid range(s). Attributes with lengths outside of
the allowed values SHOULD be treated as "invalid attributes". the allowed values SHOULD be treated as invalid attributes.
Attributes of type "string" which are allocated in the standard space Attributes of type "string" that are allocated in the standard space
(Section 1.2 of [RFC6929]) are limited to no more than 253 octets of (Section 1.2 of [RFC6929]) are limited to no more than 253 octets of
data. Attributes of type "string" which are allocated in the data. Attributes of type "string" that are allocated in the extended
extended space can be longer. In both cases, these limits are space can be longer. In both cases, these limits are reduced when
reduced when the data is encapsulated inside of an another attribute. the data is encapsulated inside of another attribute.
Note that the "string" data type does not terminate with a NUL octet Note that the "string" data type does not terminate with a NUL octet
(hex 00). The Attribute has a Length field and does not use a (hex 00). The Attribute has a Length field and does not use a
terminator. Strings of length zero (0) MUST NOT be sent; omit the terminator. Strings of length zero (0) MUST NOT be sent; omit the
entire attribute instead. a Where there is a need to encapsulate entire attribute instead. Where there is a need to encapsulate
complex data structures, and TLVs cannot be used, the "string" data complex data structures and TLVs cannot be used, the "string"
type MUST be used. This requirement includes encapsulation of data data type MUST be used. This requirement includes encapsulation of
structures defined outside of RADIUS, which are opaque to the RADIUS data structures defined outside of RADIUS that are opaque to the
infrastucture. It also includes encapsulation of some data RADIUS infrastructure. It also includes encapsulation of some data
structures which are not opaque to RADIUS, such as the contents of structures that are not opaque to RADIUS, such as the contents of
CHAP-Password. CHAP-Password.
There is little reason to define a new RADIUS data type for only one There is little reason to define a new RADIUS data type for only one
attribute. However, where the complex data type cannot be attribute. However, where the complex data type cannot be
represented as TLVs, and is expected to be used in many attributes, a represented as TLVs and is expected to be used in many attributes, a
new data type SHOULD be defined. new data type SHOULD be defined.
These requirements are stronger than [RFC6158], which makes the above These requirements are stronger than [RFC6158], which makes the above
encapsulation a "SHOULD". This document defines data types for use encapsulation a "SHOULD". This document defines data types for use
in RADIUS, so there are few reasons to avoid using them. in RADIUS, so there are few reasons to avoid using them.
Name Name
string string
Value Value
5 5
Length Length
One or more octets. One or more octets
Format Format
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
| Octets ... | Octets ...
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
3.6. concat 3.6. concat
The "concat" data type permits the transport of more than 253 octets The "concat" data type permits the transport of more than 253 octets
of data in a "standard space" [RFC6929] attribute. It is otherwise of data in a "standard space" [RFC6929] attribute. It is otherwise
identical to the "string" data type. identical to the "string" data type.
If multiple attributes of this data type are contained in a packet, If multiple attributes of this data type are contained in a packet,
all attributes of the same type code MUST be in order and they MUST all attributes of the same type code MUST be in order, and they MUST
be consecutive attributes in the packet. be consecutive attributes in the packet.
The amount of data transported in a "concat" data type can be no more The amount of data transported in a "concat" data type can be no more
than the RADIUS packet size. In practice, the requirement to than the RADIUS packet size. In practice, the requirement to
transport multiple attributes means that the limit may be transport multiple attributes means that the limit may be
substantially smaller than one RADIUS packet. As a rough guide, is substantially smaller than one RADIUS packet. As a rough guide, it
RECOMMENDED that this data type transport no more than 2048 octets of is RECOMMENDED that this data type transport no more than 2048 octets
data. of data.
The "concat" data type MAY be used for "standard space" attributes. The "concat" data type MAY be used for "standard space" attributes.
It MUST NOT be used for attributes in the "short extended space" or It MUST NOT be used for attributes in the "short extended space" or
the "long extended space". It MUST NOT be used in any field or the "long extended space". It MUST NOT be used in any field or
subfields of the following data types: "tlv", "vsa", "extended", subfields of the following data types: "tlv", "vsa", "extended",
"long-extended", or "evs". "long-extended", or "evs".
Name Name
concat concat
Value Value
6 6
Length Length
One or more octets. One or more octets
Format Format
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
| Octets ... | Octets ...
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
3.7. ifid 3.7. ifid
The "ifid" data type encodes an Interface-Id as an 8 octet IPv6 The "ifid" data type encodes an Interface-Id as an 8-octet IPv6
Interface Identifier network byte order. Interface Identifier in network byte order.
Name Name
ifid ifid
Value Value
7 7
Length Length
Eight octets Eight octets
Format Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface-ID ... | Interface-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Interface-ID | ... Interface-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8. ipv4addr 3.8. ipv4addr
The "ipv4addr" data type encodes an IPv4 address in network byte The "ipv4addr" data type encodes an IPv4 address in network byte
order. Where the range of address for a particular attribute is order. Where the range of addresses for a particular attribute is
limited to a sub-set of possible addresses, specifications MUST limited to a subset of possible addresses, specifications MUST define
define the valid range(s). Attributes with Addresses outside of the the valid range(s). Attributes with Address values outside of the
allowed range(s) SHOULD be treated as "invalid attributes". allowed range(s) SHOULD be treated as invalid attributes.
Name Name
ipv4addr ipv4addr
Value Value
8 8
Length Length
skipping to change at page 18, line 10 skipping to change at page 18, line 36
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | | Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.9. ipv6addr 3.9. ipv6addr
The "ipv6addr" data type encodes an IPv6 address in network byte The "ipv6addr" data type encodes an IPv6 address in network byte
order. Where the range of address for a particular attribute is order. Where the range of addresses for a particular attribute is
limited to a sub-set of possible addresses, specifications MUST limited to a subset of possible addresses, specifications MUST define
define the valid range(s). Attributes with Addresses outside of the the valid range(s). Attributes with Address values outside of the
allowed range(s) SHOULD be treated as "invalid attributes". allowed range(s) SHOULD be treated as invalid attributes.
Name Name
ipv6addr ipv6addr
Value Value
9 9
Length Length
skipping to change at page 18, line 45 skipping to change at page 19, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address ... ... Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address | ... Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.10. ipv6prefix 3.10. ipv6prefix
The "ipv6prefix" data type encodes an IPv6 prefix, using both a The "ipv6prefix" data type encodes an IPv6 prefix, using both a
prefix length and an IPv6 address in network byte order. Where the prefix length and an IPv6 address in network byte order. Where the
range of prefixes for a particular attribute is limited to a sub-set range of prefixes for a particular attribute is limited to a subset
of possible prefixes, specifications MUST define the valid range(s). of possible prefixes, specifications MUST define the valid range(s).
Attributes with Addresses outside of the allowed range(s) SHOULD be Attributes with Address values outside of the allowed range(s) SHOULD
treated as "invalid attributes". be treated as invalid attributes.
Attributes with a Prefix-Length field having value greater than 128 Attributes with a Prefix-Length field having a value greater than 128
MUST be treated as "invalid attributes". MUST be treated as invalid attributes.
Name Name
ipv6prefix ipv6prefix
Value Value
10 10
Length Length
At least two, and no more than eighteen octets. At least two, and no more than eighteen, octets
Format Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix-Length | Prefix ... | Reserved | Prefix-Length | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix ... ... Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 52 skipping to change at page 20, line 37
The length of the prefix, in bits. At least 0 and no larger The length of the prefix, in bits. At least 0 and no larger
than 128. This field is one octet in length. than 128. This field is one octet in length.
Prefix Prefix
The Prefix field is up to 16 octets in length. Bits outside of The Prefix field is up to 16 octets in length. Bits outside of
the Prefix-Length, if included, MUST be zero. the Prefix-Length, if included, MUST be zero.
The Prefix field SHOULD NOT contain more octets than necessary The Prefix field SHOULD NOT contain more octets than necessary
to encode the Prefix. to encode the Prefix field.
3.11. ipv4prefix 3.11. ipv4prefix
The "ipv4prefix" data type encodes an IPv4 prefix, using both a The "ipv4prefix" data type encodes an IPv4 prefix, using both a
prefix length and an IPv4 address in network byte order. Where the prefix length and an IPv4 address in network byte order. Where the
range of prefixes for a particular attribute is limited to a sub-set range of prefixes for a particular attribute is limited to a subset
of possible prefixes, specifications MUST define the valid range(s). of possible prefixes, specifications MUST define the valid range(s).
Attributes with Addresses outside of the allowed range(s) SHOULD be Attributes with Address values outside of the allowed range(s) SHOULD
treated as "invalid attributes". be treated as invalid attributes.
Attributes with a Prefix-Length field having value greater than 32 Attributes with a Prefix-Length field having a value greater than 32
MUST be treated as "invalid attributes". MUST be treated as invalid attributes.
Name Name
ipv4prefix ipv4prefix
Value Value
11 11
Length Length
six octets Six octets
Format Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix-Length | Prefix ... | Reserved | Prefix-Length | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix | ... Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields Subfields
Reserved Reserved
This field, which is reserved and MUST be present, is always This field, which is reserved and MUST be present, is always
set to zero. This field is one octet in length. set to zero. This field is one octet in length.
Note that this definition differs from that given in [RFC6572]. Note that this definition differs from that given in [RFC6572].
See Prefix-Length, below, for an explanation. See "Prefix-Length", below, for an explanation.
Prefix-Length Prefix-Length
The length of the prefix, in bits. The values MUST be no The length of the prefix, in bits. The values MUST be no
larger than 32. This field is one octet in length. larger than 32. This field is one octet in length. Note that
this definition differs from that given in [RFC6572].
Note that this definition differs from that given in [RFC6572].
As compared to [RFC6572], the Prefix-Length field has increased As compared to [RFC6572], the Prefix-Length field has increased
in size by two bits, both of which must be zero. The Reserved in size by two bits, both of which must be zero. The
field has decreased in size by two bits. The result is that Reserved field has decreased in size by two bits. The result
both fields are aligned on octet boundaries, which removes the is that both fields are aligned on octet boundaries, which
need for bit masking of the fields. removes the need for bit masking of the fields.
Since [RFC6572] required the Reserved field to be zero, the Since [RFC6572] required the Reserved field to be zero, the
definition here is compatible with the definition in the definition here is compatible with the definition in the
original specification. original specification.
Prefix Prefix
The Prefix field is 4 octets in length. Bits outside of the The Prefix field is 4 octets in length. Bits outside of the
Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type, Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type,
this field is fixed length. If the address is all zeros (i.e. this field is fixed length. If the address is all zeros (i.e.,
"0.0.0.0", then the Prefix-Length MUST be set to 32. "0.0.0.0"), then the Prefix-Length MUST be set to 32.
3.12. integer64 3.12. integer64
The "integer64" data type encodes a 64-bit unsigned integer in The "integer64" data type encodes a 64-bit unsigned integer in
network byte order. Where the range of values for a particular network byte order. Where the range of values for a particular
attribute is limited to a sub-set of the values, specifications MUST attribute is limited to a subset of the values, specifications MUST
define the valid range(s). Attributes with Values outside of the define the valid range(s). Attributes with Values outside of the
allowed range(s) SHOULD be treated as "invalid attributes". allowed range(s) SHOULD be treated as invalid attributes.
Name Name
integer64 integer64
Value Value
12 12
Length Length
skipping to change at page 22, line 4 skipping to change at page 22, line 44
Eight octets Eight octets
Format Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Value | ... Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.13. tlv 3.13. tlv
The "tlv" data type encodes a type-length-value, as defined in The "tlv" data type encodes a Type-Length-Value, as defined in
[RFC6929] Section 2.3. [RFC6929], Section 2.3.
Name Name
tlv tlv
Value Value
13 13
Length Length
skipping to change at page 22, line 38 skipping to change at page 23, line 36
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-Type | TLV-Length | TLV-Data ... | TLV-Type | TLV-Length | TLV-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields Subfields
TLV-Type TLV-Type
This field is one octet. Up-to-date values of this field are This field is one octet. Up-to-date values of this field are
specified according to the policies and rules described in specified according to the policies and rules described in
[RFC6929] Section 10. Values of 254-255 are "Reserved" for use [RFC6929], Section 10. Values of 254-255 are reserved for use
by future extensions to RADIUS. The value 26 has no special by future extensions to RADIUS. The value 26 has no special
meaning, and MUST NOT be treated as a Vendor Specific meaning and MUST NOT be treated as a Vendor-Specific Attribute.
attribute.
The TLV-Type is meaningful only within the context defined by The TLV-Type is meaningful only within the context defined by
"Type" fields of the encapsulating Attributes, using the Type fields of the encapsulating Attributes, using the
dotted-number notation introduced in [RFC6929]. dotted-number notation introduced in [RFC6929].
A RADIUS server MAY ignore Attributes with an unknown "TLV- A RADIUS server MAY ignore Attributes with an unknown
Type". "TLV-Type".
A RADIUS client MAY ignore Attributes with an unknown "TLV- A RADIUS client MAY ignore Attributes with an unknown
Type". "TLV-Type".
A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- A RADIUS proxy SHOULD forward Attributes with an unknown
Type" verbatim. "TLV-Type" verbatim.
TLV-Length TLV-Length
The TLV-Length field is one octet, and indicates the length of The TLV-Length field is one octet and indicates the length of
this TLV including the TLV-Type, TLV-Length and TLV-Value this TLV, including the TLV-Type, TLV-Length, and TLV-Value
fields. It MUST have a value between 3 and 255. If a client fields. It MUST have a value between 3 and 255. If a client
or server receives a TLV with an invalid TLV-Length, then the or server receives a TLV with an invalid TLV-Length, then the
attribute which encapsulates that TLV MUST be considered to be attribute that encapsulates that TLV MUST be considered to be
an "invalid attribute", and handled as per [RFC6929] Section an invalid attribute and is handled as per
2.8. [RFC6929], Section 2.8.
TLVs having TLV-Length of two (2) MUST NOT be sent; omit the TLVs having a TLV-Length of two (2) MUST NOT be sent; omit the
entire TLV instead. entire TLV instead.
TLV-Data TLV-Data
The TLV-Data field is one or more octets and contains The TLV-Data field is one or more octets and contains
information specific to the Attribute. The format and length information specific to the attribute. The format and length
of the TLV-Data field is determined by the TLV-Type and TLV- of the TLV-Data field are determined by the TLV-Type and
Length fields. TLV-Length fields.
The TLV-Data field MUST contain only known RADIUS data types. The TLV-Data field MUST contain only known RADIUS data types.
The TLV-Data field MUST NOT contain any of the following data The TLV-Data field MUST NOT contain any of the following
types: "concat", "vsa", "extended", "long-extended", or "evs". data types: "concat", "vsa", "extended", "long-extended",
or "evs".
3.14. vsa 3.14. vsa
The "vsa" data type encodes Vendor-Specific data, as given in The "vsa" data type encodes vendor-specific data, as given in
[RFC2865] Section 5.26. It is used only in the Attr-Data field of a [RFC2865], Section 5.26. It is used only in the Attr-Data field of a
Vendor-Specific Attribute. It MUST NOT appear in the contents of any Vendor-Specific Attribute. It MUST NOT appear in the contents of any
other data type. other data type.
Where an implementation determines that an attribute of data type Where an implementation determines that an attribute of data type
"vsa" contains data which does not match the expected format, it "vsa" contains data that does not match the expected format, it
SHOULD treat that attribute as being an "invalid attribute". SHOULD treat that attribute as being an invalid attribute.
Name Name
vsa vsa
Value Value
14 14
Length Length
skipping to change at page 24, line 21 skipping to change at page 25, line 20
| Vendor-Id | | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VSA-Data .... | VSA-Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields Subfields
Vendor-Id Vendor-Id
The 4 octets are the Network Management Private Enterprise Code The 4 octets are the Network Management Private Enterprise Code
[PEN] of the Vendor in network byte order. [PEN] of the vendor in network byte order.
VSA-Data VSA-Data
The VSA-Data field is one or more octets. The actual format of The VSA-Data field is one or more octets. The actual format of
the information is site or application specific, and a robust the information is site specific or application specific, and a
implementation SHOULD support the field as undistinguished robust implementation SHOULD support the field as
octets. 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 "vsa" data type SHOULD contain as a sequence of "tlv" data The "vsa" data type SHOULD contain a sequence of "tlv"
types. The interpretation of the TLV-Type and TLV-Data fields data types. The interpretation of the TLV-Type and TLV-Data
are dependent on the vendor's definition of that attribute. fields is dependent on the vendor's definition of that
attribute.
The "vsa" data type MUST be used as contents of the Attr-Data The "vsa" data type MUST be used as the contents of the
field of the Vendor-Specific attribute. The "vsa" data type Attr-Data field of the Vendor-Specific Attribute. The "vsa"
MUST NOT appear in the contents of any other data type. data type MUST NOT appear in the contents of any other
data type.
3.15. extended 3.15. extended
The "extended" data type encodes the "Extended Type" format, as given The "extended" data type encodes the "Extended Type" format, as given
in [RFC6929] Section 2.1. It is used only in the Attr-Data field of in [RFC6929], Section 2.1. It is used only in the Attr-Data field of
an Attribute allocated from the "standard space". It MUST NOT appear an attribute allocated from the standard space. It MUST NOT appear
in the contents of any other data type. in the contents of any other data type.
Name Name
extended extended
Value Value
15 15
skipping to change at page 25, line 27 skipping to change at page 26, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended-Type | Ext-Data ... | Extended-Type | Ext-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields Subfields
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of The Extended-Type field is one octet. Up-to-date values of
this field are specified according to the policies and rules this field are specified according to the policies and rules
described in [RFC6929] Section 10. Unlike the Type field described in [RFC6929], Section 10. Unlike the Type field
defined in [RFC2865] Section 5, no values are allocated for defined in [RFC2865], Section 5, no values are allocated for
experimental or implementation-specific use. Values 241-255 experimental or implementation-specific use. Values 241-255
are reserved and MUST NOT be used. are reserved and MUST NOT be used.
The Extended-Type is meaningful only within a context defined The Extended-Type is meaningful only within a context defined
by the Type field. That is, this field may be thought of as by the Type field. That is, this field may be thought of as
defining a new type space of the form "Type.Extended-Type". defining a new type space of the form "Type.Extended-Type".
See [RFC6929] Section 2.5 for additional discussion. See [RFC6929], Section 2.1 for additional discussion.
A RADIUS server MAY ignore Attributes with an unknown A RADIUS server MAY ignore Attributes with an unknown
"Type.Extended-Type". "Type.Extended-Type".
A RADIUS client MAY ignore Attributes with an unknown A RADIUS client MAY ignore Attributes with an unknown
"Type.Extended-Type". "Type.Extended-Type".
Ext-Data Ext-Data
The contents of this field MUST be a valid data type as defined
in the RADIUS Data Type registry. The Ext-Data field MUST NOT
contain any of the following data types: "concat", "vsa",
"extended", "long-extended", or "evs".
The Ext-Data field is one or more octets. The Ext-Data field is one or more octets.
The contents of this field MUST be a valid data type as defined
in the RADIUS "Data Type" registry. The Ext-Data field
MUST NOT contain any of the following data types: "concat",
"vsa", "extended", "long-extended", or "evs".
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the Identifier of "Type.Extended-Type" to determine the
interpretation of the Ext-Data field. interpretation of the Ext-Data field.
3.16. long-extended 3.16. long-extended
The "long-extended" data type encodes the "Long Extended Type" The "long-extended" data type encodes the "Long Extended Type"
format, as given in [RFC6929] Section 2.2. It is used only in the format, as given in [RFC6929], Section 2.2. It is used only in the
Attr-Data field of an Attribute. It MUST NOT appear in the contents Attr-Data field of an attribute. It MUST NOT appear in the contents
of any other data type. of any other data type.
Name Name
long-extended long-extended
Value Value
16 16
skipping to change at page 26, line 43 skipping to change at page 28, line 14
Subfields Subfields
Extended-Type Extended-Type
This field is identical to the Extended-Type field defined This field is identical to the Extended-Type field defined
above in Section 3.15. above in Section 3.15.
M (More) M (More)
The More field is one (1) bit in length, and indicates whether The More field (M flag) is one (1) bit in length and indicates
or not the current attribute contains "more" than 251 octets of whether or not the current attribute contains "more" than
data. The More field MUST be clear (0) if the Length field has 251 octets of data. The More field MUST be clear (0) if the
value less than 255. The More field MAY be set (1) if the Length field has a value less than 255. The More field MAY be
Length field has value of 255. set (1) if the Length field has a value of 255.
If the More field is set (1), it indicates that the Ext-Data If the More field is set (1), it indicates that the Ext-Data
field has been fragmented across multiple RADIUS attributes. field has been fragmented across multiple RADIUS attributes.
When the More field is set (1), the attribute MUST have a When the More field is set (1), the Attribute MUST have a
Length field of value 255; there MUST be an attribute following Length field value of 255; there MUST be an attribute following
this one; and the next attribute MUST have both the same Type this one; and the next attribute MUST have both the same Type
and Extended Type. That is, multiple fragments of the same and Extended-Type. That is, multiple fragments of the same
value MUST be in order and MUST be consecutive attributes in value MUST be in order and MUST be consecutive attributes in
the packet, and the last attribute in a packet MUST NOT have the packet, and the last attribute in a packet MUST NOT have
the More field set (1). the More field set (1).
That is, a packet containing a fragmented attribute needs to That is, a packet containing a fragmented attribute needs to
contain all fragments of the attribute, and those fragments contain all fragments of the attribute, and those fragments
need to be contiguous in the packet. RADIUS does not support need to be contiguous in the packet. RADIUS does not support
inter-packet fragmentation, which means that fragmenting an inter-packet fragmentation, which means that fragmenting an
attribute across multiple packets is impossible. attribute across multiple packets is impossible.
If a client or server receives an attribute fragment with the If a client or server receives an attribute fragment with the
"More" field set (1), but for which no subsequent fragment can More field set (1), but for which no subsequent fragment can be
be found, then the fragmented attribute is considered to be an found, then the fragmented attribute is considered to be an
"invalid attribute", and handled as per [RFC6929] Section 2.8. invalid attribute and is handled as per [RFC6929], Section 2.8.
T (Truncation) T (Truncation)
This field is one bit in size and is This field is one bit in size and is called "T" for Truncation.
called "T" for Truncation. It It indicates that the attribute is intentionally truncated in
indicates that the attribute is this chunk and is to be continued in the next chunk of the
intentionally truncated in this sequence. The combination of the M flag and the T flag
chunk and is to be continued in the indicates that the attribute is fragmented (M flag) but that
next chunk of the sequence. The all of the fragments are not available in this chunk (T flag).
combination of the M flag and the T Proxies implementing [RFC6929] will see these attributes as
flag indicates that the attribute is invalid (they will not be able to reconstruct them), but they
fragmented (M flag) but that all the will still forward them, as Section 5.2 of [RFC6929] indicates
fragments are not available in this that they SHOULD forward unknown attributes anyway.
chunk (T flag). Proxies
implementing [RFC6929] will see
these attributes as invalid (they
will not be able to reconstruct
them), but they will still forward
them, as Section 5.2 of [RFC6929]
indicates that they SHOULD forward
unknown attributes anyway.
Please see [RFC7499] for further Please see [RFC7499] for further discussion of the uses of
discussion of the uses of this flag. this flag.
Reserved Reserved
This field is 6 bits long, and is This field is six bits long and is reserved for future use.
reserved for future use. Implementations MUST set it to zero (0) when encoding an
Implementations MUST set it to zero attribute for sending in a packet. The contents SHOULD be
(0) when encoding an attribute for ignored on reception.
sending in a packet. The contents
SHOULD be ignored on reception.
Future specifications may define Future specifications may define one or more additional
additional meaning for this field. meanings for this field. Implementations therefore MUST NOT
Implementations therefore MUST NOT treat this field as invalid if it is non-zero.
treat this field as invalid if it is
non-zero.
Ext-Data Ext-Data
The contents of this field MUST be a The Ext-Data field is one or more octets.
valid data type as defined in the
RADIUS Data Type registry. The Ext-
Data field MUST NOT contain any of
the following data types: "concat",
"vsa", "extended", "long-extended",
or "evs".
The Ext-Data field is one or more The contents of this field MUST be a valid data type as defined
octets. in the RADIUS "Data Type" registry. The Ext-Data field MUST
NOT contain any of the following data types: "concat", "vsa",
"extended", "long-extended", or "evs".
Implementations supporting this Implementations supporting this specification MUST use the
specification MUST use the Identifier of "Type.Extended-Type" to determine the
Identifier of "Type.Extended-Type" interpretation of the Ext-Data field.
to determine the interpretation of
the Ext-Data field.
The length of the data MUST be taken The length of the data MUST be taken as the sum of the lengths
as the sum of the lengths of the of the fragments (i.e., Ext-Data fields) from which it is
fragments (i.e. Ext-Data fields) constructed. Any interpretation of the resulting data MUST
from which it is constructed. Any occur after the fragments have been reassembled. If the
interpretation of the resulting data reassembled data does not match the expected format, each
MUST occur after the fragments have fragment MUST be treated as an invalid attribute, and the
been reassembled. If the reassembled data MUST be discarded.
reassembled data does not match the
expected format, each fragment MUST
be treated as an "invalid
attribute", and the reassembled data
MUST be discarded.
We note that the maximum size of a We note that the maximum size of a fragmented attribute is
fragmented attribute is limited only limited only by the RADIUS packet length limitation.
by the RADIUS packet length Implementations MUST be able to handle the case where one
limitation. Implementations MUST be fragmented attribute completely fills the packet.
able to handle the case where one
fragmented attribute completely
fills the packet.
3.17. evs 3.17. evs
The "evs" data type encodes an "Extended Vendor-Specific" attribute, The "evs" data type encodes an Extended-Vendor-Specific Attribute, as
as given in [RFC6929] Section 2.4. The "evs" data type is used given in [RFC6929], Section 2.4. The "evs" data type is used solely
solely to extend the Vendor Specific space. It MAY appear inside of to extend the vendor-specific space. It MAY appear inside of an
an "extended" or a "long-extended" data type. It MUST NOT appear in "extended" data type or a "long-extended" data type. It MUST NOT
the contents of any other data type. appear in the contents of any other data type.
Where an implementation determines that an attribute of data type Where an implementation determines that an attribute of data type
"evs" contains data which does not match the expected format, it "evs" contains data that does not match the expected format, it
SHOULD treat that attribute as being an "invalid attribute". SHOULD treat that attribute as being an invalid attribute.
Name Name
evs evs
Value Value
17 17
Length Length
skipping to change at page 29, line 45 skipping to change at page 30, line 44
| Vendor-Id | | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | EVS-Data .... | Vendor-Type | EVS-Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields Subfields
Vendor-Id Vendor-Id
The 4 octets are the Network Management Private Enterprise Code The 4 octets are the Network Management Private Enterprise Code
[PEN] of the Vendor in network byte order. [PEN] of the vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the vendor.
EVS-Data EVS-Data
The EVS-Data field is one or more octets. It SHOULD The EVS-Data field is one or more octets. It SHOULD
encapsulate a previously defined RADIUS data type. Non- encapsulate a previously defined RADIUS data type.
standard data types SHOULD NOT be used. We note that the EVS- Non-standard data types SHOULD NOT be used. We note that the
Data field may be of data type "tlv". EVS-Data field may be of data type "tlv".
The actual format of the information is site or application The actual format of the information is site specific or
specific, and a robust implementation SHOULD support the field application specific, and a robust implementation SHOULD
as undistinguished octets. We recognise that Vendors have support the field as undistinguished octets. We recognize that
complete control over the contents and format of the Ext-Data vendors have complete control over the contents and format of
field, while at the same time recommending that good practices the Ext-Data field; at the same time, we recommend that good
be followed. practices be followed.
Further codification of the range of allowed usage of this Further codification of the range of allowed usage of this
field is outside the scope of this specification. field is outside the scope of this specification.
4. Updated Registries 4. Updated Registries
This section defines a new IANA registry for RADIUS data types, and This section defines a new IANA registry for RADIUS data types and
then updates the existing RADIUS Attribute Type registry to use the then updates the existing "RADIUS Attribute Types" registry to use
data types from the new registry. the data types from the new registry.
4.1. Create a Data Type Registry 4.1. New "Data Type" Registry
This section defines a new registry located under "RADIUS Types", This section defines a new registry located under "RADIUS Types",
called "Data Type". The "Registration Procedures" for the Data Type called "Data Type". The registration procedures for the "Data Type"
registry are "Standards Action". registry are "Standards Action" [RFC5226].
The Data Type registry contains three columns of data, as follows. The "Data Type" registry contains three columns of data, as follows.
Value Value
The number of the data type. The value field is an artifact of The number of the data type. The Value field is an artifact of
the registry, and has no on-the-wire meaning. the registry and has no on-the-wire meaning.
Name Description
The name of the data type. The name field is used only for the The name of the data type. This field is used only for the
registry, and has no on-the-wire meaning. registry and has no on-the-wire meaning.
Reference Reference
The specification where the data type was defined. The specification where the data type was defined.
The initial contents of the registry are as follows. The initial contents of the registry are as follows.
Value Description Reference Value Description Reference
----- ----------- ---------------- ----- ----------- -------------------
1 integer [RFC2865], TBD 1 integer [RFC2865], RFC 8044
2 enum [RFC2865], TBD 2 enum [RFC2865], RFC 8044
3 time [RFC2865], TBD 3 time [RFC2865], RFC 8044
4 text [RFC2865], TBD 4 text [RFC2865], RFC 8044
5 string [RFC2865], TBD 5 string [RFC2865], RFC 8044
6 concat TBD 6 concat RFC 8044
7 ifid [RFC3162], TBD 7 ifid [RFC3162], RFC 8044
8 ipv4addr [RFC2865], TBD 8 ipv4addr [RFC2865], RFC 8044
9 ipv6addr [RFC3162], TBD 9 ipv6addr [RFC3162], RFC 8044
10 ipv6prefix [RFC3162], TBD 10 ipv6prefix [RFC3162], RFC 8044
11 ipv4prefix [RFC6572], TBD 11 ipv4prefix [RFC6572], RFC 8044
12 integer64 [RFC6929], TBD 12 integer64 [RFC6929], RFC 8044
13 tlv [RFC6929], TBD 13 tlv [RFC6929], RFC 8044
14 evs [RFC6929], TBD 14 vsa [RFC2865], RFC 8044
15 extended [RFC6929], TBD 15 extended [RFC6929], RFC 8044
16 long-extended [RFC6929], TBD 16 long-extended [RFC6929], RFC 8044
17 evs [RFC6929], RFC 8044
4.2. Updates to the Attribute Type Registry 4.2. Updates to the "RADIUS Attribute Types" Registry
This section updates the RADIUS Attribute Type registry to have a new This section updates the "RADIUS Attribute Types" registry to have a
column, which is inserted in between the existing "Description" and new column, which is inserted between the existing "Description" and
"Reference" columns. The new column is named "Data Type". The "Reference" columns. The new column is named "Data Type". The
contents of that column are the name of a data type, corresponding to contents of that column are the name of a data type, corresponding to
the attribute in that row, or blank if the attribute type is the attribute in that row, or blank if the Attribute Type is
unassigned. The name of the data type is taken from the RADIUS Data unassigned. The name of the data type is taken from the RADIUS
Type registry, as defined above. "Data Type" registry, as defined above.
The existing registration requirements for the RADIUS Attribute Type
registry are otherwise unchanged.
NOTE TO RFC EDITOR: Before the document is published, please remove this
note, and the following text in this section.
The updated registry follows in CSV format.
Value,Description,Data Type,Reference The existing registration requirements for the "RADIUS Attribute
1,User-Name,text,[RFC2865] Types" registry are otherwise unchanged.
2,User-Password,string,[RFC2865]
3,CHAP-Password,string,[RFC2865]
4,NAS-IP-Address,ipv4addr,[RFC2865]
5,NAS-Port,integer,[RFC2865]
6,Service-Type,enum,[RFC2865]
7,Framed-Protocol,enum,[RFC2865]
8,Framed-IP-Address,ipv4addr,[RFC2865]
9,Framed-IP-Netmask,ipv4addr,[RFC2865]
10,Framed-Routing,enum,[RFC2865]
11,Filter-Id,text,[RFC2865]
12,Framed-MTU,integer,[RFC2865]
13,Framed-Compression,enum,[RFC2865]
14,Login-IP-Host,ipv4addr,[RFC2865]
15,Login-Service,enum,[RFC2865]
16,Login-TCP-Port,integer,[RFC2865]
17,Unassigned,,
18,Reply-Message,text,[RFC2865]
19,Callback-Number,text,[RFC2865]
20,Callback-Id,text,[RFC2865]
21,Unassigned,,
22,Framed-Route,text,[RFC2865]
23,Framed-IPX-Network,ipv4addr,[RFC2865]
24,State,string,[RFC2865]
25,Class,string,[RFC2865]
26,Vendor-Specific,vsa,[RFC2865]
27,Session-Timeout,integer,[RFC2865]
28,Idle-Timeout,integer,[RFC2865]
29,Termination-Action,enum,[RFC2865]
30,Called-Station-Id,text,[RFC2865]
31,Calling-Station-Id,text,[RFC2865]
32,NAS-Identifier,text,[RFC2865]
33,Proxy-State,string,[RFC2865]
34,Login-LAT-Service,text,[RFC2865]
35,Login-LAT-Node,text,[RFC2865]
36,Login-LAT-Group,string,[RFC2865]
37,Framed-AppleTalk-Link,integer,[RFC2865]
38,Framed-AppleTalk-Network,integer,[RFC2865]
39,Framed-AppleTalk-Zone,text,[RFC2865]
40,Acct-Status-Type,enum,[RFC2866]
41,Acct-Delay-Time,integer,[RFC2866]
42,Acct-Input-Octets,integer,[RFC2866]
43,Acct-Output-Octets,integer,[RFC2866]
44,Acct-Session-Id,text,[RFC2866]
45,Acct-Authentic,enum,[RFC2866]
46,Acct-Session-Time,integer,[RFC2866]
47,Acct-Input-Packets,integer,[RFC2866]
48,Acct-Output-Packets,integer,[RFC2866]
49,Acct-Terminate-Cause,enum,[RFC2866]
50,Acct-Multi-Session-Id,text,[RFC2866]
51,Acct-Link-Count,integer,[RFC2866]
52,Acct-Input-Gigawords,integer,[RFC2869]
53,Acct-Output-Gigawords,integer,[RFC2869]
54,Unassigned,,
55,Event-Timestamp,time,[RFC2869]
56,Egress-VLANID,integer,[RFC4675]
57,Ingress-Filters,enum,[RFC4675]
58,Egress-VLAN-Name,text,[RFC4675]
59,User-Priority-Table,string,[RFC4675]
60,CHAP-Challenge,string,[RFC2865]
61,NAS-Port-Type,enum,[RFC2865]
62,Port-Limit,integer,[RFC2865]
63,Login-LAT-Port,text,[RFC2865]
64,Tunnel-Type,enum,[RFC2868]
65,Tunnel-Medium-Type,enum,[RFC2868]
66,Tunnel-Client-Endpoint,text,[RFC2868]
67,Tunnel-Server-Endpoint,text,[RFC2868]
68,Acct-Tunnel-Connection,text,[RFC2867]
69,Tunnel-Password,string,[RFC2868]
70,ARAP-Password,string,[RFC2869]
71,ARAP-Features,string,[RFC2869]
72,ARAP-Zone-Access,enum,[RFC2869]
73,ARAP-Security,integer,[RFC2869]
74,ARAP-Security-Data,text,[RFC2869]
75,Password-Retry,integer,[RFC2869]
76,Prompt,enum,[RFC2869]
77,Connect-Info,text,[RFC2869]
78,Configuration-Token,text,[RFC2869]
79,EAP-Message,concat,[RFC2869]
80,Message-Authenticator,string,[RFC2869]
81,Tunnel-Private-Group-ID,text,[RFC2868]
82,Tunnel-Assignment-ID,text,[RFC2868]
83,Tunnel-Preference,integer,[RFC2868]
84,ARAP-Challenge-Response,string,[RFC2869]
85,Acct-Interim-Interval,integer,[RFC2869]
86,Acct-Tunnel-Packets-Lost,integer,[RFC2867]
87,NAS-Port-Id,text,[RFC2869]
88,Framed-Pool,text,[RFC2869]
89,CUI,string,[RFC4372]
90,Tunnel-Client-Auth-ID,text,[RFC2868]
91,Tunnel-Server-Auth-ID,text,[RFC2868]
92,NAS-Filter-Rule,text,[RFC4849]
93,Unassigned,,
94,Originating-Line-Info,string,[RFC7155]
95,NAS-IPv6-Address,ipv6addr,[RFC3162]
96,Framed-Interface-Id,ifid,[RFC3162]
97,Framed-IPv6-Prefix,ipv6prefix,[RFC3162]
98,Login-IPv6-Host,ipv6addr,[RFC3162]
99,Framed-IPv6-Route,text,[RFC3162]
100,Framed-IPv6-Pool,text,[RFC3162]
101,Error-Cause Attribute,enum,[RFC3576]
102,EAP-Key-Name,string,[RFC4072][RFC7268]
103,Digest-Response,text,[RFC5090]
104,Digest-Realm,text,[RFC5090]
105,Digest-Nonce,text,[RFC5090]
106,Digest-Response-Auth,text,[RFC5090]
107,Digest-Nextnonce,text,[RFC5090]
108,Digest-Method,text,[RFC5090]
109,Digest-URI,text,[RFC5090]
110,Digest-Qop,text,[RFC5090]
111,Digest-Algorithm,text,[RFC5090]
112,Digest-Entity-Body-Hash,text,[RFC5090]
113,Digest-CNonce,text,[RFC5090]
114,Digest-Nonce-Count,text,[RFC5090]
115,Digest-Username,text,[RFC5090]
116,Digest-Opaque,text,[RFC5090]
117,Digest-Auth-Param,text,[RFC5090]
118,Digest-AKA-Auts,text,[RFC5090]
119,Digest-Domain,text,[RFC5090]
120,Digest-Stale,text,[RFC5090]
121,Digest-HA1,text,[RFC5090]
122,SIP-AOR,text,[RFC5090]
123,Delegated-IPv6-Prefix,ipv6prefix,[RFC4818]
124,MIP6-Feature-Vector,string,[RFC5447]
125,MIP6-Home-Link-Prefix,ipv6prefix,[RFC5447]
126,Operator-Name,text,[RFC5580]
127,Location-Information,string,[RFC5580]
128,Location-Data,string,[RFC5580]
129,Basic-Location-Policy-Rules,string,[RFC5580]
130,Extended-Location-Policy-Rules,string,[RFC5580]
131,Location-Capable,enum,[RFC5580]
132,Requested-Location-Info,enum,[RFC5580]
133,Framed-Management-Protocol,enum,[RFC5607]
134,Management-Transport-Protection,enum,[RFC5607]
135,Management-Policy-Id,text,[RFC5607]
136,Management-Privilege-Level,integer,[RFC5607]
137,PKM-SS-Cert,concat,[RFC5904]
138,PKM-CA-Cert,concat,[RFC5904]
139,PKM-Config-Settings,string,[RFC5904]
140,PKM-Cryptosuite-List,string,[RFC5904]
141,PKM-SAID,text,[RFC5904]
142,PKM-SA-Descriptor,string,[RFC5904]
143,PKM-Auth-Key,string,[RFC5904]
144,DS-Lite-Tunnel-Name,text,[RFC6519]
145,Mobile-Node-Identifier,string,[RFC6572]
146,Service-Selection,text,[RFC6572]
147,PMIP6-Home-LMA-IPv6-Address,ipv6addr,[RFC6572]
148,PMIP6-Visited-LMA-IPv6-Address,ipv6addr,[RFC6572]
149,PMIP6-Home-LMA-IPv4-Address,ipv4addr,[RFC6572]
150,PMIP6-Visited-LMA-IPv4-Address,ipv4addr,[RFC6572]
151,PMIP6-Home-HN-Prefix,ipv6prefix,[RFC6572]
152,PMIP6-Visited-HN-Prefix,ipv6prefix,[RFC6572]
153,PMIP6-Home-Interface-ID,ifid,[RFC6572]
154,PMIP6-Visited-Interface-ID,ifid,[RFC6572]
155,PMIP6-Home-IPv4-HoA,ipv4prefix,[RFC6572]
156,PMIP6-Visited-IPv4-HoA,ipv4prefix,[RFC6572]
157,PMIP6-Home-DHCP4-Server-Address,ipv4addr,[RFC6572]
158,PMIP6-Visited-DHCP4-Server-Address,ipv4addr,[RFC6572]
159,PMIP6-Home-DHCP6-Server-Address,ipv6addr,[RFC6572]
160,PMIP6-Visited-DHCP6-Server-Address,ipv6addr,[RFC6572]
161,PMIP6-Home-IPv4-Gateway,ipv4addr,[RFC6572]
162,PMIP6-Visited-IPv4-Gateway,ipv4addr,[RFC6572]
163,EAP-Lower-Layer,enum,[RFC6677]
164,GSS-Acceptor-Service-Name,text,[RFC7055]
165,GSS-Acceptor-Host-Name,text,[RFC7055]
166,GSS-Acceptor-Service-Specifics,text,[RFC7055]
167,GSS-Acceptor-Realm-Name,text,[RFC7055]
168,Framed-IPv6-Address,ipv6addr,[RFC6911]
169,DNS-Server-IPv6-Address,ipv6addr,[RFC6911]
170,Route-IPv6-Information,ipv6prefix,[RFC6911]
171,Delegated-IPv6-Prefix-Pool,text,[RFC6911]
172,Stateful-IPv6-Address-Pool,text,[RFC6911]
173,IPv6-6rd-Configuration,tlv,[RFC6930]
174,Allowed-Called-Station-Id,text,[RFC7268]
175,EAP-Peer-Id,string,[RFC7268]
176,EAP-Server-Id,string,[RFC7268]
177,Mobility-Domain-Id,integer,[RFC7268]
178,Preauth-Timeout,integer,[RFC7268]
179,Network-Id-Name,string,[RFC7268]
180,EAPoL-Announcement,concat,[RFC7268]
181,WLAN-HESSID,text,[RFC7268]
182,WLAN-Venue-Info,integer,[RFC7268]
183,WLAN-Venue-Language,string,[RFC7268]
184,WLAN-Venue-Name,text,[RFC7268]
185,WLAN-Reason-Code,integer,[RFC7268]
186,WLAN-Pairwise-Cipher,integer,[RFC7268]
187,WLAN-Group-Cipher,integer,[RFC7268]
188,WLAN-AKM-Suite,integer,[RFC7268]
189,WLAN-Group-Mgmt-Cipher,integer,[RFC7268]
190,WLAN-RF-Band,integer,[RFC7268]
191,Unassigned,,
192-223,Experimental Use,,[RFC3575]
224-240,Implementation Specific,,[RFC3575]
241,Extended-Attribute-1,extended,[RFC6929]
241.1,Frag-Status,integer,[RFC7499]
241.2,Proxy-State-Length,integer,[RFC7499]
241.3,Response-Length,integer,[RFC7930]
241.4,Original-Packet-Code,integer,[RFC7930]
241.{5-25},Unassigned,,
241.26,Extended-Vendor-Specific-1,evs,[RFC6929]
241.{27-240},Unassigned,,
241.{241-255},Reserved,,[RFC6929]
242,Extended-Attribute-2,extended,[RFC6929]
242.{1-25},Unassigned,,
242.26,Extended-Vendor-Specific-2,evs,[RFC6929]
242.{27-240},Unassigned,,
242.{241-255},Reserved,,[RFC6929]
243,Extended-Attribute-3,extended,[RFC6929]
243.{1-25},Unassigned,,
243.26,Extended-Vendor-Specific-3,evs,[RFC6929]
243.{27-240},Unassigned,,
243.{241-255},Reserved,,[RFC6929]
244,Extended-Attribute-4,extended,[RFC6929]
244.{1-25},Unassigned,,
244.26,Extended-Vendor-Specific-4,evs,[RFC6929]
244.{27-240},Unassigned,,
244.{241-255},Reserved,,[RFC6929]
245,Extended-Attribute-5,long-extended,[RFC6929]
245.{1-25},Unassigned,,
245.26,Extended-Vendor-Specific-5,evs,[RFC6929]
245.{27-240},Unassigned,,
245.{241-255},Reserved,,[RFC6929]
246,Extended-Attribute-6,long-extended,[RFC6929]
246.{1-25},Unassigned,,
246.26,Extended-Vendor-Specific-6,evs,[RFC6929]
246.{27-240},Unassigned,,
246.{241-255},Reserved,,[RFC6929]
247-255,Reserved,,[RFC3575]
5. Security Considerations 5. Security Considerations
This specification is concerned solely with updates to IANA This specification is concerned solely with updates to IANA
registries. As such, there are no security considerations with the registries. As such, there are no security considerations with the
document itself. document itself.
However, the use of inconsistent names and poorly-defined entities in However, the use of inconsistent names and poorly defined entities in
a protocol is problematic. Inconsistencies in specifications can a protocol is problematic. Inconsistencies in specifications can
lead to security and interoperability problems in implementations. lead to security and interoperability problems in implementations.
Further, having one canonical source for the definition of data types Further, having one canonical source for the definition of data types
means an implementor has fewer specifications to read. The means that an implementor has fewer specifications to read. The
implementation work is therefore simpler, and is more likely to be implementation work is therefore simpler and more likely to be
correct. correct.
The goal of this specification is to reduce ambiguities in the RADIUS The goal of this specification is to reduce ambiguities in the RADIUS
protocol, which we believe will lead to more robust and more secure protocol, which we believe will lead to more robust and more secure
implementations. implementations.
6. IANA Considerations 6. IANA Considerations
IANA is instructed to create one new registry as described above in IANA has created one new registry, as described in Section 4.1.
Section 4.1. The "TBD" text in that section should be replaced with
the RFC number of this document when it is published.
IANA is instructed to update the RADIUS Attribute Type registry, as IANA has updated the "RADIUS Attribute Types" registry, as described
described above in Section 4.2. in Section 4.2.
IANA is instructed to require that all allocation requests in the IANA requires that all allocation requests in the "RADIUS Attribute
RADIUS Attribute Type registry contain a "Data Type" field. That Types" registry contain a Data Type field, which is required to
field is required to contain one of the "Data Type" names contained contain one of the "Data Type" names contained in the RADIUS "Data
in the RADIUS Data Type registry. Type" registry.
IANA is instructed to require that updates to the RADIUS Data Type IANA requires that updates to the RADIUS "Data Type" registry contain
registry contain the following fields, with the associated the following fields, with the associated instructions:
instructions:
* Value. IANA is instructed to assign the next unused integer in * Value. IANA is instructed to assign the next unused integer in
sequence to new data type definitions. sequence to new data type definitions.
* Name. IANA is instructed to require that this name be unique * Name. IANA is instructed to require that this name be unique in
in the registry. the registry.
* Reference. IANA is instructed to update this field with a * Reference. IANA is instructed to update this field with a
reference to the document which defines the data type. reference to the document that defines the data type.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Bradner, S., "Key words for use in RFCs to Indicate Requirement Requirement Levels", BCP 14, RFC 2119,
Levels", RFC 2119, March, 1997. DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2865] [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote "Remote Authentication Dial In User Service (RADIUS)",
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. RFC 2865, DOI 10.17487/RFC2865, June 2000,
<http://www.rfc-editor.org/info/rfc2865>.
[RFC3162] [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, RFC 3162, DOI 10.17487/RFC3162, August 2001,
August 2001. <http://www.rfc-editor.org/info/rfc3162>.
[RFC3629] [RFC3629] Yergeau, F., "UTF-8, a transformation format of
Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
3629, November 2003. November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4072] [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
Eronen, P., et al, "Diameter Extensible Authentication Protocol Extensible Authentication Protocol (EAP) Application",
(EAP) Application", RFC 4072, February 2013. RFC 4072, DOI 10.17487/RFC4072, August 2005,
<http://www.rfc-editor.org/info/rfc4072>.
[RFC6158] [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 6158, Syntax Specifications: ABNF", STD 68, RFC 5234,
March 2011. DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC6572] [RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines",
Xia, F., et al, "RADIUS Support for Proxy Mobile IPv6", RFC 6572, BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011,
June 2012. <http://www.rfc-editor.org/info/rfc6158>.
[RFC7499] [RFC6572] Xia, F., Sarikaya, B., Korhonen, J., Ed., Gundavelli, S.,
Perez-Mendez, A. Ed., et al, "Support of Fragmentation of RADIUS and D. Damic, "RADIUS Support for Proxy Mobile IPv6",
Packets", RFC 7499, April 2015. RFC 6572, DOI 10.17487/RFC6572, June 2012,
<http://www.rfc-editor.org/info/rfc6572>.
7.2. Informative References [RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia,
F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of
Fragmentation of RADIUS Packets", RFC 7499,
DOI 10.17487/RFC7499, April 2015,
<http://www.rfc-editor.org/info/rfc7499>.
[RFC2868] 7.2. Informative References
Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I.
Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868,
June 2000.
[RFC2869] [PEN] IANA, "PRIVATE ENTERPRISE NUMBERS",
Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000. <http://www.iana.org/assignments/enterprise-numbers/>.
[RFC5234] [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
Crocker, D. and P. Overell, "Augmented BNF for Syntax M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Specifications: ABNF", RFC 5234, January 2008. Support", RFC 2868, DOI 10.17487/RFC2868, June 2000,
<http://www.rfc-editor.org/info/rfc2868>.
[RFC6929] [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
DeKok, A., and Lior, A., "Remote Authentication Dial In User Extensions", RFC 2869, DOI 10.17487/RFC2869, June 2000,
Service (RADIUS) Protocol Extensions", RFC 6929, April 2013. <http://www.rfc-editor.org/info/rfc2869>.
[RFC7268] [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Aboba, B, et al, "RADIUS Attributes for IEEE 802 Networks", RFC IANA Considerations Section in RFCs", BCP 26, RFC 5226,
7268, July 2015. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC7499] [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Perez-Mendez A., et al, "Support of Fragmentation of RADIUS Service (RADIUS) Protocol Extensions", RFC 6929,
Packets", RFC 7499, April 2015. DOI 10.17487/RFC6929, April 2013,
<http://www.rfc-editor.org/info/rfc6929>.
[PEN] [RFC7268] Aboba, B., Malinen, J., Congdon, P., Salowey, J., and M.
http://www.iana.org/assignments/enterprise-numbers Jones, "RADIUS Attributes for IEEE 802 Networks",
RFC 7268, DOI 10.17487/RFC7268, July 2014,
<http://www.rfc-editor.org/info/rfc7268>.
Acknowledgments Acknowledgments
Thanks to the RADEXT WG for patience and reviews of this document. Thanks to the RADEXT WG participants for their patience and reviews
of this document.
Authors' Addresses Author's Address
Alan DeKok Alan DeKok
The FreeRADIUS Server Project The FreeRADIUS Server Project
Email: aland@freeradius.org Email: aland@freeradius.org
 End of changes. 191 change blocks. 
774 lines changed or deleted 519 lines changed or added

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