tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6929

 
 
 

Remote Authentication Dial In User Service (RADIUS) Protocol Extensions

Part 2 of 3, p. 21 to 42
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 21 
3.  Attribute Definitions

   We define four (4) attributes of "Extended Type", which are allocated
   from the "Reserved" Attribute Type codes of 241, 242, 243, and 244.
   We also define two (2) attributes of "Long Extended Type", which are
   allocated from the "Reserved" Attribute Type codes of 245 and 246.

      Type  Name
      ----  ----
      241   Extended-Type-1
      242   Extended-Type-2
      243   Extended-Type-3
      244   Extended-Type-4
      245   Long-Extended-Type-1
      246   Long-Extended-Type-2

   The rest of this section gives detailed definitions for each
   Attribute based on the above summary.

3.1.  Extended-Type-1

   Description

      This attribute encapsulates attributes of the "Extended Type"
      format, in the RADIUS Attribute Type space of 241.{1-255}.

   A summary of the Extended-Type-1 Attribute format is shown below.
   The fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      241 for Extended-Type-1.

   Length

      >= 4

Top      Up      ToC       Page 22 
   Extended-Type

      The Extended-Type field is one octet.  Up-to-date values of this
      field are specified in the 241.{1-255} RADIUS Attribute Type
      space, according to the policies and rules described in
      Section 10.  Further definition of this field is given in
      Section 2.1, above.

   Value

      The "Value" field is one or more octets.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type" to determine the interpretation
      of the "Value" field.

3.2.  Extended-Type-2

   Description

      This attribute encapsulates attributes of the "Extended Type"
      format, in the RADIUS Attribute Type space of 242.{1-255}.

   A summary of the Extended-Type-2 Attribute format is shown below.
   The fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      242 for Extended-Type-2.

   Length

      >= 4

   Extended-Type

      The Extended-Type field is one octet.  Up-to-date values of this
      field are specified in the 242.{1-255} RADIUS Attribute Type
      space, according to the policies and rules described in
      Section 10.  Further definition of this field is given in
      Section 2.1, above.

Top      Up      ToC       Page 23 
   Value

      The "Value" field is one or more octets.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type" to determine the interpretation
      of the "Value" field.

3.3.  Extended-Type-3

   Description

      This attribute encapsulates attributes of the "Extended Type"
      format, in the RADIUS Attribute Type space of 243.{1-255}.

   A summary of the Extended-Type-3 Attribute format is shown below.
   The fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      243 for Extended-Type-3.

   Length

      >= 4

   Extended-Type

      The Extended-Type field is one octet.  Up-to-date values of this
      field are specified in the 243.{1-255} RADIUS Attribute Type
      space, according to the policies and rules described in
      Section 10.  Further definition of this field is given in
      Section 2.1, above.

   Value

      The "Value" field is one or more octets.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type" to determine the interpretation
      of the "Value" field.

Top      Up      ToC       Page 24 
3.4.  Extended-Type-4

   Description

      This attribute encapsulates attributes of the "Extended Type"
      format, in the RADIUS Attribute Type space of 244.{1-255}.

   A summary of the Extended-Type-4 Attribute format is shown below.
   The fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      244 for Extended-Type-4.

   Length

      >= 4

   Extended-Type

      The Extended-Type field is one octet.  Up-to-date values of this
      field are specified in the 244.{1-255} RADIUS Attribute Type
      space, according to the policies and rules described in
      Section 10.  Further definition of this field is given in
      Section 2.1, above.

   Value

      The "Value" field is one or more octets.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type" to determine the interpretation
      of the Value Field.

Top      Up      ToC       Page 25 
3.5.  Long-Extended-Type-1

   Description

      This attribute encapsulates attributes of the "Long Extended Type"
      format, in the RADIUS Attribute Type space of 245.{1-255}.

   A summary of the Long-Extended-Type-1 Attribute format is shown
   below.  The fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type |M|  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      245 for Long-Extended-Type-1

   Length

      >= 5

   Extended-Type

      The Extended-Type field is one octet.  Up-to-date values of this
      field are specified in the 245.{1-255} RADIUS Attribute Type
      space, according to the policies and rules described in
      Section 10.  Further definition of this field is given in
      Section 2.1, above.

   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.
      Further definition of this field is given in Section 2.2, above.

   Reserved

      This field is 7 bits long and is reserved for future use.
      Implementations MUST set it to zero (0) when encoding an attribute
      for sending in a packet.  The contents SHOULD be ignored on
      reception.

Top      Up      ToC       Page 26 
   Value

      The "Value" field is one or more octets.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type" to determine the interpretation
      of the "Value" field.

3.6.  Long-Extended-Type-2

   Description

      This attribute encapsulates attributes of the "Long Extended Type"
      format, in the RADIUS Attribute Type space of 246.{1-255}.

   A summary of the Long-Extended-Type-2 Attribute format is shown
   below.  The fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type |M|  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      246 for Long-Extended-Type-2

   Length

      >= 5

   Extended-Type

      The Extended-Type field is one octet.  Up-to-date values of this
      field are specified in the 246.{1-255} RADIUS Attribute Type
      space, according to the policies and rules described in
      Section 10.  Further definition of this field is given in
      Section 2.1, above.

   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.
      Further definition of this field is given in Section 2.2, above.

Top      Up      ToC       Page 27 
   Reserved

      This field is 7 bits long and is reserved for future use.
      Implementations MUST set it to zero (0) when encoding an attribute
      for sending in a packet.  The contents SHOULD be ignored on
      reception.

   Value

      The "Value" field is one or more octets.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type" to determine the interpretation
      of the "Value" field.

4.  Vendor-Specific Attributes

   We define six new attributes that can carry vendor-specific
   information.  We define four (4) attributes of the "Extended Type"
   format, with Type codes (241.26, 242.26, 243.26, 244.26), using the
   "evs" data type.  We also define two (2) attributes using "Long
   Extended Type" format, with Type codes (245.26, 246.26), which are of
   the "evs" data type.

      Type.Extended-Type  Name
      ------------------  ----
      241.26              Extended-Vendor-Specific-1
      242.26              Extended-Vendor-Specific-2
      243.26              Extended-Vendor-Specific-3
      244.26              Extended-Vendor-Specific-4
      245.26              Extended-Vendor-Specific-5
      246.26              Extended-Vendor-Specific-6

   The rest of this section gives detailed definitions for each
   Attribute based on the above summary.

Top      Up      ToC       Page 28 
4.1.  Extended-Vendor-Specific-1

   Description

      This attribute defines a RADIUS Type Code of 241.26, using the
      "evs" data type.

   A summary of the Extended-Vendor-Specific-1 Attribute format is shown
   below.  The fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type |  Vendor-Id ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ... Vendor-Id  (cont)                        |  Vendor-Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Value ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type.Extended-Type

      241.26 for Extended-Vendor-Specific-1

   Length

      >= 9

   Vendor-Id

      The 4 octets of the Vendor-Id field are the Network Management
      Private Enterprise Code [PEN] of the vendor in network byte order.

   Vendor-Type

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

   Value

      The "Value" field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification of the range of allowed usage of this field is
      outside the scope of this specification.

Top      Up      ToC       Page 29 
      The length of the "Value" field is eight (8) less than the value
      of the Length field.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to
      determine the interpretation of the "Value" field.

4.2.  Extended-Vendor-Specific-2

   Description

      This attribute defines a RADIUS Type Code of 242.26, using the
      "evs" data type.

   A summary of the Extended-Vendor-Specific-2 Attribute format is shown
   below.  The fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type |  Vendor-Id ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ... Vendor-Id  (cont)                        |  Vendor-Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Value ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type.Extended-Type

      242.26 for Extended-Vendor-Specific-2

   Length

      >= 9

   Vendor-Id

      The 4 octets of the Vendor-Id field are the Network Management
      Private Enterprise Code [PEN] of the vendor in network byte order.

   Vendor-Type

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

Top      Up      ToC       Page 30 
   Value

      The "Value" field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification of the range of allowed usage of this field is
      outside the scope of this specification.

      The length of the "Value" field is eight (8) less than the value
      of the Length field.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to
      determine the interpretation of the "Value" field.

4.3.  Extended-Vendor-Specific-3

   Description

      This attribute defines a RADIUS Type Code of 243.26, using the
      "evs" data type.

   A summary of the Extended-Vendor-Specific-3 Attribute format is shown
   below.  The fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type |  Vendor-Id ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ... Vendor-Id  (cont)                        |  Vendor-Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Value ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type.Extended-Type

      243.26 for Extended-Vendor-Specific-3

   Length

      >= 9

   Vendor-Id

      The 4 octets of the Vendor-Id field are the Network Management
      Private Enterprise Code [PEN] of the vendor in network byte order.

Top      Up      ToC       Page 31 
   Vendor-Type

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

   Value

      The "Value" field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification of the range of allowed usage of this field is
      outside the scope of this specification.

      The length of the "Value" field is eight (8) less than the value
      of the Length field.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to
      determine the interpretation of the "Value" field.

4.4.  Extended-Vendor-Specific-4

   Description

      This attribute defines a RADIUS Type Code of 244.26, using the
      "evs" data type.

   A summary of the Extended-Vendor-Specific-4 Attribute format is shown
   below.  The fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type |  Vendor-Id ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ... Vendor-Id  (cont)                        |  Vendor-Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Value ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type.Extended-Type

      244.26 for Extended-Vendor-Specific-4

   Length

      >= 9

Top      Up      ToC       Page 32 
   Vendor-Id

      The 4 octets of the Vendor-Id field are the Network Management
      Private Enterprise Code [PEN] of the vendor in network byte order.

   Vendor-Type

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

   Value

      The "Value" field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification of the range of allowed usage of this field is
      outside the scope of this specification.

      The length of the "Value" field is eight (8) less than the value
      of the Length field.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to
      determine the interpretation of the "Value" field.

4.5.  Extended-Vendor-Specific-5

   Description

      This attribute defines a RADIUS Type Code of 245.26, using the
      "evs" data type.

   A summary of the Extended-Vendor-Specific-5 Attribute format is shown
   below.  The fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type |M|  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Vendor-Id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type   |  Value ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 33 
   Type.Extended-Type

      245.26 for Extended-Vendor-Specific-5

   Length

      >= 10   (first fragment)
      >= 5    (subsequent fragments)

      When a VSA is fragmented across multiple Attributes, only the
      first Attribute contains the Vendor-Id and Vendor-Type fields.
      Subsequent Attributes contain fragments of the "Value" field only.

   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.
      Further definition of this field is given in Section 2.2, above.

   Reserved

      This field is 7 bits long and is reserved for future use.
      Implementations MUST set it to zero (0) when encoding an attribute
      for sending in a packet.  The contents SHOULD be ignored on
      reception.

   Vendor-Id

      The 4 octets of the Vendor-Id field are the Network Management
      Private Enterprise Code [PEN] of the vendor in network byte order.

   Vendor-Type

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

   Value

      The "Value" field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification of the range of allowed usage of this field is
      outside the scope of this specification.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to
      determine the interpretation of the "Value" field.

Top      Up      ToC       Page 34 
4.6.  Extended-Vendor-Specific-6

   Description

      This attribute defines a RADIUS Type Code of 246.26, using the
      "evs" data type.

   A summary of the Extended-Vendor-Specific-6 Attribute format is shown
   below.  The fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type |M|  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Vendor-Id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Vendor-Type   |  Value ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type.Extended-Type

      246.26 for Extended-Vendor-Specific-6

   Length

      >= 10   (first fragment)
      >= 5    (subsequent fragments)

      When a VSA is fragmented across multiple Attributes, only the
      first Attribute contains the Vendor-Id and Vendor-Type fields.
      Subsequent Attributes contain fragments of the "Value" field only.

   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.
      Further definition of this field is given in Section 2.2, above.

   Reserved

      This field is 7 bits long and is reserved for future use.
      Implementations MUST set it to zero (0) when encoding an attribute
      for sending in a packet.  The contents SHOULD be ignored on
      reception.

Top      Up      ToC       Page 35 
   Vendor-Id

      The 4 octets of the Vendor-Id field are the Network Management
      Private Enterprise Code [PEN] of the vendor in network byte order.

   Vendor-Type

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

   Value

      The "Value" field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification of the range of allowed usage of this field is
      outside the scope of this specification.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to
      determine the interpretation of the "Value" field.

5.  Compatibility with Traditional RADIUS

   There are a number of potential compatibility issues with traditional
   RADIUS, as defined in [RFC6158] and earlier.  This section describes
   them.

5.1.  Attribute Allocation

   Some vendors have used Attribute Type codes from the "Reserved" space
   as part of vendor-defined dictionaries.  This practice is considered
   antisocial behavior, as noted in [RFC6158].  These vendor definitions
   conflict with the Attributes in the RADIUS Attribute Type space.  The
   conflicting definitions may make it difficult for implementations to
   support both those Vendor Attributes, and the new Extended Attribute
   formats.

   We RECOMMEND that RADIUS client and server implementations delete all
   references to these improperly defined attributes.  Failing that, we
   RECOMMEND that RADIUS server implementations have a per-client
   configurable flag that indicates which type of attributes are being
   sent from the client.  If the flag is set to "Non-Standard
   Attributes", the conflicting attributes can be interpreted as being
   improperly defined Vendor-Specific Attributes.  If the flag is set to

Top      Up      ToC       Page 36 
   "IETF Attributes", the Attributes MUST be interpreted as being of the
   Extended Attributes format.  The default SHOULD be to interpret the
   Attributes as being of the Extended Attributes format.

   Other methods of determining how to decode the Attributes into a
   "correct" form are NOT RECOMMENDED.  Those methods are likely to be
   fragile and prone to error.

   We RECOMMEND that RADIUS server implementations reuse the above flag
   to determine which types of attributes to send in a reply message.
   If the request is expected to contain the improperly defined
   attributes, the reply SHOULD NOT contain Extended Attributes.  If the
   request is expected to contain Extended Attributes, the reply MUST
   NOT contain the improper Attributes.

   RADIUS clients will have fewer issues than servers.  Clients MUST NOT
   send improperly defined Attributes in a request.  For replies,
   clients MUST interpret attributes as being of the Extended Attributes
   format, instead of the improper definitions.  These requirements
   impose no change in the RADIUS specifications, as such usage by
   vendors has always been in conflict with the standard requirements
   and the standards process.

   Existing clients that send these improperly defined attributes
   usually have a configuration setting that can disable this behavior.
   We RECOMMEND that vendors ship products with the default set to
   "disabled".  We RECOMMEND that administrators set this flag to
   "disabled" on all equipment that they manage.

5.2.  Proxy Servers

   RADIUS proxy servers will need to forward Attributes having the new
   format, even if they do not implement support for the encoding and
   decoding of those attributes.  We remind implementers of the
   following text in [RFC2865] Section 2.3:

      The forwarding server MUST NOT change the order of any attributes
      of the same type, including Proxy-State.

   This requirement solves some of the issues related to proxying of the
   new format, but not all.  The reason is that proxy servers are
   permitted to examine the contents of the packets that they forward.
   Many proxy implementations not only examine the Attributes, but they
   refuse to forward attributes that they do not understand (i.e.,
   attributes for which they have no local dictionary definitions).

Top      Up      ToC       Page 37 
   This practice is NOT RECOMMENDED.  Proxy servers SHOULD forward
   attributes, even attributes that they do not understand or that are
   not in a local dictionary.  When forwarded, these attributes SHOULD
   be sent verbatim, with no modifications or changes.  This requirement
   includes "invalid attributes", as there may be some other system in
   the network that understands them.

   The only exception to this recommendation is when local site policy
   dictates that filtering of attributes has to occur.  For example, a
   filter at a visited network may require removal of certain
   authorization rules that apply to the home network but not to the
   visited network.  This filtering can sometimes be done even when the
   contents of the Attributes are unknown, such as when all Vendor-
   Specific Attributes are designated for removal.

   As seen during testing performed in 2010 via the EDUcation ROAMing
   (EDUROAM) service (A. DeKok, unpublished data), many proxies do not
   follow these practices for unknown Attributes.  Some proxies filter
   out unknown attributes or attributes that have unexpected lengths
   (24%, 17/70), some truncate the Attributes to the "expected" length
   (11%, 8/70), some discard the request entirely (1%, 1/70), and the
   rest (63%, 44/70) follow the recommended practice of passing the
   Attributes verbatim.  It will be difficult to widely use the Extended
   Attributes format until all non-conformant proxies are fixed.  We
   therefore RECOMMEND that all proxies that do not support the Extended
   Attributes (241 through 246) define them as being of data type
   "string" and delete all other local definitions for those attributes.

   This last change should enable wider usage of the Extended Attributes
   format.

6.  Guidelines

   This specification proposes a number of changes to RADIUS and
   therefore requires a set of guidelines, as has been done in
   [RFC6158].  These guidelines include suggestions related to design,
   interaction with IANA, usage, and implementation of attributes using
   the new formats.

6.1.  Updates to RFC 6158

   This specification updates [RFC6158] by adding the data types "evs",
   "tlv", and "integer64"; defining them to be "basic" data types; and
   permitting their use subject to the restrictions outlined below.

   The recommendations for the use of the new data types and Attribute
   formats are given below.

Top      Up      ToC       Page 38 
6.2.  Guidelines for Simple Data Types

   [RFC6158] Section A.2.1 says in part:

   * Unsigned integers of size other than 32 bits.  SHOULD be replaced
     by an unsigned integer of 32 bits.  There is insufficient
     justification to define a new size of integer.

   We update that specification to permit unsigned integers of 64 bits,
   for the reasons defined above in Section 2.5. The updated text is as
   follows:

   * Unsigned integers of size other than 32 or 64 bits.  SHOULD be
     replaced by an unsigned integer of 32 or 64 bits.  There is
     insufficient justification to define a new size of integer.

   That section later continues with the following list item:

   * Nested attribute-value pairs (AVPs).  Attributes should be defined
     in a flat typespace.

   We update that specification to permit nested TLVs, as defined in
   this document:

   * Nested attribute-value pairs (AVPs) using the extended Attribute
     format MAY be used.  All other nested AVP or TLV formats MUST NOT
     be used.

   The [RFC6158] recommendations for "basic" data types apply to the
   three types listed above.  All other recommendations given in
   [RFC6158] for "basic" data types remain unchanged.

6.3.  Guidelines for Complex Data Types

   [RFC6158] Section 2.1 says:

      Complex data types MAY be used in situations where they reduce
      complexity in non-RADIUS systems or where using the basic data
      types would be awkward (such as where grouping would be required
      in order to link related attributes).

   Since the extended Attribute format allows for grouping of complex
   types via TLVs, the guidelines for complex data types need to be
   updated as follows:

      [RFC6158], Section 3.2.4, describes situations in which complex
      data types might be appropriate.  They SHOULD NOT be used even in
      those situations, without careful consideration of the described

Top      Up      ToC       Page 39 
      limitations.  In all other cases not covered by the complex data
      type exceptions, complex data types MUST NOT be used.  Instead,
      complex data types MUST be decomposed into TLVs.

   The checklist in [RFC6158] Appendix A.2.2 is similarly updated to add
   a new requirement at the top of that section, as follows:

      Does the Attribute

      * define a complex type that can be represented via TLVs?

      If so, this data type MUST be represented via TLVs.

   Note that this requirement does not override [RFC6158] Appendix A.1,
   which permits the transport of complex types in certain situations.

   All other recommendations given in [RFC6158] for "complex" data types
   remain unchanged.

6.4.  Design Guidelines for the New Types

   This section gives design guidelines for specifications defining
   attributes using the new format.  The items listed below are not
   exhaustive.  As experience is gained with the new formats, later
   specifications may define additional guidelines.

   * The data type "evs" MUST NOT be used for standard RADIUS
     Attributes, or for TLVs, or for VSAs.

   * The data type TLV SHOULD NOT be used for standard RADIUS
     attributes.

   * [RFC2866] "tagged" attributes MUST NOT be defined in the
     Extended-Type space.  The "tlv" data type should be used instead to
     group attributes.

   * The "integer64" data type MAY be used in any RADIUS attribute.  The
     use of 64-bit integers was not recommended in [RFC6158], but their
     utility is now evident.

   * Any attribute that is allocated from the long extended space of
     data type "text", "string", or "tlv" can potentially carry more
     than 251 octets of data.  Specifications defining such attributes
     SHOULD define a maximum length to guide implementations.

   All other recommendations given in [RFC6158] for attribute design
   guidelines apply to attributes using the short extended space and
   long extended space.

Top      Up      ToC       Page 40 
6.5.  TLV Guidelines

   The following items give design guidelines for specifications using
   TLVs.

   * When multiple Attributes are intended to be grouped or managed
     together, the use of TLVs to group related attributes is
     RECOMMENDED.

   * More than 4 layers (depth) of TLV nesting is NOT RECOMMENDED.

   * Interpretation of an attribute depends only on its type definition
     (e.g., Type.Extended-Type.TLV-Type) and not on its encoding or
     location in the RADIUS packet.

   * Where a group of TLVs is strictly defined, and not expected to
     change, and totals less than 247 octets of data, the specifications
     SHOULD request allocation from the short extended space.

   * Where a group of TLVs is loosely defined or is expected to change,
     the specifications SHOULD request allocation from the long extended
     space.

   All other recommendations given in [RFC6158] for attribute design
   guidelines apply to attributes using the TLV format.

6.6.  Allocation Request Guidelines

   The following items give guidelines for allocation requests made in a
   RADIUS specification.

   * Discretion is recommended when requesting allocation of attributes.
     The new space is much larger than the old one, but it is not
     infinite.

   * Specifications that allocate many attributes MUST NOT request that
     allocation be made from the standard space.  That space is under
     allocation pressure, and the extended space is more suitable for
     large allocations.  As a guideline, we suggest that one
     specification allocating twenty percent (20%) or more of the
     standard space would meet the above criteria.

   * Specifications that allocate many related attributes SHOULD define
     one or more TLVs to contain related attributes.

Top      Up      ToC       Page 41 
   * Specifications SHOULD request allocation from a specific space.
     The IANA considerations given in Section 10, below, give
     instructions to IANA, but authors should assist IANA where
     possible.

   * Specifications of an attribute that encodes 252 octets or less of
     data MAY request allocation from the short extended space.

   * Specifications of an attribute that always encode less than
     253 octets of data MUST NOT request allocation from the long
     extended space.  The standard space or the short extended space
     MUST be used instead.

   * Specifications of an attribute that encodes 253 octets or more of
     data MUST request allocation from the long extended space.

   * When the extended space is nearing exhaustion, a new specification
     will have to be written that requests allocation of one or more
     RADIUS attributes from the "Reserved" portion of the standard
     space, values 247-255, using an appropriate format ("Short Extended
     Type", or "Long Extended Type").

   An allocation request made in a specification SHOULD use one of the
   following formats when allocating an attribute type code:

   * TBDn - request allocation of an attribute from the standard space.
     The value "n" should be 1 or more, to track individual attributes
     that are to be allocated.

   * SHORT-TBDn - request allocation of an attribute from the short
     extended space.  The value "n" should be 1 or more, to track
     individual attributes that are to be allocated.

   * LONG-TBDn - request allocation of an attribute from the long
     extended space.  The value "n" should be 1 or more, to track
     individual attributes that are to be allocated.

   These guidelines should help specification authors and IANA
   communicate effectively and clearly.

6.7.  Allocation Request Guidelines for TLVs

   Specifications may allocate a new attribute of type TLV and at the
   same time allocate sub-Attributes within that TLV.  These
   specifications SHOULD request allocation of specific values for the
   sub-TLV.  The "dotted number" notation MUST be used.

Top      Up      ToC       Page 42 
   For example, a specification may request allocation of a TLV as
   SHORT-TBD1.  Within that attribute, it could request allocation of
   three sub-TLVs, as SHORT-TBD1.1, SHORT-TBD1.2, and SHORT-TBD1.3.

   Specifications may request allocation of additional sub-TLVs within
   an existing attribute of type TLV.  Those specifications SHOULD use
   the "TBDn" format for every entry in the "dotted number" notation.

   For example, a specification may request allocation within an
   existing TLV, with "dotted number" notation MM.NN.  Within that
   attribute, the specification could request allocation of three
   sub-TLVs, as MM.NN.TBD1, MM.NN.TBD2, and MM.NN.TBD3.

6.8.  Implementation Guidelines

   * RADIUS client implementations SHOULD support this specification in
     order to permit the easy deployment of specifications using the
     changes defined herein.

   * RADIUS server implementations SHOULD support this specification in
     order to permit the easy deployment of specifications using the
     changes defined herein.

   * RADIUS proxy servers MUST follow the specifications in Section 5.2.

6.9.  Vendor Guidelines

   * Vendors SHOULD use the existing Vendor-Specific Attribute Type
     space in preference to the new Extended-Vendor-Specific Attributes,
     as this specification may take time to become widely deployed.

   * Vendors SHOULD implement this specification.  The changes to RADIUS
     are relatively small and are likely to quickly be used in new
     specifications.



(page 42 continued on part 3)

Next RFC Part