Network Working Group                                        DeKok, Alan
INTERNET-DRAFT                                                FreeRADIUS
Updates: 2865,3162,6158,6572
Category: Standards Track
<draft-ietf-radext-datatypes-01.txt>
4 September
<draft-ietf-radext-datatypes-02.txt>
2 November 2015

                Data Types in the Remote Authentication
                 Dial-In User Service Protocol (RADIUS)
                   draft-ietf-radext-datatypes-01.txt
                   draft-ietf-radext-datatypes-02.txt

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 RFC
   2865.  We provide an IANA registry for the data types, and update the
   RADIUS Attribute Type 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.

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
   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 4, May 2, 2016.

Copyright Notice

   Copyright (c) 2015 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.

Table of Contents

1.  Introduction .............................................    4
   1.1.  Specification use of Problems with Data Types ..................... ..............    4
   1.2.  Implementation use of Problems with Data Types ....................    4 .............    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 ................    7
      2.1.4.  Defining a New Data Type .......................    8
   2.2.  Implementation Use of Data Types ....................    9
3.  Data Type Definitions ....................................    6
   2.1.   11
   3.1.  integer .............................................    7
   2.2.   12
   3.2.  enum ................................................    8
   2.3.   12
   3.3.  ipv4addr ............................................    9
   2.4.   13
   3.4.  time ................................................    9
   2.5.   13
   3.5.  text ................................................   10
   2.6.   14
   3.6.  string ..............................................   11
   2.7.   15
   3.7.  concat ..............................................   12
   2.8.   16
   3.8.  ifid ................................................   13
   2.9.   17
   3.9.  ipv6addr ............................................   13
   2.10.   17
   3.10.  ipv6prefix .........................................   14
   2.11.   18
   3.11.  ipv4prefix .........................................   15
   2.12.   19
   3.12.  integer64 ..........................................   16
   2.13.   20
   3.13.  tlv ................................................   17
   2.14.   21
   3.14.  vsa ................................................   18
   2.15.   23
   3.15.  extended ...........................................   20
   2.16.   24
   3.16.  long-extended ......................................   21
   2.17.   25
   3.17.  evs ................................................   23
3.   27
4.  Updated Registries .......................................   24
   3.1.   29
   4.1.  Create a Data Type Registry .........................   24
   3.2.   29
   4.2.  Updates to the Attribute Type Registry ..............   25
4.  Suggestions for Specifications ...........................   30
5.  Security Considerations ..................................   31   35
6.  IANA Considerations ......................................   32   35
7.  References ...............................................   32   36
   7.1.  Normative References ................................   32   36
   7.2.  Informative References ..............................   33   36

1.  Introduction

   RADIUS specifications have historically defined attributes in terms
   of name, type value, and data type.  Of these three pieces of
   information, only the type value is managed by IANA.  There is no
   management of, or restriction on, the attribute name, as discussed in
   [RFC6929] Section 2.7.1.  There is no management of data type name or
   definition.  Experience has shown that there is a need for well
   defined data types.

   This document defines an IANA registry for data types, and updates
   the RADIUS Attribute Type 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 Type
   registry to have a data type for each assigned attribute.

   In this section, we review the use of data types in specifications
   and implementations.  Whe highlight ambiguities and inconsistencies.
   The rest of this document is devoted to resolving those problems.

1.1.  Specification use of 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 re-use the "time" data type defined in [RFC2865].  Instead, it
   just repeats the "time" definition.  [RFC6572] defines multiple
   attributes which carry IPv4 prefixes.  However, an "IPv4 prefix" data
   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 use of Problems with Data Types

   RADIUS implementations often use "dictionaries" to map attribute
   names to type values, and to 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 RADIUS implementation, past,
   present, or future.  It instead documents existing practice, in order
   to simplify the process of writing RADIUS specifications, to clarify
   the interpretation of RADIUS standards, and to 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 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.

1.3.

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].

2.  Use of Data Type Definitions Types

   The Data Types can be used in two places: specifications, and
   implementations.  This section defines discusses both uses, and gives
   guidance on using the new data types.  For each

2.1.  Specification Use of Data Types

   In this section, we give recommendations for how specifications
   should be written using 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 types.  We first describe how attribute
   field names can be consistently named.  We then describe how
   attribute definitions have no impact on existing RADIUS
   implementations.  There is no requirement that implementations should 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, types, and deprecate the new name has been
   chosen to be compatible with [RFC2865], or with
   use in common
   implementations.  In some cases, new names are chosen to clarify the
   interpretation of the data type.

   The numbers assigned herein "Ascii art" for the 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 have no meaning other
   than to permit them to should be tracked by IANA.  As
   defined.

2.1.1.  Field Names for Attribute Values

   Previous specifications used inconsistent and conflicting names for
   the contents of RADIUS does not encode
   information about data types in a packet, attributes.  For example, the numbers assigned to a
   data type will never occur term "Value" is
   used in [RFC2865] Section 5 to define a packet. field which carries the
   contents of attribute.  It is RECOMMENDED that new
   implementations use the names defined herein, then used in order to avoid
   confusion.  Existing implementations may choose to use later sections as the names
   defined herein, but that is not required.

   The encoding sub-
   field of each data type is taken from previous specifications. attribute contents.  The fields are transmitted from left to right.

   Where result is that the data types have inter-dependencies, the simplest data type field is given first, and dependent ones are given later.

   We do not create specific data types for the "tagged" attributes, defined
   as
   discussed in [RFC2868].  That specification defines the "tagged"
   attributes recursively containing itself.  Similarly, "String" is used both
   as being backwards compatible with pre-existing a data type, and as a sub-field of other data types.  In addition, [RFC6158] Section 2.1 says that "tagged"

   We correct this ambiguity by using context-specific names for various
   fields of attributes should not be used.  There is therefore no benefit to
   defining additional and data types types.  It then becomes clear that, for these attributes.  We trust that
   implementors will be aware
   example, that tagged attributes a field called "VSA-Data" must be treated
   differently from non-tagged attributes of the same data type.

   Similarly, we do not create contain different data types for some attributes having
   complex structure, such as CHAP-Password, ARAP-Features, or Location-
   Capable.  We need to strike
   than a balance between correcting earlier
   mistakes, and making this document more complex.  In some cases, field called "EVS-Data".  Each new name is defined where it is better to treat complex attributes
   used.

   We also define the following term:

      Attr-Data

         The "Value" field of an Attribute as being defined in [RFC2865]
         Section 5.  The contents of type "string", even
   though they need to this field MUST be interpreted by RADIUS implementations.

   Implementations not supporting a particular data type MUST treat
   attributes of that data type as being of valid data
         type "string", as defined in Section 2.6. 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 such attributes be
   treated as "invalid attributes", as defined in [RFC6929] Section 2.8.

   The definitions below use specialized names for various fields of
   attributes and data types.  These names serve to address ambiguity of
   the field names in previous specifications.  For example, the term
   "Value" is used in [RFC2865] Section 5 to define a field which
   carries the contents of attribute.  It is then used in later sections
   as the sub-field 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 sub-field of other data types.

   This document uses slightly different terminology than previous
   specifications, in order to be avoid ambiguity.  The first addition
   is the following term:

      Attr-Data

         The "Value" field of an Attribute as defined in [RFC2865]
         Section 5.  The contents of new specifications follow this field MUST be a valid data
         type as defined in the RADIUS Data Type registry. practice.

   In this document, we use the term "Value" only to refer to the contents of
   a data type, where that data type cannot carry other data types.  In
   other cases, we refer to the contents of a data type with a type-specific type-
   specific name, in order to distinguish it from data of other types.
   For example, the data type "vsa" will contain a data field called
   "VSA-Data".

   These terms are used in preference to the term "String", which was
   used in multiple incompatible ways.  It is RECOMMENDED that future
   specifications use these type-specific names, and the same naming scheme
   for new
   types, in order to types.  This use will maintain consistent definitions, and to
   avoid ambiguities.

2.1.  integer

2.1.2.  Attribute Definitions using Data Types

   New RADIUS specifications MUST define attributes using data types
   from the RADIUS Data Type registry.  The "integer" specification may, of
   course, define a new data type encodes a 32-bit unsigned integer and use it in network
   byte order.  Where the range of values for same document.  The
   guidelines given in [RFC6929] MUST be followed when defining a particular attribute new
   data type.

   Attributes can usually be completely described via the Attribute Type
   code, name, and data type.  The use of "ASCII art" is then limited
   only to a sub-set of the values, specifications MUST define the
   valid range.  Attributes with Values outside definition of the allowed ranges
   SHOULD be treated as "invalid attributes".

   Name

      integer

   Number

      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                                                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2.  enum

   The "enum" new data type encodes a 32-bit unsigned integer in network
   byte order.  It differs 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 the "integer" data type only in that it standard
   space, or from one of the extended spaces.  This allocation decision
   is used made after the specification has been accepted for publication.
   That allocation strongly affects the format of the attribute header,
   making it nearly impossible to create the correct ASCII art prior to
   final publication.  Allocation from the different spaces also changes
   the value of the Length field, also making it difficult to define enumerated types, such as Service-Type.
   Specifications MUST define a valid set it
   correctly prior to final publication of enumerated values, along
   with a unique name the document.

   It is therefore RECOMMENDED that "ASCII art" diagrams not be used for each value.  Attributes with Values outside
   new RADIUS attribute specifications.

2.1.3.  Format of Attribute Definitions

   When defining a new attribute, the allowed enumerations following fields SHOULD be treated given:

      Description

         A description of the meaning and interpretation of the
         attribute.

      Type
         The Attribute Type code, given in the "dotted number" notation
         from [RFC6929].  Specifications can often leave this as "invalid attributes".

   Name

      enum

   Number

      2 "TBD",
         and request that IANA fill in the allocated values.

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |

         A description of the length of the attribute.  For attributes
         of variable length, a maximum length SHOULD be given.  Since
         the Length may depend on the Type, 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                                                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.3.  ipv4addr

   The "ipv4addr"

         A description of any attribute-specific limitations on the
         values carried by the specified data type encodes an IPv4 address in network byte
   order.  Where type.  If there are no
         attribute-specific limitations, then the range description of address for a particular attribute this
         field can be omitted, so long as the Description field is
         sufficiently explanatory.

         Where the values are limited to a sub-set subset of possible addresses, specifications MUST
   define the possible range,
         valid range(s).  Attributes with Values outside of the
   allowed range(s) SHOULD MUST be treated as "invalid attributes".

   Name

      ipv4addr

   Number

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Address                                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.4.  time

   The "time" defined.

         For attributes of data type encodes time as "enum", 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 2015 are likely to list of enumerated values
         and names MUST be
   erroneous.

   Note that the "time" given, as with [RFC2865] Section 5.6.

   Using a consistent format for attribute is defined definitions helps to be unsigned, which means
   it is not subject make the
   definitions clearer.

2.1.4.  Defining a New Data Type

   When a specification needs to define a signed integer overflow in new data type, it should
   follow the year 2038.

   Name

      time

   Number

      4

   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 format used by the definitions in Section 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Time                                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.5.  text of this
   document.  The "text" data type encodes UTF-8 text [RFC3629].  The maximum
   length at the start of the text is given by data type definition MUST
   describe the encapsulating attribute.  Where data type, including the range of lengths for expected use, and why a particular attribute new
   data type is limited to a sub-
   set of possible lengths, specifications required.  That text SHOULD include limits on expected
   values, and why those limits exist.  The fields "Name", "Value",
   "Length", and "Format", MUST define the valid
   range(s).  Attributes be given, along with length outside of the allowed values values.

   The "Name" field SHOULD be treated a single name, all lower-case.
   Contractions such as "invalid attributes".

   Where "ipv4addr" are RECOMMENDED where they add
   clarity.

   We note that the text is intended to carry data use of "Value" in a particular format,
   (e.g. Framed-Route), the format MUST RADIUS Data Type registry can
   be given.  The specification
   SHOULD describe the format in a machine-readable way, such as via
   Augmented Backus-Naur Form (ABNF).  Attributes confusing.  That name is also used in attribute definitions, but
   with values not
   matching a different meaning.  We trust that the defined format SHOULD meaning here is clear
   from the context.

   The "Value" field should be treated given as "invalid
   attributes".

   Note that the "text" data type does not terminate to be determined or "TBD" in
   specifications.  That number is assigned by IANA.

   The "Format" field SHOULD be defined with "Ascii art" in order to
   have a NUL octet
   (hex 00). precise definition.  Machine-readable formats are also
   RECOMMENDED.

   The Attribute has definition of a Length field and does new data type should be done only when absolutely
   necessary.  We do not use expect a
   terminator.  Texts need for a large number of length zero (0) MUST NOT be sent; omit the
   entire attribute instead.

   Name

      text

   Number

      5

   Length

      One or more octets.

   Format

       0
       0 1 2 3 4 5 6 7

      +-+-+-+-+-+-+-+-
      |  Value    ...
      +-+-+-+-+-+-+-+-

2.6.  string

   The "string" new data type encodes binary data, as
   types.  When defining a sequence of
   undistinguished octets.  Where new data type, the range guideliness of lengths for a particular
   attribute is limited [RFC6929]
   with respect to a sub-set of possible lengths, specifications 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 unique name in the valid range(s).  Attributes with length outside RADIUS Data Type
   registry.  The number of the allowed values SHOULD be treated as "invalid attributes".

   Note that the "string" data type does will be assigned by IANA.

2.2.  Implementation Use of Data Types

   Implementations not terminate with supporting 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" particular data type MUST be used.  This
   requirement include encapsulation treat
   attributes of that data structures defined outside
   of RADIUS, which are opaque to the RADIUS infrastucture.  It also
   includes encapsulation type as being of some data structures which are not opaque
   to RADIUS, type "string", as
   defined in Section 2.6.  It is RECOMMENDED that such attributes be
   treated as "invalid attributes", as defined in [RFC6929] Section 2.8.

   Where the contents of CHAP-Password.

   There is little reason to define a new RADIUS data type do not match the definition,
   implementations MUST treat the 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 only one
   attribute.  However, where the complex
     data type cannot be
   represented type, e.g. as TLVs, and is expected to be used given 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

   Number

      6

   Length

      One "integer", "ipv4addr",
     "ipv6addr", "ipv4prefix", "ipv6prefix", or more octets.

   Format
       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-
      |  Octets    ...
      +-+-+-+-+-+-+-+-

2.7.  concat

   The "concat" data type permits "enum".

   * "text" attributes where the transport of more contents do not match the required
   format,

   * Attributes where the length is shorter or longer than 253 octets
   of the allowed
     length(s) for the given data in a "standard space" [RFC6929] attribute.  It is otherwise
   identical 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 which define new meaning for "reserved" fields SHOULD
   describe how older implementations process those fields.  We expect
   that such descriptions are derived from practice.  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 "string"
   data type.

   If multiple attributes  These definitions have no impact on existing RADIUS
   implementations.  There is no requirement that implementations use
   these names.

   Where possible, the name of this each data type are contained in has been taken from
   previous specifications.  In some cases, a packet,
   all attributes different name has been
   chosen.  The change of name is sometimes required to avoid ambiguity
   (i.e. "address" versus "Address").  Otherwise, the same type code MUST be in order and they MUST new name has been
   chosen to be consecutive attributes compatible with [RFC2865], or with use in common
   implementations.  In some cases, new names are chosen to clarify the packet.

   The amount
   interpretation of the data transported in a "concat" type.

   The numbers assigned herein for the data type can be types have no more meaning other
   than the RADIUS packet size.  In practice, the requirement to
   transport multiple attributes means that the limit may permit them to be
   substantially smaller than one RADIUS packet. tracked by IANA.  As a rough guide, is
   RECOMMENDED that this RADIUS does not encode
   information about data types in a packet, the numbers assigned to a
   data type transport no more than 2048 octets 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
   data. each data type is taken from previous specifications.
   The "concat" fields are transmitted from left to right.

   Where the data types have inter-dependencies, the simplest data type MAY
   is given first, and dependent ones are given later.

   We do not create specific data types for the "tagged" attributes
   defines 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 used.  There is therefore no benefit to
   defining additional data types for "standard space" these attributes.
   It MUST NOT  We trust that
   implementors will be used for aware that tagged attributes in the "short extended space" or
   the "long extended space".  It MUST NOT must be used in any field or
   subfields treated
   differently from non-tagged attributes of the following same data types: "tlv", "vsa", "extended",
   "long-extended", or "evs".

   Name

      concat

   Number

      7

   Length

      One or more octets.

   Format

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-
      |  Octets    ...

      +-+-+-+-+-+-+-+-

2.8.  ifid

   The "ifid" type.

   Similarly, we do not create data type encodes an Interface-Id types for some attributes having
   complex structure, such as an 8-octet string in
   network byte order.

   Name

      ifid

   Number

      8

   Length

      Eight CHAP-Password, ARAP-Features, or Location-
   Capable.  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 [RFC6969] were used to make this
   determination.

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 sub-set 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Interface-ID ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Interface-ID     Value                                                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.9.  ipv6addr

3.2.  enum

   The "ipv6addr" "enum" data type encodes an IPv6 address a 32-bit unsigned integer in network
   byte order.  Where  It differs from the range of address for a particular attribute "integer" data type only in that it
   is
   limited used to a sub-set define enumerated types, such as Service-Type (Section 5.6
   of possible addresses, specifications [RFC 2865]).  Specifications MUST define the a valid range(s). set of enumerated
   values, along with a unique name for each value.  Attributes with
   Values outside of the allowed range(s) enumerations SHOULD be treated as
   "invalid attributes".

   Name

      ipv6addr

   Number

      9

      enum

   Value

      2

   Length
      Sixteen
      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 ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Address ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Address ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Address     Value                                                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.10.  ipv6prefix

3.3.  ipv4addr

   The "ipv6prefix" "ipv4addr" data type encodes an IPv6 prefix, using both a
   prefix length and an IPv6 IPv4 address in network byte
   order.  Where the range of prefixes address for a particular attribute is
   limited to a sub-set of possible prefixes, addresses, specifications MUST
   define the valid range(s).  Attributes with Values Addresses outside of the
   allowed range(s) SHOULD be treated as "invalid attributes".

   Attributes with a Prefix-Length field having value greater than 128
   SHOULD be treated as "invalid attributes".

   Name

      ipv6prefix

   Number

      10

      ipv4addr

   Value

      3

   Length

      At least two, and no more than eighteen octets.

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Reserved   | Prefix-Length |  Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix     Address                                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Reserved

         This field, which is reserved and MUST be present, is always
         set to zero.

      Prefix-Length

         The length of the prefix, in bits.  At least 0 and no larger
         than 128.

      Prefix

         The Prefix field is up to 16 octets in length.  Bits outside of
         the Prefix-Length, if included, MUST be zero.

2.11.  ipv4prefix

3.4.  time

   The "ipv4prefix" "time" data type encodes an IPv4 prefix, using both time as a
   prefix length and an IPv4 address 32-bit unsigned value in
   network byte order.  Where order and in seconds since 00:00:00 UTC, January 1,
   1970.  We note that dates before the
   range of prefixes for a particular year 2015 are likely to be
   erroneous.

   Note that the "time" attribute is limited defined to a sub-set
   of possible prefixes, specifications MUST define the valid range(s).
   Attributes with Values outside of the allowed range(s) SHOULD be
   treated as "invalid attributes".

   Attributes with unsigned, which means
   it is not subject to a Prefix-Length field having value greater than 32
   SHOULD be treated as "invalid attributes". signed integer overflow in the year 2038.

   Name

      ipv4prefix

   Number

      11

      time

   Value

      4

   Length

      At least two, and no more than eighteen octets.

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Reserved     Time                                                      | Prefix-Len|  Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Reserved

         This field, which is reserved and MUST be present, is always
         set to zero.

      Prefix-Length

         A 6-bit unsigned integer containing the

3.5.  text

   The "text" data type encodes UTF-8 text [RFC3629].  The maximum
   length of the prefix,
         in bits.  The values MUST be no larger than 32.

      Prefix

         The Prefix field text 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 given by the Prefix-Length MUST be set to 32.

2.12.  integer64

   The "integer64" data type encodes a 64-bit unsigned integer in
   network byte order. encapsulating attribute.  Where
   the range of values lengths for a particular attribute is limited to a sub-set sub-
   set of the values, possible lengths, specifications MUST define the valid
   range(s).  Attributes with Values length outside of the allowed range(s) values
   SHOULD be treated as "invalid attributes".

   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
   Augmented Backus-Naur Form (ABNF).  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

      integer64

   Number

      12

      text

   Value

      5

   Length
      Eight octets

      One 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +-+-+-+-+-+-+-+-
      |  Value    ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ... Value                                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.13.  tlv
      +-+-+-+-+-+-+-+-

3.6.  string

   The "tlv" "string" data type encodes binary data, as a type-length-value, sequence of
   undistinguished octets.  Where the range of lengths for a particular
   attribute is limited to a sub-set of possible lengths, specifications
   MUST define the valid range(s).  Attributes with length outside of
   the allowed values SHOULD be treated as defined in
   [RFC6929] Section 2.3.

   Name

      tlv

   Number

      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 "invalid attributes".

   Note that the policies and rules described in
         [RFC6929] Section 10.  Values 254-255 are "Reserved" for use by
         future extensions to RADIUS. "string" data type does not terminate with a NUL octet
   (hex 00).  The value 26 Attribute 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.

      TLV-Length

         The TLV-Length 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 does not use a TLV with an invalid TLV-Length, then the
         attribute which encapsulates that TLV MUST be considered to be
         an "invalid attribute", and handled as per [RFC6929] Section
         2.8.

         TLVs having TLV-Length
   terminator.  Strings of length zero (0) MUST NOT be sent; omit the
   entire TLV attribute instead.

      TLV-Data

         The TLV-Data field

   Where there is one or more octets a need to encapsulate complex data structures, and contains
         information specific
   TLVs cannot be used, the "string" data type MUST be used.  This
   requirement include encapsulation of data structures defined outside
   of RADIUS, which are opaque to the Attribute.  The format and length RADIUS infrastucture.  It also
   includes encapsulation of some data structures which are not opaque
   to RADIUS, such as the TLV-Data field contents of CHAP-Password.

   There is determined by the TLV-Type and TLV-
         Length fields.

         The TLV-Data field MUST contain only known little reason to define a new RADIUS data types.
         The TLV-Data field MUST NOT contain any of type for only one
   attribute.  However, where the following data
         types: "concat", "vsa", "extended", "long-extended", or "evs".

2.14.  vsa

   The "vsa" complex data type encodes Vendor-Specific data, cannot be
   represented as given in
   [RFC2865] Section 5.26.  It TLVs, and is expected to be used only in the Attr-Data field of many attributes, a
   Vendor-Specific Attribute.  It MUST NOT appear in the contents of any
   other data type.

   Where an implementation determines that an attribute of
   new data type
   "vsa" contains data SHOULD be defined.

   These requirements are stronger than [RFC6158], which does not match makes the expected format, it
   SHOULD treat that attribute as being an "invalid attribute". above
   encapsulation a "SHOULD".  This document defines data types for use
   in RADIUS, so there are few reasons to avoid using them.

   Name

      vsa

   Number

      14
      string

   Value

      6

   Length

      Five

      One or more octets 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                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +-+-+-+-+-+-+-+-
      |  VSA-Data ....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Vendor-Id  Octets    ...
      +-+-+-+-+-+-+-+-

3.7.  concat

   The 4 octets are "concat" data type permits the Network Management Private Enterprise Code
         [PEN] transport of the Vendor in network byte order.

      VSA-Data

         The VSA-Data field is one or more octets.  The actual format than 253 octets
   of
         the information is site or application specific, and data in a robust
         implementation SHOULD support the field as undistinguished
         octets.

         The codification of the range of allowed usage of this field "standard space" [RFC6929] attribute.  It is
         outside otherwise
   identical to the scope "string" data type.

   If multiple attributes of this specification.

         The "vsa" data type SHOULD contain as are contained in a sequence of "tlv" data
         types.  The interpretation packet,
   all attributes of the TLV-Type same type code MUST be in order and TLV-Data fields
         are dependent on they MUST
   be consecutive attributes in the vendor's definition of that attribute. packet.

   The "vsa" amount of data transported in a "concat" data type MUST can be used as contents of no more
   than the Attr-Data
         field of RADIUS packet size.  In practice, the Vendor-Specific attribute.  The "vsa" requirement to
   transport multiple attributes means that the limit may be
   substantially smaller than one RADIUS packet.  As a rough guide, is
   RECOMMENDED that this data type
         MUST NOT appear in the contents transport no more than 2048 octets of any other data type.

2.15.  extended
   data.

   The "extended" "concat" data type encodes the "Extended Type" format, as given
   in [RFC6929] Section 2.1. MAY be used for "standard space" attributes.
   It is MUST NOT be used only for attributes in the Attr-Data field of
   an Attribute allocated from "short extended space" or
   the "standard "long extended space".  It MUST NOT appear be used in the contents of any other field or
   subfields of the following data type. types: "tlv", "vsa", "extended",
   "long-extended", or "evs".

   Name

      extended

   Number

      15

      concat

   Value
      7

   Length

      Two

      One or more octets.

   Format

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-
      |  Octets    ...
      +-+-+-+-+-+-+-+-

3.8.  ifid

   The "ifid" data type encodes an Interface-Id as an 8-octet string in
   network byte order.

   Name

      ifid

   Value

      8

   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Extended-Type | Ext-Data     Interface-ID ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Extended-Type
           ... Interface-ID                                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.9.  ipv6addr

   The Extended-Type field is one octet.  Up-to-date values of
         this field are specified according to the policies and rules
         described "ipv6addr" data type encodes an IPv6 address in [RFC6929] Section 10.  Unlike network byte
   order.  Where the Type field
         defined in [RFC2865] Section 5, no values are allocated range of address 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 particular attribute is
   limited to a new type space sub-set of possible addresses, specifications MUST
   define the form "Type.Extended-Type".
         See [RFC6929] Section 2.5 for additional discussion.

         A RADIUS server MAY ignore Attributes with an unknown
         "Type.Extended-Type".

         A RADIUS client MAY ignore valid range(s).  Attributes with an unknown
         "Type.Extended-Type".

      Ext-Data

         The contents Addresses outside of this field MUST the
   allowed range(s) SHOULD be a valid data type treated 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.

         Implementations supporting this specification MUST use the
         Identifier of "Type.Extended-Type" to determine the
         interpretation of the Ext-Data field.

2.16.  long-extended "invalid attributes".

   Name

      ipv6addr

   Value

      9

   Length

      Sixteen 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 ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Address ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Address ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Address                                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.10.  ipv6prefix

   The "long-extended" "ipv6prefix" data type encodes the "Long Extended Type"
   format, as given in [RFC6929] Section 2.2.  It is used only an IPv6 prefix, using both a
   prefix length and an IPv6 address in network byte order.  Where the
   Attr-Data field
   range of an Attribute.  It prefixes for a particular attribute is limited to a sub-set
   of possible prefixes, specifications MUST NOT appear in define the contents valid range(s).
   Attributes with Addresses outside of any other data type. the allowed range(s) SHOULD be
   treated as "invalid attributes".

   Attributes with a Prefix-Length field having value greater than 128
   SHOULD be treated as "invalid attributes".

   Name

      long-extended

   Number

      16

      ipv6prefix

   Value
      10

   Length

      Three or

      At least two, and no more octets than eighteen 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|     Reserved   | Ext-Data Prefix-Length |  Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix                                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Extended-Type

      Reserved

         This field field, which is identical reserved and MUST be present, is always
         set to zero.

      Prefix-Length

         The length of the Extended-Type field defined
         above prefix, in Section 2.13.

      M (More) bits.  At least 0 and no larger
         than 128.

      Prefix

         The More Prefix field is one (1) bit in length, and indicates whether
         or not the current attribute contains "more" than 251 up to 16 octets in length.  Bits outside of
         data.  The More field MUST be clear (0) if
         the Length field has
         value less than 255.  The More field MAY be set (1) Prefix-Length, if the
         Length field has 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 of value 255; there included, MUST be zero.

3.11.  ipv4prefix

   The "ipv4prefix" data type encodes an attribute following
         this one; and the next attribute MUST have IPv4 prefix, using both the same Type
         and Extended Type.  That is, multiple fragments of the same
         value MUST be in order a
   prefix length and MUST be consecutive attributes an IPv4 address in network byte order.  Where the packet, and the last
   range of prefixes for a particular attribute in is limited to a packet sub-set
   of possible prefixes, specifications MUST NOT have define the More field set (1).

         That is, a packet containing a fragmented attribute needs to
         contain all fragments valid range(s).
   Attributes with Addresses outside of the attribute, and those fragments
         need to allowed range(s) SHOULD 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
   treated as "invalid attributes".

   Attributes with the
         "More" a Prefix-Length field set (1), but for which no subsequent fragment can
         be found, then the fragmented attribute is considered to having value greater than 32
   SHOULD be an treated as "invalid attribute", attributes".

   Name

      ipv4prefix

   Value

      11

   Length

      At least two, and handled as per [RFC6929] Section 2.8. no more than eighteen 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-Len|  Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Reserved

         This field is 7 bits long, and field, which is reserved for future use.
         Implementations and MUST be present, is always
         set it to zero (0) when encoding an
         attribute for sending zero.

      Prefix-Length

         A 6-bit unsigned integer containing the length of the prefix,
         in a packet. bits.  The contents SHOULD be
         ignored on reception.

         Future specifications may define additional meaning for this
         field.  Implementations therefore values MUST NOT treat this be no larger than 32.

      Prefix

         The Prefix field as
         invalid if it is non-zero.

      Ext-Data

         The contents 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 a valid set to 32.

3.12.  integer64

   The "integer64" data type as defined encodes a 64-bit unsigned integer in
   network byte order.  Where the RADIUS Data Type registry. The Ext-Data field MUST NOT
         contain any range of the following data types: "concat", "vsa",
         "extended", "long-extended", or "evs".

         The Ext-Data field values for a particular
   attribute is one or more octets.

         Implementations supporting this specification MUST use the
         Identifier of "Type.Extended-Type" limited to determine the
         interpretation of the Ext-Data field.

         The length a sub-set of the data values, specifications MUST be taken as the sum of
   define the lengths valid range(s).  Attributes with Values outside 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
   allowed range(s) SHOULD 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.

2.17.  evs 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                                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.13.  tlv

   The "evs" "tlv" data type encodes an "Extended Vendor-Specific" attribute, a type-length-value, as given defined 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" 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 which does not match the expected format, it
   SHOULD treat that attribute as being an "invalid attribute". 2.3.

   Name

      evs

   Number

      17

      tlv

   Value

      13

   Length

      Six

      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

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Vendor-Id                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   TLV-Type    |  Vendor-Type  TLV-Length   |  EVS-Data ....     TLV-Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Vendor-Id

         The 4 octets

      TLV-Type

         This field is one octet.  Up-to-date values of this field are
         specified according to the Network Management Private Enterprise Code
         [PEN] policies and rules described in
         [RFC6929] Section 10.  Values of the 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 in network byte order.

      Vendor-Type Specific
         attribute.

         The Vendor-Type field TLV-Type is one octet.  Values are assigned at meaningful only within the
         sole discretion context defined by
         "Type" fields of the Vendor.

      EVS-Data 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.

      TLV-Length

         The EVS-Data TLV-Length field is one or more octets. octet, and indicates the length of
         this TLV including the TLV-Type, TLV-Length and TLV-Value
         fields.  It SHOULD
         encapsulate MUST have a previously defined RADIUS data type.  Non-
         standard data types SHOULD NOT be used.  We note that value between 3 and 255.  If a client
         or server receives a TLV with an invalid TLV-Length, then the EVS-
         Data field may
         attribute which encapsulates that TLV MUST be considered to be
         an "invalid attribute", and handled as per [RFC6929] Section
         2.8.

         TLVs having TLV-Length of data type "tlv".

         The actual format of zero (0) MUST NOT be sent; omit the information
         entire TLV instead.

      TLV-Data

         The TLV-Data field is site one or application
         specific, more octets and a robust implementation SHOULD support the field
         as undistinguished octets.  We recognise that Vendors have
         complete control over contains
         information specific to the contents and Attribute.  The format and length
         of the Ext-Data
         field, while at the same time recommending that good practices
         be followed.

         Further codification of the range of allowed usage of this TLV-Data field is outside determined by the scope of this specification.

3.  Updated Registries

   This section defines a new IANA registry for RADIUS data types, TLV-Type and
   updates the existing RADIUS Attribute Type registry.

3.1.  Create a Data Type Registry

   This section defines a new RADIUS registry, called "Data Type".
   Allocation in this registry requires IETF Review.  The "Registration
   Procedures" for this registry are "Standards Action".

   The registry contains three columns of data, as follows.

   Value TLV-
         Length fields.

         The number of the TLV-Data field MUST contain only known RADIUS data type. types.
         The value TLV-Data field is an artifact of
      the registry, and has no on-the-wire meaning.

   Description

      The name MUST NOT contain any of the following data type.
         types: "concat", "vsa", "extended", "long-extended", or "evs".

3.14.  vsa

   The name field "vsa" data type encodes Vendor-Specific data, as given in
   [RFC2865] Section 5.26.  It is used only for in the
      registry, and has no on-the-wire meaning.

   Reference

      The specification where Attr-Data field of a
   Vendor-Specific Attribute.  It MUST NOT appear in the data type was defined.

   The initial contents of any
   other data type.

   Where an implementation determines that an attribute of data type
   "vsa" contains data which does not match the registry are expected format, it
   SHOULD treat that attribute as follows. being an "invalid attribute".

   Name

      vsa

   Value  Description    Reference
   -----  -----------    ----------------

      14

   Length

      Five or more octets

   Format

       0                   1                   2                   3
       0 1  integer        [RFC2865], TBD 2  enum           [RFC2865], TBD 3  ipv4addr       [RFC2865], TBD 4  time           [RFC2865], TBD 5  text           [RFC2865], TBD 6  string         [RFC2865], TBD 7  concat         TBD 8  ifid           [RFC3162], TBD 9  ipv6addr       [RFC3162], TBD
      10  ipv6prefix     [RFC3162], TBD
      11  ipv4prefix     [RFC6572], TBD
      12  integer64      [RFC6929], TBD
      13  tlv            [RFC6929], TBD
      14  evs            [RFC6929], TBD
      15  extended       [RFC6929], TBD
      16  long-extended  [RFC6929], TBD

3.2.  Updates to 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 Attribute Type Registry

   This section updates Network Management Private Enterprise Code
         [PEN] of the RADIUS Attribute Type Registry to have a new
   column, which is inserted Vendor in between network byte order.

      VSA-Data

         The VSA-Data field is one or more octets.  The actual format of
         the existing "Description" information is site or application specific, and
   "Reference" columns. a robust
         implementation SHOULD support the field as undistinguished
         octets.

         The new column codification of the range of allowed usage of this field is named "Data Type".
         outside the scope of this specification.

         The
   contents "vsa" data type SHOULD contain as a sequence of that column "tlv" data
         types.  The interpretation of the TLV-Type and TLV-Data fields
         are dependent on the name vendor's definition of a that attribute.

         The "vsa" data type, corresponding to type MUST be used as contents of the attribute in that row, or blank if Attr-Data
         field of the attribute type is
   unassigned. Vendor-Specific attribute.  The name of "vsa" data type
         MUST NOT appear in the contents of any other data type.

3.15.  extended

   The "extended" data type encodes the "Extended Type" format, as given
   in [RFC6929] Section 2.1.  It is taken used only in the Attr-Data field of
   an Attribute allocated from the RADIUS Data
   Type registry, "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 above. 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 updated registry follows 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.5 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".

      Ext-Data

         The contents of this field MUST be a valid data type as defined
         in CSV format.

   Value,Description,Data Type,Reference
   1,User-Name,text,[RFC2865]
   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-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]

4.  Suggestions 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.

         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| Reserved    | Ext-Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Extended-Type

         This field is identical to the Extended-Type field defined
         above in Section 2.13.

      M (More)

         The More field 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
         value less than 255.  The More field MAY be set (1) if the
         Length field has 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 of value 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 handled as per [RFC6929] Section 2.8.

      Reserved
         This field is 7 bits long, and is reserved for Specifications 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 additional meaning for this
         field.  Implementations therefore MUST NOT treat this field as
         invalid if it is non-zero.

      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.

         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 suggest 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.

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" or a "long-extended" data type.  It MUST NOT appear in
   the contents of any other data type.

   Where an implementation determines that these an attribute of data types be used type
   "evs" contains data which 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 new network byte order.

      Vendor-Type

         The Vendor-Type field is one octet.  Values are assigned at the
         sole discretion of the Vendor.

      EVS-Data

         The EVS-Data field is one or more octets.  It SHOULD
         encapsulate a previously defined RADIUS
   specifications.  Attributes can usually be completely described
   through their Attribute Type code, name, and data type.  Non-
         standard data types SHOULD NOT be used.  We note that the EVS-
         Data field may be of data type "tlv".

         The use actual format of
   "ASCII art" the information is then limited only to site or application
         specific, and a robust implementation SHOULD support the definition field
         as undistinguished octets.  We recognise that Vendors have
         complete control over the contents and format of the Ext-Data
         field, while at the same time recommending 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 complex data types.

   Use of
   updates the existing RADIUS Attribute Type registry.

4.1.  Create a Data Type Registry

   This section defines a new extended attributes [RFC6929] makes ASCII art even
   more problematic.  An attribute can be allocated from the standard
   space, or from one RADIUS registry, called "Data Type".
   Allocation in this registry requires IETF Review.  The "Registration
   Procedures" for this registry are "Standards Action".

   The registry contains three columns of data, as follows.

   Value

      The number of the extended spaces.  This allocation decision data type.  The value field is made after an artifact of
      the specification registry, and has been accepted for publication.
   That allocation strongly affects the format no on-the-wire meaning.

   Description

      The name of the attribute header,
   making it nearly impossible to create the correct ASCII art prior to
   final publication.  Allocation from data type.  The name field is used only for the different spaces also changes
      registry, and has no on-the-wire meaning.

   Reference

      The specification where the value data type was defined.

   The initial contents of the Length field, also making it difficult to define it
   correctly prior registry are as follows.

   Value  Description    Reference
   -----  -----------    ----------------
       1  integer        [RFC2865], TBD
       2  enum           [RFC2865], TBD
       3  ipv4addr       [RFC2865], TBD
       4  time           [RFC2865], TBD
       5  text           [RFC2865], TBD
       6  string         [RFC2865], TBD
       7  concat         TBD
       8  ifid           [RFC3162], TBD
       9  ipv6addr       [RFC3162], TBD
      10  ipv6prefix     [RFC3162], TBD
      11  ipv4prefix     [RFC6572], TBD
      12  integer64      [RFC6929], TBD
      13  tlv            [RFC6929], TBD
      14  evs            [RFC6929], TBD
      15  extended       [RFC6929], TBD
      16  long-extended  [RFC6929], TBD

4.2.  Updates to final publication of the document.

   The following fields SHOULD be given when defining new attributes:

   Description

      A description of the meaning and interpretation of the attribute. Attribute Type

      The Registry

   This section updates the RADIUS Attribute Type code, given Registry to have a new
   column, which is inserted in between the "dotted number" notation
      from [RFC6929].  Specifications can often leave this as "TBD", existing "Description" and
      request
   "Reference" columns.  The new column is named "Data Type".  The
   contents of that IANA fill in column are the allocated values.

   Length

      attributes name of variable length, a maximum length SHOULD be given.
      Since the Length may depend on data type, corresponding to
   the Type, attribute in that row, or blank if the definition of Length
      may be affected by IANA allocations.

   Data Type

      One attribute type is
   unassigned.  The name of the named data types type is taken 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 with [RFC2865] Section 5.6. registry, defined above.

   The updated registry follows in CSV format.

   Value,Description,Data Type,Reference
   1,User-Name,text,[RFC2865]
   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-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

   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 an implementor has fewer specifications to read.  The
   implementation work is therefore simpler, and is more likely to be
   correct.

   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 is instructed to create one new registry as described above in
   Section 3.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
   described above in Section 3.2.

   IANA is instructed to require that all allocation requests in the
   RADIUS Attribute Type Registry contain a "Data Type" field.  That
   field is required to contain one of the "Data Type" names contained
   in the RADIUS Data Type registry.

   IANA is instructed to require 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 which defines the data type.

7.  References

7.1.  Normative References

[RFC2119]
     Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", RFC 2119, March, 1997.

[RFC2865]
     Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
     Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.

[RFC3162]
     Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162,
     August 2001.

[RFC3629]
     Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
     3629, November 2003.

[RFC4072]
     Eronen, P., et al, "Diameter Extensible Authentication Protocol
     (EAP) Application", RFC 4072, February 2013.

[RFC6158]
     DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 6158,
     March 2011.

[RFC6572]
     Xia, F., et al, "RADIUS Support for Proxy Mobile IPv6", RFC 6572,
     June 2012.

7.2.  Informative References

[RFC2868]
     Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I.
     Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868,
     June 2000.

[RFC2869]
     Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000.

[RFC6929]
     DeKok, A., and Lior, A., "Remote Authentication Dial In User
     Service (RADIUS) Protocol Extensions", RFC 6929, April 2013.

[RFC7268]
     Aboba, B, et al, "RADIUS Attributes for IEEE 802 Networks", RFC
     7268, July 2015.

[RFC7499]
     Perez-Mendez A., et al, "Support of Fragmentation of RADIUS
     Packets", RFC 7499, April 2015.

[PEN]
     http://www.iana.org/assignments/enterprise-numbers

Acknowledgments

   Stuff

Authors' Addresses

   Alan DeKok
   The FreeRADIUS Server Project

   Email: aland@freeradius.org