idnits 2.17.1 draft-dekok-radext-datatypes-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 (1 April 2015) is 3312 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4072' is mentioned on line 1168, but not defined == Missing Reference: 'RFC7268' is mentioned on line 1168, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 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 1 April 2015 9 Data Types in the Remote Authentication 10 Dial-In User Service Protocol (RADIUS) 11 draft-dekok-radext-datatypes-06.txt 13 Abstract 15 RADIUS specifications have used data types for two decades without 16 defining them as managed entities. During this time, RADIUS 17 implementations have named the data types, and have used them in 18 attribute definitions. This document updates the specifications to 19 better follow established practice. We do this by naming the data 20 types defined in RFC 6158, which have been used since at least RFC 21 2865. We provide an IANA registry for the data types, and update the 22 RADIUS Attribute Type registry to include a "Data Type" field for 23 each attribute. Finally, we recommend that authors of RADIUS 24 specifications use these types in preference to existing practice. 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 October 1, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info/) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction ............................................. 4 67 1.1. Specification use of Data Types ..................... 4 68 1.2. Implementation use of Data Types .................... 4 69 1.3. Requirements Language ............................... 5 70 2. Data Type Definitions .................................... 6 71 2.1. integer ............................................. 7 72 2.2. enum ................................................ 8 73 2.3. ipv4addr ............................................ 8 74 2.4. time ................................................ 9 75 2.5. text ................................................ 10 76 2.6. string .............................................. 10 77 2.7. concat .............................................. 11 78 2.8. ifid ................................................ 12 79 2.9. ipv6addr ............................................ 13 80 2.10. ipv6prefix ......................................... 14 81 2.11. ipv4prefix ......................................... 15 82 2.12. integer64 .......................................... 16 83 2.13. tlv ................................................ 16 84 2.14. vsa ................................................ 18 85 2.15. extended ........................................... 19 86 2.16. long-extended ...................................... 20 87 2.17. evs ................................................ 22 88 3. Updated Registries ....................................... 24 89 3.1. Create a Data Type Registry ......................... 24 90 3.2. Updates to the Attribute Type Registry .............. 25 91 4. Suggestions for Specifications ........................... 30 92 5. Security Considerations .................................. 31 93 6. IANA Considerations ...................................... 31 94 7. References ............................................... 31 95 7.1. Normative References ................................ 31 96 7.2. Informative References .............................. 32 98 1. Introduction 100 RADIUS specifications have historically defined attributes in terms 101 of name, type value, and data type. Of these three pieces of 102 information, only the type value is managed by IANA. There is no 103 management of, or restriction on, the attribute name, as discussed in 104 [RFC6929] Section 2.7.1. There is no management of data type name or 105 definition. This document defines an IANA registry for data types, 106 and updates the RADIUS Attribute Type registry to use those newly 107 defined data types. 109 In this section, we review the use of data types in specifications 110 and implementations. Whe highlight ambiguities and inconsistencies. 111 The rest of this document is devoted to resolving those problems. 113 1.1. Specification use of Data Types 115 A number of data type names and definitions are given in [RFC2865] 116 Section 5, at the bottom of page 25. These data types are named and 117 clearly defined. However, this practice was not continued in later 118 specifications. 120 Specifically, [RFC2865] defines attributes of data type "address" to 121 carry IPv4 addresses. Despite this definition, [RFC3162] defines 122 attributes of data type "Address" to carry IPv6 addresses. We 123 suggest that the use of the word "address" to refer to disparate data 124 types is problematic. 126 Other failures are that [RFC3162] does not give a data type name and 127 definition for the data types IPv6 address, Interface-Id, or IPv6 128 prefix. [RFC2869] defines Event-Timestamp to carry a time, but does 129 not re-use the "time" data type defined in [RFC2865]. Instead, it 130 just repeats the "time" definition. [RFC6572] defines multiple 131 attributes which carry IPv4 prefixes. However, an "IPv4 prefix" data 132 type is not named, defined as a data type, or called out as an 133 addition to RADIUS. Further, [RFC6572] does not follow the 134 recommendations of [RFC6158], and does not explain why it fails to 135 follow those recommendations. 137 These ambiguities and inconsistencies need to be resolved. 139 1.2. Implementation use of Data Types 141 RADIUS implementations often use "dictionaries" to map attribute 142 names to type values, and to define data types for each attribute. 143 The data types in the dictionaries are defined by each 144 implementation, but correspond to the "ad hoc" data types used in the 145 specifications. 147 In effect, implementations have seen the need for well-defined data 148 types, and have created them. It is time for RADIUS specifications 149 to follow this practice. 151 This document requires no changes to any RADIUS implementation, past, 152 present, or future. It instead documents existing practice, in order 153 to simplify the process of writing RADIUS specifications, to clarify 154 the interpretation of RADIUS standards, and to improve the 155 communication between specification authors and IANA. 157 1.3. Requirements Language 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 2. Data Type Definitions 165 This section defines the new data types. For each data type, it 166 gives a definition, a name, a number, a length, and an encoding 167 format. Where relevant, it describes subfields contained within the 168 data type. These definitions have no impact on existing RADIUS 169 implementations. There is no requirement that implementations use 170 these names. 172 Where possible, the name of each data type has been taken from 173 previous specifications. In some cases, a different name has been 174 chosen. The change of name is sometimes required to avoid ambiguity 175 (i.e. "address" versus "Address"). Otherwise, the new name has been 176 chosen to be compatible with [RFC2865], or with use in common 177 implementations. In some cases, new names are chosen to clarify the 178 interpretation of the data type. 180 The numbers assigned herein for the data types have no meaning other 181 than to permit them to be tracked by IANA. As RADIUS does not encode 182 information about data types in a packet, the numbers assigned to a 183 data type will never occur in a packet. 185 The encoding of each data type is taken from previous specifications. 186 The fields are transmitted from left to right. 188 Where the data types have inter-dependencies, the simplest data type 189 is given first, and dependent ones are given later. 191 We do not create specific data types for the "tagged" attributes, as 192 discussed in [RFC2868]. That specification defines the "tagged" 193 attributes as being backwards compatible with pre-existing data 194 types. In addition, [RFC6158] Section 2.1 says that "tagged" 195 attributes should not be used. There is therefore no benefit to 196 defining additional data types for these attributes. 198 Similarly, we do not create data types for some attributes having 199 complex structure, such as CHAP-Password, ARAP-Features, or Location- 200 Capable. We need to strike a balance between correcting earlier 201 mistakes, and making this document more complex. In some cases, it 202 is better to treat complex attributes as being of type "string", even 203 though they need to be interpreted by RADIUS implementations. 205 Implementations not supporting a particular data type MUST treat 206 attributes of that data type as being of data type "string". See 207 Section 2.6, below for a definition of the "string" data type. 209 The definitions below use specialized names for various fields of 210 attributes and data types. These names serve to address ambiguity of 211 the field names in previous specifications. For example, the term 212 "Value" is used in [RFC2865] Section 5 to define a field which 213 carries the contents of attribute. It is then used in later sections 214 as the sub-field of attribute contents. The result is that the field 215 is defined as recursively containing itself. Similarly, "String" is 216 used both as a data type, and as a sub-field of other data types. 218 This document uses slightly different terminology than previous 219 specifications, in order to be avoid ambiguity. The first addition 220 is the following term: 222 Attr-Data 224 The "Value" field of an Attribute as defined in [RFC2865] 225 Section 5. The contents of this field MUST be a valid data 226 type as defined in the RADIUS Data Type registry. 228 In this document, we use the term "Value" only to refer to the 229 contents of a data type, where that data type cannot carry other data 230 types. In other cases, we refer to the contents of a data type as 231 "Type-Data", to distinguish it from data of other types. For 232 example, a data type "vsa" will contain a data field called "VSA- 233 Data". 235 These terms are used in preference to the term "String", which was 236 used in multiple incompatible ways. It is RECOMMENDED that future 237 specifications use the new terms in order to maintain consistent 238 definitions, and to avoid ambiguities. 240 2.1. integer 242 The "integer" data type encodes a 32-bit unsigned integer in network 243 byte order. Where the range of values for a particular attribute is 244 limited to a sub-set of the values, specifications MUST define the 245 valid range. Values outside of the allowed ranges SHOULD be treated 246 as invalid. 248 Name 250 integer 252 Number 254 1 256 Length 258 Four octets 260 Format 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Value | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 2.2. enum 270 The "enum" data type encodes a 32-bit unsigned integer in network 271 byte order. It differs from the "integer" data type only in that it 272 is used to define enumerated types, such as Service-Type. 273 Specifications MUST define a valid set of enumerated values, along 274 with a unique name for each value. 276 Name 278 enum 280 Number 282 2 284 Length 286 Four octets 288 Format 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Value | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 2.3. ipv4addr 298 The "ipv4addr" data type encodes an IPv4 address in network byte 299 order. Where the range of address for a particular attribute is 300 limited to a sub-set of possible addresses, specifications MUST 301 define the valid range(s). Values outside of the allowed range 302 SHOULD be treated as invalid. 304 Name 305 ipv4addr 307 Number 309 3 311 Length 313 Four octets 315 Format 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Address | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 2.4. time 325 The "time" data type encodes time as a 32-bit unsigned value in 326 network byte order and in seconds since 00:00:00 UTC, January 1, 327 1970. We note that dates before the year 2013 are likely to be 328 erroneous. 330 Note that the "time" attribute is defined to be unsigned, which means 331 it is not subject to a signed integer overflow in the year 2038. 333 Name 335 time 337 Number 339 4 341 Length 343 Four octets 345 Format 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Time | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 2.5. text 355 The "text" data type encodes UTF-8 text [RFC3629]. The maximum 356 length of the text is given by the encapsulating attribute. Where 357 the range of lengths for a particular attribute is limited to a sub- 358 set of possible lengths, specifications MUST define the valid 359 range(s). 361 Note that the "text" type does not terminate with a NUL octet (hex 362 00). The Attribute has a Length field and does not use a terminator. 363 Texts of length zero (0) MUST NOT be sent; omit the entire attribute 364 instead. 366 Name 368 text 370 Number 372 5 374 Length 376 One or more octets. 378 Format 380 0 381 0 1 2 3 4 5 6 7 382 +-+-+-+-+-+-+-+- 383 | Value ... 384 +-+-+-+-+-+-+-+- 386 2.6. string 388 The "string" data type encodes binary data, as a sequence of 389 undistinguished octets. Where the range of lengths for a particular 390 attribute is limited to a sub-set of possible lengths, specifications 391 MUST define the valid range(s). 393 Note that the "string" data type does not terminate with a NUL octet 394 (hex 00). The Attribute has a Length field and does not use a 395 terminator. Strings of length zero (0) MUST NOT be sent; omit the 396 entire attribute instead. 398 Where there is a need to encapsulate complex data structures, and 399 TLVs cannot be used, the "string" data type MUST be used. This 400 requirement include encapsulation of data structures defined outside 401 of RADIUS, which are opaque to the RADIUS infrastucture. It also 402 includes encapsulation of some data structures which are not opaque 403 to RADIUS, such as the contents of CHAP-Password. 405 There is little reason to define a new RADIUS data type for only one 406 attribute. However, where the complex data type cannot be 407 represented as TLVs, and is expected to be used in many attributes, a 408 new data type SHOULD be defined. 410 These requirements are stronger than [RFC6158], which makes the above 411 encapsulation a "SHOULD". This document defines data types for use 412 in RADIUS, so there are few reasons to avoid using them. 414 Name 416 string 418 Number 420 6 422 Length 424 One or more octets. 426 Format 428 0 429 0 1 2 3 4 5 6 7 430 +-+-+-+-+-+-+-+- 431 | Octets ... 432 +-+-+-+-+-+-+-+- 434 2.7. concat 436 The "concat" data type permits the transport of more than 253 octets 437 of data in a "standard space" [RFC6929] attribute. It is otherwise 438 identical to the "string" data type. 440 If multiple attributes of this data type are contained in a packet, 441 all attributes of the same type code MUST be in order and they MUST 442 be consecutive attributes in the packet. 444 The amount of data transported in a "concat" data type can be no more 445 than the RADIUS packet size. In practice, the requirement to 446 transport multiple attributes means that the limit may be 447 substantially smaller than one RADIUS packet. As a rough guide, is 448 RECOMMENDED that this data type transport no more than 2048 octets of 449 data. 451 The "concat" data type MAY be used for "standard space" attributes. 452 It MUST NOT be used for attributes in the "short extended space" or 453 the "long extended space". It MUST NOT be used in any field or 454 subfields of the following data types: "tlv", "vsa", "extended", 455 "long-extended", or "evs". 457 Name 459 concat 461 Number 463 7 465 Length 467 One or more octets. 469 Format 471 0 472 0 1 2 3 4 5 6 7 473 +-+-+-+-+-+-+-+- 474 | Octets ... 475 +-+-+-+-+-+-+-+- 477 2.8. ifid 479 The "ifid" data type encodes an Interface-Id as an 8-octet string in 480 network byte order. 482 Name 484 ifid 486 Number 488 8 490 Length 492 Eight octets 494 Format 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Interface-ID ... 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 ... Interface-ID | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 2.9. ipv6addr 506 The "ipv6addr" data type encodes an IPv6 address in network byte 507 order. Where the range of address for a particular attribute is 508 limited to a sub-set of possible addresses, specifications MUST 509 define the valid range(s). 511 Name 513 ipv6addr 515 Number 517 9 519 Length 521 Sixteen octets 523 Format 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Address ... 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 ... Address ... 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 ... Address ... 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 ... Address | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 2.10. ipv6prefix 539 The "ipv6prefix" data type encodes an IPv6 prefix, using both a 540 prefix length and an IPv6 address in network byte order. 542 Name 544 ipv6prefix 546 Number 548 10 550 Length 552 At least two, and no more than eighteen octets. 554 Format 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Reserved | Prefix-Length | Prefix ... 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 ... Prefix ... 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 ... Prefix ... 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 ... Prefix | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Subfields 570 Reserved 572 This field, which is reserved and MUST be present, is always 573 set to zero. 575 Prefix-Length 577 The length of the prefix, in bits. At least 0 and no larger 578 than 128. 580 Prefix 582 The Prefix field is up to 16 octets in length. Bits outside of 583 the Prefix-Length, if included, must be zero. 585 2.11. ipv4prefix 587 The "ipv4prefix" data type encodes an IPv4 prefix, using both a 588 prefix length and an IPv4 address in network byte order. 590 Name 592 ipv4prefix 594 Number 596 11 598 Length 600 At least two, and no more than eighteen octets. 602 Format 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Reserved | Prefix-Len| Prefix ... 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 ... Prefix | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 Subfields 614 Reserved 616 This field, which is reserved and MUST be present, is always 617 set to zero. 619 Prefix-Length 621 A 6-bit unsigned integer containing the length of the prefix, 622 in bits. The values MUST be no larger than 32. 624 Prefix 626 The Prefix field is 4 octets in length. Bits outside of the 627 Prefix-Length must be zero. Unlike the "ipv6prefix" data type, 628 this field is fixed length. If the address is all zeros (i.e. 629 "0.0.0.0", then the Prefix-Length MUST be set to 32. 631 2.12. integer64 633 The "integer64" data type encodes a 64-bit unsigned integer in 634 network byte order. Where the range of values for a particular 635 attribute is limited to a sub-set of the values, specifications MUST 636 define the valid range(s). 638 Name 640 integer64 642 Number 644 12 646 Length 648 Eight octets 650 Format 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Value ... 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 ... Value | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 2.13. tlv 662 The "tlv" data type encodes a type-length-value, as defined in 663 [RFC6929] Section 2.3. 665 Name 667 tlv 669 Number 671 13 673 Length 675 Three or more octets 677 Format 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | TLV-Type | TLV-Length | TLV-Data ... 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Subfields 686 TLV-Type 688 This field is one octet. Up-to-date values of this field are 689 specified according to the policies and rules described in 690 [RFC6929] Section 10. Values 254-255 are "Reserved" for use by 691 future extensions to RADIUS. The value 26 has no special 692 meaning, and MUST NOT be treated as a Vendor Specific 693 attribute. 695 The TLV-Type is meaningful only within the context defined by 696 "Type" fields of the encapsulating Attributes, using the 697 dotted-number notation introduced in [RFC6929]. 699 A RADIUS server MAY ignore Attributes with an unknown "TLV- 700 Type". 702 A RADIUS client MAY ignore Attributes with an unknown "TLV- 703 Type". 705 A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- 706 Type" verbatim. 708 TLV-Length 710 The TLV-Length field is one octet, and indicates the length of 711 this TLV including the TLV-Type, TLV-Length and TLV-Value 712 fields. It MUST have a value between 3 and 255. If a client 713 or server receives a TLV with an invalid TLV-Length, then the 714 attribute which encapsulates that TLV MUST be considered to be 715 an "invalid attribute", and handled as per [RFC6929] Section 716 2.8. 718 TLVs having TLV-Length of zero (0) MUST NOT be sent; omit the 719 entire TLV instead. 721 TLV-Data 723 The TLV-Data field is one or more octets and contains 724 information specific to the Attribute. The format and length 725 of the TLV-Data field is determined by the TLV-Type and TLV- 726 Length fields. 728 The TLV-Data field MUST contain only known RADIUS data types. 729 The TLV-Data field MUST NOT contain any of the following data 730 types: "concat", "vsa", "extended", "long-extended", or "evs". 732 2.14. vsa 734 The "vsa" data type encodes Vendor-Specific data, as given in 735 [RFC2865] Section 5.26. It is used only in the Attr-Data field of a 736 Vendor-Specific Attribute. It MUST NOT appear in the contents of any 737 other data type. 739 Name 741 vsa 743 Number 745 14 747 Length 749 Five or more octets 751 Format 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Vendor-Id | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | VSA-Data .... 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 Subfields 763 Vendor-Id 765 The 4 octets are the Network Management Private Enterprise Code 766 [PEN] of the Vendor in network byte order. 768 VSA-Data 770 The VSA-Data field is one or more octets. The actual format of 771 the information is site or application specific, and a robust 772 implementation SHOULD support the field as undistinguished 773 octets. 775 The codification of the range of allowed usage of this field is 776 outside the scope of this specification. 778 It SHOULD be encoded as a sequence of "tlv" fields. The 779 interpretation of the TLV-Type and TLV-Data fields are 780 dependent on the vendor's definition of that attribute. 782 The "vsa" data type MUST be used as contents of the Attr-Data 783 field of the Vendor-Specific attribute. The "vsa" data type 784 MUST NOT appear in the contents of any other data type. 786 2.15. extended 788 The "extended" data type encodes the "Extended Type" format, as given 789 in [RFC6929] Section 2.1. It is used only in the Attr-Data field of 790 an Attribute allocated from the "standard space". It MUST NOT appear 791 in the contents of any other data type. 793 Name 795 extended 797 Number 799 15 801 Length 803 Two or more octets 805 Format 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Extended-Type | Ext-Data ... 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 Subfields 815 Extended-Type 817 The Extended-Type field is one octet. Up-to-date values of 818 this field are specified according to the policies and rules 819 described in [RFC6929] Section 10. Unlike the Type field 820 defined in [RFC2865] Section 5, no values are allocated for 821 experimental or implementation-specific use. Values 241-255 822 are reserved and MUST NOT be used. 824 The Extended-Type is meaningful only within a context defined 825 by the Type field. That is, this field may be thought of as 826 defining a new type space of the form "Type.Extended-Type". 827 See [RFC6929] Section 2.5 for additional discussion. 829 A RADIUS server MAY ignore Attributes with an unknown 830 "Type.Extended-Type". 832 A RADIUS client MAY ignore Attributes with an unknown 833 "Type.Extended-Type". 835 Ext-Data 837 The contents of this field MUST be a valid data type as defined 838 in the RADIUS Data Type registry. The Ext-Data field MUST NOT 839 contain any of the following data types: "concat", "vsa", 840 "extended", "long-extended", or "evs". 842 The Ext-Data field is one or more octets. 844 Implementations supporting this specification MUST use the 845 Identifier of "Type.Extended-Type" to determine the 846 interpretation of the Ext-Data field. 848 2.16. long-extended 850 The "long-extended" data type encodes the "Long Extended Type" 851 format, as given in [RFC6929] Section 2.2. It is used only in the 852 Attr-Data field of an Attribute. It MUST NOT appear in the contents 853 of any other data type. 855 Name 857 long-extended 859 Number 861 16 863 Length 865 Three or more octets 867 Format 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Extended-Type |M| Reserved | Ext-Data ... 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 Subfields 877 Extended-Type 879 This field is identical to the Extended-Type field defined 880 above in Section 2.13. 882 M (More) 884 The More field is one (1) bit in length, and indicates whether 885 or not the current attribute contains "more" than 251 octets of 886 data. The More field MUST be clear (0) if the Length field has 887 value less than 255. The More field MAY be set (1) if the 888 Length field has value of 255. 890 If the More field is set (1), it indicates that the Ext-Data 891 field has been fragmented across multiple RADIUS attributes. 892 When the More field is set (1), the attribute MUST have a 893 Length field of value 255; there MUST be an attribute following 894 this one; and the next attribute MUST have both the same Type 895 and Extended Type. That is, multiple fragments of the same 896 value MUST be in order and MUST be consecutive attributes in 897 the packet, and the last attribute in a packet MUST NOT have 898 the More field set (1). 900 That is, a packet containing a fragmented attribute needs to 901 contain all fragments of the attribute, and those fragments 902 need to be contiguous in the packet. RADIUS does not support 903 inter-packet fragmentation, which means that fragmenting an 904 attribute across multiple packets is impossible. 906 If a client or server receives an attribute fragment with the 907 "More" field set (1), but for which no subsequent fragment can 908 be found, then the fragmented attribute is considered to be an 909 "invalid attribute", and handled as per [RFC6929] Section 2.8. 911 Reserved 913 This field is 7 bits long, and is reserved for future use. 914 Implementations MUST set it to zero (0) when encoding an 915 attribute for sending in a packet. The contents SHOULD be 916 ignored on reception. 918 Future specifications may define additional meaning for this 919 field. Implementations therefore MUST NOT treat this field as 920 invalid if it is non-zero. 922 Ext-Data 924 The contents of this field MUST be a valid data type as defined 925 in the RADIUS Data Type registry. The Ext-Data field MUST NOT 926 contain any of the following data types: "concat", "vsa", 927 "extended", "long-extended", or "evs". 929 The Ext-Data field is one or more octets. 931 Implementations supporting this specification MUST use the 932 Identifier of "Type.Extended-Type" to determine the 933 interpretation of the Ext-Data field. 935 The length of the data MUST be taken as the sum of the lengths 936 of the fragments (i.e. Ext-Data fields) from which it is 937 constructed. Any interpretation of the resulting data MUST 938 occur after the fragments have been reassembled. If the 939 reassembled data does not match the expected format, each 940 fragment MUST be treated as an "invalid attribute", and the 941 reassembled data MUST be discarded. 943 We note that the maximum size of a fragmented attribute is 944 limited only by the RADIUS packet length limitation. 945 Implementations MUST be able to handle the case where one 946 fragmented attribute completely fills the packet. 948 2.17. evs 950 The "evs" data type encodes an "Extended Vendor-Specific" attribute, 951 as given in [RFC6929] Section 2.4. The "evs" data type is used 952 solely to extend the Vendor Specific space. It MAY appear inside of 953 an "extended" or a "long-extended" data type. It MUST NOT appear in 954 the contents of any other data type. 956 Name 958 evs 960 Number 961 17 963 Length 965 Six or more octets 967 Format 969 0 1 2 3 970 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 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Vendor-Id | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Vendor-Type | EVS-Data .... 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 Subfields 979 Vendor-Id 981 The 4 octets are the Network Management Private Enterprise Code 982 [PEN] of the Vendor in network byte order. 984 Vendor-Type 986 The Vendor-Type field is one octet. Values are assigned at the 987 sole discretion of the Vendor. 989 EVS-Data 991 The EVS-Data field is one or more octets. It SHOULD 992 encapsulate a previously defined RADIUS data type. Non- 993 standard data types SHOULD NOT be used. We note that the EVS- 994 Data field may be of data type "tlv". 996 The actual format of the information is site or application 997 specific, and a robust implementation SHOULD support the field 998 as undistinguished octets. We recognise that Vendors have 999 complete control over the contents and format of the Ext-Data 1000 field, while at the same time recommending that good practices 1001 be followed. 1003 Further codification of the range of allowed usage of this 1004 field is outside the scope of this specification. 1006 3. Updated Registries 1008 This section defines a new IANA registry for RADIUS data types, and 1009 updates the existing RADIUS Attribute Type registry. 1011 3.1. Create a Data Type Registry 1013 This section defines a new RADIUS registry, called "Data Type". 1014 Allocation in this registry requires IETF Review. The "Registration 1015 Procedures" for this registry are "Standards Action". 1017 The registry contains three columns of data, as follows. 1019 Value 1021 The number of the data type. The value field is an artifact of 1022 the registry, and has no on-the-wire meaning. 1024 Description 1026 The name of the data type. The name field is used only for the 1027 registry, and has no on-the-wire meaning. 1029 Reference 1031 The specification where the data type was defined. 1033 The initial contents of the registry are as follows. 1035 Value Description Reference 1036 ----- ----------- ---------------- 1037 1 integer [RFC2865], TBD 1038 2 enum [RFC2865], TBD 1039 3 ipv4addr [RFC2865], TBD 1040 4 time [RFC2865], TBD 1041 5 text [RFC2865], TBD 1042 6 string [RFC2865], TBD 1043 7 concat TBD 1044 8 ifid [RFC3162], TBD 1045 9 ipv6addr [RFC3162], TBD 1046 10 ipv6prefix [RFC3162], TBD 1047 11 ipv4prefix [RFC6572], TBD 1048 12 integer64 [RFC6929], TBD 1049 13 tlv [RFC6929], TBD 1050 14 evs [RFC6929], TBD 1051 15 extended [RFC6929], TBD 1052 16 long-extended [RFC6929], TBD 1054 3.2. Updates to the Attribute Type Registry 1056 This section updates the RADIUS Attribute Type Registry to have a new 1057 column, which is inserted in between the existing "Description" and 1058 "Reference" columns. The new column is named "Data Type". The 1059 contents of that column are the name of a data type, corresponding to 1060 the attribute in that row, or blank if the attribute type is 1061 unassigned. The name of the data type is taken from the RADIUS Data 1062 Type registry, defined above. 1064 The updated registry follows in CSV format. 1066 Value,Description,Data Type,Reference 1067 1,User-Name,string,[RFC2865] 1068 2,User-Password,string,[RFC2865] 1069 3,CHAP-Password,string,[RFC2865] 1070 4,NAS-IP-Address,ipv4addr,[RFC2865] 1071 5,NAS-Port,integer,[RFC2865] 1072 6,Service-Type,enum,[RFC2865] 1073 7,Framed-Protocol,enum,[RFC2865] 1074 8,Framed-IP-Address,ipv4addr,[RFC2865] 1075 9,Framed-IP-Netmask,ipv4addr,[RFC2865] 1076 10,Framed-Routing,enum,[RFC2865] 1077 11,Filter-Id,text,[RFC2865] 1078 12,Framed-MTU,integer,[RFC2865] 1079 13,Framed-Compression,enum,[RFC2865] 1080 14,Login-IP-Host,ipv4addr,[RFC2865] 1081 15,Login-Service,enum,[RFC2865] 1082 16,Login-TCP-Port,integer,[RFC2865] 1083 17,Unassigned,, 1084 18,Reply-Message,text,[RFC2865] 1085 19,Callback-Number,text,[RFC2865] 1086 20,Callback-Id,text,[RFC2865] 1087 21,Unassigned,, 1088 22,Framed-Route,text,[RFC2865] 1089 23,Framed-IPX-Network,ipv4addr,[RFC2865] 1090 24,State,string,[RFC2865] 1091 25,Class,string,[RFC2865] 1092 26,Vendor-Specific,vsa,[RFC2865] 1093 27,Session-Timeout,integer,[RFC2865] 1094 28,Idle-Timeout,integer,[RFC2865] 1095 29,Termination-Action,enum,[RFC2865] 1096 30,Called-Station-Id,text,[RFC2865] 1097 31,Calling-Station-Id,text,[RFC2865] 1098 32,NAS-Identifier,text,[RFC2865] 1099 33,Proxy-State,string,[RFC2865] 1100 34,Login-LAT-Service,text,[RFC2865] 1101 35,Login-LAT-Node,text,[RFC2865] 1102 36,Login-LAT-Group,string,[RFC2865] 1103 37,Framed-AppleTalk-Link,integer,[RFC2865] 1104 38,Framed-AppleTalk-Network,integer,[RFC2865] 1105 39,Framed-AppleTalk-Zone,text,[RFC2865] 1106 40,Acct-Status-Type,enum,[RFC2866] 1107 41,Acct-Delay-Time,integer,[RFC2866] 1108 42,Acct-Input-Octets,integer,[RFC2866] 1109 43,Acct-Output-Octets,integer,[RFC2866] 1110 44,Acct-Session-Id,text,[RFC2866] 1111 45,Acct-Authentic,enum,[RFC2866] 1112 46,Acct-Session-Time,integer,[RFC2866] 1113 47,Acct-Input-Packets,integer,[RFC2866] 1114 48,Acct-Output-Packets,integer,[RFC2866] 1115 49,Acct-Terminate-Cause,enum,[RFC2866] 1116 50,Acct-Multi-Session-Id,text,[RFC2866] 1117 51,Acct-Link-Count,integer,[RFC2866] 1118 52,Acct-Input-Gigawords,integer,[RFC2869] 1119 53,Acct-Output-Gigawords,integer,[RFC2869] 1120 54,Unassigned,, 1121 55,Event-Timestamp,time,[RFC2869] 1122 56,Egress-VLANID,integer,[RFC4675] 1123 57,Ingress-Filters,enum,[RFC4675] 1124 58,Egress-VLAN-Name,text,[RFC4675] 1125 59,User-Priority-Table,string,[RFC4675] 1126 60,CHAP-Challenge,string,[RFC2865] 1127 61,NAS-Port-Type,enum,[RFC2865] 1128 62,Port-Limit,integer,[RFC2865] 1129 63,Login-LAT-Port,text,[RFC2865] 1130 64,Tunnel-Type,enum,[RFC2868] 1131 65,Tunnel-Medium-Type,enum,[RFC2868] 1132 66,Tunnel-Client-Endpoint,text,[RFC2868] 1133 67,Tunnel-Server-Endpoint,text,[RFC2868] 1134 68,Acct-Tunnel-Connection,text,[RFC2867] 1135 69,Tunnel-Password,text,[RFC2868] 1136 70,ARAP-Password,string,[RFC2869] 1137 71,ARAP-Features,string,[RFC2869] 1138 72,ARAP-Zone-Access,enum,[RFC2869] 1139 73,ARAP-Security,integer,[RFC2869] 1140 74,ARAP-Security-Data,text,[RFC2869] 1141 75,Password-Retry,integer,[RFC2869] 1142 76,Prompt,enum,[RFC2869] 1143 77,Connect-Info,text,[RFC2869] 1144 78,Configuration-Token,text,[RFC2869] 1145 79,EAP-Message,concat,[RFC2869] 1146 80,Message-Authenticator,string,[RFC2869] 1147 81,Tunnel-Private-Group-ID,text,[RFC2868] 1148 82,Tunnel-Assignment-ID,text,[RFC2868] 1149 83,Tunnel-Preference,integer,[RFC2868] 1150 84,ARAP-Challenge-Response,string,[RFC2869] 1151 85,Acct-Interim-Interval,integer,[RFC2869] 1152 86,Acct-Tunnel-Packets-Lost,integer,[RFC2867] 1153 87,NAS-Port-Id,text,[RFC2869] 1154 88,Framed-Pool,text,[RFC2869] 1155 89,CUI,string,[RFC4372] 1156 90,Tunnel-Client-Auth-ID,text,[RFC2868] 1157 91,Tunnel-Server-Auth-ID,text,[RFC2868] 1158 92,NAS-Filter-Rule,text,[RFC4849] 1159 93,Unassigned,, 1160 94,Originating-Line-Info,string,[RFC7155] 1161 95,NAS-IPv6-Address,ipv6addr,[RFC3162] 1162 96,Framed-Interface-Id,ifid,[RFC3162] 1163 97,Framed-IPv6-Prefix,ipv6prefix,[RFC3162] 1164 98,Login-IPv6-Host,ipv6addr,[RFC3162] 1165 99,Framed-IPv6-Route,text,[RFC3162] 1166 100,Framed-IPv6-Pool,text,[RFC3162] 1167 101,Error-Cause Attribute,enum,[RFC3576] 1168 102,EAP-Key-Name,string,[RFC4072][RFC7268] 1169 103,Digest-Response,text,[RFC5090] 1170 104,Digest-Realm,text,[RFC5090] 1171 105,Digest-Nonce,text,[RFC5090] 1172 106,Digest-Response-Auth,text,[RFC5090] 1173 107,Digest-Nextnonce,text,[RFC5090] 1174 108,Digest-Method,text,[RFC5090] 1175 109,Digest-URI,text,[RFC5090] 1176 110,Digest-Qop,text,[RFC5090] 1177 111,Digest-Algorithm,text,[RFC5090] 1178 112,Digest-Entity-Body-Hash,text,[RFC5090] 1179 113,Digest-CNonce,text,[RFC5090] 1180 114,Digest-Nonce-Count,text,[RFC5090] 1181 115,Digest-Username,text,[RFC5090] 1182 116,Digest-Opaque,text,[RFC5090] 1183 117,Digest-Auth-Param,text,[RFC5090] 1184 118,Digest-AKA-Auts,text,[RFC5090] 1185 119,Digest-Domain,text,[RFC5090] 1186 120,Digest-Stale,text,[RFC5090] 1187 121,Digest-HA1,text,[RFC5090] 1188 122,SIP-AOR,text,[RFC5090] 1189 123,Delegated-IPv6-Prefix,ipv6prefix,[RFC4818] 1190 124,MIP6-Feature-Vector,string,[RFC5447] 1191 125,MIP6-Home-Link-Prefix,ipv6prefix,[RFC5447] 1192 126,Operator-Name,text,[RFC5580] 1193 127,Location-Information,string,[RFC5580] 1194 128,Location-Data,string,[RFC5580] 1195 129,Basic-Location-Policy-Rules,string,[RFC5580] 1196 130,Extended-Location-Policy-Rules,string,[RFC5580] 1197 131,Location-Capable,enum,[RFC5580] 1198 132,Requested-Location-Info,enum,[RFC5580] 1199 133,Framed-Management-Protocol,enum,[RFC5607] 1200 134,Management-Transport-Protection,enum,[RFC5607] 1201 135,Management-Policy-Id,text,[RFC5607] 1202 136,Management-Privilege-Level,integer,[RFC5607] 1203 137,PKM-SS-Cert,concat,[RFC5904] 1204 138,PKM-CA-Cert,concat,[RFC5904] 1205 139,PKM-Config-Settings,string,[RFC5904] 1206 140,PKM-Cryptosuite-List,string,[RFC5904] 1207 141,PKM-SAID,text,[RFC5904] 1208 142,PKM-SA-Descriptor,string,[RFC5904] 1209 143,PKM-Auth-Key,string,[RFC5904] 1210 144,DS-Lite-Tunnel-Name,text,[RFC6519] 1211 145,Mobile-Node-Identifier,string,[RFC6572] 1212 146,Service-Selection,text,[RFC6572] 1213 147,PMIP6-Home-LMA-IPv6-Address,ipv6addr,[RFC6572] 1214 148,PMIP6-Visited-LMA-IPv6-Address,ipv6addr,[RFC6572] 1215 149,PMIP6-Home-LMA-IPv4-Address,ipv4addr,[RFC6572] 1216 150,PMIP6-Visited-LMA-IPv4-Address,ipv4addr,[RFC6572] 1217 151,PMIP6-Home-HN-Prefix,ipv6prefix,[RFC6572] 1218 152,PMIP6-Visited-HN-Prefix,ipv6prefix,[RFC6572] 1219 153,PMIP6-Home-Interface-ID,ifid,[RFC6572] 1220 154,PMIP6-Visited-Interface-ID,ifid,[RFC6572] 1221 155,PMIP6-Home-IPv4-HoA,ipv4prefix,[RFC6572] 1222 156,PMIP6-Visited-IPv4-HoA,ipv4prefix,[RFC6572] 1223 157,PMIP6-Home-DHCP4-Server-Address,ipv4addr,[RFC6572] 1224 158,PMIP6-Visited-DHCP4-Server-Address,ipv4addr,[RFC6572] 1225 159,PMIP6-Home-DHCP6-Server-Address,ipv6addr,[RFC6572] 1226 160,PMIP6-Visited-DHCP6-Server-Address,ipv6addr,[RFC6572] 1227 161,PMIP6-Home-IPv4-Gateway,ipv4addr,[RFC6572] 1228 162,PMIP6-Visited-IPv4-Gateway,ipv4addr,[RFC6572] 1229 163,EAP-Lower-Layer,enum,[RFC6677] 1230 164,GSS-Acceptor-Service-Name,text,[RFC7055] 1231 165,GSS-Acceptor-Host-Name,text,[RFC7055] 1232 166,GSS-Acceptor-Service-Specifics,text,[RFC7055] 1233 167,GSS-Acceptor-Realm-Name,text,[RFC7055] 1234 168,Framed-IPv6-Address,ipv6addr,[RFC6911] 1235 169,DNS-Server-IPv6-Address,ipv6addr,[RFC6911] 1236 170,Route-IPv6-Information,ipv6prefix,[RFC6911] 1237 171,Delegated-IPv6-Prefix-Pool,text,[RFC6911] 1238 172,Stateful-IPv6-Address-Pool,text,[RFC6911] 1239 173,IPv6-6rd-Configuration,tlv,[RFC6930] 1240 174,Allowed-Called-Station-Id,text,[RFC7268] 1241 175,EAP-Peer-Id,string,[RFC7268] 1242 176,EAP-Server-Id,string,[RFC7268] 1243 177,Mobility-Domain-Id,integer,[RFC7268] 1244 178,Preauth-Timeout,integer,[RFC7268] 1245 179,Network-Id-Name,string,[RFC7268] 1246 180,EAPoL-Announcement,concat,[RFC7268] 1247 181,WLAN-HESSID,text,[RFC7268] 1248 182,WLAN-Venue-Info,integer,[RFC7268] 1249 183,WLAN-Venue-Language,string,[RFC7268] 1250 184,WLAN-Venue-Name,text,[RFC7268] 1251 185,WLAN-Reason-Code,integer,[RFC7268] 1252 186,WLAN-Pairwise-Cipher,integer,[RFC7268] 1253 187,WLAN-Group-Cipher,integer,[RFC7268] 1254 188,WLAN-AKM-Suite,integer,[RFC7268] 1255 189,WLAN-Group-Mgmt-Cipher,integer,[RFC7268] 1256 190,WLAN-RF-Band,integer,[RFC7268] 1257 191,Unassigned,, 1258 192-223,Experimental Use,,[RFC3575] 1259 224-240,Implementation Specific,,[RFC3575] 1260 241,Extended-Attribute-1,extended,[RFC6929] 1261 241.{1-25},Unassigned,, 1262 241.26,Extended-Vendor-Specific-1,evs,[RFC6929] 1263 241.{27-240},Unassigned,, 1264 241.{241-255},Reserved,,[RFC6929] 1265 242,Extended-Attribute-2,extended,[RFC6929] 1266 242.{1-25},Unassigned,, 1267 242.26,Extended-Vendor-Specific-2,evs,[RFC6929] 1268 242.{27-240},Unassigned,, 1269 242.{241-255},Reserved,,[RFC6929] 1270 243,Extended-Attribute-3,extended,[RFC6929] 1271 243.{1-25},Unassigned,, 1272 243.26,Extended-Vendor-Specific-3,evs,[RFC6929] 1273 243.{27-240},Unassigned,, 1274 243.{241-255},Reserved,,[RFC6929] 1275 244,Extended-Attribute-4,extended,[RFC6929] 1276 244.{1-25},Unassigned,, 1277 244.26,Extended-Vendor-Specific-4,evs,[RFC6929] 1278 244.{27-240},Unassigned,, 1279 244.{241-255},Reserved,,[RFC6929] 1280 245,Extended-Attribute-5,long-extended,[RFC6929] 1281 245.{1-25},Unassigned,, 1282 245.26,Extended-Vendor-Specific-5,evs,[RFC6929] 1283 245.{27-240},Unassigned,, 1284 245.{241-255},Reserved,,[RFC6929] 1285 246,Extended-Attribute-6,long-extended,[RFC6929] 1286 246.{1-25},Unassigned,, 1287 246.26,Extended-Vendor-Specific-6,evs,[RFC6929] 1288 246.{27-240},Unassigned,, 1289 246.{241-255},Reserved,,[RFC6929] 1290 247-255,Reserved,,[RFC3575] 1292 4. Suggestions for Specifications 1294 We suggest that these data types be used in new RADIUS 1295 specifications. Attributes can usually be completely described 1296 through their Attribute Type code, name, and data type. The use of 1297 "ASCII art" is then limited only to the definition of new data types, 1298 and complex data types. 1300 Use of the new extended attributes [RFC6929] makes ASCII art even 1301 more problematic. An attribute can be allocated from the standard 1302 space, or from one of the extended spaces. This allocation decision 1303 is made after the specification has been accepted for publication. 1304 That allocation strongly affects the format of the attribute header, 1305 making it nearly impossible to create the correct ASCII art prior to 1306 final publication. Allocation from the different spaces also changes 1307 the value of the Length field, also making it difficult to define it 1308 correctly prior to final publication of the document. 1310 The following fields SHOULD be given when defining new attributes: 1312 Description 1314 A description of the meaning and interpretation of the attribute. 1316 Type 1318 The Attribute Type code, given in the "dotted number" notation 1319 from [RFC6929]. Specifications can often leave this as "TBD", and 1320 request that IANA fill in the allocated values. 1322 Length 1324 A description of the length of the attribute. For attributes of 1325 variable length, a maximum length SHOULD be given. 1327 Data Type 1329 One of the named data types from the RADIUS Data Type registry. 1331 Value 1333 A description of any attribute-specific limitations on the values 1334 carried by the specified data type. If there are no attribute- 1335 specific limitations, then the description of this field can be 1336 omitted. 1338 Where the values are limited to a subset of the possible range, 1339 valid range(s) MUST be defined. 1341 For attributes of data type "enum", a list of enumerated values 1342 and names MUST be given, as with [RFC2865] Section 5.6. 1344 5. Security Considerations 1346 This specification is concerned solely with updates to IANA 1347 registries. As such, there are no security considerations with the 1348 document itself. 1350 However, the use of inconsistent names and poorly-defined entities in 1351 a protocol is problematic. Inconsistencies in specifications can 1352 lead to security and interoperability problems in implementations. 1353 Further, having one canonical source for the definition of data types 1354 means an implementor has fewer specifications to read. The 1355 implementation work is therefore simpler, and is more likely to be 1356 correct. 1358 The goal of this specification is to reduce ambiguities in the RADIUS 1359 protocol, which we believe will lead to more robust and more secure 1360 implementations. 1362 6. IANA Considerations 1364 IANA is instructed to create one new registry as described above in 1365 Section 3.1. The "TBD" text in that section should be replaced with 1366 the RFC number of this document when it is published. 1368 IANA is instructed to update the RADIUS Attribute Type registry, as 1369 described above in Section 3.2. 1371 IANA is instructed to require that all allocation requests in the 1372 RADIUS Attribute Type Registry contain a "data type" field. That 1373 field is required to contain one of the "data type" names contained 1374 in the RADIUS Data Type registry. 1376 7. References 1378 7.1. Normative References 1380 [RFC2119] 1381 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1382 Levels", RFC 2119, March, 1997. 1384 [RFC2865] 1385 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1386 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1388 [RFC3629] 1389 Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1390 3629, November 2003. 1392 [RFC6158] 1393 DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 6158, 1394 March 2011. 1396 [RFC6572] 1397 Xia, F., et al, "RADIUS Support for Proxy Mobile IPv6", RFC 6572, 1398 June 2012. 1400 7.2. Informative References 1402 [RFC2868] 1403 Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. 1404 Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 1405 June 2000. 1407 [RFC2869] 1408 Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000. 1410 [RFC3162] 1411 Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, 1412 August 2001. 1414 [RFC6929] 1415 DeKok, A., and Lior, A., "Remote Authentication Dial In User 1416 Service (RADIUS) Protocol Extensions", RFC 6929, April 2013. 1418 [PEN] 1419 http://www.iana.org/assignments/enterprise-numbers 1421 Acknowledgments 1423 Stuff 1425 Authors' Addresses 1427 Alan DeKok 1428 The FreeRADIUS Server Project 1430 Email: aland@freeradius.org