idnits 2.17.1 draft-ietf-radext-datatypes-03.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 (6 May 2016) is 2911 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 1622, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 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 6 May 2016 9 Data Types in the Remote Authentication 10 Dial-In User Service Protocol (RADIUS) 11 draft-ietf-radext-datatypes-03.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 November 6, 2016. 49 Copyright Notice 51 Copyright (c) 2016 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. time ................................................ 13 82 3.4. text ................................................ 13 83 3.5. string .............................................. 14 84 3.6. concat .............................................. 15 85 3.7. ifid ................................................ 16 86 3.8. ipv4addr ............................................ 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 any of the 264 extended spaces, with more than one option for attribute header 265 format. This allocation decision is made after the specification has 266 been accepted for publication. As the allocation affects the format 267 of the attribute header, it is esstentially impossible to create the 268 correct ASCII art prior to final publication. Allocation from the 269 different spaces also changes the value of the Length field, also 270 making it difficult to define it correctly prior to final publication 271 of the document. 273 It is therefore RECOMMENDED that "ASCII art" diagrams not be used for 274 new RADIUS attribute specifications. 276 2.1.3. Format of Attribute Definitions 278 When defining a new attribute, the following fields SHOULD be given: 280 Description 282 A description of the meaning and interpretation of the 283 attribute. 285 Type 287 The Attribute Type code, given in the "dotted number" notation 288 from [RFC6929]. Specifications can often leave this as "TBD", 289 and request that IANA fill in the allocated values. 291 Length 293 A description of the length of the attribute. For attributes 294 of variable length, a maximum length SHOULD be given. Since 295 the Length may depend on the Type, the definition of Length may 296 be affected by IANA allocations. 298 Data Type 300 One of the named data types from the RADIUS Data Type registry. 302 Value 304 A description of any attribute-specific limitations on the 305 values carried by the specified data type. If there are no 306 attribute-specific limitations, then the description of this 307 field can be omitted, so long as the Description field is 308 sufficiently explanatory. 310 Where the values are limited to a subset of the possible range, 311 valid range(s) MUST be defined. 313 For attributes of data type "enum", a list of enumerated values 314 and names MUST be given, as with [RFC2865] Section 5.6. 316 Using a consistent format for attribute definitions helps to make the 317 definitions clearer. 319 2.1.4. Defining a New Data Type 321 When a specification needs to define a new data type, it should 322 follow the format used by the definitions in Section 3 of this 323 document. The text at the start of the data type definition MUST 324 describe the data type, including the expected use, and why a new 325 data type is required. That text SHOULD include limits on expected 326 values, and why those limits exist. The fields "Name", "Value", 327 "Length", and "Format", MUST be given, along with values. 329 The "Name" field SHOULD be a single name, all lower-case. 330 Contractions such as "ipv4addr" are RECOMMENDED where they add 331 clarity. 333 We note that the use of "Value" in the RADIUS Data Type registry can 334 be confusing. That name is also used in attribute definitions, but 335 with a different meaning. We trust that the meaning here is clear 336 from the context. 338 The "Value" field should be given as to be determined or "TBD" in 339 specifications. That number is assigned by IANA. 341 The "Format" field SHOULD be defined with "ASCII art" in order to 342 have a precise definition. Machine-readable formats are also 343 RECOMMENDED. 345 The definition of a new data type should be done only when absolutely 346 necessary. We do not expect a need for a large number of new data 347 types. When defining a new data type, the guideliness of [RFC6929] 348 with respect to data types MUST be followed. 350 It is RECOMMENDED that vendors not define "vendor specific" data 351 types. As discussed in [RFC6929], those data types are rarely 352 necessary, and can cause interoperability problems. 354 Any new data type MUST have unique name in the RADIUS Data Type 355 registry. The number of the data type will be assigned by IANA. 357 2.2. Implementation Use of Data Types 359 Implementations not supporting a particular data type MUST treat 360 attributes of that data type as being of data type "string", as 361 defined in Section 3.6. It is RECOMMENDED that such attributes be 362 treated as "invalid attributes", as defined in [RFC6929] Section 2.8. 364 Where the contents of a data type do not match the definition, 365 implementations MUST treat the the enclosing attribute as being an 366 "invalid attribute". This requirement includes, but is not limited 367 to, the following situations: 369 * Attributes with values outside of the allowed range(s) for the 370 data type, e.g. as given in the data types "integer", "ipv4addr", 371 "ipv6addr", "ipv4prefix", "ipv6prefix", or "enum". 373 * "text" attributes where the contents do not match the required 374 format, 376 * Attributes where the length is shorter or longer than the allowed 377 length(s) for the given data type, 379 The requirements for "reserved" fields are more difficult to 380 quantify. Implementations SHOULD be able to receive and process 381 attributes where "reserved" fields are non-zero. We do not, however, 382 define any "correct" processing of such attributes. Instead, 383 specifications which define new meaning for "reserved" fields SHOULD 384 describe how older implementations process those fields. We expect 385 that such descriptions are derived from practice. Implementations 386 MUST set "reserved" fields to zero when creating attributes. 388 3. Data Type Definitions 390 This section defines the new data types. For each data type, it 391 gives a definition, a name, a number, a length, and an encoding 392 format. Where relevant, it describes subfields contained within the 393 data type. These definitions have no impact on existing RADIUS 394 implementations. There is no requirement that implementations use 395 these names. 397 Where possible, the name of each data type has been taken from 398 previous specifications. In some cases, a different name has been 399 chosen. The change of name is sometimes required to avoid ambiguity 400 (i.e. "address" versus "Address"). Otherwise, the new name has been 401 chosen to be compatible with [RFC2865], or with use in common 402 implementations. In some cases, new names are chosen to clarify the 403 interpretation of the data type. 405 The numbers assigned herein for the data types have no meaning other 406 than to permit them to be tracked by IANA. As RADIUS does not encode 407 information about data types in a packet, the numbers assigned to a 408 data type will never occur in a packet. It is RECOMMENDED that new 409 implementations use the names defined in this document, in order to 410 avoid confusion. Existing implementations may choose to use the 411 names defined here, but that is not required. 413 The encoding of each data type is taken from previous specifications. 414 The fields are transmitted from left to right. 416 Where the data types have inter-dependencies, the simplest data type 417 is given first, and dependent ones are given later. 419 We do not create specific data types for the "tagged" attributes 420 defined in [RFC2868]. That specification defines the "tagged" 421 attributes as being backwards compatible with pre-existing data 422 types. In addition, [RFC6158] Section 2.1 says that "tagged" 423 attributes should not be used. There is therefore no benefit to 424 defining additional data types for these attributes. We trust that 425 implementors will be aware that tagged attributes must be treated 426 differently from non-tagged attributes of the same data type. 428 Similarly, we do not create data types for some attributes having 429 complex structure, such as CHAP-Password, ARAP-Features, or Location- 430 Information. We need to strike a balance between correcting earlier 431 mistakes, and making this document more complex. In some cases, it 432 is better to treat complex attributes as being of type "string", even 433 though they need to be interpreted by RADIUS implementations. The 434 guidelines given in Section 6.3 of [RFC6929] were used to make this 435 determination. 437 3.1. integer 439 The "integer" data type encodes a 32-bit unsigned integer in network 440 byte order. Where the range of values for a particular attribute is 441 limited to a sub-set of the values, specifications MUST define the 442 valid range. Attributes with Values outside of the allowed ranges 443 SHOULD be treated as "invalid attributes". 445 Name 447 integer 449 Value 451 1 453 Length 455 Four octets 457 Format 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Value | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 3.2. enum 467 The "enum" data type encodes a 32-bit unsigned integer in network 468 byte order. It differs from the "integer" data type only in that it 469 is used to define enumerated types, such as Service-Type (Section 5.6 470 of [RFC2865]). Specifications MUST define a valid set of enumerated 471 values, along with a unique name for each value. Attributes with 472 Values outside of the allowed enumerations SHOULD be treated as 473 "invalid attributes". 475 Name 477 enum 479 Value 481 2 483 Length 484 Four octets 486 Format 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Value | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 3.3. time 496 The "time" data type encodes time as a 32-bit unsigned value in 497 network byte order and in seconds since 00:00:00 UTC, January 1, 498 1970. We note that dates before the year 2016 are likely to indicate 499 configuration errors, or lack of access to the correct time. 501 Note that the "time" attribute is defined to be unsigned, which means 502 it is not subject to a signed integer overflow in the year 2038. 504 Name 506 time 508 Value 510 3 512 Length 514 Four octets 516 Format 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Time | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 3.4. text 526 The "text" data type encodes UTF-8 text [RFC3629]. The maximum 527 length of the text is given by the encapsulating attribute. Where 528 the range of lengths for a particular attribute is limited to a sub- 529 set of possible lengths, specifications MUST define the valid 530 range(s). Attributes with length outside of the allowed values 531 SHOULD be treated as "invalid attributes". 533 Where the text is intended to carry data in a particular format, 534 (e.g. Framed-Route), the format MUST be given. The specification 535 SHOULD describe the format in a machine-readable way, such as via 536 Augmented Backus-Naur Form (ABNF). Attributes with values not 537 matching the defined format SHOULD be treated as "invalid 538 attributes". 540 Note that the "text" data type does not terminate with a NUL octet 541 (hex 00). The Attribute has a Length field and does not use a 542 terminator. Texts of length zero (0) MUST NOT be sent; omit the 543 entire attribute instead. 545 Name 547 text 549 Value 551 4 553 Length 555 One or more octets. 557 Format 559 0 560 0 1 2 3 4 5 6 7 561 +-+-+-+-+-+-+-+- 562 | Value ... 563 +-+-+-+-+-+-+-+- 565 3.5. string 567 The "string" data type encodes binary data, as a sequence of 568 undistinguished octets. Where the range of lengths for a particular 569 attribute is limited to a sub-set of possible lengths, specifications 570 MUST define the valid range(s). Attributes with length outside of 571 the allowed values SHOULD be treated as "invalid attributes". 573 Note that the "string" data type does not terminate with a NUL octet 574 (hex 00). The Attribute has a Length field and does not use a 575 terminator. Strings of length zero (0) MUST NOT be sent; omit the 576 entire attribute instead. 578 Where there is a need to encapsulate complex data structures, and 579 TLVs cannot be used, the "string" data type MUST be used. This 580 requirement include encapsulation of data structures defined outside 581 of RADIUS, which are opaque to the RADIUS infrastucture. It also 582 includes encapsulation of some data structures which are not opaque 583 to RADIUS, such as the contents of CHAP-Password. 585 There is little reason to define a new RADIUS data type for only one 586 attribute. However, where the complex data type cannot be 587 represented as TLVs, and is expected to be used in many attributes, a 588 new data type SHOULD be defined. 590 These requirements are stronger than [RFC6158], which makes the above 591 encapsulation a "SHOULD". This document defines data types for use 592 in RADIUS, so there are few reasons to avoid using them. 594 Name 596 string 598 Value 600 5 602 Length 604 One or more octets. 606 Format 608 0 609 0 1 2 3 4 5 6 7 610 +-+-+-+-+-+-+-+- 611 | Octets ... 612 +-+-+-+-+-+-+-+- 614 3.6. concat 616 The "concat" data type permits the transport of more than 253 octets 617 of data in a "standard space" [RFC6929] attribute. It is otherwise 618 identical to the "string" data type. 620 If multiple attributes of this data type are contained in a packet, 621 all attributes of the same type code MUST be in order and they MUST 622 be consecutive attributes in the packet. 624 The amount of data transported in a "concat" data type can be no more 625 than the RADIUS packet size. In practice, the requirement to 626 transport multiple attributes means that the limit may be 627 substantially smaller than one RADIUS packet. As a rough guide, is 628 RECOMMENDED that this data type transport no more than 2048 octets of 629 data. 631 The "concat" data type MAY be used for "standard space" attributes. 632 It MUST NOT be used for attributes in the "short extended space" or 633 the "long extended space". It MUST NOT be used in any field or 634 subfields of the following data types: "tlv", "vsa", "extended", 635 "long-extended", or "evs". 637 Name 639 concat 641 Value 643 6 645 Length 647 One or more octets. 649 Format 651 0 652 0 1 2 3 4 5 6 7 653 +-+-+-+-+-+-+-+- 654 | Octets ... 655 +-+-+-+-+-+-+-+- 657 3.7. ifid 659 The "ifid" data type encodes an Interface-Id as an 8-octet string in 660 network byte order. 662 Name 664 ifid 666 Value 668 7 670 Length 671 Eight octets 673 Format 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Interface-ID ... 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 ... Interface-ID | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 3.8. ipv4addr 685 The "ipv4addr" data type encodes an IPv4 address in network byte 686 order. Where the range of address for a particular attribute is 687 limited to a sub-set of possible addresses, specifications MUST 688 define the valid range(s). Attributes with Addresses outside of the 689 allowed range(s) SHOULD be treated as "invalid attributes". 691 Name 693 ipv4addr 695 Value 697 8 699 Length 701 Four octets 703 Format 705 0 1 2 3 706 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 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Address | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 3.9. ipv6addr 713 The "ipv6addr" data type encodes an IPv6 address in network byte 714 order. Where the range of address for a particular attribute is 715 limited to a sub-set of possible addresses, specifications MUST 716 define the valid range(s). Attributes with Addresses outside of the 717 allowed range(s) SHOULD be treated as "invalid attributes". 719 Name 721 ipv6addr 723 Value 725 9 727 Length 729 Sixteen octets 731 Format 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Address ... 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 ... Address ... 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 ... Address ... 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 ... Address | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 3.10. ipv6prefix 747 The "ipv6prefix" data type encodes an IPv6 prefix, using both a 748 prefix length and an IPv6 address in network byte order. Where the 749 range of prefixes for a particular attribute is limited to a sub-set 750 of possible prefixes, specifications MUST define the valid range(s). 751 Attributes with Addresses outside of the allowed range(s) SHOULD be 752 treated as "invalid attributes". 754 Attributes with a Prefix-Length field having value greater than 128 755 SHOULD be treated as "invalid attributes". 757 Name 759 ipv6prefix 761 Value 763 10 765 Length 767 At least two, and no more than eighteen octets. 769 Format 771 0 1 2 3 772 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 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Reserved | Prefix-Length | Prefix ... 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 ... Prefix ... 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 ... Prefix ... 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 ... Prefix | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 Subfields 785 Reserved 787 This field, which is reserved and MUST be present, is always 788 set to zero. 790 Prefix-Length 792 The length of the prefix, in bits. At least 0 and no larger 793 than 128. 795 Prefix 797 The Prefix field is up to 16 octets in length. Bits outside of 798 the Prefix-Length, if included, MUST be zero. 800 3.11. ipv4prefix 802 The "ipv4prefix" data type encodes an IPv4 prefix, using both a 803 prefix length and an IPv4 address in network byte order. Where the 804 range of prefixes for a particular attribute is limited to a sub-set 805 of possible prefixes, specifications MUST define the valid range(s). 806 Attributes with Addresses outside of the allowed range(s) SHOULD be 807 treated as "invalid attributes". 809 Attributes with a Prefix-Length field having value greater than 32 810 SHOULD be treated as "invalid attributes". 812 Name 814 ipv4prefix 816 Value 818 11 820 Length 822 six octets 824 Format 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Reserved | Prefix-Length | Prefix ... 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 ... Prefix | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 Subfields 836 Reserved 838 This field, which is reserved and MUST be present, is always 839 set to zero. 841 Prefix-Length < 842 The length of the prefix, in bits. The values MUST be no 843 larger than 32. 845 Prefix 847 The Prefix field is 4 octets in length. Bits outside of the 848 Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type, 849 this field is fixed length. If the address is all zeros (i.e. 850 "0.0.0.0", then the Prefix-Length MUST be set to 32. 852 3.12. integer64 854 The "integer64" data type encodes a 64-bit unsigned integer in 855 network byte order. Where the range of values for a particular 856 attribute is limited to a sub-set of the values, specifications MUST 857 define the valid range(s). Attributes with Values outside of the 858 allowed range(s) SHOULD be treated as "invalid attributes". 860 Name 862 integer64 864 Value 866 12 868 Length 870 Eight octets 872 Format 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Value ... 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 ... Value | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 3.13. tlv 884 The "tlv" data type encodes a type-length-value, as defined in 885 [RFC6929] Section 2.3. 887 Name 889 tlv 891 Value 893 13 895 Length 897 Three or more octets 899 Format 901 0 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | TLV-Type | TLV-Length | TLV-Data ... 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 Subfields 909 TLV-Type 911 This field is one octet. Up-to-date values of this field are 912 specified according to the policies and rules described in 913 [RFC6929] Section 10. Values of 254-255 are "Reserved" for use 914 by future extensions to RADIUS. The value 26 has no special 915 meaning, and MUST NOT be treated as a Vendor Specific 916 attribute. 918 The TLV-Type is meaningful only within the context defined by 919 "Type" fields of the encapsulating Attributes, using the 920 dotted-number notation introduced in [RFC6929]. 922 A RADIUS server MAY ignore Attributes with an unknown "TLV- 923 Type". 925 A RADIUS client MAY ignore Attributes with an unknown "TLV- 926 Type". 928 A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- 929 Type" verbatim. 931 TLV-Length 933 The TLV-Length field is one octet, and indicates the length of 934 this TLV including the TLV-Type, TLV-Length and TLV-Value 935 fields. It MUST have a value between 3 and 255. If a client 936 or server receives a TLV with an invalid TLV-Length, then the 937 attribute which encapsulates that TLV MUST be considered to be 938 an "invalid attribute", and handled as per [RFC6929] Section 939 2.8. 941 TLVs having TLV-Length of two (2) MUST NOT be sent; omit the 942 entire TLV instead. 944 TLV-Data 946 The TLV-Data field is one or more octets and contains 947 information specific to the Attribute. The format and length 948 of the TLV-Data field is determined by the TLV-Type and TLV- 949 Length fields. 951 The TLV-Data field MUST contain only known RADIUS data types. 952 The TLV-Data field MUST NOT contain any of the following data 953 types: "concat", "vsa", "extended", "long-extended", or "evs". 955 3.14. vsa 957 The "vsa" data type encodes Vendor-Specific data, as given in 958 [RFC2865] Section 5.26. It is used only in the Attr-Data field of a 959 Vendor-Specific Attribute. It MUST NOT appear in the contents of any 960 other data type. 962 Where an implementation determines that an attribute of data type 963 "vsa" contains data which does not match the expected format, it 964 SHOULD treat that attribute as being an "invalid attribute". 966 Name 968 vsa 970 Value 972 14 974 Length 976 Five or more octets 978 Format 980 0 1 2 3 981 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 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Vendor-Id | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | VSA-Data .... 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 Subfields 990 Vendor-Id 992 The 4 octets are the Network Management Private Enterprise Code 993 [PEN] of the Vendor in network byte order. 995 VSA-Data 997 The VSA-Data field is one or more octets. The actual format of 998 the information is site or application specific, and a robust 999 implementation SHOULD support the field as undistinguished 1000 octets. 1002 The codification of the range of allowed usage of this field is 1003 outside the scope of this specification. 1005 The "vsa" data type SHOULD contain as a sequence of "tlv" data 1006 types. The interpretation of the TLV-Type and TLV-Data fields 1007 are dependent on the vendor's definition of that attribute. 1009 The "vsa" data type MUST be used as contents of the Attr-Data 1010 field of the Vendor-Specific attribute. The "vsa" data type 1011 MUST NOT appear in the contents of any other data type. 1013 3.15. extended 1015 The "extended" data type encodes the "Extended Type" format, as given 1016 in [RFC6929] Section 2.1. It is used only in the Attr-Data field of 1017 an Attribute allocated from the "standard space". It MUST NOT appear 1018 in the contents of any other data type. 1020 Name 1022 extended 1024 Value 1026 15 1028 Length 1030 Two or more octets 1032 Format 1034 0 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Extended-Type | Ext-Data ... 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 Subfields 1042 Extended-Type 1044 The Extended-Type field is one octet. Up-to-date values of 1045 this field are specified according to the policies and rules 1046 described in [RFC6929] Section 10. Unlike the Type field 1047 defined in [RFC2865] Section 5, no values are allocated for 1048 experimental or implementation-specific use. Values 241-255 1049 are reserved and MUST NOT be used. 1051 The Extended-Type is meaningful only within a context defined 1052 by the Type field. That is, this field may be thought of as 1053 defining a new type space of the form "Type.Extended-Type". 1054 See [RFC6929] Section 2.5 for additional discussion. 1056 A RADIUS server MAY ignore Attributes with an unknown 1057 "Type.Extended-Type". 1059 A RADIUS client MAY ignore Attributes with an unknown 1060 "Type.Extended-Type". 1062 Ext-Data 1064 The contents of this field MUST be a valid data type as defined 1065 in the RADIUS Data Type registry. The Ext-Data field MUST NOT 1066 contain any of the following data types: "concat", "vsa", 1067 "extended", "long-extended", or "evs". 1069 The Ext-Data field is one or more octets. 1071 Implementations supporting this specification MUST use the 1072 Identifier of "Type.Extended-Type" to determine the 1073 interpretation of the Ext-Data field. 1075 3.16. long-extended 1077 The "long-extended" data type encodes the "Long Extended Type" 1078 format, as given in [RFC6929] Section 2.2. It is used only in the 1079 Attr-Data field of an Attribute. It MUST NOT appear in the contents 1080 of any other data type. 1082 Name 1084 long-extended 1086 Value 1088 16 1090 Length 1092 Three or more octets 1094 Format 1096 0 1 2 3 1097 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 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | Extended-Type |M| Reserved | Ext-Data ... 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 Subfields 1105 Extended-Type 1107 This field is identical to the Extended-Type field defined 1108 above in Section 2.13. 1110 M (More) 1112 The More field is one (1) bit in length, and indicates whether 1113 or not the current attribute contains "more" than 251 octets of 1114 data. The More field MUST be clear (0) if the Length field has 1115 value less than 255. The More field MAY be set (1) if the 1116 Length field has value of 255. 1118 If the More field is set (1), it indicates that the Ext-Data 1119 field has been fragmented across multiple RADIUS attributes. 1120 When the More field is set (1), the attribute MUST have a 1121 Length field of value 255; there MUST be an attribute following 1122 this one; and the next attribute MUST have both the same Type 1123 and Extended Type. That is, multiple fragments of the same 1124 value MUST be in order and MUST be consecutive attributes in 1125 the packet, and the last attribute in a packet MUST NOT have 1126 the More field set (1). 1128 That is, a packet containing a fragmented attribute needs to 1129 contain all fragments of the attribute, and those fragments 1130 need to be contiguous in the packet. RADIUS does not support 1131 inter-packet fragmentation, which means that fragmenting an 1132 attribute across multiple packets is impossible. 1134 If a client or server receives an attribute fragment with the 1135 "More" field set (1), but for which no subsequent fragment can 1136 be found, then the fragmented attribute is considered to be an 1137 "invalid attribute", and handled as per [RFC6929] Section 2.8. 1139 Reserved 1141 This field is 7 bits long, and is reserved for future use. 1142 Implementations MUST set it to zero (0) when encoding an 1143 attribute for sending in a packet. The contents SHOULD be 1144 ignored on reception. 1146 Future specifications may define additional meaning for this 1147 field. Implementations therefore MUST NOT treat this field as 1148 invalid if it is non-zero. 1150 Ext-Data 1152 The contents of this field MUST be a valid data type as defined 1153 in the RADIUS Data Type registry. The Ext-Data field MUST NOT 1154 contain any of the following data types: "concat", "vsa", 1155 "extended", "long-extended", or "evs". 1157 The Ext-Data field is one or more octets. 1159 Implementations supporting this specification MUST use the 1160 Identifier of "Type.Extended-Type" to determine the 1161 interpretation of the Ext-Data field. 1163 The length of the data MUST be taken as the sum of the lengths 1164 of the fragments (i.e. Ext-Data fields) from which it is 1165 constructed. Any interpretation of the resulting data MUST 1166 occur after the fragments have been reassembled. If the 1167 reassembled data does not match the expected format, each 1168 fragment MUST be treated as an "invalid attribute", and the 1169 reassembled data MUST be discarded. 1171 We note that the maximum size of a fragmented attribute is 1172 limited only by the RADIUS packet length limitation. 1173 Implementations MUST be able to handle the case where one 1174 fragmented attribute completely fills the packet. 1176 3.17. evs 1178 The "evs" data type encodes an "Extended Vendor-Specific" attribute, 1179 as given in [RFC6929] Section 2.4. The "evs" data type is used 1180 solely to extend the Vendor Specific space. It MAY appear inside of 1181 an "extended" or a "long-extended" data type. It MUST NOT appear in 1182 the contents of any other data type. 1184 Where an implementation determines that an attribute of data type 1185 "evs" contains data which does not match the expected format, it 1186 SHOULD treat that attribute as being an "invalid attribute". 1188 Name 1190 evs 1192 Value 1193 17 1195 Length 1197 Six or more octets 1199 Format 1201 0 1 2 3 1202 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 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Vendor-Id | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | Vendor-Type | EVS-Data .... 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 Subfields 1211 Vendor-Id 1213 The 4 octets are the Network Management Private Enterprise Code 1214 [PEN] of the Vendor in network byte order. 1216 Vendor-Type 1218 The Vendor-Type field is one octet. Values are assigned at the 1219 sole discretion of the Vendor. 1221 EVS-Data 1223 The EVS-Data field is one or more octets. It SHOULD 1224 encapsulate a previously defined RADIUS data type. Non- 1225 standard data types SHOULD NOT be used. We note that the EVS- 1226 Data field may be of data type "tlv". 1228 The actual format of the information is site or application 1229 specific, and a robust implementation SHOULD support the field 1230 as undistinguished octets. We recognise that Vendors have 1231 complete control over the contents and format of the Ext-Data 1232 field, while at the same time recommending that good practices 1233 be followed. 1235 Further codification of the range of allowed usage of this 1236 field is outside the scope of this specification. 1238 4. Updated Registries 1240 This section defines a new IANA registry for RADIUS data types, and 1241 updates the existing RADIUS Attribute Type registry. 1243 4.1. Create a Data Type Registry 1245 This section defines a new RADIUS registry, called "Data Type". 1246 Allocation in this registry requires IETF Review. The "Registration 1247 Procedures" for this registry are "Standards Action". 1249 The registry contains three columns of data, as follows. 1251 Value 1253 The number of the data type. The value field is an artifact of 1254 the registry, and has no on-the-wire meaning. 1256 Description 1258 The name of the data type. The name field is used only for the 1259 registry, and has no on-the-wire meaning. 1261 Reference 1263 The specification where the data type was defined. 1265 The initial contents of the registry are as follows. 1267 Value Description Reference 1268 ----- ----------- ---------------- 1269 1 integer [RFC2865], TBD 1270 2 enum [RFC2865], TBD 1271 3 time [RFC2865], TBD 1272 4 text [RFC2865], TBD 1273 5 string [RFC2865], TBD 1274 6 concat TBD 1275 7 ifid [RFC3162], TBD 1276 8 ipv4addr [RFC2865], TBD 1277 9 ipv6addr [RFC3162], TBD 1278 10 ipv6prefix [RFC3162], TBD 1279 11 ipv4prefix [RFC6572], TBD 1280 12 integer64 [RFC6929], TBD 1281 13 tlv [RFC6929], TBD 1282 14 evs [RFC6929], TBD 1283 15 extended [RFC6929], TBD 1284 16 long-extended [RFC6929], TBD 1286 4.2. Updates to the Attribute Type Registry 1288 This section updates the RADIUS Attribute Type Registry to have a new 1289 column, which is inserted in between the existing "Description" and 1290 "Reference" columns. The new column is named "Data Type". The 1291 contents of that column are the name of a data type, corresponding to 1292 the attribute in that row, or blank if the attribute type is 1293 unassigned. The name of the data type is taken from the RADIUS Data 1294 Type registry, defined above. 1296 The updated registry follows in CSV format. 1298 Value,Description,Data Type,Reference 1299 1,User-Name,text,[RFC2865] 1300 2,User-Password,string,[RFC2865] 1301 3,CHAP-Password,string,[RFC2865] 1302 4,NAS-IP-Address,ipv4addr,[RFC2865] 1303 5,NAS-Port,integer,[RFC2865] 1304 6,Service-Type,enum,[RFC2865] 1305 7,Framed-Protocol,enum,[RFC2865] 1306 8,Framed-IP-Address,ipv4addr,[RFC2865] 1307 9,Framed-IP-Netmask,ipv4addr,[RFC2865] 1308 10,Framed-Routing,enum,[RFC2865] 1309 11,Filter-Id,text,[RFC2865] 1310 12,Framed-MTU,integer,[RFC2865] 1311 13,Framed-Compression,enum,[RFC2865] 1312 14,Login-IP-Host,ipv4addr,[RFC2865] 1313 15,Login-Service,enum,[RFC2865] 1314 16,Login-TCP-Port,integer,[RFC2865] 1315 17,Unassigned,, 1316 18,Reply-Message,text,[RFC2865] 1317 19,Callback-Number,text,[RFC2865] 1318 20,Callback-Id,text,[RFC2865] 1319 21,Unassigned,, 1320 22,Framed-Route,text,[RFC2865] 1321 23,Framed-IPX-Network,ipv4addr,[RFC2865] 1322 24,State,string,[RFC2865] 1323 25,Class,string,[RFC2865] 1324 26,Vendor-Specific,vsa,[RFC2865] 1325 27,Session-Timeout,integer,[RFC2865] 1326 28,Idle-Timeout,integer,[RFC2865] 1327 29,Termination-Action,enum,[RFC2865] 1328 30,Called-Station-Id,text,[RFC2865] 1329 31,Calling-Station-Id,text,[RFC2865] 1330 32,NAS-Identifier,text,[RFC2865] 1331 33,Proxy-State,string,[RFC2865] 1332 34,Login-LAT-Service,text,[RFC2865] 1333 35,Login-LAT-Node,text,[RFC2865] 1334 36,Login-LAT-Group,string,[RFC2865] 1335 37,Framed-AppleTalk-Link,integer,[RFC2865] 1336 38,Framed-AppleTalk-Network,integer,[RFC2865] 1337 39,Framed-AppleTalk-Zone,text,[RFC2865] 1338 40,Acct-Status-Type,enum,[RFC2866] 1339 41,Acct-Delay-Time,integer,[RFC2866] 1340 42,Acct-Input-Octets,integer,[RFC2866] 1341 43,Acct-Output-Octets,integer,[RFC2866] 1342 44,Acct-Session-Id,text,[RFC2866] 1343 45,Acct-Authentic,enum,[RFC2866] 1344 46,Acct-Session-Time,integer,[RFC2866] 1345 47,Acct-Input-Packets,integer,[RFC2866] 1346 48,Acct-Output-Packets,integer,[RFC2866] 1347 49,Acct-Terminate-Cause,enum,[RFC2866] 1348 50,Acct-Multi-Session-Id,text,[RFC2866] 1349 51,Acct-Link-Count,integer,[RFC2866] 1350 52,Acct-Input-Gigawords,integer,[RFC2869] 1351 53,Acct-Output-Gigawords,integer,[RFC2869] 1352 54,Unassigned,, 1353 55,Event-Timestamp,time,[RFC2869] 1354 56,Egress-VLANID,integer,[RFC4675] 1355 57,Ingress-Filters,enum,[RFC4675] 1356 58,Egress-VLAN-Name,text,[RFC4675] 1357 59,User-Priority-Table,string,[RFC4675] 1358 60,CHAP-Challenge,string,[RFC2865] 1359 61,NAS-Port-Type,enum,[RFC2865] 1360 62,Port-Limit,integer,[RFC2865] 1361 63,Login-LAT-Port,text,[RFC2865] 1362 64,Tunnel-Type,enum,[RFC2868] 1363 65,Tunnel-Medium-Type,enum,[RFC2868] 1364 66,Tunnel-Client-Endpoint,text,[RFC2868] 1365 67,Tunnel-Server-Endpoint,text,[RFC2868] 1366 68,Acct-Tunnel-Connection,text,[RFC2867] 1367 69,Tunnel-Password,string,[RFC2868] 1368 70,ARAP-Password,string,[RFC2869] 1369 71,ARAP-Features,string,[RFC2869] 1370 72,ARAP-Zone-Access,enum,[RFC2869] 1371 73,ARAP-Security,integer,[RFC2869] 1372 74,ARAP-Security-Data,text,[RFC2869] 1373 75,Password-Retry,integer,[RFC2869] 1374 76,Prompt,enum,[RFC2869] 1375 77,Connect-Info,text,[RFC2869] 1376 78,Configuration-Token,text,[RFC2869] 1377 79,EAP-Message,concat,[RFC2869] 1378 80,Message-Authenticator,string,[RFC2869] 1379 81,Tunnel-Private-Group-ID,text,[RFC2868] 1380 82,Tunnel-Assignment-ID,text,[RFC2868] 1381 83,Tunnel-Preference,integer,[RFC2868] 1382 84,ARAP-Challenge-Response,string,[RFC2869] 1383 85,Acct-Interim-Interval,integer,[RFC2869] 1384 86,Acct-Tunnel-Packets-Lost,integer,[RFC2867] 1385 87,NAS-Port-Id,text,[RFC2869] 1386 88,Framed-Pool,text,[RFC2869] 1387 89,CUI,string,[RFC4372] 1388 90,Tunnel-Client-Auth-ID,text,[RFC2868] 1389 91,Tunnel-Server-Auth-ID,text,[RFC2868] 1390 92,NAS-Filter-Rule,text,[RFC4849] 1391 93,Unassigned,, 1392 94,Originating-Line-Info,string,[RFC7155] 1393 95,NAS-IPv6-Address,ipv6addr,[RFC3162] 1394 96,Framed-Interface-Id,ifid,[RFC3162] 1395 97,Framed-IPv6-Prefix,ipv6prefix,[RFC3162] 1396 98,Login-IPv6-Host,ipv6addr,[RFC3162] 1397 99,Framed-IPv6-Route,text,[RFC3162] 1398 100,Framed-IPv6-Pool,text,[RFC3162] 1399 101,Error-Cause Attribute,enum,[RFC3576] 1400 102,EAP-Key-Name,string,[RFC4072][RFC7268] 1401 103,Digest-Response,text,[RFC5090] 1402 104,Digest-Realm,text,[RFC5090] 1403 105,Digest-Nonce,text,[RFC5090] 1404 106,Digest-Response-Auth,text,[RFC5090] 1405 107,Digest-Nextnonce,text,[RFC5090] 1406 108,Digest-Method,text,[RFC5090] 1407 109,Digest-URI,text,[RFC5090] 1408 110,Digest-Qop,text,[RFC5090] 1409 111,Digest-Algorithm,text,[RFC5090] 1410 112,Digest-Entity-Body-Hash,text,[RFC5090] 1411 113,Digest-CNonce,text,[RFC5090] 1412 114,Digest-Nonce-Count,text,[RFC5090] 1413 115,Digest-Username,text,[RFC5090] 1414 116,Digest-Opaque,text,[RFC5090] 1415 117,Digest-Auth-Param,text,[RFC5090] 1416 118,Digest-AKA-Auts,text,[RFC5090] 1417 119,Digest-Domain,text,[RFC5090] 1418 120,Digest-Stale,text,[RFC5090] 1419 121,Digest-HA1,text,[RFC5090] 1420 122,SIP-AOR,text,[RFC5090] 1421 123,Delegated-IPv6-Prefix,ipv6prefix,[RFC4818] 1422 124,MIP6-Feature-Vector,string,[RFC5447] 1423 125,MIP6-Home-Link-Prefix,ipv6prefix,[RFC5447] 1424 126,Operator-Name,text,[RFC5580] 1425 127,Location-Information,string,[RFC5580] 1426 128,Location-Data,string,[RFC5580] 1427 129,Basic-Location-Policy-Rules,string,[RFC5580] 1428 130,Extended-Location-Policy-Rules,string,[RFC5580] 1429 131,Location-Capable,enum,[RFC5580] 1430 132,Requested-Location-Info,enum,[RFC5580] 1431 133,Framed-Management-Protocol,enum,[RFC5607] 1432 134,Management-Transport-Protection,enum,[RFC5607] 1433 135,Management-Policy-Id,text,[RFC5607] 1434 136,Management-Privilege-Level,integer,[RFC5607] 1435 137,PKM-SS-Cert,concat,[RFC5904] 1436 138,PKM-CA-Cert,concat,[RFC5904] 1437 139,PKM-Config-Settings,string,[RFC5904] 1438 140,PKM-Cryptosuite-List,string,[RFC5904] 1439 141,PKM-SAID,text,[RFC5904] 1440 142,PKM-SA-Descriptor,string,[RFC5904] 1441 143,PKM-Auth-Key,string,[RFC5904] 1442 144,DS-Lite-Tunnel-Name,text,[RFC6519] 1443 145,Mobile-Node-Identifier,string,[RFC6572] 1444 146,Service-Selection,text,[RFC6572] 1445 147,PMIP6-Home-LMA-IPv6-Address,ipv6addr,[RFC6572] 1446 148,PMIP6-Visited-LMA-IPv6-Address,ipv6addr,[RFC6572] 1447 149,PMIP6-Home-LMA-IPv4-Address,ipv4addr,[RFC6572] 1448 150,PMIP6-Visited-LMA-IPv4-Address,ipv4addr,[RFC6572] 1449 151,PMIP6-Home-HN-Prefix,ipv6prefix,[RFC6572] 1450 152,PMIP6-Visited-HN-Prefix,ipv6prefix,[RFC6572] 1451 153,PMIP6-Home-Interface-ID,ifid,[RFC6572] 1452 154,PMIP6-Visited-Interface-ID,ifid,[RFC6572] 1453 155,PMIP6-Home-IPv4-HoA,ipv4prefix,[RFC6572] 1454 156,PMIP6-Visited-IPv4-HoA,ipv4prefix,[RFC6572] 1455 157,PMIP6-Home-DHCP4-Server-Address,ipv4addr,[RFC6572] 1456 158,PMIP6-Visited-DHCP4-Server-Address,ipv4addr,[RFC6572] 1457 159,PMIP6-Home-DHCP6-Server-Address,ipv6addr,[RFC6572] 1458 160,PMIP6-Visited-DHCP6-Server-Address,ipv6addr,[RFC6572] 1459 161,PMIP6-Home-IPv4-Gateway,ipv4addr,[RFC6572] 1460 162,PMIP6-Visited-IPv4-Gateway,ipv4addr,[RFC6572] 1461 163,EAP-Lower-Layer,enum,[RFC6677] 1462 164,GSS-Acceptor-Service-Name,text,[RFC7055] 1463 165,GSS-Acceptor-Host-Name,text,[RFC7055] 1464 166,GSS-Acceptor-Service-Specifics,text,[RFC7055] 1465 167,GSS-Acceptor-Realm-Name,text,[RFC7055] 1466 168,Framed-IPv6-Address,ipv6addr,[RFC6911] 1467 169,DNS-Server-IPv6-Address,ipv6addr,[RFC6911] 1468 170,Route-IPv6-Information,ipv6prefix,[RFC6911] 1469 171,Delegated-IPv6-Prefix-Pool,text,[RFC6911] 1470 172,Stateful-IPv6-Address-Pool,text,[RFC6911] 1471 173,IPv6-6rd-Configuration,tlv,[RFC6930] 1472 174,Allowed-Called-Station-Id,text,[RFC7268] 1473 175,EAP-Peer-Id,string,[RFC7268] 1474 176,EAP-Server-Id,string,[RFC7268] 1475 177,Mobility-Domain-Id,integer,[RFC7268] 1476 178,Preauth-Timeout,integer,[RFC7268] 1477 179,Network-Id-Name,string,[RFC7268] 1478 180,EAPoL-Announcement,concat,[RFC7268] 1479 181,WLAN-HESSID,text,[RFC7268] 1480 182,WLAN-Venue-Info,integer,[RFC7268] 1481 183,WLAN-Venue-Language,string,[RFC7268] 1482 184,WLAN-Venue-Name,text,[RFC7268] 1483 185,WLAN-Reason-Code,integer,[RFC7268] 1484 186,WLAN-Pairwise-Cipher,integer,[RFC7268] 1485 187,WLAN-Group-Cipher,integer,[RFC7268] 1486 188,WLAN-AKM-Suite,integer,[RFC7268] 1487 189,WLAN-Group-Mgmt-Cipher,integer,[RFC7268] 1488 190,WLAN-RF-Band,integer,[RFC7268] 1489 191,Unassigned,, 1490 192-223,Experimental Use,,[RFC3575] 1491 224-240,Implementation Specific,,[RFC3575] 1492 241,Extended-Attribute-1,extended,[RFC6929] 1493 241.1,Frag-Status,integer,[RFC7499] 1494 241.2,Proxy-State-Length,integer,[RFC7499] 1495 241.{3-25},Unassigned,, 1496 241.26,Extended-Vendor-Specific-1,evs,[RFC6929] 1497 241.{27-240},Unassigned,, 1498 241.{241-255},Reserved,,[RFC6929] 1499 242,Extended-Attribute-2,extended,[RFC6929] 1500 242.{1-25},Unassigned,, 1501 242.26,Extended-Vendor-Specific-2,evs,[RFC6929] 1502 242.{27-240},Unassigned,, 1503 242.{241-255},Reserved,,[RFC6929] 1504 243,Extended-Attribute-3,extended,[RFC6929] 1505 243.{1-25},Unassigned,, 1506 243.26,Extended-Vendor-Specific-3,evs,[RFC6929] 1507 243.{27-240},Unassigned,, 1508 243.{241-255},Reserved,,[RFC6929] 1509 244,Extended-Attribute-4,extended,[RFC6929] 1510 244.{1-25},Unassigned,, 1511 244.26,Extended-Vendor-Specific-4,evs,[RFC6929] 1512 244.{27-240},Unassigned,, 1513 244.{241-255},Reserved,,[RFC6929] 1514 245,Extended-Attribute-5,long-extended,[RFC6929] 1515 245.{1-25},Unassigned,, 1516 245.26,Extended-Vendor-Specific-5,evs,[RFC6929] 1517 245.{27-240},Unassigned,, 1518 245.{241-255},Reserved,,[RFC6929] 1519 246,Extended-Attribute-6,long-extended,[RFC6929] 1520 246.{1-25},Unassigned,, 1521 246.26,Extended-Vendor-Specific-6,evs,[RFC6929] 1522 246.{27-240},Unassigned,, 1523 246.{241-255},Reserved,,[RFC6929] 1524 247-255,Reserved,,[RFC3575] 1526 5. Security Considerations 1528 This specification is concerned solely with updates to IANA 1529 registries. As such, there are no security considerations with the 1530 document itself. 1532 However, the use of inconsistent names and poorly-defined entities in 1533 a protocol is problematic. Inconsistencies in specifications can 1534 lead to security and interoperability problems in implementations. 1535 Further, having one canonical source for the definition of data types 1536 means an implementor has fewer specifications to read. The 1537 implementation work is therefore simpler, and is more likely to be 1538 correct. 1540 The goal of this specification is to reduce ambiguities in the RADIUS 1541 protocol, which we believe will lead to more robust and more secure 1542 implementations. 1544 6. IANA Considerations 1546 IANA is instructed to create one new registry as described above in 1547 Section 4.1. The "TBD" text in that section should be replaced with 1548 the RFC number of this document when it is published. 1550 IANA is instructed to update the RADIUS Attribute Type registry, as 1551 described above in Section 4.2. 1553 IANA is instructed to require that all allocation requests in the 1554 RADIUS Attribute Type Registry contain a "Data Type" field. That 1555 field is required to contain one of the "Data Type" names contained 1556 in the RADIUS Data Type registry. 1558 IANA is instructed to require that updates to the RADIUS Data Type 1559 registry contain the following fields, with the associated 1560 instructions: 1562 * Value. IANA is instructed to assign the next unused integer in 1563 sequence to new data type definitions. 1565 * Name. IANA is instructed to require that this name be unique 1566 in the registry. 1568 * Reference. IANA is instructed to update this field with a 1569 reference 1570 to the document which defines the data type. 1572 7. References 1574 7.1. Normative References 1576 [RFC2119] 1577 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1578 Levels", RFC 2119, March, 1997. 1580 [RFC2865] 1581 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1582 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1584 [RFC3162] 1585 Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, 1586 August 2001. 1588 [RFC3629] 1589 Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1590 3629, November 2003. 1592 [RFC4072] 1593 Eronen, P., et al, "Diameter Extensible Authentication Protocol 1594 (EAP) Application", RFC 4072, February 2013. 1596 [RFC6158] 1597 DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 6158, 1598 March 2011. 1600 [RFC6572] 1601 Xia, F., et al, "RADIUS Support for Proxy Mobile IPv6", RFC 6572, 1602 June 2012. 1604 7.2. Informative References 1606 [RFC2868] 1607 Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. 1608 Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 1609 June 2000. 1611 [RFC2869] 1612 Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000. 1614 [RFC6929] 1615 DeKok, A., and Lior, A., "Remote Authentication Dial In User 1616 Service (RADIUS) Protocol Extensions", RFC 6929, April 2013. 1618 [RFC7268] 1619 Aboba, B, et al, "RADIUS Attributes for IEEE 802 Networks", RFC 1620 7268, July 2015. 1622 [RFC7499] 1623 Perez-Mendez A., et al, "Support of Fragmentation of RADIUS 1624 Packets", RFC 7499, April 2015. 1626 [PEN] 1627 http://www.iana.org/assignments/enterprise-numbers 1629 Acknowledgments 1631 Thanks to the RADEXT WG for patience and reviews of this document. 1633 Authors' Addresses 1635 Alan DeKok 1636 The FreeRADIUS Server Project 1638 Email: aland@freeradius.org