idnits 2.17.1 draft-ietf-radext-datatypes-04.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 (22 June 2016) is 2864 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 1637, 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 22 June 2016 9 Data Types in the Remote Authentication 10 Dial-In User Service Protocol (RADIUS) 11 draft-ietf-radext-datatypes-04.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 January 22, 2017. 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 .......................................... 21 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 ................................................ 28 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 .............................. 37 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 essentially 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. This field is one octet in length. 841 Note that this definition differs from that given in [RFC6572]. 842 See Prefix-Length, below, for an explanation. 844 Prefix-Length 846 The length of the prefix, in bits. The values MUST be no 847 larger than 32. This field is one octet in length. 849 Note that this definition differs from that given in [RFC6572]. 851 As compared to [RFC6572], the Prefix-Length field has increased 852 in size by two bits, both of which must be zero. The Reserved 853 field has decreased in size by two bits. The result is that 854 both fields are aligned on octet boundaries, which removes the 855 need for bit masking of the fields. 857 Since [RFC6572] required the Reserved field to be zero, the 858 definition here is compatible with the definition in the 859 original specification. 861 Prefix 863 The Prefix field is 4 octets in length. Bits outside of the 864 Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type, 865 this field is fixed length. If the address is all zeros (i.e. 866 "0.0.0.0", then the Prefix-Length MUST be set to 32. 868 3.12. integer64 870 The "integer64" data type encodes a 64-bit unsigned integer in 871 network byte order. Where the range of values for a particular 872 attribute is limited to a sub-set of the values, specifications MUST 873 define the valid range(s). Attributes with Values outside of the 874 allowed range(s) SHOULD be treated as "invalid attributes". 876 Name 878 integer64 880 Value 882 12 884 Length 886 Eight octets 888 Format 890 0 1 2 3 891 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 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Value ... 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 ... Value | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 3.13. tlv 900 The "tlv" data type encodes a type-length-value, as defined in 901 [RFC6929] Section 2.3. 903 Name 905 tlv 907 Value 909 13 911 Length 913 Three or more octets 915 Format 917 0 1 2 3 918 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 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | TLV-Type | TLV-Length | TLV-Data ... 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 Subfields 925 TLV-Type 927 This field is one octet. Up-to-date values of this field are 928 specified according to the policies and rules described in 929 [RFC6929] Section 10. Values of 254-255 are "Reserved" for use 930 by future extensions to RADIUS. The value 26 has no special 931 meaning, and MUST NOT be treated as a Vendor Specific 932 attribute. 934 The TLV-Type is meaningful only within the context defined by 935 "Type" fields of the encapsulating Attributes, using the 936 dotted-number notation introduced in [RFC6929]. 938 A RADIUS server MAY ignore Attributes with an unknown "TLV- 939 Type". 941 A RADIUS client MAY ignore Attributes with an unknown "TLV- 942 Type". 944 A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- 945 Type" verbatim. 947 TLV-Length 949 The TLV-Length field is one octet, and indicates the length of 950 this TLV including the TLV-Type, TLV-Length and TLV-Value 951 fields. It MUST have a value between 3 and 255. If a client 952 or server receives a TLV with an invalid TLV-Length, then the 953 attribute which encapsulates that TLV MUST be considered to be 954 an "invalid attribute", and handled as per [RFC6929] Section 955 2.8. 957 TLVs having TLV-Length of two (2) MUST NOT be sent; omit the 958 entire TLV instead. 960 TLV-Data 962 The TLV-Data field is one or more octets and contains 963 information specific to the Attribute. The format and length 964 of the TLV-Data field is determined by the TLV-Type and TLV- 965 Length fields. 967 The TLV-Data field MUST contain only known RADIUS data types. 968 The TLV-Data field MUST NOT contain any of the following data 969 types: "concat", "vsa", "extended", "long-extended", or "evs". 971 3.14. vsa 973 The "vsa" data type encodes Vendor-Specific data, as given in 974 [RFC2865] Section 5.26. It is used only in the Attr-Data field of a 975 Vendor-Specific Attribute. It MUST NOT appear in the contents of any 976 other data type. 978 Where an implementation determines that an attribute of data type 979 "vsa" contains data which does not match the expected format, it 980 SHOULD treat that attribute as being an "invalid attribute". 982 Name 984 vsa 986 Value 988 14 990 Length 992 Five or more octets 994 Format 996 0 1 2 3 997 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 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Vendor-Id | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | VSA-Data .... 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 Subfields 1007 Vendor-Id 1009 The 4 octets are the Network Management Private Enterprise Code 1010 [PEN] of the Vendor in network byte order. 1012 VSA-Data 1014 The VSA-Data field is one or more octets. The actual format of 1015 the information is site or application specific, and a robust 1016 implementation SHOULD support the field as undistinguished 1017 octets. 1019 The codification of the range of allowed usage of this field is 1020 outside the scope of this specification. 1022 The "vsa" data type SHOULD contain as a sequence of "tlv" data 1023 types. The interpretation of the TLV-Type and TLV-Data fields 1024 are dependent on the vendor's definition of that attribute. 1026 The "vsa" data type MUST be used as contents of the Attr-Data 1027 field of the Vendor-Specific attribute. The "vsa" data type 1028 MUST NOT appear in the contents of any other data type. 1030 3.15. extended 1032 The "extended" data type encodes the "Extended Type" format, as given 1033 in [RFC6929] Section 2.1. It is used only in the Attr-Data field of 1034 an Attribute allocated from the "standard space". It MUST NOT appear 1035 in the contents of any other data type. 1037 Name 1039 extended 1041 Value 1043 15 1045 Length 1047 Two or more octets 1049 Format 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Extended-Type | Ext-Data ... 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 Subfields 1058 Extended-Type 1060 The Extended-Type field is one octet. Up-to-date values of 1061 this field are specified according to the policies and rules 1062 described in [RFC6929] Section 10. Unlike the Type field 1063 defined in [RFC2865] Section 5, no values are allocated for 1064 experimental or implementation-specific use. Values 241-255 1065 are reserved and MUST NOT be used. 1067 The Extended-Type is meaningful only within a context defined 1068 by the Type field. That is, this field may be thought of as 1069 defining a new type space of the form "Type.Extended-Type". 1070 See [RFC6929] Section 2.5 for additional discussion. 1072 A RADIUS server MAY ignore Attributes with an unknown 1073 "Type.Extended-Type". 1075 A RADIUS client MAY ignore Attributes with an unknown 1076 "Type.Extended-Type". 1078 Ext-Data 1080 The contents of this field MUST be a valid data type as defined 1081 in the RADIUS Data Type registry. The Ext-Data field MUST NOT 1082 contain any of the following data types: "concat", "vsa", 1083 "extended", "long-extended", or "evs". 1085 The Ext-Data field is one or more octets. 1087 Implementations supporting this specification MUST use the 1088 Identifier of "Type.Extended-Type" to determine the 1089 interpretation of the Ext-Data field. 1091 3.16. long-extended 1093 The "long-extended" data type encodes the "Long Extended Type" 1094 format, as given in [RFC6929] Section 2.2. It is used only in the 1095 Attr-Data field of an Attribute. It MUST NOT appear in the contents 1096 of any other data type. 1098 Name 1100 long-extended 1102 Value 1104 16 1106 Length 1108 Three or more octets 1110 Format 1112 0 1 2 3 1113 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 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Extended-Type |M| Reserved | Ext-Data ... 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 Subfields 1120 Extended-Type 1122 This field is identical to the Extended-Type field defined 1123 above in Section 2.13. 1125 M (More) 1127 The More field is one (1) bit in length, and indicates whether 1128 or not the current attribute contains "more" than 251 octets of 1129 data. The More field MUST be clear (0) if the Length field has 1130 value less than 255. The More field MAY be set (1) if the 1131 Length field has value of 255. 1133 If the More field is set (1), it indicates that the Ext-Data 1134 field has been fragmented across multiple RADIUS attributes. 1135 When the More field is set (1), the attribute MUST have a 1136 Length field of value 255; there MUST be an attribute following 1137 this one; and the next attribute MUST have both the same Type 1138 and Extended Type. That is, multiple fragments of the same 1139 value MUST be in order and MUST be consecutive attributes in 1140 the packet, and the last attribute in a packet MUST NOT have 1141 the More field set (1). 1143 That is, a packet containing a fragmented attribute needs to 1144 contain all fragments of the attribute, and those fragments 1145 need to be contiguous in the packet. RADIUS does not support 1146 inter-packet fragmentation, which means that fragmenting an 1147 attribute across multiple packets is impossible. 1149 If a client or server receives an attribute fragment with the 1150 "More" field set (1), but for which no subsequent fragment can 1151 be found, then the fragmented attribute is considered to be an 1152 "invalid attribute", and handled as per [RFC6929] Section 2.8. 1154 Reserved 1156 This field is 7 bits long, and is reserved for future use. 1157 Implementations MUST set it to zero (0) when encoding an 1158 attribute for sending in a packet. The contents SHOULD be 1159 ignored on reception. 1161 Future specifications may define additional meaning for this 1162 field. Implementations therefore MUST NOT treat this field as 1163 invalid if it is non-zero. 1165 Ext-Data 1167 The contents of this field MUST be a valid data type as defined 1168 in the RADIUS Data Type registry. The Ext-Data field MUST NOT 1169 contain any of the following data types: "concat", "vsa", 1170 "extended", "long-extended", or "evs". 1172 The Ext-Data field is one or more octets. 1174 Implementations supporting this specification MUST use the 1175 Identifier of "Type.Extended-Type" to determine the 1176 interpretation of the Ext-Data field. 1178 The length of the data MUST be taken as the sum of the lengths 1179 of the fragments (i.e. Ext-Data fields) from which it is 1180 constructed. Any interpretation of the resulting data MUST 1181 occur after the fragments have been reassembled. If the 1182 reassembled data does not match the expected format, each 1183 fragment MUST be treated as an "invalid attribute", and the 1184 reassembled data MUST be discarded. 1186 We note that the maximum size of a fragmented attribute is 1187 limited only by the RADIUS packet length limitation. 1188 Implementations MUST be able to handle the case where one 1189 fragmented attribute completely fills the packet. 1191 3.17. evs 1193 The "evs" data type encodes an "Extended Vendor-Specific" attribute, 1194 as given in [RFC6929] Section 2.4. The "evs" data type is used 1195 solely to extend the Vendor Specific space. It MAY appear inside of 1196 an "extended" or a "long-extended" data type. It MUST NOT appear in 1197 the contents of any other data type. 1199 Where an implementation determines that an attribute of data type 1200 "evs" contains data which does not match the expected format, it 1201 SHOULD treat that attribute as being an "invalid attribute". 1203 Name 1205 evs 1207 Value 1209 17 1211 Length 1213 Six or more octets 1215 Format 1217 0 1 2 3 1218 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 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | Vendor-Id | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | Vendor-Type | EVS-Data .... 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 Subfields 1227 Vendor-Id 1229 The 4 octets are the Network Management Private Enterprise Code 1230 [PEN] of the Vendor in network byte order. 1232 Vendor-Type 1234 The Vendor-Type field is one octet. Values are assigned at the 1235 sole discretion of the Vendor. 1237 EVS-Data 1238 The EVS-Data field is one or more octets. It SHOULD 1239 encapsulate a previously defined RADIUS data type. Non- 1240 standard data types SHOULD NOT be used. We note that the EVS- 1241 Data field may be of data type "tlv". 1243 The actual format of the information is site or application 1244 specific, and a robust implementation SHOULD support the field 1245 as undistinguished octets. We recognise that Vendors have 1246 complete control over the contents and format of the Ext-Data 1247 field, while at the same time recommending that good practices 1248 be followed. 1250 Further codification of the range of allowed usage of this 1251 field is outside the scope of this specification. 1253 4. Updated Registries 1255 This section defines a new IANA registry for RADIUS data types, and 1256 updates the existing RADIUS Attribute Type registry. 1258 4.1. Create a Data Type Registry 1260 This section defines a new RADIUS registry, called "Data Type". 1261 Allocation in this registry requires IETF Review. The "Registration 1262 Procedures" for this registry are "Standards Action". 1264 The registry contains three columns of data, as follows. 1266 Value 1268 The number of the data type. The value field is an artifact of 1269 the registry, and has no on-the-wire meaning. 1271 Description 1273 The name of the data type. The name field is used only for the 1274 registry, and has no on-the-wire meaning. 1276 Reference 1278 The specification where the data type was defined. 1280 The initial contents of the registry are as follows. 1282 Value Description Reference 1283 ----- ----------- ---------------- 1284 1 integer [RFC2865], TBD 1285 2 enum [RFC2865], TBD 1286 3 time [RFC2865], TBD 1287 4 text [RFC2865], TBD 1288 5 string [RFC2865], TBD 1289 6 concat TBD 1290 7 ifid [RFC3162], TBD 1291 8 ipv4addr [RFC2865], TBD 1292 9 ipv6addr [RFC3162], TBD 1293 10 ipv6prefix [RFC3162], TBD 1294 11 ipv4prefix [RFC6572], TBD 1295 12 integer64 [RFC6929], TBD 1296 13 tlv [RFC6929], TBD 1297 14 evs [RFC6929], TBD 1298 15 extended [RFC6929], TBD 1299 16 long-extended [RFC6929], TBD 1301 4.2. Updates to the Attribute Type Registry 1303 This section updates the RADIUS Attribute Type Registry to have a new 1304 column, which is inserted in between the existing "Description" and 1305 "Reference" columns. The new column is named "Data Type". The 1306 contents of that column are the name of a data type, corresponding to 1307 the attribute in that row, or blank if the attribute type is 1308 unassigned. The name of the data type is taken from the RADIUS Data 1309 Type registry, defined above. 1311 The updated registry follows in CSV format. 1313 Value,Description,Data Type,Reference 1314 1,User-Name,text,[RFC2865] 1315 2,User-Password,string,[RFC2865] 1316 3,CHAP-Password,string,[RFC2865] 1317 4,NAS-IP-Address,ipv4addr,[RFC2865] 1318 5,NAS-Port,integer,[RFC2865] 1319 6,Service-Type,enum,[RFC2865] 1320 7,Framed-Protocol,enum,[RFC2865] 1321 8,Framed-IP-Address,ipv4addr,[RFC2865] 1322 9,Framed-IP-Netmask,ipv4addr,[RFC2865] 1323 10,Framed-Routing,enum,[RFC2865] 1324 11,Filter-Id,text,[RFC2865] 1325 12,Framed-MTU,integer,[RFC2865] 1326 13,Framed-Compression,enum,[RFC2865] 1327 14,Login-IP-Host,ipv4addr,[RFC2865] 1328 15,Login-Service,enum,[RFC2865] 1329 16,Login-TCP-Port,integer,[RFC2865] 1330 17,Unassigned,, 1331 18,Reply-Message,text,[RFC2865] 1332 19,Callback-Number,text,[RFC2865] 1333 20,Callback-Id,text,[RFC2865] 1334 21,Unassigned,, 1335 22,Framed-Route,text,[RFC2865] 1336 23,Framed-IPX-Network,ipv4addr,[RFC2865] 1337 24,State,string,[RFC2865] 1338 25,Class,string,[RFC2865] 1339 26,Vendor-Specific,vsa,[RFC2865] 1340 27,Session-Timeout,integer,[RFC2865] 1341 28,Idle-Timeout,integer,[RFC2865] 1342 29,Termination-Action,enum,[RFC2865] 1343 30,Called-Station-Id,text,[RFC2865] 1344 31,Calling-Station-Id,text,[RFC2865] 1345 32,NAS-Identifier,text,[RFC2865] 1346 33,Proxy-State,string,[RFC2865] 1347 34,Login-LAT-Service,text,[RFC2865] 1348 35,Login-LAT-Node,text,[RFC2865] 1349 36,Login-LAT-Group,string,[RFC2865] 1350 37,Framed-AppleTalk-Link,integer,[RFC2865] 1351 38,Framed-AppleTalk-Network,integer,[RFC2865] 1352 39,Framed-AppleTalk-Zone,text,[RFC2865] 1353 40,Acct-Status-Type,enum,[RFC2866] 1354 41,Acct-Delay-Time,integer,[RFC2866] 1355 42,Acct-Input-Octets,integer,[RFC2866] 1356 43,Acct-Output-Octets,integer,[RFC2866] 1357 44,Acct-Session-Id,text,[RFC2866] 1358 45,Acct-Authentic,enum,[RFC2866] 1359 46,Acct-Session-Time,integer,[RFC2866] 1360 47,Acct-Input-Packets,integer,[RFC2866] 1361 48,Acct-Output-Packets,integer,[RFC2866] 1362 49,Acct-Terminate-Cause,enum,[RFC2866] 1363 50,Acct-Multi-Session-Id,text,[RFC2866] 1364 51,Acct-Link-Count,integer,[RFC2866] 1365 52,Acct-Input-Gigawords,integer,[RFC2869] 1366 53,Acct-Output-Gigawords,integer,[RFC2869] 1367 54,Unassigned,, 1368 55,Event-Timestamp,time,[RFC2869] 1369 56,Egress-VLANID,integer,[RFC4675] 1370 57,Ingress-Filters,enum,[RFC4675] 1371 58,Egress-VLAN-Name,text,[RFC4675] 1372 59,User-Priority-Table,string,[RFC4675] 1373 60,CHAP-Challenge,string,[RFC2865] 1374 61,NAS-Port-Type,enum,[RFC2865] 1375 62,Port-Limit,integer,[RFC2865] 1376 63,Login-LAT-Port,text,[RFC2865] 1377 64,Tunnel-Type,enum,[RFC2868] 1378 65,Tunnel-Medium-Type,enum,[RFC2868] 1379 66,Tunnel-Client-Endpoint,text,[RFC2868] 1380 67,Tunnel-Server-Endpoint,text,[RFC2868] 1381 68,Acct-Tunnel-Connection,text,[RFC2867] 1382 69,Tunnel-Password,string,[RFC2868] 1383 70,ARAP-Password,string,[RFC2869] 1384 71,ARAP-Features,string,[RFC2869] 1385 72,ARAP-Zone-Access,enum,[RFC2869] 1386 73,ARAP-Security,integer,[RFC2869] 1387 74,ARAP-Security-Data,text,[RFC2869] 1388 75,Password-Retry,integer,[RFC2869] 1389 76,Prompt,enum,[RFC2869] 1390 77,Connect-Info,text,[RFC2869] 1391 78,Configuration-Token,text,[RFC2869] 1392 79,EAP-Message,concat,[RFC2869] 1393 80,Message-Authenticator,string,[RFC2869] 1394 81,Tunnel-Private-Group-ID,text,[RFC2868] 1395 82,Tunnel-Assignment-ID,text,[RFC2868] 1396 83,Tunnel-Preference,integer,[RFC2868] 1397 84,ARAP-Challenge-Response,string,[RFC2869] 1398 85,Acct-Interim-Interval,integer,[RFC2869] 1399 86,Acct-Tunnel-Packets-Lost,integer,[RFC2867] 1400 87,NAS-Port-Id,text,[RFC2869] 1401 88,Framed-Pool,text,[RFC2869] 1402 89,CUI,string,[RFC4372] 1403 90,Tunnel-Client-Auth-ID,text,[RFC2868] 1404 91,Tunnel-Server-Auth-ID,text,[RFC2868] 1405 92,NAS-Filter-Rule,text,[RFC4849] 1406 93,Unassigned,, 1407 94,Originating-Line-Info,string,[RFC7155] 1408 95,NAS-IPv6-Address,ipv6addr,[RFC3162] 1409 96,Framed-Interface-Id,ifid,[RFC3162] 1410 97,Framed-IPv6-Prefix,ipv6prefix,[RFC3162] 1411 98,Login-IPv6-Host,ipv6addr,[RFC3162] 1412 99,Framed-IPv6-Route,text,[RFC3162] 1413 100,Framed-IPv6-Pool,text,[RFC3162] 1414 101,Error-Cause Attribute,enum,[RFC3576] 1415 102,EAP-Key-Name,string,[RFC4072][RFC7268] 1416 103,Digest-Response,text,[RFC5090] 1417 104,Digest-Realm,text,[RFC5090] 1418 105,Digest-Nonce,text,[RFC5090] 1419 106,Digest-Response-Auth,text,[RFC5090] 1420 107,Digest-Nextnonce,text,[RFC5090] 1421 108,Digest-Method,text,[RFC5090] 1422 109,Digest-URI,text,[RFC5090] 1423 110,Digest-Qop,text,[RFC5090] 1424 111,Digest-Algorithm,text,[RFC5090] 1425 112,Digest-Entity-Body-Hash,text,[RFC5090] 1426 113,Digest-CNonce,text,[RFC5090] 1427 114,Digest-Nonce-Count,text,[RFC5090] 1428 115,Digest-Username,text,[RFC5090] 1429 116,Digest-Opaque,text,[RFC5090] 1430 117,Digest-Auth-Param,text,[RFC5090] 1431 118,Digest-AKA-Auts,text,[RFC5090] 1432 119,Digest-Domain,text,[RFC5090] 1433 120,Digest-Stale,text,[RFC5090] 1434 121,Digest-HA1,text,[RFC5090] 1435 122,SIP-AOR,text,[RFC5090] 1436 123,Delegated-IPv6-Prefix,ipv6prefix,[RFC4818] 1437 124,MIP6-Feature-Vector,string,[RFC5447] 1438 125,MIP6-Home-Link-Prefix,ipv6prefix,[RFC5447] 1439 126,Operator-Name,text,[RFC5580] 1440 127,Location-Information,string,[RFC5580] 1441 128,Location-Data,string,[RFC5580] 1442 129,Basic-Location-Policy-Rules,string,[RFC5580] 1443 130,Extended-Location-Policy-Rules,string,[RFC5580] 1444 131,Location-Capable,enum,[RFC5580] 1445 132,Requested-Location-Info,enum,[RFC5580] 1446 133,Framed-Management-Protocol,enum,[RFC5607] 1447 134,Management-Transport-Protection,enum,[RFC5607] 1448 135,Management-Policy-Id,text,[RFC5607] 1449 136,Management-Privilege-Level,integer,[RFC5607] 1450 137,PKM-SS-Cert,concat,[RFC5904] 1451 138,PKM-CA-Cert,concat,[RFC5904] 1452 139,PKM-Config-Settings,string,[RFC5904] 1453 140,PKM-Cryptosuite-List,string,[RFC5904] 1454 141,PKM-SAID,text,[RFC5904] 1455 142,PKM-SA-Descriptor,string,[RFC5904] 1456 143,PKM-Auth-Key,string,[RFC5904] 1457 144,DS-Lite-Tunnel-Name,text,[RFC6519] 1458 145,Mobile-Node-Identifier,string,[RFC6572] 1459 146,Service-Selection,text,[RFC6572] 1460 147,PMIP6-Home-LMA-IPv6-Address,ipv6addr,[RFC6572] 1461 148,PMIP6-Visited-LMA-IPv6-Address,ipv6addr,[RFC6572] 1462 149,PMIP6-Home-LMA-IPv4-Address,ipv4addr,[RFC6572] 1463 150,PMIP6-Visited-LMA-IPv4-Address,ipv4addr,[RFC6572] 1464 151,PMIP6-Home-HN-Prefix,ipv6prefix,[RFC6572] 1465 152,PMIP6-Visited-HN-Prefix,ipv6prefix,[RFC6572] 1466 153,PMIP6-Home-Interface-ID,ifid,[RFC6572] 1467 154,PMIP6-Visited-Interface-ID,ifid,[RFC6572] 1468 155,PMIP6-Home-IPv4-HoA,ipv4prefix,[RFC6572] 1469 156,PMIP6-Visited-IPv4-HoA,ipv4prefix,[RFC6572] 1470 157,PMIP6-Home-DHCP4-Server-Address,ipv4addr,[RFC6572] 1471 158,PMIP6-Visited-DHCP4-Server-Address,ipv4addr,[RFC6572] 1472 159,PMIP6-Home-DHCP6-Server-Address,ipv6addr,[RFC6572] 1473 160,PMIP6-Visited-DHCP6-Server-Address,ipv6addr,[RFC6572] 1474 161,PMIP6-Home-IPv4-Gateway,ipv4addr,[RFC6572] 1475 162,PMIP6-Visited-IPv4-Gateway,ipv4addr,[RFC6572] 1476 163,EAP-Lower-Layer,enum,[RFC6677] 1477 164,GSS-Acceptor-Service-Name,text,[RFC7055] 1478 165,GSS-Acceptor-Host-Name,text,[RFC7055] 1479 166,GSS-Acceptor-Service-Specifics,text,[RFC7055] 1480 167,GSS-Acceptor-Realm-Name,text,[RFC7055] 1481 168,Framed-IPv6-Address,ipv6addr,[RFC6911] 1482 169,DNS-Server-IPv6-Address,ipv6addr,[RFC6911] 1483 170,Route-IPv6-Information,ipv6prefix,[RFC6911] 1484 171,Delegated-IPv6-Prefix-Pool,text,[RFC6911] 1485 172,Stateful-IPv6-Address-Pool,text,[RFC6911] 1486 173,IPv6-6rd-Configuration,tlv,[RFC6930] 1487 174,Allowed-Called-Station-Id,text,[RFC7268] 1488 175,EAP-Peer-Id,string,[RFC7268] 1489 176,EAP-Server-Id,string,[RFC7268] 1490 177,Mobility-Domain-Id,integer,[RFC7268] 1491 178,Preauth-Timeout,integer,[RFC7268] 1492 179,Network-Id-Name,string,[RFC7268] 1493 180,EAPoL-Announcement,concat,[RFC7268] 1494 181,WLAN-HESSID,text,[RFC7268] 1495 182,WLAN-Venue-Info,integer,[RFC7268] 1496 183,WLAN-Venue-Language,string,[RFC7268] 1497 184,WLAN-Venue-Name,text,[RFC7268] 1498 185,WLAN-Reason-Code,integer,[RFC7268] 1499 186,WLAN-Pairwise-Cipher,integer,[RFC7268] 1500 187,WLAN-Group-Cipher,integer,[RFC7268] 1501 188,WLAN-AKM-Suite,integer,[RFC7268] 1502 189,WLAN-Group-Mgmt-Cipher,integer,[RFC7268] 1503 190,WLAN-RF-Band,integer,[RFC7268] 1504 191,Unassigned,, 1505 192-223,Experimental Use,,[RFC3575] 1506 224-240,Implementation Specific,,[RFC3575] 1507 241,Extended-Attribute-1,extended,[RFC6929] 1508 241.1,Frag-Status,integer,[RFC7499] 1509 241.2,Proxy-State-Length,integer,[RFC7499] 1510 241.{3-25},Unassigned,, 1511 241.26,Extended-Vendor-Specific-1,evs,[RFC6929] 1512 241.{27-240},Unassigned,, 1513 241.{241-255},Reserved,,[RFC6929] 1514 242,Extended-Attribute-2,extended,[RFC6929] 1515 242.{1-25},Unassigned,, 1516 242.26,Extended-Vendor-Specific-2,evs,[RFC6929] 1517 242.{27-240},Unassigned,, 1518 242.{241-255},Reserved,,[RFC6929] 1519 243,Extended-Attribute-3,extended,[RFC6929] 1520 243.{1-25},Unassigned,, 1521 243.26,Extended-Vendor-Specific-3,evs,[RFC6929] 1522 243.{27-240},Unassigned,, 1523 243.{241-255},Reserved,,[RFC6929] 1524 244,Extended-Attribute-4,extended,[RFC6929] 1525 244.{1-25},Unassigned,, 1526 244.26,Extended-Vendor-Specific-4,evs,[RFC6929] 1527 244.{27-240},Unassigned,, 1528 244.{241-255},Reserved,,[RFC6929] 1529 245,Extended-Attribute-5,long-extended,[RFC6929] 1530 245.{1-25},Unassigned,, 1531 245.26,Extended-Vendor-Specific-5,evs,[RFC6929] 1532 245.{27-240},Unassigned,, 1533 245.{241-255},Reserved,,[RFC6929] 1534 246,Extended-Attribute-6,long-extended,[RFC6929] 1535 246.{1-25},Unassigned,, 1536 246.26,Extended-Vendor-Specific-6,evs,[RFC6929] 1537 246.{27-240},Unassigned,, 1538 246.{241-255},Reserved,,[RFC6929] 1539 247-255,Reserved,,[RFC3575] 1541 5. Security Considerations 1543 This specification is concerned solely with updates to IANA 1544 registries. As such, there are no security considerations with the 1545 document itself. 1547 However, the use of inconsistent names and poorly-defined entities in 1548 a protocol is problematic. Inconsistencies in specifications can 1549 lead to security and interoperability problems in implementations. 1550 Further, having one canonical source for the definition of data types 1551 means an implementor has fewer specifications to read. The 1552 implementation work is therefore simpler, and is more likely to be 1553 correct. 1555 The goal of this specification is to reduce ambiguities in the RADIUS 1556 protocol, which we believe will lead to more robust and more secure 1557 implementations. 1559 6. IANA Considerations 1561 IANA is instructed to create one new registry as described above in 1562 Section 4.1. The "TBD" text in that section should be replaced with 1563 the RFC number of this document when it is published. 1565 IANA is instructed to update the RADIUS Attribute Type registry, as 1566 described above in Section 4.2. 1568 IANA is instructed to require that all allocation requests in the 1569 RADIUS Attribute Type Registry contain a "Data Type" field. That 1570 field is required to contain one of the "Data Type" names contained 1571 in the RADIUS Data Type registry. 1573 IANA is instructed to require that updates to the RADIUS Data Type 1574 registry contain the following fields, with the associated 1575 instructions: 1577 * Value. IANA is instructed to assign the next unused integer in 1578 sequence to new data type definitions. 1580 * Name. IANA is instructed to require that this name be unique 1581 in the registry. 1583 * Reference. IANA is instructed to update this field with a 1584 reference 1585 to the document which defines the data type. 1587 7. References 1589 7.1. Normative References 1591 [RFC2119] 1592 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1593 Levels", RFC 2119, March, 1997. 1595 [RFC2865] 1596 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1597 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1599 [RFC3162] 1600 Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, 1601 August 2001. 1603 [RFC3629] 1604 Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1605 3629, November 2003. 1607 [RFC4072] 1608 Eronen, P., et al, "Diameter Extensible Authentication Protocol 1609 (EAP) Application", RFC 4072, February 2013. 1611 [RFC6158] 1612 DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 6158, 1613 March 2011. 1615 [RFC6572] 1616 Xia, F., et al, "RADIUS Support for Proxy Mobile IPv6", RFC 6572, 1617 June 2012. 1619 7.2. Informative References 1621 [RFC2868] 1622 Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. 1623 Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 1624 June 2000. 1626 [RFC2869] 1627 Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000. 1629 [RFC6929] 1630 DeKok, A., and Lior, A., "Remote Authentication Dial In User 1631 Service (RADIUS) Protocol Extensions", RFC 6929, April 2013. 1633 [RFC7268] 1634 Aboba, B, et al, "RADIUS Attributes for IEEE 802 Networks", RFC 1635 7268, July 2015. 1637 [RFC7499] 1638 Perez-Mendez A., et al, "Support of Fragmentation of RADIUS 1639 Packets", RFC 7499, April 2015. 1641 [PEN] 1642 http://www.iana.org/assignments/enterprise-numbers 1644 Acknowledgments 1646 Thanks to the RADEXT WG for patience and reviews of this document. 1648 Authors' Addresses 1650 Alan DeKok 1651 The FreeRADIUS Server Project 1653 Email: aland@freeradius.org