Data Types in RADIUS
updates
Extracted elements (30)
ASCII art diagrams are deprecated for new RADIUS attribute specifications because allocation from different extended spaces changes the attribute header format and Length field value in ways that cannot be determined prior to final IANA allocation, making pre-publication ASCII art inherently incorrect.
Data type numbers assigned in the registry have no on-the-wire meaning since RADIUS packets do not encode data type information. The numbers exist solely for IANA tracking purposes.
Tagged attributes (RFC 2868) are not given their own data types because RFC 6158 Section 2.1 discourages their use and they are defined as backwards-compatible with existing types. Similarly, some complex attributes like CHAP-Password are left as 'string' to avoid excessive specification complexity.
The 'ipv4prefix' definition intentionally differs from RFC 6572 by aligning the Reserved and Prefix-Length fields on octet boundaries (each one full octet), eliminating the need for bit masking. The result is backward-compatible because RFC 6572 required Reserved to be zero.
Previous specifications used 'address' (RFC 2865 for IPv4) and 'Address' (RFC 3162 for IPv6) inconsistently, and RFC 3162 failed to formally define data type names for IPv6 address, Interface-Id, and IPv6 prefix. RFC 8044 resolves these by introducing unambiguous names: ipv4addr, ipv6addr, ifid, ipv6prefix.
This document mandates no changes to past, present, or future RADIUS implementations; it documents existing practice. Most ad hoc data types used by implementations are compatible with the formally named types defined here, with differences typically limited to naming.
For 'long-extended' fragmented attributes: the More field MUST be clear if Length < 255; when More is set, Length MUST be 255, a next attribute MUST follow with the same Type and Extended-Type, and the last attribute in a packet MUST NOT have More set.
Implementations MUST set Reserved fields to zero when creating attributes. Implementations SHOULD be able to receive and process attributes where Reserved fields are non-zero.
Implementations not supporting a particular data type MUST treat attributes of that data type as being of data type 'string'. It is RECOMMENDED that such attributes be treated as 'invalid attributes' as defined in RFC 6929 Section 2.8.
New RADIUS specifications MUST define attributes using data types from the RADIUS 'Data Type' registry. The guidelines given in RFC 6929 MUST be followed when defining a new data type.
Where the contents of a data type do not match the definition, implementations MUST treat the enclosing attribute as being an invalid attribute. This applies to out-of-range values, malformed text, and incorrect lengths.
A new IANA 'Data Type' registry is created under 'RADIUS Types' with registration procedure 'Standards Action'. It contains 17 initial entries (integer through evs) with Value, Description, and Reference columns. The Value field has no on-the-wire meaning.
The existing 'RADIUS Attribute Types' registry is updated to include a new 'Data Type' column inserted between the 'Description' and 'Reference' columns. All new allocation requests must include a Data Type field referencing an entry in the RADIUS 'Data Type' registry.
Inconsistencies in RADIUS specifications can lead to security and interoperability problems in implementations. Establishing a canonical, unambiguous source for data type definitions reduces ambiguity and is expected to produce more robust and secure implementations.
The 'concat' data type (value 6) permits transport of more than 253 octets in a standard-space attribute by concatenating multiple attributes of the same type code, which MUST be consecutive and in order. It MUST NOT be used in extended or long-extended spaces, or inside tlv, vsa, extended, long-extended, or evs data types.
The 'enum' data type (value 2) encodes a 32-bit unsigned integer in network byte order (four octets), used exclusively for enumerated types. Specifications MUST define a valid set of enumerated values with unique names.
The 'evs' data type (value 17) encodes an Extended-Vendor-Specific Attribute as a 4-octet Vendor-Id, a 1-octet Vendor-Type, and one or more octets of EVS-Data. It MAY appear inside 'extended' or 'long-extended' types only.
The 'extended' data type (value 15) encodes a 1-octet Extended-Type followed by one or more octets of Ext-Data. Extended-Type values 241–255 are reserved and MUST NOT be used. Ext-Data MUST NOT contain concat, vsa, extended, long-extended, or evs types.
The 'ifid' data type (value 7) encodes an IPv6 Interface Identifier as exactly 8 octets in network byte order.
The 'integer' data type (value 1) encodes a 32-bit unsigned integer in network byte order, fixed at four octets. Out-of-range values SHOULD be treated as invalid attributes.
The 'integer64' data type (value 12) encodes a 64-bit unsigned integer in network byte order, fixed at eight octets.
The 'ipv4addr' data type (value 8) encodes an IPv4 address in network byte order, fixed at four octets. The 'ipv6addr' data type (value 9) encodes an IPv6 address in network byte order, fixed at sixteen octets.
The 'ipv4prefix' data type (value 11) encodes an IPv4 prefix as a 1-octet Reserved field, a 1-octet Prefix-Length (0–32), and a fixed 4-octet Prefix, for a total of 6 octets. This differs from RFC 6572, which used sub-octet bit alignment; this definition aligns both fields on octet boundaries.
The 'ipv6prefix' data type (value 10) encodes an IPv6 prefix as a 1-octet Reserved field (MUST be zero), a 1-octet Prefix-Length (0–128), and up to 16 octets of Prefix. Total length is 2 to 18 octets. Prefix-Length > 128 MUST be treated as invalid.
The 'long-extended' data type (value 16) adds a flags octet containing a 1-bit More (M) flag, a 1-bit Truncation (T) flag, and 6 Reserved bits after the Extended-Type. The M flag signals fragmentation across multiple consecutive attributes of the same Type and Extended-Type.
The 'string' data type (value 5) encodes binary data as one or more undistinguished octets. Standard-space attributes are limited to 253 octets. Zero-length strings MUST NOT be sent; it MUST be used for encapsulating complex or opaque data structures when TLVs cannot be used.
The 'text' data type (value 4) encodes UTF-8 text of one or more octets. Standard-space attributes are limited to 253 octets. Text MUST NOT be NUL-terminated, and zero-length texts MUST NOT be sent.
The 'time' data type (value 3) encodes a 32-bit unsigned integer in network byte order representing seconds since 00:00:00 UTC January 1 1970, fixed at four octets. Being unsigned, it is not subject to a Year 2038 signed overflow.
The 'tlv' data type (value 13) encodes a Type-Length-Value as a 1-octet TLV-Type, 1-octet TLV-Length (MUST be 3–255), and one or more octets of TLV-Data. TLV-Data MUST NOT contain concat, vsa, extended, long-extended, or evs types.
The 'vsa' data type (value 14) encodes a 4-octet Vendor-Id (IANA PEN) followed by one or more octets of VSA-Data. It MUST only appear in the Attr-Data field of a Vendor-Specific Attribute and MUST NOT appear in the contents of any other data type.