idnits 2.17.1 draft-ietf-radext-datatypes-06.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 : ---------------------------------------------------------------------------- No issues found here. 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 (3 August 2016) is 2817 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) == Unused Reference: 'RFC7499' is defined on line 1642, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 3 August 2016 9 Data Types in the Remote Authentication 10 Dial-In User Service Protocol (RADIUS) 11 draft-ietf-radext-datatypes-06.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. 25 This document updates RFC 2865, 3162, 6158, and 6572. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on March 3, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info/) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction ............................................. 4 68 1.1. Specification Problems with Data Types .............. 4 69 1.2. Implementation Problems with Data Types ............. 5 70 1.3. No Mandated Changes ................................. 5 71 1.4. Requirements Language ............................... 5 72 2. Use of Data Types ........................................ 6 73 2.1. Specification Use of Data Types ..................... 6 74 2.1.1. Field Names for Attribute Values ............... 6 75 2.1.2. Attribute Definitions using Data Types ......... 7 76 2.1.3. Format of Attribute Definitions ................ 7 77 2.1.4. Defining a New Data Type ....................... 8 78 2.2. Implementation Use of Data Types .................... 9 79 3. Data Type Definitions .................................... 11 80 3.1. integer ............................................. 12 81 3.2. enum ................................................ 12 82 3.3. time ................................................ 13 83 3.4. text ................................................ 13 84 3.5. string .............................................. 14 85 3.6. concat .............................................. 15 86 3.7. ifid ................................................ 16 87 3.8. ipv4addr ............................................ 17 88 3.9. ipv6addr ............................................ 17 89 3.10. ipv6prefix ......................................... 18 90 3.11. ipv4prefix ......................................... 19 91 3.12. integer64 .......................................... 21 92 3.13. tlv ................................................ 21 93 3.14. vsa ................................................ 23 94 3.15. extended ........................................... 24 95 3.16. long-extended ...................................... 25 96 3.17. evs ................................................ 28 97 4. Updated Registries ....................................... 29 98 4.1. Create a Data Type Registry ......................... 29 99 4.2. Updates to the Attribute Type Registry .............. 30 100 5. Security Considerations .................................. 35 101 6. IANA Considerations ...................................... 35 102 7. References ............................................... 36 103 7.1. Normative References ................................ 36 104 7.2. Informative References .............................. 37 106 1. Introduction 108 RADIUS specifications have historically defined attributes in terms 109 of name, type value, and data type. Of these three pieces of 110 information, only the type value is managed by IANA. There is no 111 management of, or restriction on, the attribute name, as discussed in 112 [RFC6929] Section 2.7.1. There is no management of data type name or 113 definition. Experience has shown that there is a need for well 114 defined data types. 116 This document defines an IANA registry for data types, and updates 117 the RADIUS Attribute Type registry to use those newly defined data 118 types. It recommends how both specifications and implementations 119 should use the data types. It extends the RADIUS Attribute Type 120 registry to have a data type for each assigned attribute. 122 In this section, we review the use of data types in specifications 123 and implementations. Whe highlight ambiguities and inconsistencies. 124 The rest of this document is devoted to resolving those problems. 126 1.1. Specification Problems with Data Types 128 When attributes are defined in the specifications, the terms "Value" 129 and "String" are used to refer to the contents of an attribute. 130 However, these names are used recursively and inconsistently. We 131 suggest that defining a field to recursively contain itself is 132 problematic. 134 A number of data type names and definitions are given in [RFC2865] 135 Section 5, at the bottom of page 25. These data types are named and 136 clearly defined. However, this practice was not continued in later 137 specifications. 139 Specifically, [RFC2865] defines attributes of data type "address" to 140 carry IPv4 addresses. Despite this definition, [RFC3162] defines 141 attributes of data type "Address" to carry IPv6 addresses. We 142 suggest that the use of the word "address" to refer to disparate data 143 types is problematic. 145 Other failures are that [RFC3162] does not give a data type name and 146 definition for the data types IPv6 address, Interface-Id, or IPv6 147 prefix. [RFC2869] defines Event-Timestamp to carry a time, but does 148 not re-use the "time" data type defined in [RFC2865]. Instead, it 149 just repeats the "time" definition. [RFC6572] defines multiple 150 attributes which carry IPv4 prefixes. However, an "IPv4 prefix" data 151 type is not named, defined as a data type, or called out as an 152 addition to RADIUS. Further, [RFC6572] does not follow the 153 recommendations of [RFC6158], and does not explain why it fails to 154 follow those recommendations. 156 These ambiguities and inconsistencies need to be resolved. 158 1.2. Implementation Problems with Data Types 160 RADIUS implementations often use "dictionaries" to map attribute 161 names to type values, and to define data types for each attribute. 162 The data types in the dictionaries are defined by each 163 implementation, but correspond to the "ad hoc" data types used in the 164 specifications. 166 In effect, implementations have seen the need for well-defined data 167 types, and have created them. It is time for RADIUS specifications 168 to follow this practice. 170 1.3. No Mandated Changes 172 This document mandates no changes to any RADIUS implementation, past, 173 present, or future. It instead documents existing practice, in order 174 to simplify the process of writing RADIUS specifications, to clarify 175 the interpretation of RADIUS standards, and to improve the 176 communication between specification authors and IANA. 178 This document suggests that implementations SHOULD use the data types 179 defined here, in preference to any "ad hoc" data types currently in 180 use. This suggestion should have minimal effect on implementations, 181 as most "ad hoc" data types are compatible with the ones defined 182 here. Any difference will typically be limited to the name of the 183 data type. 185 1.4. Requirements Language 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in [RFC2119]. 191 2. Use of Data Types 193 The Data Types can be used in two places: specifications, and 194 implementations. This section discusses both uses, and gives 195 guidance on using the data types. 197 2.1. Specification Use of Data Types 199 In this section, we give recommendations for how specifications 200 should be written using data types. We first describe how attribute 201 field names can be consistently named. We then describe how 202 attribute definitions should use the data types, and deprecate the 203 use of "ASCII art" for attribute definitions. We suggest a format 204 for new attribute definitions. This format includes recommended 205 fields, and suggestions for how those fields should be described. 207 Finally, we make recommendations for how new data types should be 208 defined. 210 2.1.1. Field Names for Attribute Values 212 Previous specifications used inconsistent and conflicting names for 213 the contents of RADIUS attributes. For example, the term "Value" is 214 used in [RFC2865] Section 5 to define a field which carries the 215 contents of attribute. It is then used in later sections as the sub- 216 field of attribute contents. The result is that the field is defined 217 as recursively containing itself. Similarly, "String" is used both 218 as a data type, and as a sub-field of other data types. 220 We correct this ambiguity by using context-specific names for various 221 fields of attributes and data types. It then becomes clear that, for 222 example, that a field called "VSA-Data" must contain different data 223 than a field called "EVS-Data". Each new name is defined where it is 224 used. 226 We also define the following term: 228 Attr-Data 230 The "Value" field of an Attribute as defined in [RFC2865] 231 Section 5. The contents of this field MUST be of a valid data 232 type as defined in the RADIUS Data Type registry. 234 We consistently use "Attr-Data" to refer to the contents of an 235 attribute, instead of the more ambiguous name "Value". It is 236 RECOMMENDED that new specifications follow this practice. 238 In this document, we use the term "Value" to refer to the contents of 239 a data type, where that data type cannot carry other data types. In 240 other cases, we refer to the contents of a data type with a type- 241 specific name, in order to distinguish it from data of other types. 242 For example, the data type "vsa" will contain a data field called 243 "VSA-Data". 245 These terms are used in preference to the term "String", which was 246 used in multiple incompatible ways. It is RECOMMENDED that future 247 specifications use type-specific names, and the same naming scheme 248 for new types. This use will maintain consistent definitions, and 249 avoid ambiguities. 251 2.1.2. Attribute Definitions using Data Types 253 New RADIUS specifications MUST define attributes using data types 254 from the RADIUS Data Type registry. The specification may, of 255 course, define a new data type and use it in the same document. The 256 guidelines given in [RFC6929] MUST be followed when defining a new 257 data type. 259 Attributes can usually be completely described via the Attribute Type 260 code, name, and data type. The use of "ASCII art" is then limited 261 only to the definition of new data types, and for complex data types. 263 Use of the new extended attributes [RFC6929] makes ASCII art even 264 more problematic. An attribute can be allocated from any of the 265 extended spaces, with more than one option for attribute header 266 format. This allocation decision is made after the specification has 267 been accepted for publication. As the allocation affects the format 268 of the attribute header, it is essentially impossible to create the 269 correct ASCII art prior to final publication. Allocation from the 270 different spaces also changes the value of the Length field, also 271 making it difficult to define it correctly prior to final publication 272 of the document. 274 It is therefore RECOMMENDED that "ASCII art" diagrams not be used for 275 new RADIUS attribute specifications. 277 2.1.3. Format of Attribute Definitions 279 When defining a new attribute, the following fields SHOULD be given: 281 Description 283 A description of the meaning and interpretation of the 284 attribute. 286 Type 288 The Attribute Type code, given in the "dotted number" notation 289 from [RFC6929]. Specifications can often leave this as "TBD", 290 and request that IANA fill in the allocated values. 292 Length 294 A description of the length of the attribute. For attributes 295 of variable length, a maximum length SHOULD be given. Since 296 the Length may depend on the Type, the definition of Length may 297 be affected by IANA allocations. 299 Data Type 301 One of the named data types from the RADIUS Data Type registry. 303 Value 305 A description of any attribute-specific limitations on the 306 values carried by the specified data type. If there are no 307 attribute-specific limitations, then the description of this 308 field can be omitted, so long as the Description field is 309 sufficiently explanatory. 311 Where the values are limited to a subset of the possible range, 312 valid range(s) MUST be defined. 314 For attributes of data type "enum", a list of enumerated values 315 and names MUST be given, as with [RFC2865] Section 5.6. 317 Using a consistent format for attribute definitions helps to make the 318 definitions clearer. 320 2.1.4. Defining a New Data Type 322 When a specification needs to define a new data type, it should 323 follow the format used by the definitions in Section 3 of this 324 document. The text at the start of the data type definition MUST 325 describe the data type, including the expected use, and why a new 326 data type is required. That text SHOULD include limits on expected 327 values, and why those limits exist. The fields "Name", "Value", 328 "Length", and "Format", MUST be given, along with values. 330 The "Name" field SHOULD be a single name, all lower-case. 331 Contractions such as "ipv4addr" are RECOMMENDED where they add 332 clarity. 334 We note that the use of "Value" in the RADIUS Data Type registry can 335 be confusing. That name is also used in attribute definitions, but 336 with a different meaning. We trust that the meaning here is clear 337 from the context. 339 The "Value" field should be given as to be determined or "TBD" in 340 specifications. That number is assigned by IANA. 342 The "Format" field SHOULD be defined with "ASCII art" in order to 343 have a precise definition. Machine-readable formats are also 344 RECOMMENDED. 346 The definition of a new data type should be done only when absolutely 347 necessary. We do not expect a need for a large number of new data 348 types. When defining a new data type, the guideliness of [RFC6929] 349 with respect to data types MUST be followed. 351 It is RECOMMENDED that vendors not define "vendor specific" data 352 types. As discussed in [RFC6929], those data types are rarely 353 necessary, and can cause interoperability problems. 355 Any new data type MUST have unique name in the RADIUS Data Type 356 registry. The number of the data type will be assigned by IANA. 358 2.2. Implementation Use of Data Types 360 Implementations not supporting a particular data type MUST treat 361 attributes of that data type as being of data type "string", as 362 defined in Section 3.6. It is RECOMMENDED that such attributes be 363 treated as "invalid attributes", as defined in [RFC6929] Section 2.8. 365 Where the contents of a data type do not match the definition, 366 implementations MUST treat the the enclosing attribute as being an 367 "invalid attribute". This requirement includes, but is not limited 368 to, the following situations: 370 * Attributes with values outside of the allowed range(s) for the 371 data type, e.g. as given in the data types "integer", "ipv4addr", 372 "ipv6addr", "ipv4prefix", "ipv6prefix", or "enum". 374 * "text" attributes where the contents do not match the required 375 format, 377 * Attributes where the length is shorter or longer than the allowed 378 length(s) for the given data type, 380 The requirements for "reserved" fields are more difficult to 381 quantify. Implementations SHOULD be able to receive and process 382 attributes where "reserved" fields are non-zero. We do not, however, 383 define any "correct" processing of such attributes. Instead, 384 specifications which define new meaning for "reserved" fields SHOULD 385 describe how older implementations process those fields. We expect 386 that such descriptions are derived from practice. Implementations 387 MUST set "reserved" fields to zero when creating attributes. 389 3. Data Type Definitions 391 This section defines the new data types. For each data type, it 392 gives a definition, a name, a number, a length, and an encoding 393 format. Where relevant, it describes subfields contained within the 394 data type. These definitions have no impact on existing RADIUS 395 implementations. There is no requirement that implementations use 396 these names. 398 Where possible, the name of each data type has been taken from 399 previous specifications. In some cases, a different name has been 400 chosen. The change of name is sometimes required to avoid ambiguity 401 (i.e. "address" versus "Address"). Otherwise, the new name has been 402 chosen to be compatible with [RFC2865], or with use in common 403 implementations. In some cases, new names are chosen to clarify the 404 interpretation of the data type. 406 The numbers assigned herein for the data types have no meaning other 407 than to permit them to be tracked by IANA. As RADIUS does not encode 408 information about data types in a packet, the numbers assigned to a 409 data type will never occur in a packet. It is RECOMMENDED that new 410 implementations use the names defined in this document, in order to 411 avoid confusion. Existing implementations may choose to use the 412 names defined here, but that is not required. 414 The encoding of each data type is taken from previous specifications. 415 The fields are transmitted from left to right. 417 Where the data types have inter-dependencies, the simplest data type 418 is given first, and dependent ones are given later. 420 We do not create specific data types for the "tagged" attributes 421 defined in [RFC2868]. That specification defines the "tagged" 422 attributes as being backwards compatible with pre-existing data 423 types. In addition, [RFC6158] Section 2.1 says that "tagged" 424 attributes should not be used. There is therefore no benefit to 425 defining additional data types for these attributes. We trust that 426 implementors will be aware that tagged attributes must be treated 427 differently from non-tagged attributes of the same data type. 429 Similarly, we do not create data types for some attributes having 430 complex structure, such as CHAP-Password, ARAP-Features, or Location- 431 Information. We need to strike a balance between correcting earlier 432 mistakes, and making this document more complex. In some cases, it 433 is better to treat complex attributes as being of type "string", even 434 though they need to be interpreted by RADIUS implementations. The 435 guidelines given in Section 6.3 of [RFC6929] were used to make this 436 determination. 438 3.1. integer 440 The "integer" data type encodes a 32-bit unsigned integer in network 441 byte order. Where the range of values for a particular attribute is 442 limited to a sub-set of the values, specifications MUST define the 443 valid range. Attributes with Values outside of the allowed ranges 444 SHOULD be treated as "invalid attributes". 446 Name 448 integer 450 Value 452 1 454 Length 456 Four octets 458 Format 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Value | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 3.2. enum 468 The "enum" data type encodes a 32-bit unsigned integer in network 469 byte order. It differs from the "integer" data type only in that it 470 is used to define enumerated types, such as Service-Type (Section 5.6 471 of [RFC2865]). Specifications MUST define a valid set of enumerated 472 values, along with a unique name for each value. Attributes with 473 Values outside of the allowed enumerations SHOULD be treated as 474 "invalid attributes". 476 Name 478 enum 480 Value 482 2 484 Length 485 Four octets 487 Format 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Value | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 3.3. time 497 The "time" data type encodes time as a 32-bit unsigned value in 498 network byte order and in seconds since 00:00:00 UTC, January 1, 499 1970. We note that dates before the year 2016 are likely to indicate 500 configuration errors, or lack of access to the correct time. 502 Note that the "time" attribute is defined to be unsigned, which means 503 it is not subject to a signed integer overflow in the year 2038. 505 Name 507 time 509 Value 511 3 513 Length 515 Four octets 517 Format 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Time | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 3.4. text 527 The "text" data type encodes UTF-8 text [RFC3629]. The maximum 528 length of the text is given by the encapsulating attribute. Where 529 the range of lengths for a particular attribute is limited to a sub- 530 set of possible lengths, specifications MUST define the valid 531 range(s). Attributes with length outside of the allowed values 532 SHOULD be treated as "invalid attributes". 534 Where the text is intended to carry data in a particular format, 535 (e.g. Framed-Route), the format MUST be given. The specification 536 SHOULD describe the format in a machine-readable way, such as via 537 Augmented Backus-Naur Form (ABNF). Attributes with values not 538 matching the defined format SHOULD be treated as "invalid 539 attributes". 541 Note that the "text" data type does not terminate with a NUL octet 542 (hex 00). The Attribute has a Length field and does not use a 543 terminator. Texts of length zero (0) MUST NOT be sent; omit the 544 entire attribute instead. 546 Name 548 text 550 Value 552 4 554 Length 556 One or more octets. 558 Format 560 0 561 0 1 2 3 4 5 6 7 562 +-+-+-+-+-+-+-+- 563 | Value ... 564 +-+-+-+-+-+-+-+- 566 3.5. string 568 The "string" data type encodes binary data, as a sequence of 569 undistinguished octets. Where the range of lengths for a particular 570 attribute is limited to a sub-set of possible lengths, specifications 571 MUST define the valid range(s). Attributes with length outside of 572 the allowed values SHOULD be treated as "invalid attributes". 574 Note that the "string" data type does not terminate with a NUL octet 575 (hex 00). The Attribute has a Length field and does not use a 576 terminator. Strings of length zero (0) MUST NOT be sent; omit the 577 entire attribute instead. 579 Where there is a need to encapsulate complex data structures, and 580 TLVs cannot be used, the "string" data type MUST be used. This 581 requirement include encapsulation of data structures defined outside 582 of RADIUS, which are opaque to the RADIUS infrastucture. It also 583 includes encapsulation of some data structures which are not opaque 584 to RADIUS, such as the contents of CHAP-Password. 586 There is little reason to define a new RADIUS data type for only one 587 attribute. However, where the complex data type cannot be 588 represented as TLVs, and is expected to be used in many attributes, a 589 new data type SHOULD be defined. 591 These requirements are stronger than [RFC6158], which makes the above 592 encapsulation a "SHOULD". This document defines data types for use 593 in RADIUS, so there are few reasons to avoid using them. 595 Name 597 string 599 Value 601 5 603 Length 605 One or more octets. 607 Format 609 0 610 0 1 2 3 4 5 6 7 611 +-+-+-+-+-+-+-+- 612 | Octets ... 613 +-+-+-+-+-+-+-+- 615 3.6. concat 617 The "concat" data type permits the transport of more than 253 octets 618 of data in a "standard space" [RFC6929] attribute. It is otherwise 619 identical to the "string" data type. 621 If multiple attributes of this data type are contained in a packet, 622 all attributes of the same type code MUST be in order and they MUST 623 be consecutive attributes in the packet. 625 The amount of data transported in a "concat" data type can be no more 626 than the RADIUS packet size. In practice, the requirement to 627 transport multiple attributes means that the limit may be 628 substantially smaller than one RADIUS packet. As a rough guide, is 629 RECOMMENDED that this data type transport no more than 2048 octets of 630 data. 632 The "concat" data type MAY be used for "standard space" attributes. 633 It MUST NOT be used for attributes in the "short extended space" or 634 the "long extended space". It MUST NOT be used in any field or 635 subfields of the following data types: "tlv", "vsa", "extended", 636 "long-extended", or "evs". 638 Name 640 concat 642 Value 644 6 646 Length 648 One or more octets. 650 Format 652 0 653 0 1 2 3 4 5 6 7 654 +-+-+-+-+-+-+-+- 655 | Octets ... 656 +-+-+-+-+-+-+-+- 658 3.7. ifid 660 The "ifid" data type encodes an Interface-Id as an 8-octet string in 661 network byte order. 663 Name 665 ifid 667 Value 669 7 671 Length 672 Eight octets 674 Format 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Interface-ID ... 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 ... Interface-ID | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 3.8. ipv4addr 686 The "ipv4addr" data type encodes an IPv4 address in network byte 687 order. Where the range of address for a particular attribute is 688 limited to a sub-set of possible addresses, specifications MUST 689 define the valid range(s). Attributes with Addresses outside of the 690 allowed range(s) SHOULD be treated as "invalid attributes". 692 Name 694 ipv4addr 696 Value 698 8 700 Length 702 Four octets 704 Format 706 0 1 2 3 707 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 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Address | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 3.9. ipv6addr 714 The "ipv6addr" data type encodes an IPv6 address in network byte 715 order. Where the range of address for a particular attribute is 716 limited to a sub-set of possible addresses, specifications MUST 717 define the valid range(s). Attributes with Addresses outside of the 718 allowed range(s) SHOULD be treated as "invalid attributes". 720 Name 722 ipv6addr 724 Value 726 9 728 Length 730 Sixteen octets 732 Format 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Address ... 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 ... Address ... 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 ... Address ... 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 ... Address | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 3.10. ipv6prefix 748 The "ipv6prefix" data type encodes an IPv6 prefix, using both a 749 prefix length and an IPv6 address in network byte order. Where the 750 range of prefixes for a particular attribute is limited to a sub-set 751 of possible prefixes, specifications MUST define the valid range(s). 752 Attributes with Addresses outside of the allowed range(s) SHOULD be 753 treated as "invalid attributes". 755 Attributes with a Prefix-Length field having value greater than 128 756 SHOULD be treated as "invalid attributes". 758 Name 760 ipv6prefix 762 Value 764 10 766 Length 768 At least two, and no more than eighteen octets. 770 Format 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Reserved | Prefix-Length | Prefix ... 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 ... Prefix ... 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 ... Prefix ... 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 ... Prefix | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 Subfields 786 Reserved 788 This field, which is reserved and MUST be present, is always 789 set to zero. 791 Prefix-Length 793 The length of the prefix, in bits. At least 0 and no larger 794 than 128. 796 Prefix 798 The Prefix field is up to 16 octets in length. Bits outside of 799 the Prefix-Length, if included, MUST be zero. 801 3.11. ipv4prefix 803 The "ipv4prefix" data type encodes an IPv4 prefix, using both a 804 prefix length and an IPv4 address in network byte order. Where the 805 range of prefixes for a particular attribute is limited to a sub-set 806 of possible prefixes, specifications MUST define the valid range(s). 807 Attributes with Addresses outside of the allowed range(s) SHOULD be 808 treated as "invalid attributes". 810 Attributes with a Prefix-Length field having value greater than 32 811 SHOULD be treated as "invalid attributes". 813 Name 815 ipv4prefix 817 Value 819 11 821 Length 823 six octets 825 Format 827 0 1 2 3 828 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 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Reserved | Prefix-Length | Prefix ... 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 ... Prefix | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 Subfields 837 Reserved 839 This field, which is reserved and MUST be present, is always 840 set to zero. This field is one octet in length. 842 Note that this definition differs from that given in [RFC6572]. 843 See Prefix-Length, below, for an explanation. 845 Prefix-Length 847 The length of the prefix, in bits. The values MUST be no 848 larger than 32. This field is one octet in length. 850 Note that this definition differs from that given in [RFC6572]. 852 As compared to [RFC6572], the Prefix-Length field has increased 853 in size by two bits, both of which must be zero. The Reserved 854 field has decreased in size by two bits. The result is that 855 both fields are aligned on octet boundaries, which removes the 856 need for bit masking of the fields. 858 Since [RFC6572] required the Reserved field to be zero, the 859 definition here is compatible with the definition in the 860 original specification. 862 Prefix 864 The Prefix field is 4 octets in length. Bits outside of the 865 Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type, 866 this field is fixed length. If the address is all zeros (i.e. 867 "0.0.0.0", then the Prefix-Length MUST be set to 32. 869 3.12. integer64 871 The "integer64" data type encodes a 64-bit unsigned integer in 872 network byte order. Where the range of values for a particular 873 attribute is limited to a sub-set of the values, specifications MUST 874 define the valid range(s). Attributes with Values outside of the 875 allowed range(s) SHOULD be treated as "invalid attributes". 877 Name 879 integer64 881 Value 883 12 885 Length 887 Eight octets 889 Format 891 0 1 2 3 892 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 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Value ... 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 ... Value | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 3.13. tlv 901 The "tlv" data type encodes a type-length-value, as defined in 902 [RFC6929] Section 2.3. 904 Name 906 tlv 908 Value 910 13 912 Length 914 Three or more octets 916 Format 918 0 1 2 3 919 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 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | TLV-Type | TLV-Length | TLV-Data ... 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 Subfields 926 TLV-Type 928 This field is one octet. Up-to-date values of this field are 929 specified according to the policies and rules described in 930 [RFC6929] Section 10. Values of 254-255 are "Reserved" for use 931 by future extensions to RADIUS. The value 26 has no special 932 meaning, and MUST NOT be treated as a Vendor Specific 933 attribute. 935 The TLV-Type is meaningful only within the context defined by 936 "Type" fields of the encapsulating Attributes, using the 937 dotted-number notation introduced in [RFC6929]. 939 A RADIUS server MAY ignore Attributes with an unknown "TLV- 940 Type". 942 A RADIUS client MAY ignore Attributes with an unknown "TLV- 943 Type". 945 A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- 946 Type" verbatim. 948 TLV-Length 950 The TLV-Length field is one octet, and indicates the length of 951 this TLV including the TLV-Type, TLV-Length and TLV-Value 952 fields. It MUST have a value between 3 and 255. If a client 953 or server receives a TLV with an invalid TLV-Length, then the 954 attribute which encapsulates that TLV MUST be considered to be 955 an "invalid attribute", and handled as per [RFC6929] Section 956 2.8. 958 TLVs having TLV-Length of two (2) MUST NOT be sent; omit the 959 entire TLV instead. 961 TLV-Data 963 The TLV-Data field is one or more octets and contains 964 information specific to the Attribute. The format and length 965 of the TLV-Data field is determined by the TLV-Type and TLV- 966 Length fields. 968 The TLV-Data field MUST contain only known RADIUS data types. 969 The TLV-Data field MUST NOT contain any of the following data 970 types: "concat", "vsa", "extended", "long-extended", or "evs". 972 3.14. vsa 974 The "vsa" data type encodes Vendor-Specific data, as given in 975 [RFC2865] Section 5.26. It is used only in the Attr-Data field of a 976 Vendor-Specific Attribute. It MUST NOT appear in the contents of any 977 other data type. 979 Where an implementation determines that an attribute of data type 980 "vsa" contains data which does not match the expected format, it 981 SHOULD treat that attribute as being an "invalid attribute". 983 Name 985 vsa 987 Value 989 14 991 Length 993 Five or more octets 995 Format 997 0 1 2 3 998 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 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Vendor-Id | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | VSA-Data .... 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 Subfields 1008 Vendor-Id 1010 The 4 octets are the Network Management Private Enterprise Code 1011 [PEN] of the Vendor in network byte order. 1013 VSA-Data 1015 The VSA-Data field is one or more octets. The actual format of 1016 the information is site or application specific, and a robust 1017 implementation SHOULD support the field as undistinguished 1018 octets. 1020 The codification of the range of allowed usage of this field is 1021 outside the scope of this specification. 1023 The "vsa" data type SHOULD contain as a sequence of "tlv" data 1024 types. The interpretation of the TLV-Type and TLV-Data fields 1025 are dependent on the vendor's definition of that attribute. 1027 The "vsa" data type MUST be used as contents of the Attr-Data 1028 field of the Vendor-Specific attribute. The "vsa" data type 1029 MUST NOT appear in the contents of any other data type. 1031 3.15. extended 1033 The "extended" data type encodes the "Extended Type" format, as given 1034 in [RFC6929] Section 2.1. It is used only in the Attr-Data field of 1035 an Attribute allocated from the "standard space". It MUST NOT appear 1036 in the contents of any other data type. 1038 Name 1040 extended 1042 Value 1044 15 1046 Length 1048 Two or more octets 1050 Format 1051 0 1 2 3 1052 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 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Extended-Type | Ext-Data ... 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 Subfields 1059 Extended-Type 1061 The Extended-Type field is one octet. Up-to-date values of 1062 this field are specified according to the policies and rules 1063 described in [RFC6929] Section 10. Unlike the Type field 1064 defined in [RFC2865] Section 5, no values are allocated for 1065 experimental or implementation-specific use. Values 241-255 1066 are reserved and MUST NOT be used. 1068 The Extended-Type is meaningful only within a context defined 1069 by the Type field. That is, this field may be thought of as 1070 defining a new type space of the form "Type.Extended-Type". 1071 See [RFC6929] Section 2.5 for additional discussion. 1073 A RADIUS server MAY ignore Attributes with an unknown 1074 "Type.Extended-Type". 1076 A RADIUS client MAY ignore Attributes with an unknown 1077 "Type.Extended-Type". 1079 Ext-Data 1081 The contents of this field MUST be a valid data type as defined 1082 in the RADIUS Data Type registry. The Ext-Data field MUST NOT 1083 contain any of the following data types: "concat", "vsa", 1084 "extended", "long-extended", or "evs". 1086 The Ext-Data field is one or more octets. 1088 Implementations supporting this specification MUST use the 1089 Identifier of "Type.Extended-Type" to determine the 1090 interpretation of the Ext-Data field. 1092 3.16. long-extended 1094 The "long-extended" data type encodes the "Long Extended Type" 1095 format, as given in [RFC6929] Section 2.2. It is used only in the 1096 Attr-Data field of an Attribute. It MUST NOT appear in the contents 1097 of any other data type. 1099 Name 1101 long-extended 1103 Value 1105 16 1107 Length 1109 Three or more octets 1111 Format 1113 0 1 2 3 1114 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 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | Extended-Type |M| Reserved | Ext-Data ... 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 Subfields 1121 Extended-Type 1123 This field is identical to the Extended-Type field defined 1124 above in Section 2.13. 1126 M (More) 1128 The More field is one (1) bit in length, and indicates whether 1129 or not the current attribute contains "more" than 251 octets of 1130 data. The More field MUST be clear (0) if the Length field has 1131 value less than 255. The More field MAY be set (1) if the 1132 Length field has value of 255. 1134 If the More field is set (1), it indicates that the Ext-Data 1135 field has been fragmented across multiple RADIUS attributes. 1136 When the More field is set (1), the attribute MUST have a 1137 Length field of value 255; there MUST be an attribute following 1138 this one; and the next attribute MUST have both the same Type 1139 and Extended Type. That is, multiple fragments of the same 1140 value MUST be in order and MUST be consecutive attributes in 1141 the packet, and the last attribute in a packet MUST NOT have 1142 the More field set (1). 1144 That is, a packet containing a fragmented attribute needs to 1145 contain all fragments of the attribute, and those fragments 1146 need to be contiguous in the packet. RADIUS does not support 1147 inter-packet fragmentation, which means that fragmenting an 1148 attribute across multiple packets is impossible. 1150 If a client or server receives an attribute fragment with the 1151 "More" field set (1), but for which no subsequent fragment can 1152 be found, then the fragmented attribute is considered to be an 1153 "invalid attribute", and handled as per [RFC6929] Section 2.8. 1155 Reserved 1157 This field is 7 bits long, and is reserved for future use. 1158 Implementations MUST set it to zero (0) when encoding an 1159 attribute for sending in a packet. The contents SHOULD be 1160 ignored on reception. 1162 Future specifications may define additional meaning for this 1163 field. Implementations therefore MUST NOT treat this field as 1164 invalid if it is non-zero. 1166 Ext-Data 1168 The contents of this field MUST be a valid data type as defined 1169 in the RADIUS Data Type registry. The Ext-Data field MUST NOT 1170 contain any of the following data types: "concat", "vsa", 1171 "extended", "long-extended", or "evs". 1173 The Ext-Data field is one or more octets. 1175 Implementations supporting this specification MUST use the 1176 Identifier of "Type.Extended-Type" to determine the 1177 interpretation of the Ext-Data field. 1179 The length of the data MUST be taken as the sum of the lengths 1180 of the fragments (i.e. Ext-Data fields) from which it is 1181 constructed. Any interpretation of the resulting data MUST 1182 occur after the fragments have been reassembled. If the 1183 reassembled data does not match the expected format, each 1184 fragment MUST be treated as an "invalid attribute", and the 1185 reassembled data MUST be discarded. 1187 We note that the maximum size of a fragmented attribute is 1188 limited only by the RADIUS packet length limitation. 1189 Implementations MUST be able to handle the case where one 1190 fragmented attribute completely fills the packet. 1192 3.17. evs 1194 The "evs" data type encodes an "Extended Vendor-Specific" attribute, 1195 as given in [RFC6929] Section 2.4. The "evs" data type is used 1196 solely to extend the Vendor Specific space. It MAY appear inside of 1197 an "extended" or a "long-extended" data type. It MUST NOT appear in 1198 the contents of any other data type. 1200 Where an implementation determines that an attribute of data type 1201 "evs" contains data which does not match the expected format, it 1202 SHOULD treat that attribute as being an "invalid attribute". 1204 Name 1206 evs 1208 Value 1210 17 1212 Length 1214 Six or more octets 1216 Format 1218 0 1 2 3 1219 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 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Vendor-Id | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | Vendor-Type | EVS-Data .... 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 Subfields 1228 Vendor-Id 1230 The 4 octets are the Network Management Private Enterprise Code 1231 [PEN] of the Vendor in network byte order. 1233 Vendor-Type 1235 The Vendor-Type field is one octet. Values are assigned at the 1236 sole discretion of the Vendor. 1238 EVS-Data 1239 The EVS-Data field is one or more octets. It SHOULD 1240 encapsulate a previously defined RADIUS data type. Non- 1241 standard data types SHOULD NOT be used. We note that the EVS- 1242 Data field may be of data type "tlv". 1244 The actual format of the information is site or application 1245 specific, and a robust implementation SHOULD support the field 1246 as undistinguished octets. We recognise that Vendors have 1247 complete control over the contents and format of the Ext-Data 1248 field, while at the same time recommending that good practices 1249 be followed. 1251 Further codification of the range of allowed usage of this 1252 field is outside the scope of this specification. 1254 4. Updated Registries 1256 This section defines a new IANA registry for RADIUS data types, and 1257 then updates the existing RADIUS Attribute Type registry to use the 1258 data types from the new registry. 1260 4.1. Create a Data Type Registry 1262 This section defines a new RADIUS registry, called "Data Type". 1263 Allocation in this registry requires IETF Review. The "Registration 1264 Procedures" for the Data Type Registry are "Standards Action". 1266 The Data Type Registry contains three columns of data, as follows. 1268 Value 1270 The number of the data type. The value field is an artifact of 1271 the registry, and has no on-the-wire meaning. 1273 Description 1275 The name of the data type. The name field is used only for the 1276 registry, and has no on-the-wire meaning. 1278 Reference 1280 The specification where the data type was defined. 1282 The initial contents of the registry are as follows. 1284 Value Description Reference 1285 ----- ----------- ---------------- 1286 1 integer [RFC2865], TBD 1287 2 enum [RFC2865], TBD 1288 3 time [RFC2865], TBD 1289 4 text [RFC2865], TBD 1290 5 string [RFC2865], TBD 1291 6 concat TBD 1292 7 ifid [RFC3162], TBD 1293 8 ipv4addr [RFC2865], TBD 1294 9 ipv6addr [RFC3162], TBD 1295 10 ipv6prefix [RFC3162], TBD 1296 11 ipv4prefix [RFC6572], TBD 1297 12 integer64 [RFC6929], TBD 1298 13 tlv [RFC6929], TBD 1299 14 evs [RFC6929], TBD 1300 15 extended [RFC6929], TBD 1301 16 long-extended [RFC6929], TBD 1303 4.2. Updates to the Attribute Type Registry 1305 This section updates the RADIUS Attribute Type Registry to have a new 1306 column, which is inserted in between the existing "Description" and 1307 "Reference" columns. The new column is named "Data Type". The 1308 contents of that column are the name of a data type, corresponding to 1309 the attribute in that row, or blank if the attribute type is 1310 unassigned. The name of the data type is taken from the RADIUS Data 1311 Type registry, defined above. 1313 The existing registration requirements for the Attribute Type 1314 Registry are unchanged. 1316 The updated registry follows in CSV format. 1318 Value,Description,Data Type,Reference 1319 1,User-Name,text,[RFC2865] 1320 2,User-Password,string,[RFC2865] 1321 3,CHAP-Password,string,[RFC2865] 1322 4,NAS-IP-Address,ipv4addr,[RFC2865] 1323 5,NAS-Port,integer,[RFC2865] 1324 6,Service-Type,enum,[RFC2865] 1325 7,Framed-Protocol,enum,[RFC2865] 1326 8,Framed-IP-Address,ipv4addr,[RFC2865] 1327 9,Framed-IP-Netmask,ipv4addr,[RFC2865] 1328 10,Framed-Routing,enum,[RFC2865] 1329 11,Filter-Id,text,[RFC2865] 1330 12,Framed-MTU,integer,[RFC2865] 1331 13,Framed-Compression,enum,[RFC2865] 1332 14,Login-IP-Host,ipv4addr,[RFC2865] 1333 15,Login-Service,enum,[RFC2865] 1334 16,Login-TCP-Port,integer,[RFC2865] 1335 17,Unassigned,, 1336 18,Reply-Message,text,[RFC2865] 1337 19,Callback-Number,text,[RFC2865] 1338 20,Callback-Id,text,[RFC2865] 1339 21,Unassigned,, 1340 22,Framed-Route,text,[RFC2865] 1341 23,Framed-IPX-Network,ipv4addr,[RFC2865] 1342 24,State,string,[RFC2865] 1343 25,Class,string,[RFC2865] 1344 26,Vendor-Specific,vsa,[RFC2865] 1345 27,Session-Timeout,integer,[RFC2865] 1346 28,Idle-Timeout,integer,[RFC2865] 1347 29,Termination-Action,enum,[RFC2865] 1348 30,Called-Station-Id,text,[RFC2865] 1349 31,Calling-Station-Id,text,[RFC2865] 1350 32,NAS-Identifier,text,[RFC2865] 1351 33,Proxy-State,string,[RFC2865] 1352 34,Login-LAT-Service,text,[RFC2865] 1353 35,Login-LAT-Node,text,[RFC2865] 1354 36,Login-LAT-Group,string,[RFC2865] 1355 37,Framed-AppleTalk-Link,integer,[RFC2865] 1356 38,Framed-AppleTalk-Network,integer,[RFC2865] 1357 39,Framed-AppleTalk-Zone,text,[RFC2865] 1358 40,Acct-Status-Type,enum,[RFC2866] 1359 41,Acct-Delay-Time,integer,[RFC2866] 1360 42,Acct-Input-Octets,integer,[RFC2866] 1361 43,Acct-Output-Octets,integer,[RFC2866] 1362 44,Acct-Session-Id,text,[RFC2866] 1363 45,Acct-Authentic,enum,[RFC2866] 1364 46,Acct-Session-Time,integer,[RFC2866] 1365 47,Acct-Input-Packets,integer,[RFC2866] 1366 48,Acct-Output-Packets,integer,[RFC2866] 1367 49,Acct-Terminate-Cause,enum,[RFC2866] 1368 50,Acct-Multi-Session-Id,text,[RFC2866] 1369 51,Acct-Link-Count,integer,[RFC2866] 1370 52,Acct-Input-Gigawords,integer,[RFC2869] 1371 53,Acct-Output-Gigawords,integer,[RFC2869] 1372 54,Unassigned,, 1373 55,Event-Timestamp,time,[RFC2869] 1374 56,Egress-VLANID,integer,[RFC4675] 1375 57,Ingress-Filters,enum,[RFC4675] 1376 58,Egress-VLAN-Name,text,[RFC4675] 1377 59,User-Priority-Table,string,[RFC4675] 1378 60,CHAP-Challenge,string,[RFC2865] 1379 61,NAS-Port-Type,enum,[RFC2865] 1380 62,Port-Limit,integer,[RFC2865] 1381 63,Login-LAT-Port,text,[RFC2865] 1382 64,Tunnel-Type,enum,[RFC2868] 1383 65,Tunnel-Medium-Type,enum,[RFC2868] 1384 66,Tunnel-Client-Endpoint,text,[RFC2868] 1385 67,Tunnel-Server-Endpoint,text,[RFC2868] 1386 68,Acct-Tunnel-Connection,text,[RFC2867] 1387 69,Tunnel-Password,string,[RFC2868] 1388 70,ARAP-Password,string,[RFC2869] 1389 71,ARAP-Features,string,[RFC2869] 1390 72,ARAP-Zone-Access,enum,[RFC2869] 1391 73,ARAP-Security,integer,[RFC2869] 1392 74,ARAP-Security-Data,text,[RFC2869] 1393 75,Password-Retry,integer,[RFC2869] 1394 76,Prompt,enum,[RFC2869] 1395 77,Connect-Info,text,[RFC2869] 1396 78,Configuration-Token,text,[RFC2869] 1397 79,EAP-Message,concat,[RFC2869] 1398 80,Message-Authenticator,string,[RFC2869] 1399 81,Tunnel-Private-Group-ID,text,[RFC2868] 1400 82,Tunnel-Assignment-ID,text,[RFC2868] 1401 83,Tunnel-Preference,integer,[RFC2868] 1402 84,ARAP-Challenge-Response,string,[RFC2869] 1403 85,Acct-Interim-Interval,integer,[RFC2869] 1404 86,Acct-Tunnel-Packets-Lost,integer,[RFC2867] 1405 87,NAS-Port-Id,text,[RFC2869] 1406 88,Framed-Pool,text,[RFC2869] 1407 89,CUI,string,[RFC4372] 1408 90,Tunnel-Client-Auth-ID,text,[RFC2868] 1409 91,Tunnel-Server-Auth-ID,text,[RFC2868] 1410 92,NAS-Filter-Rule,text,[RFC4849] 1411 93,Unassigned,, 1412 94,Originating-Line-Info,string,[RFC7155] 1413 95,NAS-IPv6-Address,ipv6addr,[RFC3162] 1414 96,Framed-Interface-Id,ifid,[RFC3162] 1415 97,Framed-IPv6-Prefix,ipv6prefix,[RFC3162] 1416 98,Login-IPv6-Host,ipv6addr,[RFC3162] 1417 99,Framed-IPv6-Route,text,[RFC3162] 1418 100,Framed-IPv6-Pool,text,[RFC3162] 1419 101,Error-Cause Attribute,enum,[RFC3576] 1420 102,EAP-Key-Name,string,[RFC4072][RFC7268] 1421 103,Digest-Response,text,[RFC5090] 1422 104,Digest-Realm,text,[RFC5090] 1423 105,Digest-Nonce,text,[RFC5090] 1424 106,Digest-Response-Auth,text,[RFC5090] 1425 107,Digest-Nextnonce,text,[RFC5090] 1426 108,Digest-Method,text,[RFC5090] 1427 109,Digest-URI,text,[RFC5090] 1428 110,Digest-Qop,text,[RFC5090] 1429 111,Digest-Algorithm,text,[RFC5090] 1430 112,Digest-Entity-Body-Hash,text,[RFC5090] 1431 113,Digest-CNonce,text,[RFC5090] 1432 114,Digest-Nonce-Count,text,[RFC5090] 1433 115,Digest-Username,text,[RFC5090] 1434 116,Digest-Opaque,text,[RFC5090] 1435 117,Digest-Auth-Param,text,[RFC5090] 1436 118,Digest-AKA-Auts,text,[RFC5090] 1437 119,Digest-Domain,text,[RFC5090] 1438 120,Digest-Stale,text,[RFC5090] 1439 121,Digest-HA1,text,[RFC5090] 1440 122,SIP-AOR,text,[RFC5090] 1441 123,Delegated-IPv6-Prefix,ipv6prefix,[RFC4818] 1442 124,MIP6-Feature-Vector,string,[RFC5447] 1443 125,MIP6-Home-Link-Prefix,ipv6prefix,[RFC5447] 1444 126,Operator-Name,text,[RFC5580] 1445 127,Location-Information,string,[RFC5580] 1446 128,Location-Data,string,[RFC5580] 1447 129,Basic-Location-Policy-Rules,string,[RFC5580] 1448 130,Extended-Location-Policy-Rules,string,[RFC5580] 1449 131,Location-Capable,enum,[RFC5580] 1450 132,Requested-Location-Info,enum,[RFC5580] 1451 133,Framed-Management-Protocol,enum,[RFC5607] 1452 134,Management-Transport-Protection,enum,[RFC5607] 1453 135,Management-Policy-Id,text,[RFC5607] 1454 136,Management-Privilege-Level,integer,[RFC5607] 1455 137,PKM-SS-Cert,concat,[RFC5904] 1456 138,PKM-CA-Cert,concat,[RFC5904] 1457 139,PKM-Config-Settings,string,[RFC5904] 1458 140,PKM-Cryptosuite-List,string,[RFC5904] 1459 141,PKM-SAID,text,[RFC5904] 1460 142,PKM-SA-Descriptor,string,[RFC5904] 1461 143,PKM-Auth-Key,string,[RFC5904] 1462 144,DS-Lite-Tunnel-Name,text,[RFC6519] 1463 145,Mobile-Node-Identifier,string,[RFC6572] 1464 146,Service-Selection,text,[RFC6572] 1465 147,PMIP6-Home-LMA-IPv6-Address,ipv6addr,[RFC6572] 1466 148,PMIP6-Visited-LMA-IPv6-Address,ipv6addr,[RFC6572] 1467 149,PMIP6-Home-LMA-IPv4-Address,ipv4addr,[RFC6572] 1468 150,PMIP6-Visited-LMA-IPv4-Address,ipv4addr,[RFC6572] 1469 151,PMIP6-Home-HN-Prefix,ipv6prefix,[RFC6572] 1470 152,PMIP6-Visited-HN-Prefix,ipv6prefix,[RFC6572] 1471 153,PMIP6-Home-Interface-ID,ifid,[RFC6572] 1472 154,PMIP6-Visited-Interface-ID,ifid,[RFC6572] 1473 155,PMIP6-Home-IPv4-HoA,ipv4prefix,[RFC6572] 1474 156,PMIP6-Visited-IPv4-HoA,ipv4prefix,[RFC6572] 1475 157,PMIP6-Home-DHCP4-Server-Address,ipv4addr,[RFC6572] 1476 158,PMIP6-Visited-DHCP4-Server-Address,ipv4addr,[RFC6572] 1477 159,PMIP6-Home-DHCP6-Server-Address,ipv6addr,[RFC6572] 1478 160,PMIP6-Visited-DHCP6-Server-Address,ipv6addr,[RFC6572] 1479 161,PMIP6-Home-IPv4-Gateway,ipv4addr,[RFC6572] 1480 162,PMIP6-Visited-IPv4-Gateway,ipv4addr,[RFC6572] 1481 163,EAP-Lower-Layer,enum,[RFC6677] 1482 164,GSS-Acceptor-Service-Name,text,[RFC7055] 1483 165,GSS-Acceptor-Host-Name,text,[RFC7055] 1484 166,GSS-Acceptor-Service-Specifics,text,[RFC7055] 1485 167,GSS-Acceptor-Realm-Name,text,[RFC7055] 1486 168,Framed-IPv6-Address,ipv6addr,[RFC6911] 1487 169,DNS-Server-IPv6-Address,ipv6addr,[RFC6911] 1488 170,Route-IPv6-Information,ipv6prefix,[RFC6911] 1489 171,Delegated-IPv6-Prefix-Pool,text,[RFC6911] 1490 172,Stateful-IPv6-Address-Pool,text,[RFC6911] 1491 173,IPv6-6rd-Configuration,tlv,[RFC6930] 1492 174,Allowed-Called-Station-Id,text,[RFC7268] 1493 175,EAP-Peer-Id,string,[RFC7268] 1494 176,EAP-Server-Id,string,[RFC7268] 1495 177,Mobility-Domain-Id,integer,[RFC7268] 1496 178,Preauth-Timeout,integer,[RFC7268] 1497 179,Network-Id-Name,string,[RFC7268] 1498 180,EAPoL-Announcement,concat,[RFC7268] 1499 181,WLAN-HESSID,text,[RFC7268] 1500 182,WLAN-Venue-Info,integer,[RFC7268] 1501 183,WLAN-Venue-Language,string,[RFC7268] 1502 184,WLAN-Venue-Name,text,[RFC7268] 1503 185,WLAN-Reason-Code,integer,[RFC7268] 1504 186,WLAN-Pairwise-Cipher,integer,[RFC7268] 1505 187,WLAN-Group-Cipher,integer,[RFC7268] 1506 188,WLAN-AKM-Suite,integer,[RFC7268] 1507 189,WLAN-Group-Mgmt-Cipher,integer,[RFC7268] 1508 190,WLAN-RF-Band,integer,[RFC7268] 1509 191,Unassigned,, 1510 192-223,Experimental Use,,[RFC3575] 1511 224-240,Implementation Specific,,[RFC3575] 1512 241,Extended-Attribute-1,extended,[RFC6929] 1513 241.1,Frag-Status,integer,[RFC7499] 1514 241.2,Proxy-State-Length,integer,[RFC7499] 1515 241.{3-25},Unassigned,, 1516 241.26,Extended-Vendor-Specific-1,evs,[RFC6929] 1517 241.{27-240},Unassigned,, 1518 241.{241-255},Reserved,,[RFC6929] 1519 242,Extended-Attribute-2,extended,[RFC6929] 1520 242.{1-25},Unassigned,, 1521 242.26,Extended-Vendor-Specific-2,evs,[RFC6929] 1522 242.{27-240},Unassigned,, 1523 242.{241-255},Reserved,,[RFC6929] 1524 243,Extended-Attribute-3,extended,[RFC6929] 1525 243.{1-25},Unassigned,, 1526 243.26,Extended-Vendor-Specific-3,evs,[RFC6929] 1527 243.{27-240},Unassigned,, 1528 243.{241-255},Reserved,,[RFC6929] 1529 244,Extended-Attribute-4,extended,[RFC6929] 1530 244.{1-25},Unassigned,, 1531 244.26,Extended-Vendor-Specific-4,evs,[RFC6929] 1532 244.{27-240},Unassigned,, 1533 244.{241-255},Reserved,,[RFC6929] 1534 245,Extended-Attribute-5,long-extended,[RFC6929] 1535 245.{1-25},Unassigned,, 1536 245.26,Extended-Vendor-Specific-5,evs,[RFC6929] 1537 245.{27-240},Unassigned,, 1538 245.{241-255},Reserved,,[RFC6929] 1539 246,Extended-Attribute-6,long-extended,[RFC6929] 1540 246.{1-25},Unassigned,, 1541 246.26,Extended-Vendor-Specific-6,evs,[RFC6929] 1542 246.{27-240},Unassigned,, 1543 246.{241-255},Reserved,,[RFC6929] 1544 247-255,Reserved,,[RFC3575] 1546 5. Security Considerations 1548 This specification is concerned solely with updates to IANA 1549 registries. As such, there are no security considerations with the 1550 document itself. 1552 However, the use of inconsistent names and poorly-defined entities in 1553 a protocol is problematic. Inconsistencies in specifications can 1554 lead to security and interoperability problems in implementations. 1555 Further, having one canonical source for the definition of data types 1556 means an implementor has fewer specifications to read. The 1557 implementation work is therefore simpler, and is more likely to be 1558 correct. 1560 The goal of this specification is to reduce ambiguities in the RADIUS 1561 protocol, which we believe will lead to more robust and more secure 1562 implementations. 1564 6. IANA Considerations 1566 IANA is instructed to create one new registry as described above in 1567 Section 4.1. The "TBD" text in that section should be replaced with 1568 the RFC number of this document when it is published. 1570 IANA is instructed to update the RADIUS Attribute Type registry, as 1571 described above in Section 4.2. 1573 IANA is instructed to require that all allocation requests in the 1574 RADIUS Attribute Type Registry contain a "Data Type" field. That 1575 field is required to contain one of the "Data Type" names contained 1576 in the RADIUS Data Type registry. 1578 IANA is instructed to require that updates to the RADIUS Data Type 1579 registry contain the following fields, with the associated 1580 instructions: 1582 * Value. IANA is instructed to assign the next unused integer in 1583 sequence to new data type definitions. 1585 * Name. IANA is instructed to require that this name be unique 1586 in the registry. 1588 * Reference. IANA is instructed to update this field with a 1589 reference 1590 to the document which defines the data type. 1592 7. References 1594 7.1. Normative References 1596 [RFC2119] 1597 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1598 Levels", RFC 2119, March, 1997. 1600 [RFC2865] 1601 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1602 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1604 [RFC3162] 1605 Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, 1606 August 2001. 1608 [RFC3629] 1609 Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1610 3629, November 2003. 1612 [RFC4072] 1613 Eronen, P., et al, "Diameter Extensible Authentication Protocol 1614 (EAP) Application", RFC 4072, February 2013. 1616 [RFC6158] 1617 DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 6158, 1618 March 2011. 1620 [RFC6572] 1621 Xia, F., et al, "RADIUS Support for Proxy Mobile IPv6", RFC 6572, 1622 June 2012. 1624 7.2. Informative References 1626 [RFC2868] 1627 Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. 1628 Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 1629 June 2000. 1631 [RFC2869] 1632 Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000. 1634 [RFC6929] 1635 DeKok, A., and Lior, A., "Remote Authentication Dial In User 1636 Service (RADIUS) Protocol Extensions", RFC 6929, April 2013. 1638 [RFC7268] 1639 Aboba, B, et al, "RADIUS Attributes for IEEE 802 Networks", RFC 1640 7268, July 2015. 1642 [RFC7499] 1643 Perez-Mendez A., et al, "Support of Fragmentation of RADIUS 1644 Packets", RFC 7499, April 2015. 1646 [PEN] 1647 http://www.iana.org/assignments/enterprise-numbers 1649 Acknowledgments 1651 Thanks to the RADEXT WG for patience and reviews of this document. 1653 Authors' Addresses 1655 Alan DeKok 1656 The FreeRADIUS Server Project 1658 Email: aland@freeradius.org