summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8044.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8044.txt')
-rw-r--r--doc/rfc/rfc8044.txt1963
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc8044.txt b/doc/rfc/rfc8044.txt
new file mode 100644
index 0000000..fbbbcad
--- /dev/null
+++ b/doc/rfc/rfc8044.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. DeKok
+Request for Comments: 8044 FreeRADIUS
+Updates: 2865, 3162, 4072, 6158, 6572, 7268 January 2017
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ Data Types in RADIUS
+
+Abstract
+
+ RADIUS specifications have used data types for two decades without
+ defining them as managed entities. During this time, RADIUS
+ implementations have named the data types and have used them in
+ attribute definitions. This document updates the specifications to
+ better follow established practice. We do this by naming the data
+ 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
+ types and update the "RADIUS Attribute Types" registry to include a
+ Data Type field for each attribute. Finally, we recommend that
+ authors of RADIUS specifications use these types in preference to
+ existing practice. This document updates RFCs 2865, 3162, 4072,
+ 6158, 6572, and 7268.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 1]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 2]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Specification Problems with Data Types .....................4
+ 1.2. Implementation Problems with Data Types ....................5
+ 1.3. No Mandated Changes ........................................5
+ 1.4. Requirements Language ......................................5
+ 2. Use of Data Types ...............................................6
+ 2.1. Specification Use of Data Types ............................6
+ 2.1.1. Field Names for Attribute Values ....................6
+ 2.1.2. Attribute Definitions Using Data Types ..............7
+ 2.1.3. Format of Attribute Definitions .....................8
+ 2.1.4. Defining a New Data Type ............................9
+ 2.2. Implementation Use of Data Types ...........................9
+ 3. Data Type Definitions ..........................................10
+ 3.1. integer ...................................................12
+ 3.2. enum ......................................................12
+ 3.3. time ......................................................13
+ 3.4. text ......................................................14
+ 3.5. string ....................................................15
+ 3.6. concat ....................................................16
+ 3.7. ifid ......................................................17
+ 3.8. ipv4addr ..................................................18
+ 3.9. ipv6addr ..................................................18
+ 3.10. ipv6prefix ...............................................19
+ 3.11. ipv4prefix ...............................................20
+ 3.12. integer64 ................................................22
+ 3.13. tlv ......................................................23
+ 3.14. vsa ......................................................24
+ 3.15. extended .................................................26
+ 3.16. long-extended ............................................27
+ 3.17. evs ......................................................30
+ 4. Updated Registries .............................................31
+ 4.1. New "Data Type" Registry ..................................31
+ 4.2. Updates to the "RADIUS Attribute Types" Registry ..........32
+ 5. Security Considerations ........................................32
+ 6. IANA Considerations ............................................33
+ 7. References .....................................................33
+ 7.1. Normative References ......................................33
+ 7.2. Informative References ....................................34
+ Acknowledgments ...................................................35
+ Author's Address ..................................................35
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 3]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+1. Introduction
+
+ RADIUS specifications have historically defined attributes in terms
+ of name, value, and data type. Of these three pieces of information,
+ the name is recorded by IANA in the "RADIUS Attribute Types" registry
+ but is not otherwise managed or restricted, as discussed in
+ [RFC6929], Section 2.7.1. The value is managed by IANA and recorded
+ in that registry. The data type is not managed or recorded in the
+ "RADIUS Attribute Types" registry. Experience has shown that there
+ 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
+ the "RADIUS Attribute Types" registry to use those newly defined
+ data types. It recommends how both specifications and
+ implementations should use the data types. It extends the "RADIUS
+ Attribute Types" registry to have a data type for each assigned
+ attribute.
+
+ In this section, we review the use of data types in specifications
+ and implementations. We highlight ambiguities and inconsistencies.
+ The rest of this document is devoted to resolving those problems.
+
+1.1. Specification Problems with Data Types
+
+ When attributes are defined in the specifications, the terms "Value"
+ and "String" are used to refer to the contents of an attribute.
+ However, these names are used recursively and inconsistently. We
+ suggest that defining a field to recursively contain itself is
+ problematic.
+
+ A number of data type names and definitions are given in
+ [RFC2865], Section 5, at the bottom of page 25. These data types are
+ named and clearly defined. However, this practice was not continued
+ in later specifications.
+
+ Specifically, [RFC2865] defines attributes of data type "address" to
+ carry IPv4 addresses. Despite this definition, [RFC3162] defines
+ attributes of data type "Address" to carry IPv6 addresses. We
+ suggest that the use of the word "address" to refer to disparate
+ data types is problematic.
+
+ Other failures are that [RFC3162] does not give a data type name and
+ definition for the data types IPv6 address, Interface-Id, or IPv6
+ prefix. [RFC2869] defines Event-Timestamp to carry a time but does
+ not reuse the "time" data type defined in [RFC2865]. Instead, it
+ just repeats the "time" definition. [RFC6572] defines multiple
+ attributes that carry IPv4 prefixes. However, an "IPv4 prefix" data
+
+
+
+DeKok Standards Track [Page 4]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ type is not named, defined as a data type, or called out as an
+ addition to RADIUS. Further, [RFC6572] does not follow the
+ recommendations of [RFC6158] and does not explain why it fails to
+ follow those recommendations.
+
+ These ambiguities and inconsistencies need to be resolved.
+
+1.2. Implementation Problems with Data Types
+
+ RADIUS implementations often use "dictionaries" to map attribute
+ names to type values and define data types for each attribute. The
+ data types in the dictionaries are defined by each implementation but
+ correspond to the "ad hoc" data types used in the specifications.
+
+ In effect, implementations have seen the need for well-defined
+ data types and have created them. It is time for RADIUS
+ specifications to follow this practice.
+
+1.3. No Mandated Changes
+
+ This document mandates no changes to any past, present, or future
+ RADIUS implementation. It instead documents existing practice in
+ order to simplify the process of writing RADIUS specifications,
+ clarify the interpretation of RADIUS standards, and improve the
+ communication between specification authors and IANA.
+
+ This document suggests that implementations SHOULD use the data types
+ defined here, in preference to any ad hoc data types currently in
+ use. This suggestion should have a minimal effect on
+ implementations, as most ad hoc data types are compatible with the
+ ones defined here. Any difference will typically be limited to the
+ name of the data type.
+
+ 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
+ [RFC6158]. The recommendations of [RFC6158] are otherwise unchanged.
+
+1.4. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 5]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+2. Use of Data Types
+
+ The data types can be used in two places: specifications and
+ implementations. This section discusses both uses and gives guidance
+ on using the data types.
+
+2.1. Specification Use of Data Types
+
+ In this section, we give recommendations for how specifications
+ should be written using data types. We first describe how attribute
+ field names can be consistently named. We then describe how
+ attribute definitions should use the data types and deprecate the use
+ of "ASCII art" for attribute definitions. We suggest a format for
+ new attribute definitions. This format includes recommended fields
+ and suggestions for how those fields should be described.
+
+ Finally, we make recommendations for how new data types should be
+ defined.
+
+2.1.1. Field Names for Attribute Values
+
+ Previous specifications used inconsistent and conflicting names for
+ the contents of RADIUS attributes. For example, the term "Value" is
+ used in [RFC2865], Section 5 to define a field that carries the
+ contents of an attribute. It is then used in later sections as the
+ subfield of attribute contents. The result is that the field is
+ defined as recursively containing itself. Similarly, "String" is
+ 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
+ fields of attributes and data types. It then becomes clear that, for
+ example, a field called "VSA-Data" must contain different data than a
+ field called "EVS-Data". Each new name is defined where it is used.
+
+ We also define the following term:
+
+ Attr-Data
+
+ The Value field of an Attribute as defined in
+ [RFC2865], Section 5. The contents of this field MUST be of a
+ valid data type as defined in the RADIUS "Data Type" registry.
+
+ We consistently use "Attr-Data" to refer to the contents of an
+ attribute, instead of the more ambiguous name "Value". It is
+ RECOMMENDED that new specifications follow this practice.
+
+
+
+
+
+
+DeKok Standards Track [Page 6]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ 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
+ "Value". In contrast, a Vendor-Specific Attribute carries complex
+ information and thus cannot have a "Value".
+
+ For data types that carry complex information, we name the fields
+ 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 type are described herein as "VSA-Data".
+
+ These terms are used in preference to the term "String", which was
+ previously used in ambiguous ways. It is RECOMMENDED that future
+ specifications use type-specific names and the same naming scheme for
+ new types. This use will maintain consistent definitions and help to
+ avoid ambiguities.
+
+2.1.2. Attribute Definitions Using Data Types
+
+ New RADIUS specifications MUST define attributes using data types
+ from the RADIUS "Data Type" registry. The specification may, of
+ course, define a new data type, update the "Data Type" registry, and
+ use the new data type, all in the same document. The guidelines
+ given in [RFC6929] MUST be followed when defining a new data type.
+
+ Attributes can usually be completely described via the Attribute Type
+ 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.
+
+ Use of the new extended attributes [RFC6929] makes ASCII art even
+ more problematic. An attribute can be allocated from any of the
+ extended spaces, with more than one option for the attribute header
+ format. This allocation decision is made after the specification has
+ been accepted for publication. As the allocation affects the format
+ of the attribute header, it is essentially impossible to create the
+ correct ASCII art prior to final publication. Allocation from the
+ different spaces also changes the value of the Length field, making
+ it difficult to define it correctly prior to final publication of the
+ document.
+
+ It is therefore RECOMMENDED that ASCII art diagrams not be used for
+ new RADIUS attribute specifications.
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 7]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+2.1.3. Format of Attribute Definitions
+
+ When defining a new attribute, the following fields SHOULD be given:
+
+ Description
+
+ A description of the meaning and interpretation of the
+ attribute.
+
+ Type
+
+ The Attribute Type value, given in the "dotted number" notation
+ from [RFC6929]. Specifications can often leave this as "TBD"
+ (to be determined) and request that IANA fill in the allocated
+ values.
+
+ Length
+
+ A description of the length of the attribute. For attributes
+ of variable length, a maximum length SHOULD be given. Since
+ the Length value may depend on the Type value, the definition
+ of Length may be affected by IANA allocations.
+
+ Data Type
+
+ One of the named data types from the RADIUS "Data Type"
+ registry.
+
+ Value
+
+ A description of any attribute-specific limitations on the
+ values carried by the specified data type. If there are no
+ attribute-specific limitations, then the description of this
+ field can be omitted, so long as the Description field is
+ sufficiently explanatory.
+
+ Where the values are limited to a subset of the possible range,
+ valid range(s) MUST be defined.
+
+ For attributes of data type "enum", a list of enumerated values
+ and names MUST be given, as shown in [RFC2865], Section 5.6.
+
+ Using a consistent format for attribute definitions helps to make the
+ definitions clearer.
+
+
+
+
+
+
+
+DeKok Standards Track [Page 8]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+2.1.4. Defining a New Data Type
+
+ When a specification needs to define a new data type, it SHOULD
+ follow the format used by the definitions in Section 3 of this
+ document. The text at the start of the data type definition MUST
+ describe the data type, including the expected use, and why a new
+ data type is required. That text SHOULD include limits on expected
+ values and why those limits exist. The fields "Name", "Value",
+ "Length", and "Format" MUST be given, along with values.
+
+ The Name field SHOULD be a single name, all lowercase.
+
+ Contractions such as "ipv4addr" are RECOMMENDED where they add
+ clarity.
+
+ We note that the use of "Value" in the RADIUS "Data Type" registry
+ can be confusing. That name is also used in attribute definitions,
+ but with a different meaning. We trust that the meaning here is
+ clear from the context.
+
+ The Value field SHOULD be given as "TBD" in specifications. That
+ number is assigned by IANA.
+
+ The Format field SHOULD be defined with ASCII art in order to have a
+ precise definition. Machine-readable formats are also RECOMMENDED.
+
+ 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 types. When defining a new data type, the guidelines of
+ [RFC6929] with respect to data types MUST be followed.
+
+ It is RECOMMENDED that vendors not define "vendor-specific"
+ data types. As discussed in [RFC6929], those data types are rarely
+ necessary and can cause interoperability problems.
+
+ 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.
+
+2.2. Implementation Use of Data Types
+
+ Implementations not supporting a particular data type MUST treat
+ attributes of that data type as being of data type "string", as
+ defined in Section 3.5. It is RECOMMENDED that such attributes
+ be treated as "invalid attributes", as defined in
+ [RFC6929], Section 2.8.
+
+
+
+
+
+
+DeKok Standards Track [Page 9]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ Where the contents of a data type do not match the definition,
+ implementations MUST treat the enclosing attribute as being an
+ invalid attribute. This requirement includes, but is not limited to,
+ the following situations:
+
+ * Attributes with values outside of the allowed range(s) for the
+ data type, e.g., as given in the data types "integer", "ipv4addr",
+ "ipv6addr", "ipv4prefix", "ipv6prefix", or "enum".
+
+ * "text" attributes where the contents do not match the required
+ format.
+
+ * Attributes where the length is shorter or longer than the allowed
+ length(s) for the given data type.
+
+ The requirements for Reserved fields are more difficult to quantify.
+ Implementations SHOULD be able to receive and process attributes
+ where Reserved fields are non-zero. We do not, however, define any
+ "correct" processing of such attributes. Instead, specifications
+ that define one or more new meanings for Reserved fields SHOULD
+ describe how each new meaning is compatible with older
+ implementations. We expect that such descriptions are derived from
+ practical experience with implementations. Implementations MUST set
+ Reserved fields to zero when creating attributes.
+
+3. Data Type Definitions
+
+ This section defines the new data types. For each data type, it
+ gives a definition, a name, a number, a length, and an encoding
+ format. Where relevant, it describes subfields contained within the
+ data type. These definitions have no impact on existing RADIUS
+ implementations. There is no requirement that implementations use
+ these names.
+
+ Where possible, the name of each data type has been taken from
+ previous specifications. In some cases, a different name has been
+ chosen. The change of name is sometimes required to avoid ambiguity
+ (i.e., "address" versus "Address"). Otherwise, the new name has been
+ chosen to be compatible with [RFC2865] or with usage in common
+ implementations. In some cases, new names are chosen to clarify the
+ interpretation of the data type.
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 10]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ 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
+ 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
+ implementations use the names defined in this document in order to
+ avoid confusion. Existing implementations may choose to use the
+ names defined here, but that is not required.
+
+ The encoding of each data type is taken from previous specifications.
+ The fields are transmitted from left to right.
+
+ Where the data types have interdependencies, the simplest data type
+ is given first, and dependent ones are given later.
+
+ We do not create specific data types for the "tagged" attributes
+ (i.e., attributes containing a Tag field) defined in [RFC2868]. That
+ specification defines the tagged attributes as being backwards
+ compatible with pre-existing data types. In addition,
+ [RFC6158], Section 2.1 says that tagged attributes should not be
+ used. There is therefore no benefit to defining additional
+ data types for these attributes. We trust that implementors will be
+ 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 a
+ complex structure, such as CHAP-Password, ARAP-Features, or
+ Location-Information. ("CHAP" refers to the Challenge Handshake
+ Authentication Protocol, and "ARAP" refers to the Apple Remote Access
+ 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
+ guidelines given in Section 6.3 of [RFC6929] were used to make this
+ determination.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 11]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+3.1. integer
+
+ The "integer" data type encodes a 32-bit unsigned integer in network
+ byte order. Where the range of values for a particular attribute is
+ limited to a subset of the values, specifications MUST define the
+ valid range. Attributes with Values outside of the allowed ranges
+ SHOULD be treated as invalid attributes.
+
+ Name
+
+ integer
+
+ Value
+
+ 1
+
+ Length
+
+ Four octets
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.2. enum
+
+ 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
+ is used to define enumerated types, such as Service-Type (Section 5.6
+ of [RFC2865]). Specifications MUST define a valid set of enumerated
+ values, along with a unique name for each value. Attributes with
+ Values outside of the allowed enumerations SHOULD be treated as
+ invalid attributes.
+
+ Name
+
+ enum
+
+ Value
+
+ 2
+
+
+
+
+
+
+DeKok Standards Track [Page 12]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ Length
+
+ Four octets
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.3. time
+
+ 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,
+ 1970. We note that dates before the year 2017 are likely to indicate
+ configuration errors or lack of access to the correct time.
+
+ Note that the "time" attribute is defined to be unsigned, which means
+ that it is not subject to a signed integer overflow in the year 2038.
+
+ Name
+
+ time
+
+ Value
+
+ 3
+
+ Length
+
+ Four octets
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 13]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+3.4. text
+
+ The "text" data type encodes UTF-8 text [RFC3629]. The maximum
+ length of the text is given by the encapsulating attribute. Where
+ the range of lengths for a particular attribute is limited to a
+ subset of possible lengths, specifications MUST define the valid
+ range(s). Attributes with lengths outside of the allowed values
+ SHOULD be treated as invalid attributes.
+
+ 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
+ data. Attributes of type "text" that are allocated in the extended
+ space can be longer. In both cases, these limits are reduced when
+ the data is encapsulated inside of another attribute.
+
+ Where the text is intended to carry data in a particular format
+ (e.g., Framed-Route), the format MUST be given. The specification
+ SHOULD describe the format in a machine-readable way, such as via the
+ Augmented Backus-Naur Form (ABNF) [RFC5234]. Attributes with
+ Values not matching the defined format SHOULD be treated as
+ invalid attributes.
+
+ 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
+ terminator. Texts of length zero (0) MUST NOT be sent; omit the
+ entire attribute instead.
+
+ Name
+
+ text
+
+ Value
+
+ 4
+
+ Length
+
+ One or more octets
+
+ Format
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-
+ | Value ...
+ +-+-+-+-+-+-+-+-
+
+
+
+
+
+DeKok Standards Track [Page 14]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+3.5. string
+
+ The "string" data type encodes binary data as a sequence of
+ undistinguished octets. Where the range of lengths for a particular
+ attribute is limited to a subset of possible lengths, specifications
+ MUST define the valid range(s). Attributes with lengths outside of
+ the allowed values SHOULD be treated as invalid attributes.
+
+ 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
+ data. Attributes of type "string" that are allocated in the extended
+ space can be longer. In both cases, these limits are reduced when
+ the data is encapsulated inside of another attribute.
+
+ 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
+ terminator. Strings of length zero (0) MUST NOT be sent; omit the
+ entire attribute instead. Where there is a need to encapsulate
+ complex data structures and TLVs cannot be used, the "string"
+ data type MUST be used. This requirement includes encapsulation of
+ data structures defined outside of RADIUS that are opaque to the
+ RADIUS infrastructure. It also includes encapsulation of some data
+ structures that are not opaque to RADIUS, such as the contents of
+ CHAP-Password.
+
+ There is little reason to define a new RADIUS data type for only one
+ attribute. However, where the complex data type cannot be
+ represented as TLVs and is expected to be used in many attributes, a
+ new data type SHOULD be defined.
+
+ These requirements are stronger than [RFC6158], which makes the above
+ encapsulation a "SHOULD". This document defines data types for use
+ in RADIUS, so there are few reasons to avoid using them.
+
+ Name
+
+ string
+
+ Value
+
+ 5
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 15]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ Length
+
+ One or more octets
+
+ Format
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-
+ | Octets ...
+ +-+-+-+-+-+-+-+-
+
+3.6. concat
+
+ The "concat" data type permits the transport of more than 253 octets
+ of data in a "standard space" [RFC6929] attribute. It is otherwise
+ identical to the "string" data type.
+
+ 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
+ be consecutive attributes in the packet.
+
+ The amount of data transported in a "concat" data type can be no more
+ than the RADIUS packet size. In practice, the requirement to
+ transport multiple attributes means that the limit may be
+ substantially smaller than one RADIUS packet. As a rough guide, it
+ is RECOMMENDED that this data type transport no more than 2048 octets
+ of data.
+
+ The "concat" data type MAY be used for "standard space" attributes.
+ 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
+ subfields of the following data types: "tlv", "vsa", "extended",
+ "long-extended", or "evs".
+
+ Name
+
+ concat
+
+ Value
+
+ 6
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 16]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ Length
+
+ One or more octets
+
+ Format
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-
+ | Octets ...
+ +-+-+-+-+-+-+-+-
+
+3.7. ifid
+
+ The "ifid" data type encodes an Interface-Id as an 8-octet IPv6
+ Interface Identifier in network byte order.
+
+ Name
+
+ ifid
+
+ Value
+
+ 7
+
+ Length
+
+ Eight octets
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface-Id ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ... Interface-Id |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 17]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+3.8. ipv4addr
+
+ The "ipv4addr" data type encodes an IPv4 address in network byte
+ order. Where the range of addresses for a particular attribute is
+ limited to a subset of possible addresses, specifications MUST define
+ the valid range(s). Attributes with Address values outside of the
+ allowed range(s) SHOULD be treated as invalid attributes.
+
+ Name
+
+ ipv4addr
+
+ Value
+
+ 8
+
+ Length
+
+ Four octets
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.9. ipv6addr
+
+ The "ipv6addr" data type encodes an IPv6 address in network byte
+ order. Where the range of addresses for a particular attribute is
+ limited to a subset of possible addresses, specifications MUST define
+ the valid range(s). Attributes with Address values outside of the
+ allowed range(s) SHOULD be treated as invalid attributes.
+
+ Name
+
+ ipv6addr
+
+ Value
+
+ 9
+
+ Length
+
+ Sixteen octets
+
+
+
+
+DeKok Standards Track [Page 18]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Address ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ... Address ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ... Address ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ... Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.10. ipv6prefix
+
+ The "ipv6prefix" data type encodes an IPv6 prefix, using both a
+ prefix length and an IPv6 address in network byte order. Where the
+ range of prefixes for a particular attribute is limited to a subset
+ of possible prefixes, specifications MUST define the valid range(s).
+ Attributes with Address values outside of the allowed range(s) SHOULD
+ be treated as invalid attributes.
+
+ Attributes with a Prefix-Length field having a value greater than 128
+ MUST be treated as invalid attributes.
+
+ Name
+
+ ipv6prefix
+
+ Value
+
+ 10
+
+ Length
+
+ At least two, and no more than eighteen, octets
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 19]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved | Prefix-Length | Prefix ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ... Prefix ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ... Prefix ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ... Prefix |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Subfields
+
+ Reserved
+
+ This field, which is reserved and MUST be present, is always
+ set to zero. This field is one octet in length.
+
+ Prefix-Length
+
+ The length of the prefix, in bits. At least 0 and no larger
+ than 128. This field is one octet in length.
+
+ Prefix
+
+ The Prefix field is up to 16 octets in length. Bits outside of
+ the Prefix-Length, if included, MUST be zero.
+
+ The Prefix field SHOULD NOT contain more octets than necessary
+ to encode the Prefix field.
+
+3.11. ipv4prefix
+
+ The "ipv4prefix" data type encodes an IPv4 prefix, using both a
+ prefix length and an IPv4 address in network byte order. Where the
+ range of prefixes for a particular attribute is limited to a subset
+ of possible prefixes, specifications MUST define the valid range(s).
+ Attributes with Address values outside of the allowed range(s) SHOULD
+ be treated as invalid attributes.
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 20]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ Attributes with a Prefix-Length field having a value greater than 32
+ MUST be treated as invalid attributes.
+
+ Name
+
+ ipv4prefix
+
+ Value
+
+ 11
+
+ Length
+
+ Six octets
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved | Prefix-Length | Prefix ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ... Prefix |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Subfields
+
+ Reserved
+
+ This field, which is reserved and MUST be present, is always
+ set to zero. This field is one octet in length.
+
+ Note that this definition differs from that given in [RFC6572].
+ See "Prefix-Length", below, for an explanation.
+
+ Prefix-Length
+
+ The length of the prefix, in bits. The values MUST be no
+ larger than 32. This field is one octet in length. Note that
+ this definition differs from that given in [RFC6572].
+
+ As compared to [RFC6572], the Prefix-Length field has increased
+ in size by two bits, both of which must be zero. The
+ Reserved field has decreased in size by two bits. The result
+ is that both fields are aligned on octet boundaries, which
+ removes the need for bit masking of the fields.
+
+
+
+
+
+DeKok Standards Track [Page 21]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ Since [RFC6572] required the Reserved field to be zero, the
+ definition here is compatible with the definition in the
+ original specification.
+
+ Prefix
+
+ The Prefix field is 4 octets in length. Bits outside of the
+ Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type,
+ 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.
+
+3.12. integer64
+
+ The "integer64" data type encodes a 64-bit unsigned integer in
+ network byte order. Where the range of values for a particular
+ attribute is limited to a subset of the values, specifications MUST
+ define the valid range(s). Attributes with Values outside of the
+ allowed range(s) SHOULD be treated as invalid attributes.
+
+ Name
+
+ integer64
+
+ Value
+
+ 12
+
+ Length
+
+ Eight octets
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ... Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 22]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+3.13. tlv
+
+ The "tlv" data type encodes a Type-Length-Value, as defined in
+ [RFC6929], Section 2.3.
+
+ Name
+
+ tlv
+
+ Value
+
+ 13
+
+ Length
+
+ Three or more octets
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TLV-Type | TLV-Length | TLV-Data ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Subfields
+
+ TLV-Type
+
+ This field is one octet. Up-to-date values of this field are
+ specified according to the policies and rules described in
+ [RFC6929], Section 10. Values of 254-255 are reserved for use
+ by future extensions to RADIUS. The value 26 has no special
+ meaning and MUST NOT be treated as a Vendor-Specific Attribute.
+
+ The TLV-Type is meaningful only within the context defined by
+ Type fields of the encapsulating Attributes, using the
+ dotted-number notation introduced in [RFC6929].
+
+ A RADIUS server MAY ignore Attributes with an unknown
+ "TLV-Type".
+
+ A RADIUS client MAY ignore Attributes with an unknown
+ "TLV-Type".
+
+ A RADIUS proxy SHOULD forward Attributes with an unknown
+ "TLV-Type" verbatim.
+
+
+
+
+DeKok Standards Track [Page 23]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ TLV-Length
+
+ The TLV-Length field is one octet and indicates the length of
+ this TLV, including the TLV-Type, TLV-Length, and TLV-Value
+ fields. It MUST have a value between 3 and 255. If a client
+ or server receives a TLV with an invalid TLV-Length, then the
+ attribute that encapsulates that TLV MUST be considered to be
+ an invalid attribute and is handled as per
+ [RFC6929], Section 2.8.
+
+ TLVs having a TLV-Length of two (2) MUST NOT be sent; omit the
+ entire TLV instead.
+
+ TLV-Data
+
+ The TLV-Data field is one or more octets and contains
+ information specific to the attribute. The format and length
+ of the TLV-Data field are determined by the TLV-Type and
+ TLV-Length fields.
+
+ The TLV-Data field MUST contain only known RADIUS data types.
+ The TLV-Data field MUST NOT contain any of the following
+ data types: "concat", "vsa", "extended", "long-extended",
+ or "evs".
+
+3.14. vsa
+
+ 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
+ Vendor-Specific Attribute. It MUST NOT appear in the contents of any
+ other data type.
+
+ Where an implementation determines that an attribute of data type
+ "vsa" contains data that does not match the expected format, it
+ SHOULD treat that attribute as being an invalid attribute.
+
+ Name
+
+ vsa
+
+ Value
+
+ 14
+
+ Length
+
+ Five or more octets
+
+
+
+
+DeKok Standards Track [Page 24]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Id |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | VSA-Data ....
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Subfields
+
+ Vendor-Id
+
+ The 4 octets are the Network Management Private Enterprise Code
+ [PEN] of the vendor in network byte order.
+
+ VSA-Data
+
+ The VSA-Data field is one or more octets. The actual format of
+ the information is site specific or application specific, and a
+ robust implementation SHOULD support the field as
+ undistinguished octets.
+
+ The codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+ The "vsa" data type SHOULD contain a sequence of "tlv"
+ data types. The interpretation of the TLV-Type and TLV-Data
+ fields is dependent on the vendor's definition of that
+ attribute.
+
+ The "vsa" data type MUST be used as the contents of the
+ Attr-Data field of the Vendor-Specific Attribute. The "vsa"
+ data type MUST NOT appear in the contents of any other
+ data type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 25]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+3.15. extended
+
+ 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
+ an attribute allocated from the standard space. It MUST NOT appear
+ in the contents of any other data type.
+
+ Name
+
+ extended
+
+ Value
+
+ 15
+
+ Length
+
+ Two or more octets
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Extended-Type | Ext-Data ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Subfields
+
+ Extended-Type
+
+ The Extended-Type field is one octet. Up-to-date values of
+ this field are specified according to the policies and rules
+ described in [RFC6929], Section 10. Unlike the Type field
+ defined in [RFC2865], Section 5, no values are allocated for
+ experimental or implementation-specific use. Values 241-255
+ are reserved and MUST NOT be used.
+
+ The Extended-Type is meaningful only within a context defined
+ by the Type field. That is, this field may be thought of as
+ defining a new type space of the form "Type.Extended-Type".
+ See [RFC6929], Section 2.1 for additional discussion.
+
+ A RADIUS server MAY ignore Attributes with an unknown
+ "Type.Extended-Type".
+
+ A RADIUS client MAY ignore Attributes with an unknown
+ "Type.Extended-Type".
+
+
+
+DeKok Standards Track [Page 26]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ Ext-Data
+
+ 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
+ Identifier of "Type.Extended-Type" to determine the
+ interpretation of the Ext-Data field.
+
+3.16. long-extended
+
+ The "long-extended" data type encodes the "Long Extended Type"
+ 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
+ of any other data type.
+
+ Name
+
+ long-extended
+
+ Value
+
+ 16
+
+ Length
+
+ Three or more octets
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Extended-Type |M|T| Reserved | Ext-Data ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 27]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ Subfields
+
+ Extended-Type
+
+ This field is identical to the Extended-Type field defined
+ above in Section 3.15.
+
+ M (More)
+
+ The More field (M flag) is one (1) bit in length and indicates
+ whether or not the current attribute contains "more" than
+ 251 octets of data. The More field MUST be clear (0) if the
+ Length field has a value less than 255. The More field MAY be
+ set (1) if the Length field has a value of 255.
+
+ If the More field is set (1), it indicates that the Ext-Data
+ field has been fragmented across multiple RADIUS attributes.
+
+ When the More field is set (1), the Attribute MUST have a
+ Length field value of 255; there MUST be an attribute following
+ this one; and the next attribute MUST have both the same Type
+ and Extended-Type. That is, multiple fragments of the same
+ value MUST be in order and MUST be consecutive attributes in
+ the packet, and the last attribute in a packet MUST NOT have
+ the More field set (1).
+
+ That is, a packet containing a fragmented attribute needs to
+ contain all fragments of the attribute, and those fragments
+ need to be contiguous in the packet. RADIUS does not support
+ inter-packet fragmentation, which means that fragmenting an
+ attribute across multiple packets is impossible.
+
+ If a client or server receives an attribute fragment with the
+ More field set (1), but for which no subsequent fragment can be
+ found, then the fragmented attribute is considered to be an
+ invalid attribute and is handled as per [RFC6929], Section 2.8.
+
+ T (Truncation)
+
+ This field is one bit in size and is called "T" for Truncation.
+ It indicates that the attribute is intentionally truncated in
+ this chunk and is to be continued in the next chunk of the
+ sequence. The combination of the M flag and the T flag
+ indicates that the attribute is fragmented (M flag) but that
+ all of the fragments are not available in this chunk (T flag).
+ Proxies implementing [RFC6929] will see these attributes as
+
+
+
+
+
+DeKok Standards Track [Page 28]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ 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 discussion of the uses of
+ this flag.
+
+ Reserved
+
+ This field is six bits long and is reserved for future use.
+ Implementations MUST set it to zero (0) when encoding an
+ attribute for sending in a packet. The contents SHOULD be
+ ignored on reception.
+
+ Future specifications may define one or more additional
+ meanings for this field. Implementations therefore MUST NOT
+ treat this field as invalid if it is non-zero.
+
+ Ext-Data
+
+ 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
+ Identifier of "Type.Extended-Type" to determine the
+ interpretation of the Ext-Data field.
+
+ The length of the data MUST be taken as the sum of the lengths
+ of the fragments (i.e., Ext-Data fields) from which it is
+ constructed. Any interpretation of the resulting data MUST
+ occur after the fragments have been reassembled. If the
+ 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 fragmented attribute is
+ limited only by the RADIUS packet length limitation.
+ Implementations MUST be able to handle the case where one
+ fragmented attribute completely fills the packet.
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 29]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+3.17. evs
+
+ The "evs" data type encodes an Extended-Vendor-Specific Attribute, as
+ given in [RFC6929], Section 2.4. The "evs" data type is used solely
+ to extend the vendor-specific space. It MAY appear inside of an
+ "extended" data type or a "long-extended" data type. It MUST NOT
+ appear in the contents of any other data type.
+
+ Where an implementation determines that an attribute of data type
+ "evs" contains data that does not match the expected format, it
+ SHOULD treat that attribute as being an invalid attribute.
+
+ Name
+
+ evs
+
+ Value
+
+ 17
+
+ Length
+
+ Six or more octets
+
+ Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Id |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor-Type | EVS-Data ....
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Subfields
+
+ Vendor-Id
+
+ The 4 octets are the Network Management Private Enterprise Code
+ [PEN] of the vendor in network byte order.
+
+ Vendor-Type
+
+ The Vendor-Type field is one octet. Values are assigned at the
+ sole discretion of the vendor.
+
+
+
+
+
+
+DeKok Standards Track [Page 30]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ EVS-Data
+
+ The EVS-Data field is one or more octets. It SHOULD
+ encapsulate a previously defined RADIUS data type.
+ Non-standard data types SHOULD NOT be used. We note that the
+ EVS-Data field may be of data type "tlv".
+
+ The actual format of the information is site specific or
+ application specific, and a robust implementation SHOULD
+ support the field as undistinguished octets. We recognize that
+ vendors have complete control over the contents and format of
+ the Ext-Data field; at the same time, we recommend that good
+ practices be followed.
+
+ Further codification of the range of allowed usage of this
+ field is outside the scope of this specification.
+
+4. Updated Registries
+
+ This section defines a new IANA registry for RADIUS data types and
+ then updates the existing "RADIUS Attribute Types" registry to use
+ the data types from the new registry.
+
+4.1. New "Data Type" Registry
+
+ This section defines a new registry located under "RADIUS Types",
+ called "Data Type". The registration procedures for the "Data Type"
+ registry are "Standards Action" [RFC5226].
+
+ The "Data Type" registry contains three columns of data, as follows.
+
+ Value
+
+ The number of the data type. The Value field is an artifact of
+ the registry and has no on-the-wire meaning.
+
+ Description
+
+ The name of the data type. This field is used only for the
+ registry and has no on-the-wire meaning.
+
+ Reference
+
+ The specification where the data type was defined.
+
+
+
+
+
+
+
+DeKok Standards Track [Page 31]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ The initial contents of the registry are as follows.
+
+ Value Description Reference
+ ----- ----------- -------------------
+ 1 integer [RFC2865], RFC 8044
+ 2 enum [RFC2865], RFC 8044
+ 3 time [RFC2865], RFC 8044
+ 4 text [RFC2865], RFC 8044
+ 5 string [RFC2865], RFC 8044
+ 6 concat RFC 8044
+ 7 ifid [RFC3162], RFC 8044
+ 8 ipv4addr [RFC2865], RFC 8044
+ 9 ipv6addr [RFC3162], RFC 8044
+ 10 ipv6prefix [RFC3162], RFC 8044
+ 11 ipv4prefix [RFC6572], RFC 8044
+ 12 integer64 [RFC6929], RFC 8044
+ 13 tlv [RFC6929], RFC 8044
+ 14 vsa [RFC2865], RFC 8044
+ 15 extended [RFC6929], RFC 8044
+ 16 long-extended [RFC6929], RFC 8044
+ 17 evs [RFC6929], RFC 8044
+
+4.2. Updates to the "RADIUS Attribute Types" Registry
+
+ This section updates the "RADIUS Attribute Types" registry to have a
+ new column, which is inserted between the existing "Description" and
+ "Reference" columns. The new column is named "Data Type". The
+ 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
+ unassigned. The name of the data type is taken from the RADIUS
+ "Data Type" registry, as defined above.
+
+ The existing registration requirements for the "RADIUS Attribute
+ Types" registry are otherwise unchanged.
+
+5. Security Considerations
+
+ This specification is concerned solely with updates to IANA
+ registries. As such, there are no security considerations with the
+ document itself.
+
+ However, the use of inconsistent names and poorly defined entities in
+ a protocol is problematic. Inconsistencies in specifications can
+ lead to security and interoperability problems in implementations.
+ Further, having one canonical source for the definition of data types
+ means that an implementor has fewer specifications to read. The
+ implementation work is therefore simpler and more likely to be
+ correct.
+
+
+
+DeKok Standards Track [Page 32]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ The goal of this specification is to reduce ambiguities in the RADIUS
+ protocol, which we believe will lead to more robust and more secure
+ implementations.
+
+6. IANA Considerations
+
+ IANA has created one new registry, as described in Section 4.1.
+
+ IANA has updated the "RADIUS Attribute Types" registry, as described
+ in Section 4.2.
+
+ IANA requires that all allocation requests in the "RADIUS Attribute
+ Types" registry contain a Data Type field, which is required to
+ contain one of the "Data Type" names contained in the RADIUS "Data
+ Type" registry.
+
+ IANA requires that updates to the RADIUS "Data Type" registry contain
+ the following fields, with the associated instructions:
+
+ * Value. IANA is instructed to assign the next unused integer in
+ sequence to new data type definitions.
+
+ * Name. IANA is instructed to require that this name be unique in
+ the registry.
+
+ * Reference. IANA is instructed to update this field with a
+ reference to the document that defines the data type.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+ "Remote Authentication Dial In User Service (RADIUS)",
+ RFC 2865, DOI 10.17487/RFC2865, June 2000,
+ <http://www.rfc-editor.org/info/rfc2865>.
+
+ [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
+ RFC 3162, DOI 10.17487/RFC3162, August 2001,
+ <http://www.rfc-editor.org/info/rfc3162>.
+
+
+
+
+
+
+DeKok Standards Track [Page 33]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of
+ ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
+ November 2003, <http://www.rfc-editor.org/info/rfc3629>.
+
+ [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
+ Extensible Authentication Protocol (EAP) Application",
+ RFC 4072, DOI 10.17487/RFC4072, August 2005,
+ <http://www.rfc-editor.org/info/rfc4072>.
+
+ [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", STD 68, RFC 5234,
+ DOI 10.17487/RFC5234, January 2008,
+ <http://www.rfc-editor.org/info/rfc5234>.
+
+ [RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines",
+ BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011,
+ <http://www.rfc-editor.org/info/rfc6158>.
+
+ [RFC6572] Xia, F., Sarikaya, B., Korhonen, J., Ed., Gundavelli, S.,
+ and D. Damic, "RADIUS Support for Proxy Mobile IPv6",
+ RFC 6572, DOI 10.17487/RFC6572, June 2012,
+ <http://www.rfc-editor.org/info/rfc6572>.
+
+ [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>.
+
+7.2. Informative References
+
+ [PEN] IANA, "PRIVATE ENTERPRISE NUMBERS",
+ <http://www.iana.org/assignments/enterprise-numbers/>.
+
+ [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
+ M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
+ Support", RFC 2868, DOI 10.17487/RFC2868, June 2000,
+ <http://www.rfc-editor.org/info/rfc2868>.
+
+ [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
+ Extensions", RFC 2869, DOI 10.17487/RFC2869, June 2000,
+ <http://www.rfc-editor.org/info/rfc2869>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ DOI 10.17487/RFC5226, May 2008,
+ <http://www.rfc-editor.org/info/rfc5226>.
+
+
+
+
+DeKok Standards Track [Page 34]
+
+RFC 8044 Data Types in RADIUS January 2017
+
+
+ [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
+ Service (RADIUS) Protocol Extensions", RFC 6929,
+ DOI 10.17487/RFC6929, April 2013,
+ <http://www.rfc-editor.org/info/rfc6929>.
+
+ [RFC7268] Aboba, B., Malinen, J., Congdon, P., Salowey, J., and M.
+ Jones, "RADIUS Attributes for IEEE 802 Networks",
+ RFC 7268, DOI 10.17487/RFC7268, July 2014,
+ <http://www.rfc-editor.org/info/rfc7268>.
+
+Acknowledgments
+
+ Thanks to the RADEXT WG participants for their patience and reviews
+ of this document.
+
+Author's Address
+
+ Alan DeKok
+ The FreeRADIUS Server Project
+
+ Email: aland@freeradius.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok Standards Track [Page 35]
+