--- 1/draft-ietf-radext-datatypes-03.txt 2016-06-22 07:15:57.089781984 -0700 +++ 2/draft-ietf-radext-datatypes-04.txt 2016-06-22 07:15:57.149783481 -0700 @@ -1,21 +1,21 @@ Network Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Updates: 2865,3162,6158,6572 Category: Standards Track - -6 May 2016 + +22 June 2016 Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) - draft-ietf-radext-datatypes-03.txt + draft-ietf-radext-datatypes-04.txt Abstract RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least RFC 2865. We provide an IANA registry for the data types, and update the @@ -37,21 +37,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on November 6, 2016. + This Internet-Draft will expire on January 22, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info/) in effect on the date of publication of this document. Please review these documents @@ -80,34 +80,34 @@ 3.2. enum ................................................ 12 3.3. time ................................................ 13 3.4. text ................................................ 13 3.5. string .............................................. 14 3.6. concat .............................................. 15 3.7. ifid ................................................ 16 3.8. ipv4addr ............................................ 17 3.9. ipv6addr ............................................ 17 3.10. ipv6prefix ......................................... 18 3.11. ipv4prefix ......................................... 19 - 3.12. integer64 .......................................... 20 + 3.12. integer64 .......................................... 21 3.13. tlv ................................................ 21 3.14. vsa ................................................ 23 3.15. extended ........................................... 24 3.16. long-extended ...................................... 25 - 3.17. evs ................................................ 27 + 3.17. evs ................................................ 28 4. Updated Registries ....................................... 29 4.1. Create a Data Type Registry ......................... 29 4.2. Updates to the Attribute Type Registry .............. 30 5. Security Considerations .................................. 35 6. IANA Considerations ...................................... 35 7. References ............................................... 36 7.1. Normative References ................................ 36 - 7.2. Informative References .............................. 36 + 7.2. Informative References .............................. 37 1. Introduction RADIUS specifications have historically defined attributes in terms of name, type value, and data type. Of these three pieces of information, only the type value is managed by IANA. There is no management of, or restriction on, the attribute name, as discussed in [RFC6929] Section 2.7.1. There is no management of data type name or definition. Experience has shown that there is a need for well defined data types. @@ -257,21 +257,21 @@ Attributes can usually be completely described via the Attribute Type code, name, and data type. The use of "ASCII art" is then limited only to the definition of new data types, and for complex data types. Use of the new extended attributes [RFC6929] makes ASCII art even more problematic. An attribute can be allocated from any of the extended spaces, with more than one option for attribute header format. This allocation decision is made after the specification has been accepted for publication. As the allocation affects the format - of the attribute header, it is esstentially impossible to create the + of the attribute header, it is essentially impossible to create the correct ASCII art prior to final publication. Allocation from the different spaces also changes the value of the Length field, also making it difficult to define it correctly prior to final publication of the document. It is therefore RECOMMENDED that "ASCII art" diagrams not be used for new RADIUS attribute specifications. 2.1.3. Format of Attribute Definitions @@ -829,25 +829,41 @@ | Reserved | Prefix-Length | Prefix ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subfields Reserved This field, which is reserved and MUST be present, is always - set to zero. + set to zero. This field is one octet in length. + + Note that this definition differs from that given in [RFC6572]. + See Prefix-Length, below, for an explanation. + + Prefix-Length - Prefix-Length < The length of the prefix, in bits. The values MUST be no - larger than 32. + larger than 32. This field is one octet in length. + + Note that this definition differs from that given in [RFC6572]. + + As compared to [RFC6572], the Prefix-Length field has increased + in size by two bits, both of which must be zero. The Reserved + field has decreased in size by two bits. The result is that + both fields are aligned on octet boundaries, which removes the + need for bit masking of the fields. + + Since [RFC6572] required the Reserved field to be zero, the + definition here is compatible with the definition in the + original specification. Prefix The Prefix field is 4 octets in length. Bits outside of the Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type, this field is fixed length. If the address is all zeros (i.e. "0.0.0.0", then the Prefix-Length MUST be set to 32. 3.12. integer64