idnits 2.17.1 draft-ietf-radext-datatypes-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2865, but the abstract doesn't seem to directly say this. It does mention RFC2865 though, so this could be OK. -- The draft header indicates that this document updates RFC3162, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6158, but the abstract doesn't seem to directly say this. It does mention RFC6158 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2865, updated by this document, for RFC5378 checks: 1999-03-04) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (2 November 2015) is 3098 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6969' is mentioned on line 432, but not defined == Missing Reference: 'RFC 2865' is mentioned on line 468, but not defined == Unused Reference: 'RFC7499' is defined on line 1618, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group DeKok, Alan 3 INTERNET-DRAFT FreeRADIUS 4 Updates: 2865,3162,6158,6572 5 Category: Standards Track 6 7 2 November 2015 9 Data Types in the Remote Authentication 10 Dial-In User Service Protocol (RADIUS) 11 draft-ietf-radext-datatypes-02.txt 13 Abstract 15 RADIUS specifications have used data types for two decades without 16 defining them as managed entities. During this time, RADIUS 17 implementations have named the data types, and have used them in 18 attribute definitions. This document updates the specifications to 19 better follow established practice. We do this by naming the data 20 types defined in RFC 6158, which have been used since at least RFC 21 2865. We provide an IANA registry for the data types, and update the 22 RADIUS Attribute Type registry to include a "Data Type" field for 23 each attribute. Finally, we recommend that authors of RADIUS 24 specifications use these types in preference to existing practice. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on May 2, 2016. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info/) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction ............................................. 4 67 1.1. Specification Problems with Data Types .............. 4 68 1.2. Implementation Problems with Data Types ............. 5 69 1.3. No Mandated Changes ................................. 5 70 1.4. Requirements Language ............................... 5 71 2. Use of Data Types ........................................ 6 72 2.1. Specification Use of Data Types ..................... 6 73 2.1.1. Field Names for Attribute Values ............... 6 74 2.1.2. Attribute Definitions using Data Types ......... 7 75 2.1.3. Format of Attribute Definitions ................ 7 76 2.1.4. Defining a New Data Type ....................... 8 77 2.2. Implementation Use of Data Types .................... 9 78 3. Data Type Definitions .................................... 11 79 3.1. integer ............................................. 12 80 3.2. enum ................................................ 12 81 3.3. ipv4addr ............................................ 13 82 3.4. time ................................................ 13 83 3.5. text ................................................ 14 84 3.6. string .............................................. 15 85 3.7. concat .............................................. 16 86 3.8. ifid ................................................ 17 87 3.9. ipv6addr ............................................ 17 88 3.10. ipv6prefix ......................................... 18 89 3.11. ipv4prefix ......................................... 19 90 3.12. integer64 .......................................... 20 91 3.13. tlv ................................................ 21 92 3.14. vsa ................................................ 23 93 3.15. extended ........................................... 24 94 3.16. long-extended ...................................... 25 95 3.17. evs ................................................ 27 96 4. Updated Registries ....................................... 29 97 4.1. Create a Data Type Registry ......................... 29 98 4.2. Updates to the Attribute Type Registry .............. 30 99 5. Security Considerations .................................. 35 100 6. IANA Considerations ...................................... 35 101 7. References ............................................... 36 102 7.1. Normative References ................................ 36 103 7.2. Informative References .............................. 36 105 1. Introduction 107 RADIUS specifications have historically defined attributes in terms 108 of name, type value, and data type. Of these three pieces of 109 information, only the type value is managed by IANA. There is no 110 management of, or restriction on, the attribute name, as discussed in 111 [RFC6929] Section 2.7.1. There is no management of data type name or 112 definition. Experience has shown that there is a need for well 113 defined data types. 115 This document defines an IANA registry for data types, and updates 116 the RADIUS Attribute Type registry to use those newly defined data 117 types. It recommends how both specifications and implementations 118 should use the data types. It extends the RADIUS Attribute Type 119 registry to have a data type for each assigned attribute. 121 In this section, we review the use of data types in specifications 122 and implementations. Whe highlight ambiguities and inconsistencies. 123 The rest of this document is devoted to resolving those problems. 125 1.1. Specification Problems with Data Types 127 When attributes are defined in the specifications, the terms "Value" 128 and "String" are used to refer to the contents of an attribute. 129 However, these names are used recursively and inconsistently. We 130 suggest that defining a field to recursively contain itself is 131 problematic. 133 A number of data type names and definitions are given in [RFC2865] 134 Section 5, at the bottom of page 25. These data types are named and 135 clearly defined. However, this practice was not continued in later 136 specifications. 138 Specifically, [RFC2865] defines attributes of data type "address" to 139 carry IPv4 addresses. Despite this definition, [RFC3162] defines 140 attributes of data type "Address" to carry IPv6 addresses. We 141 suggest that the use of the word "address" to refer to disparate data 142 types is problematic. 144 Other failures are that [RFC3162] does not give a data type name and 145 definition for the data types IPv6 address, Interface-Id, or IPv6 146 prefix. [RFC2869] defines Event-Timestamp to carry a time, but does 147 not re-use the "time" data type defined in [RFC2865]. Instead, it 148 just repeats the "time" definition. [RFC6572] defines multiple 149 attributes which carry IPv4 prefixes. However, an "IPv4 prefix" data 150 type is not named, defined as a data type, or called out as an 151 addition to RADIUS. Further, [RFC6572] does not follow the 152 recommendations of [RFC6158], and does not explain why it fails to 153 follow those recommendations. 155 These ambiguities and inconsistencies need to be resolved. 157 1.2. Implementation Problems with Data Types 159 RADIUS implementations often use "dictionaries" to map attribute 160 names to type values, and to define data types for each attribute. 161 The data types in the dictionaries are defined by each 162 implementation, but correspond to the "ad hoc" data types used in the 163 specifications. 165 In effect, implementations have seen the need for well-defined data 166 types, and have created them. It is time for RADIUS specifications 167 to follow this practice. 169 1.3. No Mandated Changes 171 This document mandates no changes to any RADIUS implementation, past, 172 present, or future. It instead documents existing practice, in order 173 to simplify the process of writing RADIUS specifications, to clarify 174 the interpretation of RADIUS standards, and to improve the 175 communication between specification authors and IANA. 177 This document suggests that implementations SHOULD use the data types 178 defined here, in preference to any "ad hoc" data types currently in 179 use. This suggestion should have minimal effect on implementations, 180 as most "ad hoc" data types are compatible with the ones defined 181 here. Any difference will typically be limited to the name of the 182 data type. 184 1.4. Requirements Language 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 2. Use of Data Types 192 The Data Types can be used in two places: specifications, and 193 implementations. This section discusses both uses, and gives 194 guidance on using the data types. 196 2.1. Specification Use of Data Types 198 In this section, we give recommendations for how specifications 199 should be written using data types. We first describe how attribute 200 field names can be consistently named. We then describe how 201 attribute definitions should use the data types, and deprecate the 202 use of "Ascii art" for attribute definitions. We suggest a format 203 for new attribute definitions. This format includes recommended 204 fields, and suggestions for how those fields should be described. 206 Finally, we make recommendations for how new data types should be 207 defined. 209 2.1.1. Field Names for Attribute Values 211 Previous specifications used inconsistent and conflicting names for 212 the contents of RADIUS attributes. For example, the term "Value" is 213 used in [RFC2865] Section 5 to define a field which carries the 214 contents of attribute. It is then used in later sections as the sub- 215 field of attribute contents. The result is that the field is defined 216 as recursively containing itself. Similarly, "String" is used both 217 as a data type, and as a sub-field of other data types. 219 We correct this ambiguity by using context-specific names for various 220 fields of attributes and data types. It then becomes clear that, for 221 example, that a field called "VSA-Data" must contain different data 222 than a field called "EVS-Data". Each new name is defined where it is 223 used. 225 We also define the following term: 227 Attr-Data 229 The "Value" field of an Attribute as defined in [RFC2865] 230 Section 5. The contents of this field MUST be a valid data 231 type as defined in the RADIUS Data Type registry. 233 We consistently use "Attr-Data" to refer to the contents of an 234 attribute, instead of the more ambiguous name "Value". It is 235 RECOMMENDED that new specifications follow this practice. 237 In this document, we use the term "Value" to refer to the contents of 238 a data type, where that data type cannot carry other data types. In 239 other cases, we refer to the contents of a data type with a type- 240 specific name, in order to distinguish it from data of other types. 241 For example, the data type "vsa" will contain a data field called 242 "VSA-Data". 244 These terms are used in preference to the term "String", which was 245 used in multiple incompatible ways. It is RECOMMENDED that future 246 specifications use type-specific names, and the same naming scheme 247 for new types. This use will maintain consistent definitions, and 248 avoid ambiguities. 250 2.1.2. Attribute Definitions using Data Types 252 New RADIUS specifications MUST define attributes using data types 253 from the RADIUS Data Type registry. The specification may, of 254 course, define a new data type and use it in the same document. The 255 guidelines given in [RFC6929] MUST be followed when defining a new 256 data type. 258 Attributes can usually be completely described via the Attribute Type 259 code, name, and data type. The use of "ASCII art" is then limited 260 only to the definition of new data types, and for complex data types. 262 Use of the new extended attributes [RFC6929] makes ASCII art even 263 more problematic. An attribute can be allocated from the standard 264 space, or from one of the extended spaces. This allocation decision 265 is made after the specification has been accepted for publication. 266 That allocation strongly affects the format of the attribute header, 267 making it nearly impossible to create the correct ASCII art prior to 268 final publication. Allocation from the different spaces also changes 269 the value of the Length field, also making it difficult to define it 270 correctly prior to final publication of the document. 272 It is therefore RECOMMENDED that "ASCII art" diagrams not be used for 273 new RADIUS attribute specifications. 275 2.1.3. Format of Attribute Definitions 277 When defining a new attribute, the following fields SHOULD be given: 279 Description 281 A description of the meaning and interpretation of the 282 attribute. 284 Type 285 The Attribute Type code, given in the "dotted number" notation 286 from [RFC6929]. Specifications can often leave this as "TBD", 287 and request that IANA fill in the allocated values. 289 Length 291 A description of the length of the attribute. For attributes 292 of variable length, a maximum length SHOULD be given. Since 293 the Length may depend on the Type, the definition of Length may 294 be affected by IANA allocations. 296 Data Type 298 One of the named data types from the RADIUS Data Type registry. 300 Value 302 A description of any attribute-specific limitations on the 303 values carried by the specified data type. If there are no 304 attribute-specific limitations, then the description of this 305 field can be omitted, so long as the Description field is 306 sufficiently explanatory. 308 Where the values are limited to a subset of the possible range, 309 valid range(s) MUST be defined. 311 For attributes of data type "enum", a list of enumerated values 312 and names MUST be given, as with [RFC2865] Section 5.6. 314 Using a consistent format for attribute definitions helps to make the 315 definitions clearer. 317 2.1.4. Defining a New Data Type 319 When a specification needs to define a new data type, it should 320 follow the format used by the definitions in Section 3 of this 321 document. The text at the start of the data type definition MUST 322 describe the data type, including the expected use, and why a new 323 data type is required. That text SHOULD include limits on expected 324 values, and why those limits exist. The fields "Name", "Value", 325 "Length", and "Format", MUST be given, along with values. 327 The "Name" field SHOULD be a single name, all lower-case. 328 Contractions such as "ipv4addr" are RECOMMENDED where they add 329 clarity. 331 We note that the use of "Value" in the RADIUS Data Type registry can 332 be confusing. That name is also used in attribute definitions, but 333 with a different meaning. We trust that the meaning here is clear 334 from the context. 336 The "Value" field should be given as to be determined or "TBD" in 337 specifications. That number is assigned by IANA. 339 The "Format" field SHOULD be defined with "Ascii art" in order to 340 have a precise definition. Machine-readable formats are also 341 RECOMMENDED. 343 The definition of a new data type should be done only when absolutely 344 necessary. We do not expect a need for a large number of new data 345 types. When defining a new data type, the guideliness of [RFC6929] 346 with respect to data types MUST be followed. 348 It is RECOMMENDED that vendors not define "vendor specific" data 349 types. As discussed in [RFC6929], those data types are rarely 350 necessary, and can cause interoperability problems. 352 Any new data type MUST have unique name in the RADIUS Data Type 353 registry. The number of the data type will be assigned by IANA. 355 2.2. Implementation Use of Data Types 357 Implementations not supporting a particular data type MUST treat 358 attributes of that data type as being of data type "string", as 359 defined in Section 2.6. It is RECOMMENDED that such attributes be 360 treated as "invalid attributes", as defined in [RFC6929] Section 2.8. 362 Where the contents of a data type do not match the definition, 363 implementations MUST treat the the enclosing attribute as being an 364 "invalid attribute". This requirement includes, but is not limited 365 to, the following situations: 367 * Attributes with values outside of the allowed range(s) for the 368 data type, e.g. as given in the data types "integer", "ipv4addr", 369 "ipv6addr", "ipv4prefix", "ipv6prefix", or "enum". 371 * "text" attributes where the contents do not match the required 372 format, 374 * Attributes where the length is shorter or longer than the allowed 375 length(s) for the given data type, 377 The requirements for "reserved" fields are more difficult to 378 quantify. Implementations SHOULD be able to receive and process 379 attributes where "reserved" fields are non-zero. We do not, however, 380 define any "correct" processing of such attributes. Instead, 381 specifications which define new meaning for "reserved" fields SHOULD 382 describe how older implementations process those fields. We expect 383 that such descriptions are derived from practice. Implementations 384 MUST set "reserved" fields to zero when creating attributes. 386 3. Data Type Definitions 388 This section defines the new data types. For each data type, it 389 gives a definition, a name, a number, a length, and an encoding 390 format. Where relevant, it describes subfields contained within the 391 data type. These definitions have no impact on existing RADIUS 392 implementations. There is no requirement that implementations use 393 these names. 395 Where possible, the name of each data type has been taken from 396 previous specifications. In some cases, a different name has been 397 chosen. The change of name is sometimes required to avoid ambiguity 398 (i.e. "address" versus "Address"). Otherwise, the new name has been 399 chosen to be compatible with [RFC2865], or with use in common 400 implementations. In some cases, new names are chosen to clarify the 401 interpretation of the data type. 403 The numbers assigned herein for the data types have no meaning other 404 than to permit them to be tracked by IANA. As RADIUS does not encode 405 information about data types in a packet, the numbers assigned to a 406 data type will never occur in a packet. It is RECOMMENDED that new 407 implementations use the names defined in this document, in order to 408 avoid confusion. Existing implementations may choose to use the 409 names defined here, but that is not required. 411 The encoding of each data type is taken from previous specifications. 412 The fields are transmitted from left to right. 414 Where the data types have inter-dependencies, the simplest data type 415 is given first, and dependent ones are given later. 417 We do not create specific data types for the "tagged" attributes 418 defines in [RFC2868]. That specification defines the "tagged" 419 attributes as being backwards compatible with pre-existing data 420 types. In addition, [RFC6158] Section 2.1 says that "tagged" 421 attributes should not be used. There is therefore no benefit to 422 defining additional data types for these attributes. We trust that 423 implementors will be aware that tagged attributes must be treated 424 differently from non-tagged attributes of the same data type. 426 Similarly, we do not create data types for some attributes having 427 complex structure, such as CHAP-Password, ARAP-Features, or Location- 428 Capable. We need to strike a balance between correcting earlier 429 mistakes, and making this document more complex. In some cases, it 430 is better to treat complex attributes as being of type "string", even 431 though they need to be interpreted by RADIUS implementations. The 432 guidelines given in Section 6.3 of [RFC6969] were used to make this 433 determination. 435 3.1. integer 437 The "integer" data type encodes a 32-bit unsigned integer in network 438 byte order. Where the range of values for a particular attribute is 439 limited to a sub-set of the values, specifications MUST define the 440 valid range. Attributes with Values outside of the allowed ranges 441 SHOULD be treated as "invalid attributes". 443 Name 445 integer 447 Value 449 1 451 Length 453 Four octets 455 Format 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Value | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 3.2. enum 465 The "enum" data type encodes a 32-bit unsigned integer in network 466 byte order. It differs from the "integer" data type only in that it 467 is used to define enumerated types, such as Service-Type (Section 5.6 468 of [RFC 2865]). Specifications MUST define a valid set of enumerated 469 values, along with a unique name for each value. Attributes with 470 Values outside of the allowed enumerations SHOULD be treated as 471 "invalid attributes". 473 Name 475 enum 477 Value 479 2 481 Length 482 Four octets 484 Format 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Value | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 3.3. ipv4addr 494 The "ipv4addr" data type encodes an IPv4 address in network byte 495 order. Where the range of address for a particular attribute is 496 limited to a sub-set of possible addresses, specifications MUST 497 define the valid range(s). Attributes with Addresses outside of the 498 allowed range(s) SHOULD be treated as "invalid attributes". 500 Name 502 ipv4addr 504 Value 506 3 508 Length 510 Four octets 512 Format 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Address | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 3.4. time 522 The "time" data type encodes time as a 32-bit unsigned value in 523 network byte order and in seconds since 00:00:00 UTC, January 1, 524 1970. We note that dates before the year 2015 are likely to be 525 erroneous. 527 Note that the "time" attribute is defined to be unsigned, which means 528 it is not subject to a signed integer overflow in the year 2038. 530 Name 532 time 534 Value 536 4 538 Length 540 Four octets 542 Format 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Time | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 3.5. text 552 The "text" data type encodes UTF-8 text [RFC3629]. The maximum 553 length of the text is given by the encapsulating attribute. Where 554 the range of lengths for a particular attribute is limited to a sub- 555 set of possible lengths, specifications MUST define the valid 556 range(s). Attributes with length outside of the allowed values 557 SHOULD be treated as "invalid attributes". 559 Where the text is intended to carry data in a particular format, 560 (e.g. Framed-Route), the format MUST be given. The specification 561 SHOULD describe the format in a machine-readable way, such as via 562 Augmented Backus-Naur Form (ABNF). Attributes with values not 563 matching the defined format SHOULD be treated as "invalid 564 attributes". 566 Note that the "text" data type does not terminate with a NUL octet 567 (hex 00). The Attribute has a Length field and does not use a 568 terminator. Texts of length zero (0) MUST NOT be sent; omit the 569 entire attribute instead. 571 Name 573 text 575 Value 577 5 579 Length 581 One or more octets. 583 Format 585 0 586 0 1 2 3 4 5 6 7 587 +-+-+-+-+-+-+-+- 588 | Value ... 589 +-+-+-+-+-+-+-+- 591 3.6. string 593 The "string" data type encodes binary data, as a sequence of 594 undistinguished octets. Where the range of lengths for a particular 595 attribute is limited to a sub-set of possible lengths, specifications 596 MUST define the valid range(s). Attributes with length outside of 597 the allowed values SHOULD be treated as "invalid attributes". 599 Note that the "string" data type does not terminate with a NUL octet 600 (hex 00). The Attribute has a Length field and does not use a 601 terminator. Strings of length zero (0) MUST NOT be sent; omit the 602 entire attribute instead. 604 Where there is a need to encapsulate complex data structures, and 605 TLVs cannot be used, the "string" data type MUST be used. This 606 requirement include encapsulation of data structures defined outside 607 of RADIUS, which are opaque to the RADIUS infrastucture. It also 608 includes encapsulation of some data structures which are not opaque 609 to RADIUS, such as the contents of CHAP-Password. 611 There is little reason to define a new RADIUS data type for only one 612 attribute. However, where the complex data type cannot be 613 represented as TLVs, and is expected to be used in many attributes, a 614 new data type SHOULD be defined. 616 These requirements are stronger than [RFC6158], which makes the above 617 encapsulation a "SHOULD". This document defines data types for use 618 in RADIUS, so there are few reasons to avoid using them. 620 Name 621 string 623 Value 625 6 627 Length 629 One or more octets. 631 Format 633 0 634 0 1 2 3 4 5 6 7 635 +-+-+-+-+-+-+-+- 636 | Octets ... 637 +-+-+-+-+-+-+-+- 639 3.7. concat 641 The "concat" data type permits the transport of more than 253 octets 642 of data in a "standard space" [RFC6929] attribute. It is otherwise 643 identical to the "string" data type. 645 If multiple attributes of this data type are contained in a packet, 646 all attributes of the same type code MUST be in order and they MUST 647 be consecutive attributes in the packet. 649 The amount of data transported in a "concat" data type can be no more 650 than the RADIUS packet size. In practice, the requirement to 651 transport multiple attributes means that the limit may be 652 substantially smaller than one RADIUS packet. As a rough guide, is 653 RECOMMENDED that this data type transport no more than 2048 octets of 654 data. 656 The "concat" data type MAY be used for "standard space" attributes. 657 It MUST NOT be used for attributes in the "short extended space" or 658 the "long extended space". It MUST NOT be used in any field or 659 subfields of the following data types: "tlv", "vsa", "extended", 660 "long-extended", or "evs". 662 Name 664 concat 666 Value 667 7 669 Length 671 One or more octets. 673 Format 675 0 676 0 1 2 3 4 5 6 7 677 +-+-+-+-+-+-+-+- 678 | Octets ... 679 +-+-+-+-+-+-+-+- 681 3.8. ifid 683 The "ifid" data type encodes an Interface-Id as an 8-octet string in 684 network byte order. 686 Name 688 ifid 690 Value 692 8 694 Length 696 Eight octets 698 Format 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Interface-ID ... 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 ... Interface-ID | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 3.9. ipv6addr 710 The "ipv6addr" data type encodes an IPv6 address in network byte 711 order. Where the range of address for a particular attribute is 712 limited to a sub-set of possible addresses, specifications MUST 713 define the valid range(s). Attributes with Addresses outside of the 714 allowed range(s) SHOULD be treated as "invalid attributes". 716 Name 718 ipv6addr 720 Value 722 9 724 Length 726 Sixteen octets 728 Format 730 0 1 2 3 731 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 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Address ... 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 ... Address ... 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 ... Address ... 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 ... Address | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 3.10. ipv6prefix 744 The "ipv6prefix" data type encodes an IPv6 prefix, using both a 745 prefix length and an IPv6 address in network byte order. Where the 746 range of prefixes for a particular attribute is limited to a sub-set 747 of possible prefixes, specifications MUST define the valid range(s). 748 Attributes with Addresses outside of the allowed range(s) SHOULD be 749 treated as "invalid attributes". 751 Attributes with a Prefix-Length field having value greater than 128 752 SHOULD be treated as "invalid attributes". 754 Name 756 ipv6prefix 758 Value 759 10 761 Length 763 At least two, and no more than eighteen octets. 765 Format 767 0 1 2 3 768 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 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Reserved | Prefix-Length | Prefix ... 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 ... Prefix ... 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 ... Prefix ... 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 ... Prefix | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 Subfields 781 Reserved 783 This field, which is reserved and MUST be present, is always 784 set to zero. 786 Prefix-Length 788 The length of the prefix, in bits. At least 0 and no larger 789 than 128. 791 Prefix 793 The Prefix field is up to 16 octets in length. Bits outside of 794 the Prefix-Length, if included, MUST be zero. 796 3.11. ipv4prefix 798 The "ipv4prefix" data type encodes an IPv4 prefix, using both a 799 prefix length and an IPv4 address in network byte order. Where the 800 range of prefixes for a particular attribute is limited to a sub-set 801 of possible prefixes, specifications MUST define the valid range(s). 802 Attributes with Addresses outside of the allowed range(s) SHOULD be 803 treated as "invalid attributes". 805 Attributes with a Prefix-Length field having value greater than 32 806 SHOULD be treated as "invalid attributes". 808 Name 810 ipv4prefix 812 Value 814 11 816 Length 818 At least two, and no more than eighteen octets. 820 Format 822 0 1 2 3 823 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 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Reserved | Prefix-Len| Prefix ... 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 ... Prefix | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 Subfields 832 Reserved 834 This field, which is reserved and MUST be present, is always 835 set to zero. 837 Prefix-Length 839 A 6-bit unsigned integer containing the length of the prefix, 840 in bits. The values MUST be no larger than 32. 842 Prefix 844 The Prefix field is 4 octets in length. Bits outside of the 845 Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type, 846 this field is fixed length. If the address is all zeros (i.e. 847 "0.0.0.0", then the Prefix-Length MUST be set to 32. 849 3.12. integer64 851 The "integer64" data type encodes a 64-bit unsigned integer in 852 network byte order. Where the range of values for a particular 853 attribute is limited to a sub-set of the values, specifications MUST 854 define the valid range(s). Attributes with Values outside of the 855 allowed range(s) SHOULD be treated as "invalid attributes". 857 Name 859 integer64 861 Value 863 12 865 Length 867 Eight octets 869 Format 871 0 1 2 3 872 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 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Value ... 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 ... Value | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 3.13. tlv 881 The "tlv" data type encodes a type-length-value, as defined in 882 [RFC6929] Section 2.3. 884 Name 886 tlv 888 Value 890 13 892 Length 894 Three or more octets 896 Format 898 0 1 2 3 899 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 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | TLV-Type | TLV-Length | TLV-Data ... 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 Subfields 907 TLV-Type 909 This field is one octet. Up-to-date values of this field are 910 specified according to the policies and rules described in 911 [RFC6929] Section 10. Values of 254-255 are "Reserved" for use 912 by future extensions to RADIUS. The value 26 has no special 913 meaning, and MUST NOT be treated as a Vendor Specific 914 attribute. 916 The TLV-Type is meaningful only within the context defined by 917 "Type" fields of the encapsulating Attributes, using the 918 dotted-number notation introduced in [RFC6929]. 920 A RADIUS server MAY ignore Attributes with an unknown "TLV- 921 Type". 923 A RADIUS client MAY ignore Attributes with an unknown "TLV- 924 Type". 926 A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- 927 Type" verbatim. 929 TLV-Length 931 The TLV-Length field is one octet, and indicates the length of 932 this TLV including the TLV-Type, TLV-Length and TLV-Value 933 fields. It MUST have a value between 3 and 255. If a client 934 or server receives a TLV with an invalid TLV-Length, then the 935 attribute which encapsulates that TLV MUST be considered to be 936 an "invalid attribute", and handled as per [RFC6929] Section 937 2.8. 939 TLVs having TLV-Length of zero (0) MUST NOT be sent; omit the 940 entire TLV instead. 942 TLV-Data 944 The TLV-Data field is one or more octets and contains 945 information specific to the Attribute. The format and length 946 of the TLV-Data field is determined by the TLV-Type and TLV- 947 Length fields. 949 The TLV-Data field MUST contain only known RADIUS data types. 950 The TLV-Data field MUST NOT contain any of the following data 951 types: "concat", "vsa", "extended", "long-extended", or "evs". 953 3.14. vsa 955 The "vsa" data type encodes Vendor-Specific data, as given in 956 [RFC2865] Section 5.26. It is used only in the Attr-Data field of a 957 Vendor-Specific Attribute. It MUST NOT appear in the contents of any 958 other data type. 960 Where an implementation determines that an attribute of data type 961 "vsa" contains data which does not match the expected format, it 962 SHOULD treat that attribute as being an "invalid attribute". 964 Name 966 vsa 968 Value 970 14 972 Length 974 Five or more octets 976 Format 978 0 1 2 3 979 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 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Vendor-Id | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | VSA-Data .... 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 Subfields 988 Vendor-Id 990 The 4 octets are the Network Management Private Enterprise Code 991 [PEN] of the Vendor in network byte order. 993 VSA-Data 995 The VSA-Data field is one or more octets. The actual format of 996 the information is site or application specific, and a robust 997 implementation SHOULD support the field as undistinguished 998 octets. 1000 The codification of the range of allowed usage of this field is 1001 outside the scope of this specification. 1003 The "vsa" data type SHOULD contain as a sequence of "tlv" data 1004 types. The interpretation of the TLV-Type and TLV-Data fields 1005 are dependent on the vendor's definition of that attribute. 1007 The "vsa" data type MUST be used as contents of the Attr-Data 1008 field of the Vendor-Specific attribute. The "vsa" data type 1009 MUST NOT appear in the contents of any other data type. 1011 3.15. extended 1013 The "extended" data type encodes the "Extended Type" format, as given 1014 in [RFC6929] Section 2.1. It is used only in the Attr-Data field of 1015 an Attribute allocated from the "standard space". It MUST NOT appear 1016 in the contents of any other data type. 1018 Name 1020 extended 1022 Value 1024 15 1026 Length 1028 Two or more octets 1030 Format 1032 0 1 2 3 1033 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 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Extended-Type | Ext-Data ... 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 Subfields 1040 Extended-Type 1042 The Extended-Type field is one octet. Up-to-date values of 1043 this field are specified according to the policies and rules 1044 described in [RFC6929] Section 10. Unlike the Type field 1045 defined in [RFC2865] Section 5, no values are allocated for 1046 experimental or implementation-specific use. Values 241-255 1047 are reserved and MUST NOT be used. 1049 The Extended-Type is meaningful only within a context defined 1050 by the Type field. That is, this field may be thought of as 1051 defining a new type space of the form "Type.Extended-Type". 1052 See [RFC6929] Section 2.5 for additional discussion. 1054 A RADIUS server MAY ignore Attributes with an unknown 1055 "Type.Extended-Type". 1057 A RADIUS client MAY ignore Attributes with an unknown 1058 "Type.Extended-Type". 1060 Ext-Data 1062 The contents of this field MUST be a valid data type as defined 1063 in the RADIUS Data Type registry. The Ext-Data field MUST NOT 1064 contain any of the following data types: "concat", "vsa", 1065 "extended", "long-extended", or "evs". 1067 The Ext-Data field is one or more octets. 1069 Implementations supporting this specification MUST use the 1070 Identifier of "Type.Extended-Type" to determine the 1071 interpretation of the Ext-Data field. 1073 3.16. long-extended 1075 The "long-extended" data type encodes the "Long Extended Type" 1076 format, as given in [RFC6929] Section 2.2. It is used only in the 1077 Attr-Data field of an Attribute. It MUST NOT appear in the contents 1078 of any other data type. 1080 Name 1082 long-extended 1084 Value 1086 16 1088 Length 1089 Three or more octets 1091 Format 1093 0 1 2 3 1094 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 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | Extended-Type |M| Reserved | Ext-Data ... 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 Subfields 1101 Extended-Type 1103 This field is identical to the Extended-Type field defined 1104 above in Section 2.13. 1106 M (More) 1108 The More field is one (1) bit in length, and indicates whether 1109 or not the current attribute contains "more" than 251 octets of 1110 data. The More field MUST be clear (0) if the Length field has 1111 value less than 255. The More field MAY be set (1) if the 1112 Length field has value of 255. 1114 If the More field is set (1), it indicates that the Ext-Data 1115 field has been fragmented across multiple RADIUS attributes. 1116 When the More field is set (1), the attribute MUST have a 1117 Length field of value 255; there MUST be an attribute following 1118 this one; and the next attribute MUST have both the same Type 1119 and Extended Type. That is, multiple fragments of the same 1120 value MUST be in order and MUST be consecutive attributes in 1121 the packet, and the last attribute in a packet MUST NOT have 1122 the More field set (1). 1124 That is, a packet containing a fragmented attribute needs to 1125 contain all fragments of the attribute, and those fragments 1126 need to be contiguous in the packet. RADIUS does not support 1127 inter-packet fragmentation, which means that fragmenting an 1128 attribute across multiple packets is impossible. 1130 If a client or server receives an attribute fragment with the 1131 "More" field set (1), but for which no subsequent fragment can 1132 be found, then the fragmented attribute is considered to be an 1133 "invalid attribute", and handled as per [RFC6929] Section 2.8. 1135 Reserved 1136 This field is 7 bits long, and is reserved for future use. 1137 Implementations MUST set it to zero (0) when encoding an 1138 attribute for sending in a packet. The contents SHOULD be 1139 ignored on reception. 1141 Future specifications may define additional meaning for this 1142 field. Implementations therefore MUST NOT treat this field as 1143 invalid if it is non-zero. 1145 Ext-Data 1147 The contents of this field MUST be a valid data type as defined 1148 in the RADIUS Data Type registry. The Ext-Data field MUST NOT 1149 contain any of the following data types: "concat", "vsa", 1150 "extended", "long-extended", or "evs". 1152 The Ext-Data field is one or more octets. 1154 Implementations supporting this specification MUST use the 1155 Identifier of "Type.Extended-Type" to determine the 1156 interpretation of the Ext-Data field. 1158 The length of the data MUST be taken as the sum of the lengths 1159 of the fragments (i.e. Ext-Data fields) from which it is 1160 constructed. Any interpretation of the resulting data MUST 1161 occur after the fragments have been reassembled. If the 1162 reassembled data does not match the expected format, each 1163 fragment MUST be treated as an "invalid attribute", and the 1164 reassembled data MUST be discarded. 1166 We note that the maximum size of a fragmented attribute is 1167 limited only by the RADIUS packet length limitation. 1168 Implementations MUST be able to handle the case where one 1169 fragmented attribute completely fills the packet. 1171 3.17. evs 1173 The "evs" data type encodes an "Extended Vendor-Specific" attribute, 1174 as given in [RFC6929] Section 2.4. The "evs" data type is used 1175 solely to extend the Vendor Specific space. It MAY appear inside of 1176 an "extended" or a "long-extended" data type. It MUST NOT appear in 1177 the contents of any other data type. 1179 Where an implementation determines that an attribute of data type 1180 "evs" contains data which does not match the expected format, it 1181 SHOULD treat that attribute as being an "invalid attribute". 1183 Name 1185 evs 1187 Value 1189 17 1191 Length 1193 Six or more octets 1195 Format 1197 0 1 2 3 1198 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 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | Vendor-Id | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Vendor-Type | EVS-Data .... 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 Subfields 1207 Vendor-Id 1209 The 4 octets are the Network Management Private Enterprise Code 1210 [PEN] of the Vendor in network byte order. 1212 Vendor-Type 1214 The Vendor-Type field is one octet. Values are assigned at the 1215 sole discretion of the Vendor. 1217 EVS-Data 1219 The EVS-Data field is one or more octets. It SHOULD 1220 encapsulate a previously defined RADIUS data type. Non- 1221 standard data types SHOULD NOT be used. We note that the EVS- 1222 Data field may be of data type "tlv". 1224 The actual format of the information is site or application 1225 specific, and a robust implementation SHOULD support the field 1226 as undistinguished octets. We recognise that Vendors have 1227 complete control over the contents and format of the Ext-Data 1228 field, while at the same time recommending that good practices 1229 be followed. 1231 Further codification of the range of allowed usage of this 1232 field is outside the scope of this specification. 1234 4. Updated Registries 1236 This section defines a new IANA registry for RADIUS data types, and 1237 updates the existing RADIUS Attribute Type registry. 1239 4.1. Create a Data Type Registry 1241 This section defines a new RADIUS registry, called "Data Type". 1242 Allocation in this registry requires IETF Review. The "Registration 1243 Procedures" for this registry are "Standards Action". 1245 The registry contains three columns of data, as follows. 1247 Value 1249 The number of the data type. The value field is an artifact of 1250 the registry, and has no on-the-wire meaning. 1252 Description 1254 The name of the data type. The name field is used only for the 1255 registry, and has no on-the-wire meaning. 1257 Reference 1259 The specification where the data type was defined. 1261 The initial contents of the registry are as follows. 1263 Value Description Reference 1264 ----- ----------- ---------------- 1265 1 integer [RFC2865], TBD 1266 2 enum [RFC2865], TBD 1267 3 ipv4addr [RFC2865], TBD 1268 4 time [RFC2865], TBD 1269 5 text [RFC2865], TBD 1270 6 string [RFC2865], TBD 1271 7 concat TBD 1272 8 ifid [RFC3162], TBD 1273 9 ipv6addr [RFC3162], TBD 1274 10 ipv6prefix [RFC3162], TBD 1275 11 ipv4prefix [RFC6572], TBD 1276 12 integer64 [RFC6929], TBD 1277 13 tlv [RFC6929], TBD 1278 14 evs [RFC6929], TBD 1279 15 extended [RFC6929], TBD 1280 16 long-extended [RFC6929], TBD 1282 4.2. Updates to the Attribute Type Registry 1284 This section updates the RADIUS Attribute Type Registry to have a new 1285 column, which is inserted in between the existing "Description" and 1286 "Reference" columns. The new column is named "Data Type". The 1287 contents of that column are the name of a data type, corresponding to 1288 the attribute in that row, or blank if the attribute type is 1289 unassigned. The name of the data type is taken from the RADIUS Data 1290 Type registry, defined above. 1292 The updated registry follows in CSV format. 1294 Value,Description,Data Type,Reference 1295 1,User-Name,text,[RFC2865] 1296 2,User-Password,string,[RFC2865] 1297 3,CHAP-Password,string,[RFC2865] 1298 4,NAS-IP-Address,ipv4addr,[RFC2865] 1299 5,NAS-Port,integer,[RFC2865] 1300 6,Service-Type,enum,[RFC2865] 1301 7,Framed-Protocol,enum,[RFC2865] 1302 8,Framed-IP-Address,ipv4addr,[RFC2865] 1303 9,Framed-IP-Netmask,ipv4addr,[RFC2865] 1304 10,Framed-Routing,enum,[RFC2865] 1305 11,Filter-Id,text,[RFC2865] 1306 12,Framed-MTU,integer,[RFC2865] 1307 13,Framed-Compression,enum,[RFC2865] 1308 14,Login-IP-Host,ipv4addr,[RFC2865] 1309 15,Login-Service,enum,[RFC2865] 1310 16,Login-TCP-Port,integer,[RFC2865] 1311 17,Unassigned,, 1312 18,Reply-Message,text,[RFC2865] 1313 19,Callback-Number,text,[RFC2865] 1314 20,Callback-Id,text,[RFC2865] 1315 21,Unassigned,, 1316 22,Framed-Route,text,[RFC2865] 1317 23,Framed-IPX-Network,ipv4addr,[RFC2865] 1318 24,State,string,[RFC2865] 1319 25,Class,string,[RFC2865] 1320 26,Vendor-Specific,vsa,[RFC2865] 1321 27,Session-Timeout,integer,[RFC2865] 1322 28,Idle-Timeout,integer,[RFC2865] 1323 29,Termination-Action,enum,[RFC2865] 1324 30,Called-Station-Id,text,[RFC2865] 1325 31,Calling-Station-Id,text,[RFC2865] 1326 32,NAS-Identifier,text,[RFC2865] 1327 33,Proxy-State,string,[RFC2865] 1328 34,Login-LAT-Service,text,[RFC2865] 1329 35,Login-LAT-Node,text,[RFC2865] 1330 36,Login-LAT-Group,string,[RFC2865] 1331 37,Framed-AppleTalk-Link,integer,[RFC2865] 1332 38,Framed-AppleTalk-Network,integer,[RFC2865] 1333 39,Framed-AppleTalk-Zone,text,[RFC2865] 1334 40,Acct-Status-Type,enum,[RFC2866] 1335 41,Acct-Delay-Time,integer,[RFC2866] 1336 42,Acct-Input-Octets,integer,[RFC2866] 1337 43,Acct-Output-Octets,integer,[RFC2866] 1338 44,Acct-Session-Id,text,[RFC2866] 1339 45,Acct-Authentic,enum,[RFC2866] 1340 46,Acct-Session-Time,integer,[RFC2866] 1341 47,Acct-Input-Packets,integer,[RFC2866] 1342 48,Acct-Output-Packets,integer,[RFC2866] 1343 49,Acct-Terminate-Cause,enum,[RFC2866] 1344 50,Acct-Multi-Session-Id,text,[RFC2866] 1345 51,Acct-Link-Count,integer,[RFC2866] 1346 52,Acct-Input-Gigawords,integer,[RFC2869] 1347 53,Acct-Output-Gigawords,integer,[RFC2869] 1348 54,Unassigned,, 1349 55,Event-Timestamp,time,[RFC2869] 1350 56,Egress-VLANID,integer,[RFC4675] 1351 57,Ingress-Filters,enum,[RFC4675] 1352 58,Egress-VLAN-Name,text,[RFC4675] 1353 59,User-Priority-Table,string,[RFC4675] 1354 60,CHAP-Challenge,string,[RFC2865] 1355 61,NAS-Port-Type,enum,[RFC2865] 1356 62,Port-Limit,integer,[RFC2865] 1357 63,Login-LAT-Port,text,[RFC2865] 1358 64,Tunnel-Type,enum,[RFC2868] 1359 65,Tunnel-Medium-Type,enum,[RFC2868] 1360 66,Tunnel-Client-Endpoint,text,[RFC2868] 1361 67,Tunnel-Server-Endpoint,text,[RFC2868] 1362 68,Acct-Tunnel-Connection,text,[RFC2867] 1363 69,Tunnel-Password,string,[RFC2868] 1364 70,ARAP-Password,string,[RFC2869] 1365 71,ARAP-Features,string,[RFC2869] 1366 72,ARAP-Zone-Access,enum,[RFC2869] 1367 73,ARAP-Security,integer,[RFC2869] 1368 74,ARAP-Security-Data,text,[RFC2869] 1369 75,Password-Retry,integer,[RFC2869] 1370 76,Prompt,enum,[RFC2869] 1371 77,Connect-Info,text,[RFC2869] 1372 78,Configuration-Token,text,[RFC2869] 1373 79,EAP-Message,concat,[RFC2869] 1374 80,Message-Authenticator,string,[RFC2869] 1375 81,Tunnel-Private-Group-ID,text,[RFC2868] 1376 82,Tunnel-Assignment-ID,text,[RFC2868] 1377 83,Tunnel-Preference,integer,[RFC2868] 1378 84,ARAP-Challenge-Response,string,[RFC2869] 1379 85,Acct-Interim-Interval,integer,[RFC2869] 1380 86,Acct-Tunnel-Packets-Lost,integer,[RFC2867] 1381 87,NAS-Port-Id,text,[RFC2869] 1382 88,Framed-Pool,text,[RFC2869] 1383 89,CUI,string,[RFC4372] 1384 90,Tunnel-Client-Auth-ID,text,[RFC2868] 1385 91,Tunnel-Server-Auth-ID,text,[RFC2868] 1386 92,NAS-Filter-Rule,text,[RFC4849] 1387 93,Unassigned,, 1388 94,Originating-Line-Info,string,[RFC7155] 1389 95,NAS-IPv6-Address,ipv6addr,[RFC3162] 1390 96,Framed-Interface-Id,ifid,[RFC3162] 1391 97,Framed-IPv6-Prefix,ipv6prefix,[RFC3162] 1392 98,Login-IPv6-Host,ipv6addr,[RFC3162] 1393 99,Framed-IPv6-Route,text,[RFC3162] 1394 100,Framed-IPv6-Pool,text,[RFC3162] 1395 101,Error-Cause Attribute,enum,[RFC3576] 1396 102,EAP-Key-Name,string,[RFC4072][RFC7268] 1397 103,Digest-Response,text,[RFC5090] 1398 104,Digest-Realm,text,[RFC5090] 1399 105,Digest-Nonce,text,[RFC5090] 1400 106,Digest-Response-Auth,text,[RFC5090] 1401 107,Digest-Nextnonce,text,[RFC5090] 1402 108,Digest-Method,text,[RFC5090] 1403 109,Digest-URI,text,[RFC5090] 1404 110,Digest-Qop,text,[RFC5090] 1405 111,Digest-Algorithm,text,[RFC5090] 1406 112,Digest-Entity-Body-Hash,text,[RFC5090] 1407 113,Digest-CNonce,text,[RFC5090] 1408 114,Digest-Nonce-Count,text,[RFC5090] 1409 115,Digest-Username,text,[RFC5090] 1410 116,Digest-Opaque,text,[RFC5090] 1411 117,Digest-Auth-Param,text,[RFC5090] 1412 118,Digest-AKA-Auts,text,[RFC5090] 1413 119,Digest-Domain,text,[RFC5090] 1414 120,Digest-Stale,text,[RFC5090] 1415 121,Digest-HA1,text,[RFC5090] 1416 122,SIP-AOR,text,[RFC5090] 1417 123,Delegated-IPv6-Prefix,ipv6prefix,[RFC4818] 1418 124,MIP6-Feature-Vector,string,[RFC5447] 1419 125,MIP6-Home-Link-Prefix,ipv6prefix,[RFC5447] 1420 126,Operator-Name,text,[RFC5580] 1421 127,Location-Information,string,[RFC5580] 1422 128,Location-Data,string,[RFC5580] 1423 129,Basic-Location-Policy-Rules,string,[RFC5580] 1424 130,Extended-Location-Policy-Rules,string,[RFC5580] 1425 131,Location-Capable,enum,[RFC5580] 1426 132,Requested-Location-Info,enum,[RFC5580] 1427 133,Framed-Management-Protocol,enum,[RFC5607] 1428 134,Management-Transport-Protection,enum,[RFC5607] 1429 135,Management-Policy-Id,text,[RFC5607] 1430 136,Management-Privilege-Level,integer,[RFC5607] 1431 137,PKM-SS-Cert,concat,[RFC5904] 1432 138,PKM-CA-Cert,concat,[RFC5904] 1433 139,PKM-Config-Settings,string,[RFC5904] 1434 140,PKM-Cryptosuite-List,string,[RFC5904] 1435 141,PKM-SAID,text,[RFC5904] 1436 142,PKM-SA-Descriptor,string,[RFC5904] 1437 143,PKM-Auth-Key,string,[RFC5904] 1438 144,DS-Lite-Tunnel-Name,text,[RFC6519] 1439 145,Mobile-Node-Identifier,string,[RFC6572] 1440 146,Service-Selection,text,[RFC6572] 1441 147,PMIP6-Home-LMA-IPv6-Address,ipv6addr,[RFC6572] 1442 148,PMIP6-Visited-LMA-IPv6-Address,ipv6addr,[RFC6572] 1443 149,PMIP6-Home-LMA-IPv4-Address,ipv4addr,[RFC6572] 1444 150,PMIP6-Visited-LMA-IPv4-Address,ipv4addr,[RFC6572] 1445 151,PMIP6-Home-HN-Prefix,ipv6prefix,[RFC6572] 1446 152,PMIP6-Visited-HN-Prefix,ipv6prefix,[RFC6572] 1447 153,PMIP6-Home-Interface-ID,ifid,[RFC6572] 1448 154,PMIP6-Visited-Interface-ID,ifid,[RFC6572] 1449 155,PMIP6-Home-IPv4-HoA,ipv4prefix,[RFC6572] 1450 156,PMIP6-Visited-IPv4-HoA,ipv4prefix,[RFC6572] 1451 157,PMIP6-Home-DHCP4-Server-Address,ipv4addr,[RFC6572] 1452 158,PMIP6-Visited-DHCP4-Server-Address,ipv4addr,[RFC6572] 1453 159,PMIP6-Home-DHCP6-Server-Address,ipv6addr,[RFC6572] 1454 160,PMIP6-Visited-DHCP6-Server-Address,ipv6addr,[RFC6572] 1455 161,PMIP6-Home-IPv4-Gateway,ipv4addr,[RFC6572] 1456 162,PMIP6-Visited-IPv4-Gateway,ipv4addr,[RFC6572] 1457 163,EAP-Lower-Layer,enum,[RFC6677] 1458 164,GSS-Acceptor-Service-Name,text,[RFC7055] 1459 165,GSS-Acceptor-Host-Name,text,[RFC7055] 1460 166,GSS-Acceptor-Service-Specifics,text,[RFC7055] 1461 167,GSS-Acceptor-Realm-Name,text,[RFC7055] 1462 168,Framed-IPv6-Address,ipv6addr,[RFC6911] 1463 169,DNS-Server-IPv6-Address,ipv6addr,[RFC6911] 1464 170,Route-IPv6-Information,ipv6prefix,[RFC6911] 1465 171,Delegated-IPv6-Prefix-Pool,text,[RFC6911] 1466 172,Stateful-IPv6-Address-Pool,text,[RFC6911] 1467 173,IPv6-6rd-Configuration,tlv,[RFC6930] 1468 174,Allowed-Called-Station-Id,text,[RFC7268] 1469 175,EAP-Peer-Id,string,[RFC7268] 1470 176,EAP-Server-Id,string,[RFC7268] 1471 177,Mobility-Domain-Id,integer,[RFC7268] 1472 178,Preauth-Timeout,integer,[RFC7268] 1473 179,Network-Id-Name,string,[RFC7268] 1474 180,EAPoL-Announcement,concat,[RFC7268] 1475 181,WLAN-HESSID,text,[RFC7268] 1476 182,WLAN-Venue-Info,integer,[RFC7268] 1477 183,WLAN-Venue-Language,string,[RFC7268] 1478 184,WLAN-Venue-Name,text,[RFC7268] 1479 185,WLAN-Reason-Code,integer,[RFC7268] 1480 186,WLAN-Pairwise-Cipher,integer,[RFC7268] 1481 187,WLAN-Group-Cipher,integer,[RFC7268] 1482 188,WLAN-AKM-Suite,integer,[RFC7268] 1483 189,WLAN-Group-Mgmt-Cipher,integer,[RFC7268] 1484 190,WLAN-RF-Band,integer,[RFC7268] 1485 191,Unassigned,, 1486 192-223,Experimental Use,,[RFC3575] 1487 224-240,Implementation Specific,,[RFC3575] 1488 241,Extended-Attribute-1,extended,[RFC6929] 1489 241.1,Frag-Status,integer,[RFC7499] 1490 241.2,Proxy-State-Length,integer,[RFC7499] 1491 241.{3-25},Unassigned,, 1492 241.26,Extended-Vendor-Specific-1,evs,[RFC6929] 1493 241.{27-240},Unassigned,, 1494 241.{241-255},Reserved,,[RFC6929] 1495 242,Extended-Attribute-2,extended,[RFC6929] 1496 242.{1-25},Unassigned,, 1497 242.26,Extended-Vendor-Specific-2,evs,[RFC6929] 1498 242.{27-240},Unassigned,, 1499 242.{241-255},Reserved,,[RFC6929] 1500 243,Extended-Attribute-3,extended,[RFC6929] 1501 243.{1-25},Unassigned,, 1502 243.26,Extended-Vendor-Specific-3,evs,[RFC6929] 1503 243.{27-240},Unassigned,, 1504 243.{241-255},Reserved,,[RFC6929] 1505 244,Extended-Attribute-4,extended,[RFC6929] 1506 244.{1-25},Unassigned,, 1507 244.26,Extended-Vendor-Specific-4,evs,[RFC6929] 1508 244.{27-240},Unassigned,, 1509 244.{241-255},Reserved,,[RFC6929] 1510 245,Extended-Attribute-5,long-extended,[RFC6929] 1511 245.{1-25},Unassigned,, 1512 245.26,Extended-Vendor-Specific-5,evs,[RFC6929] 1513 245.{27-240},Unassigned,, 1514 245.{241-255},Reserved,,[RFC6929] 1515 246,Extended-Attribute-6,long-extended,[RFC6929] 1516 246.{1-25},Unassigned,, 1517 246.26,Extended-Vendor-Specific-6,evs,[RFC6929] 1518 246.{27-240},Unassigned,, 1519 246.{241-255},Reserved,,[RFC6929] 1520 247-255,Reserved,,[RFC3575] 1522 5. Security Considerations 1524 This specification is concerned solely with updates to IANA 1525 registries. As such, there are no security considerations with the 1526 document itself. 1528 However, the use of inconsistent names and poorly-defined entities in 1529 a protocol is problematic. Inconsistencies in specifications can 1530 lead to security and interoperability problems in implementations. 1531 Further, having one canonical source for the definition of data types 1532 means an implementor has fewer specifications to read. The 1533 implementation work is therefore simpler, and is more likely to be 1534 correct. 1536 The goal of this specification is to reduce ambiguities in the RADIUS 1537 protocol, which we believe will lead to more robust and more secure 1538 implementations. 1540 6. IANA Considerations 1542 IANA is instructed to create one new registry as described above in 1543 Section 3.1. The "TBD" text in that section should be replaced with 1544 the RFC number of this document when it is published. 1546 IANA is instructed to update the RADIUS Attribute Type registry, as 1547 described above in Section 3.2. 1549 IANA is instructed to require that all allocation requests in the 1550 RADIUS Attribute Type Registry contain a "Data Type" field. That 1551 field is required to contain one of the "Data Type" names contained 1552 in the RADIUS Data Type registry. 1554 IANA is instructed to require that updates to the RADIUS Data Type 1555 registry contain the following fields, with the associated 1556 instructions: 1558 * Value. IANA is instructed to assign the next unused integer in 1559 sequence to new data type definitions. 1561 * Name. IANA is instructed to require that this name be unique 1562 in the registry. 1564 * Reference. IANA is instructed to update this field with a 1565 reference 1566 to the document which defines the data type. 1568 7. References 1570 7.1. Normative References 1572 [RFC2119] 1573 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1574 Levels", RFC 2119, March, 1997. 1576 [RFC2865] 1577 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1578 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1580 [RFC3162] 1581 Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, 1582 August 2001. 1584 [RFC3629] 1585 Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1586 3629, November 2003. 1588 [RFC4072] 1589 Eronen, P., et al, "Diameter Extensible Authentication Protocol 1590 (EAP) Application", RFC 4072, February 2013. 1592 [RFC6158] 1593 DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 6158, 1594 March 2011. 1596 [RFC6572] 1597 Xia, F., et al, "RADIUS Support for Proxy Mobile IPv6", RFC 6572, 1598 June 2012. 1600 7.2. Informative References 1602 [RFC2868] 1603 Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. 1604 Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 1605 June 2000. 1607 [RFC2869] 1608 Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000. 1610 [RFC6929] 1611 DeKok, A., and Lior, A., "Remote Authentication Dial In User 1612 Service (RADIUS) Protocol Extensions", RFC 6929, April 2013. 1614 [RFC7268] 1615 Aboba, B, et al, "RADIUS Attributes for IEEE 802 Networks", RFC 1616 7268, July 2015. 1618 [RFC7499] 1619 Perez-Mendez A., et al, "Support of Fragmentation of RADIUS 1620 Packets", RFC 7499, April 2015. 1622 [PEN] 1623 http://www.iana.org/assignments/enterprise-numbers 1625 Acknowledgments 1627 Stuff 1629 Authors' Addresses 1631 Alan DeKok 1632 The FreeRADIUS Server Project 1634 Email: aland@freeradius.org