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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/