draft-ietf-radext-datatypes-01.txt		draft-ietf-radext-datatypes-02.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-01.txt>		<draft-ietf-radext-datatypes-02.txt>
	4 September 2015		2 November 2015
	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-01.txt		draft-ietf-radext-datatypes-02.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 March 4, 2016.		This Internet-Draft will expire on May 2, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction ............................................. 4		1. Introduction ............................................. 4
	1.1. Specification use of Data Types ..................... 4		1.1. Specification Problems with Data Types .............. 4
	1.2. Implementation use of Data Types .................... 4		1.2. Implementation Problems with Data Types ............. 5
	1.3. Requirements Language ............................... 5		1.3. No Mandated Changes ................................. 5
	2. Data Type Definitions .................................... 6		1.4. Requirements Language ............................... 5
	2.1. integer ............................................. 7		2. Use of Data Types ........................................ 6
	2.2. enum ................................................ 8		2.1. Specification Use of Data Types ..................... 6
	2.3. ipv4addr ............................................ 9		2.1.1. Field Names for Attribute Values ............... 6
	2.4. time ................................................ 9		2.1.2. Attribute Definitions using Data Types ......... 7
	2.5. text ................................................ 10		2.1.3. Format of Attribute Definitions ................ 7
	2.6. string .............................................. 11		2.1.4. Defining a New Data Type ....................... 8
	2.7. concat .............................................. 12		2.2. Implementation Use of Data Types .................... 9
	2.8. ifid ................................................ 13		3. Data Type Definitions .................................... 11
	2.9. ipv6addr ............................................ 13		3.1. integer ............................................. 12
	2.10. ipv6prefix ......................................... 14		3.2. enum ................................................ 12
	2.11. ipv4prefix ......................................... 15		3.3. ipv4addr ............................................ 13
	2.12. integer64 .......................................... 16		3.4. time ................................................ 13
	2.13. tlv ................................................ 17		3.5. text ................................................ 14
	2.14. vsa ................................................ 18		3.6. string .............................................. 15
	2.15. extended ........................................... 20		3.7. concat .............................................. 16
	2.16. long-extended ...................................... 21		3.8. ifid ................................................ 17
	2.17. evs ................................................ 23		3.9. ipv6addr ............................................ 17
	3. Updated Registries ....................................... 24		3.10. ipv6prefix ......................................... 18
	3.1. Create a Data Type Registry ......................... 24		3.11. ipv4prefix ......................................... 19
	3.2. Updates to the Attribute Type Registry .............. 25		3.12. integer64 .......................................... 20
	4. Suggestions for Specifications ........................... 30		3.13. tlv ................................................ 21
	5. Security Considerations .................................. 31		3.14. vsa ................................................ 23
	6. IANA Considerations ...................................... 32		3.15. extended ........................................... 24
	7. References ............................................... 32		3.16. long-extended ...................................... 25
	7.1. Normative References ................................ 32		3.17. evs ................................................ 27
	7.2. Informative References .............................. 33		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
	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. This document defines an IANA registry for data types,		definition. Experience has shown that there is a need for well
	and updates the RADIUS Attribute Type registry to use those newly
	defined data types.		defined data types.
			This document defines an IANA registry for data types, and updates
			the RADIUS Attribute Type registry to use those newly defined data
			types. It recommends how both specifications and implementations
			should use the data types. It extends the RADIUS Attribute Type
			registry to have a data type for each assigned attribute.
	In this section, we review the use of data types in specifications		In this section, we review the use of data types in specifications
	and implementations. Whe highlight ambiguities and inconsistencies.		and implementations. Whe highlight ambiguities and inconsistencies.
	The rest of this document is devoted to resolving those problems.		The rest of this document is devoted to resolving those problems.
	1.1. Specification use of Data Types		1.1. Specification Problems with Data Types
			When attributes are defined in the specifications, the terms "Value"
			and "String" are used to refer to the contents of an attribute.
			However, these names are used recursively and inconsistently. We
			suggest that defining a field to recursively contain itself is
			problematic.
	A number of data type names and definitions are given in [RFC2865]		A number of data type names and definitions are given in [RFC2865]
	Section 5, at the bottom of page 25. These data types are named and		Section 5, at the bottom of page 25. These data types are named and
	clearly defined. However, this practice was not continued in later		clearly defined. However, this practice was not continued in later
	specifications.		specifications.
	Specifically, [RFC2865] defines attributes of data type "address" to		Specifically, [RFC2865] defines attributes of data type "address" to
	carry IPv4 addresses. Despite this definition, [RFC3162] defines		carry IPv4 addresses. Despite this definition, [RFC3162] defines
	attributes of data type "Address" to carry IPv6 addresses. We		attributes of data type "Address" to carry IPv6 addresses. We
	suggest that the use of the word "address" to refer to disparate data		suggest that the use of the word "address" to refer to disparate data
	skipping to change at page 4, line 46		skipping to change at page 5, line 8
	not re-use the "time" data type defined in [RFC2865]. Instead, it		not re-use the "time" data type defined in [RFC2865]. Instead, it
	just repeats the "time" definition. [RFC6572] defines multiple		just repeats the "time" definition. [RFC6572] defines multiple
	attributes which carry IPv4 prefixes. However, an "IPv4 prefix" data		attributes which carry IPv4 prefixes. However, an "IPv4 prefix" data
	type is not named, defined as a data type, or called out as an		type is not named, defined as a data type, or called out as an
	addition to RADIUS. Further, [RFC6572] does not follow the		addition to RADIUS. Further, [RFC6572] does not follow the
	recommendations of [RFC6158], and does not explain why it fails to		recommendations of [RFC6158], and does not explain why it fails to
	follow those recommendations.		follow those recommendations.
	These ambiguities and inconsistencies need to be resolved.		These ambiguities and inconsistencies need to be resolved.
	1.2. Implementation use of Data Types		1.2. Implementation Problems with Data Types
	RADIUS implementations often use "dictionaries" to map attribute		RADIUS implementations often use "dictionaries" to map attribute
	names to type values, and to define data types for each attribute.		names to type values, and to define data types for each attribute.
	The data types in the dictionaries are defined by each		The data types in the dictionaries are defined by each
	implementation, but correspond to the "ad hoc" data types used in the		implementation, but correspond to the "ad hoc" data types used in the
	specifications.		specifications.
	In effect, implementations have seen the need for well-defined data		In effect, implementations have seen the need for well-defined data
	types, and have created them. It is time for RADIUS specifications		types, and have created them. It is time for RADIUS specifications
	to follow this practice.		to follow this practice.
			1.3. No Mandated Changes
	This document mandates no changes to any RADIUS implementation, past,		This document mandates no changes to any RADIUS implementation, past,
	present, or future. It instead documents existing practice, in order		present, or future. It instead documents existing practice, in order
	to simplify the process of writing RADIUS specifications, to clarify		to simplify the process of writing RADIUS specifications, to clarify
	the interpretation of RADIUS standards, and to improve the		the interpretation of RADIUS standards, and to improve the
	communication between specification authors and IANA.		communication between specification authors and IANA.
	This document suggests that implementations SHOULD use the data types		This document suggests that implementations SHOULD use the data types
	defined here, in preference to any "ad hoc" data types currently in		defined here, in preference to any "ad hoc" data types currently in
	use. This suggestion should have minimal effect on implementations,		use. This suggestion should have minimal effect on implementations,
	as most "ad hoc" data types are compatible with the ones defined		as most "ad hoc" data types are compatible with the ones defined
	here. Any difference will typically be limited to the name of the		here. Any difference will typically be limited to the name of the
	data type.		data type.
	1.3. Requirements Language		1.4. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Data Type Definitions		2. Use of Data Types
			The Data Types can be used in two places: specifications, and
			implementations. This section discusses both uses, and gives
			guidance on using the data types.
			2.1. Specification Use of Data Types
			In this section, we give recommendations for how specifications
			should be written using data types. We first describe how attribute
			field names can be consistently named. We then describe how
			attribute definitions should use the data types, and deprecate the
			use of "Ascii art" for attribute definitions. We suggest a format
			for new attribute definitions. This format includes recommended
			fields, and suggestions for how those fields should be described.
			Finally, we make recommendations for how new data types should be
			defined.
			2.1.1. Field Names for Attribute Values
			Previous specifications used inconsistent and conflicting names for
			the contents of RADIUS attributes. For example, the term "Value" is
			used in [RFC2865] Section 5 to define a field which carries the
			contents of attribute. It is then used in later sections as the sub-
			field of attribute contents. The result is that the field is defined
			as recursively containing itself. Similarly, "String" is used both
			as a data type, and as a sub-field of other data types.
			We correct this ambiguity by using context-specific names for various
			fields of attributes and data types. It then becomes clear that, for
			example, that a field called "VSA-Data" must contain different data
			than a field called "EVS-Data". Each new name is defined where it is
			used.
			We also define the following term:
			Attr-Data
			The "Value" field of an Attribute as defined in [RFC2865]
			Section 5. The contents of this field MUST be a valid data
			type as defined in the RADIUS Data Type registry.
			We consistently use "Attr-Data" to refer to the contents of an
			attribute, instead of the more ambiguous name "Value". It is
			RECOMMENDED that new specifications follow this practice.
			In this document, we use the term "Value" to refer to the contents of
			a data type, where that data type cannot carry other data types. In
			other cases, we refer to the contents of a data type with a type-
			specific name, in order to distinguish it from data of other types.
			For example, the data type "vsa" will contain a data field called
			"VSA-Data".
			These terms are used in preference to the term "String", which was
			used in multiple incompatible ways. It is RECOMMENDED that future
			specifications use type-specific names, and the same naming scheme
			for new types. This use will maintain consistent definitions, and
			avoid ambiguities.
			2.1.2. Attribute Definitions using Data Types
			New RADIUS specifications MUST define attributes using data types
			from the RADIUS Data Type registry. The specification may, of
			course, define a new data type and use it in the same document. The
			guidelines given in [RFC6929] MUST be followed when defining a new
			data type.
			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 the standard
			space, or from one of the extended spaces. This allocation decision
			is made after the specification has been accepted for publication.
			That allocation strongly affects the format of the attribute header,
			making it nearly 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
			When defining a new attribute, the following fields SHOULD be given:
			Description
			A description of the meaning and interpretation of the
			attribute.
			Type
			The Attribute Type code, given in the "dotted number" notation
			from [RFC6929]. Specifications can often leave this as "TBD",
			and request that IANA fill in the allocated values.
			Length
			A description of the length of the attribute. For attributes
			of variable length, a maximum length SHOULD be given. Since
			the Length may depend on the Type, the definition of Length may
			be affected by IANA allocations.
			Data Type
			One of the named data types from the RADIUS Data Type registry.
			Value
			A description of any attribute-specific limitations on the
			values carried by the specified data type. If there are no
			attribute-specific limitations, then the description of this
			field can be omitted, so long as the Description field is
			sufficiently explanatory.
			Where the values are limited to a subset of the possible range,
			valid range(s) MUST be defined.
			For attributes of data type "enum", a list of enumerated values
			and names MUST be given, as with [RFC2865] Section 5.6.
			Using a consistent format for attribute definitions helps to make the
			definitions clearer.
			2.1.4. Defining a New Data Type
			When a specification needs to define a new data type, it should
			follow the format used by the definitions in Section 3 of this
			document. The text at the start of the data type definition MUST
			describe the data type, including the expected use, and why a new
			data type is required. That text SHOULD include limits on expected
			values, and why those limits exist. The fields "Name", "Value",
			"Length", and "Format", MUST be given, along with values.
			The "Name" field SHOULD be a single name, all lower-case.
			Contractions such as "ipv4addr" are RECOMMENDED where they add
			clarity.
			We note that the use of "Value" in the RADIUS Data Type registry can
			be confusing. That name is also used in attribute definitions, but
			with a different meaning. We trust that the meaning here is clear
			from the context.
			The "Value" field should be given as to be determined or "TBD" in
			specifications. That number is assigned by IANA.
			The "Format" field SHOULD be defined with "Ascii art" in order to
			have a precise definition. Machine-readable formats are also
			RECOMMENDED.
			The definition of a new data type should be done only when absolutely
			necessary. We do not expect a need for a large number of new data
			types. When defining a new data type, the guideliness of [RFC6929]
			with respect to data types MUST be followed.
			It is RECOMMENDED that vendors not define "vendor specific" data
			types. As discussed in [RFC6929], those data types are rarely
			necessary, and can cause interoperability problems.
			Any new data type MUST have unique name in the RADIUS Data Type
			registry. The number of the data type will be assigned by IANA.
			2.2. Implementation Use of Data Types
			Implementations not supporting a particular data type MUST treat
			attributes of that data type as being of data type "string", as
			defined in Section 2.6. It is RECOMMENDED that such attributes be
			treated as "invalid attributes", as defined in [RFC6929] Section 2.8.
			Where the contents of a data type do not match the definition,
			implementations MUST treat the the enclosing attribute as being an
			"invalid attribute". This requirement includes, but is not limited
			to, the following situations:
			* Attributes with values outside of the allowed range(s) for the
			data type, e.g. as given in the data types "integer", "ipv4addr",
			"ipv6addr", "ipv4prefix", "ipv6prefix", or "enum".
			* "text" attributes where the contents do not match the required
			format,
			* Attributes where the length is shorter or longer than the allowed
			length(s) for the given data type,
			The requirements for "reserved" fields are more difficult to
			quantify. Implementations SHOULD be able to receive and process
			attributes where "reserved" fields are non-zero. We do not, however,
			define any "correct" processing of such attributes. Instead,
			specifications which define new meaning for "reserved" fields SHOULD
			describe how older implementations process those fields. We expect
			that such descriptions are derived from practice. Implementations
			MUST set "reserved" fields to zero when creating attributes.
			3. Data Type Definitions
	This section defines the new data types. For each data type, it		This section defines the new data types. For each data type, it
	gives a definition, a name, a number, a length, and an encoding		gives a definition, a name, a number, a length, and an encoding
	format. Where relevant, it describes subfields contained within the		format. Where relevant, it describes subfields contained within the
	data type. These definitions have no impact on existing RADIUS		data type. These definitions have no impact on existing RADIUS
	implementations. There is no requirement that implementations use		implementations. There is no requirement that implementations use
	these names.		these names.
	Where possible, the name of each data type has been taken from		Where possible, the name of each data type has been taken from
	previous specifications. In some cases, a different name has been		previous specifications. In some cases, a different name has been
	chosen. The change of name is sometimes required to avoid ambiguity		chosen. The change of name is sometimes required to avoid ambiguity
	(i.e. "address" versus "Address"). Otherwise, the new name has been		(i.e. "address" versus "Address"). Otherwise, the new name has been
	chosen to be compatible with [RFC2865], or with use in common		chosen to be compatible with [RFC2865], or with use in common
	implementations. In some cases, new names are chosen to clarify the		implementations. In some cases, new names are chosen to clarify the
	interpretation of the data type.		interpretation of the data type.
	The numbers assigned herein for the data types have no meaning other		The numbers assigned herein for the data types have no meaning other
	than to permit them to be tracked by IANA. As RADIUS does not encode		than to permit them to be tracked by IANA. As RADIUS does not encode
	information about data types in a packet, the numbers assigned to a		information about data types in a packet, the numbers assigned to a
	data type will never occur in a packet. It is RECOMMENDED that new		data type will never occur in a packet. It is RECOMMENDED that new
	implementations use the names defined herein, in order to avoid		implementations use the names defined in this document, in order to
	confusion. Existing implementations may choose to use the names		avoid confusion. Existing implementations may choose to use the
	defined herein, but that is not required.		names defined here, but that is not required.
	The encoding of each data type is taken from previous specifications.		The encoding of each data type is taken from previous specifications.
	The fields are transmitted from left to right.		The fields are transmitted from left to right.
	Where the data types have inter-dependencies, the simplest data type		Where the data types have inter-dependencies, the simplest data type
	is given first, and dependent ones are given later.		is given first, and dependent ones are given later.
	We do not create specific data types for the "tagged" attributes, as		We do not create specific data types for the "tagged" attributes
	discussed in [RFC2868]. That specification defines the "tagged"		defines in [RFC2868]. That specification defines the "tagged"
	attributes as being backwards compatible with pre-existing data		attributes as being backwards compatible with pre-existing data
	types. In addition, [RFC6158] Section 2.1 says that "tagged"		types. In addition, [RFC6158] Section 2.1 says that "tagged"
	attributes should not be used. There is therefore no benefit to		attributes should not be used. There is therefore no benefit to
	defining additional data types for these attributes. We trust that		defining additional data types for these attributes. We trust that
	implementors will be aware that tagged attributes must be treated		implementors will be aware that tagged attributes must be treated
	differently from non-tagged attributes of the same data type.		differently from non-tagged attributes of the same data type.
	Similarly, we do not create data types for some attributes having		Similarly, we do not create data types for some attributes having
	complex structure, such as CHAP-Password, ARAP-Features, or Location-		complex structure, such as CHAP-Password, ARAP-Features, or Location-
	Capable. We need to strike a balance between correcting earlier		Capable. We need to strike a balance between correcting earlier
	mistakes, and making this document more complex. In some cases, it		mistakes, and making this document more complex. In some cases, it
	is better to treat complex attributes as being of type "string", even		is better to treat complex attributes as being of type "string", even
	though they need to be interpreted by RADIUS implementations.		though they need to be interpreted by RADIUS implementations. The
			guidelines given in Section 6.3 of [RFC6969] were used to make this
	Implementations not supporting a particular data type MUST treat		determination.
	attributes of that data type as being of data type "string", as
	defined in Section 2.6. It is RECOMMENDED that such attributes be
	treated as "invalid attributes", as defined in [RFC6929] Section 2.8.
	The definitions below use specialized names for various fields of
	attributes and data types. These names serve to address ambiguity of
	the field names in previous specifications. For example, the term
	"Value" is used in [RFC2865] Section 5 to define a field which
	carries the contents of attribute. It is then used in later sections
	as the sub-field of attribute contents. The result is that the field
	is defined as recursively containing itself. Similarly, "String" is
	used both as a data type, and as a sub-field of other data types.
	This document uses slightly different terminology than previous
	specifications, in order to be avoid ambiguity. The first addition
	is the following term:
	Attr-Data
	The "Value" field of an Attribute as defined in [RFC2865]
	Section 5. The contents of this field MUST be a valid data
	type as defined in the RADIUS Data Type registry.
	In this document, we use the term "Value" only to refer to the
	contents of a data type, where that data type cannot carry other data
	types. In other cases, we refer to the contents of a data type with
	a type-specific name, in order to distinguish it from data of other
	types. For example, the data type "vsa" will contain a data field
	called "VSA-Data".
	These terms are used in preference to the term "String", which was
	used in multiple incompatible ways. It is RECOMMENDED that future
	specifications use these names, and the same naming scheme for new
	types, in order to maintain consistent definitions, and to avoid
	ambiguities.
	2.1. integer		3.1. integer
	The "integer" data type encodes a 32-bit unsigned integer in network		The "integer" data type encodes a 32-bit unsigned integer in network
	byte order. Where the range of values for a particular attribute is		byte order. Where the range of values for a particular attribute is
	limited to a sub-set of the values, specifications MUST define the		limited to a sub-set of the values, specifications MUST define the
	valid range. Attributes with Values outside of the allowed ranges		valid range. Attributes with Values outside of the allowed ranges
	SHOULD be treated as "invalid attributes".		SHOULD be treated as "invalid attributes".
	Name		Name
	integer		integer
	Number		Value
	1		1
	Length		Length
	Four octets		Four octets
	Format		Format
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value |		| Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.2. enum		3.2. enum
	The "enum" data type encodes a 32-bit unsigned integer in network		The "enum" data type encodes a 32-bit unsigned integer in network
	byte order. It differs from the "integer" data type only in that it		byte order. It differs from the "integer" data type only in that it
	is used to define enumerated types, such as Service-Type.		is used to define enumerated types, such as Service-Type (Section 5.6
	Specifications MUST define a valid set of enumerated values, along		of [RFC 2865]). Specifications MUST define a valid set of enumerated
	with a unique name for each value. Attributes with Values outside of		values, along with a unique name for each value. Attributes with
	the allowed enumerations SHOULD be treated as "invalid attributes".		Values outside of the allowed enumerations SHOULD be treated as
			"invalid attributes".
	Name		Name
	enum		enum
	Number		Value
	2		2
	Length		Length
	Four octets		Four octets
	Format		Format
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value |		| Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 9, line 5		skipping to change at page 13, line 14
	Four octets		Four octets
	Format		Format
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value |		| Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.3. ipv4addr		3.3. ipv4addr
	The "ipv4addr" data type encodes an IPv4 address in network byte		The "ipv4addr" data type encodes an IPv4 address in network byte
	order. Where the range of address for a particular attribute is		order. Where the range of address for a particular attribute is
	limited to a sub-set of possible addresses, specifications MUST		limited to a sub-set of possible addresses, specifications MUST
	define the valid range(s). Attributes with Values outside of the		define the valid range(s). Attributes with Addresses outside of the
	allowed range(s) SHOULD be treated as "invalid attributes".		allowed range(s) SHOULD be treated as "invalid attributes".
	Name		Name
	ipv4addr		ipv4addr
	Number		Value
	3		3
	Length		Length
	Four octets		Four octets
	Format		Format
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Address |		| Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.4. time		3.4. time
	The "time" data type encodes time as a 32-bit unsigned value in		The "time" data type encodes time as a 32-bit unsigned value in
	network byte order and in seconds since 00:00:00 UTC, January 1,		network byte order and in seconds since 00:00:00 UTC, January 1,
	1970. We note that dates before the year 2015 are likely to be		1970. We note that dates before the year 2015 are likely to be
	erroneous.		erroneous.
	Note that the "time" attribute is defined to be unsigned, which means		Note that the "time" attribute is defined to be unsigned, which means
	it is not subject to a signed integer overflow in the year 2038.		it is not subject to a signed integer overflow in the year 2038.
	Name		Name
	time		time
	Number		Value
	4		4
	Length		Length
	Four octets		Four octets
	Format		Format
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Time |		| Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 10, line 14		skipping to change at page 14, line 26
	Four octets		Four octets
	Format		Format
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Time |		| Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.5. text		3.5. text
	The "text" data type encodes UTF-8 text [RFC3629]. The maximum		The "text" data type encodes UTF-8 text [RFC3629]. The maximum
	length of the text is given by the encapsulating attribute. Where		length of the text is given by the encapsulating attribute. Where
	the range of lengths for a particular attribute is limited to a sub-		the range of lengths for a particular attribute is limited to a sub-
	set of possible lengths, specifications MUST define the valid		set of possible lengths, specifications MUST define the valid
	range(s). Attributes with length outside of the allowed values		range(s). Attributes with length outside of the allowed values
	SHOULD be treated as "invalid attributes".		SHOULD be treated as "invalid attributes".
	Where the text is intended to carry data in a particular format,		Where the text is intended to carry data in a particular format,
	(e.g. Framed-Route), the format MUST be given. The specification		(e.g. Framed-Route), the format MUST be given. The specification
	skipping to change at page 10, line 39		skipping to change at page 15, line 5
	Note that the "text" data type does not terminate with a NUL octet		Note that the "text" data type does not terminate with a NUL octet
	(hex 00). The Attribute has a Length field and does not use a		(hex 00). The Attribute has a Length field and does not use a
	terminator. Texts of length zero (0) MUST NOT be sent; omit the		terminator. Texts of length zero (0) MUST NOT be sent; omit the
	entire attribute instead.		entire attribute instead.
	Name		Name
	text		text
	Number		Value
	5		5
	Length		Length
	One or more octets.		One or more octets.
	Format		Format
	0		0
	skipping to change at page 11, line 4		skipping to change at page 15, line 17
	5		5
	Length		Length
	One or more octets.		One or more octets.
	Format		Format
	0		0
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-
	| Value ...		| Value ...
	+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-
	2.6. string		3.6. string
	The "string" data type encodes binary data, as a sequence of		The "string" data type encodes binary data, as a sequence of
	undistinguished octets. Where the range of lengths for a particular		undistinguished octets. Where the range of lengths for a particular
	attribute is limited to a sub-set of possible lengths, specifications		attribute is limited to a sub-set of possible lengths, specifications
	MUST define the valid range(s). Attributes with length outside of		MUST define the valid range(s). Attributes with length outside of
	the allowed values SHOULD be treated as "invalid attributes".		the allowed values SHOULD be treated as "invalid attributes".
	Note that the "string" data type does not terminate with a NUL octet		Note that the "string" data type does not terminate with a NUL octet
	(hex 00). The Attribute has a Length field and does not use a		(hex 00). The Attribute has a Length field and does not use a
	terminator. Strings of length zero (0) MUST NOT be sent; omit the		terminator. Strings of length zero (0) MUST NOT be sent; omit the
	skipping to change at page 11, line 39		skipping to change at page 16, line 4
	There is little reason to define a new RADIUS data type for only one		There is little reason to define a new RADIUS data type for only one
	attribute. However, where the complex data type cannot be		attribute. However, where the complex data type cannot be
	represented as TLVs, and is expected to be used in many attributes, a		represented as TLVs, and is expected to be used in many attributes, a
	new data type SHOULD be defined.		new data type SHOULD be defined.
	These requirements are stronger than [RFC6158], which makes the above		These requirements are stronger than [RFC6158], which makes the above
	encapsulation a "SHOULD". This document defines data types for use		encapsulation a "SHOULD". This document defines data types for use
	in RADIUS, so there are few reasons to avoid using them.		in RADIUS, so there are few reasons to avoid using them.
	Name		Name
	string		string
	Number		Value
	6		6
	Length		Length
	One or more octets.		One or more octets.
	Format		Format
	0		0
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-
	| Octets ...		| Octets ...
	+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-
	2.7. concat		3.7. concat
	The "concat" data type permits the transport of more than 253 octets		The "concat" data type permits the transport of more than 253 octets
	of data in a "standard space" [RFC6929] attribute. It is otherwise		of data in a "standard space" [RFC6929] attribute. It is otherwise
	identical to the "string" data type.		identical to the "string" data type.
	If multiple attributes of this data type are contained in a packet,		If multiple attributes of this data type are contained in a packet,
	all attributes of the same type code MUST be in order and they MUST		all attributes of the same type code MUST be in order and they MUST
	be consecutive attributes in the packet.		be consecutive attributes in the packet.
	The amount of data transported in a "concat" data type can be no more		The amount of data transported in a "concat" data type can be no more
	skipping to change at page 12, line 37		skipping to change at page 16, line 49
	The "concat" data type MAY be used for "standard space" attributes.		The "concat" data type MAY be used for "standard space" attributes.
	It MUST NOT be used for attributes in the "short extended space" or		It MUST NOT be used for attributes in the "short extended space" or
	the "long extended space". It MUST NOT be used in any field or		the "long extended space". It MUST NOT be used in any field or
	subfields of the following data types: "tlv", "vsa", "extended",		subfields of the following data types: "tlv", "vsa", "extended",
	"long-extended", or "evs".		"long-extended", or "evs".
	Name		Name
	concat		concat
	Number		Value
	7		7
	Length		Length
	One or more octets.		One or more octets.
	Format		Format
	0		0
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	skipping to change at page 13, line 4		skipping to change at page 17, line 16
	Length		Length
	One or more octets.		One or more octets.
	Format		Format
	0		0
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-
	| Octets ...		| Octets ...
	+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-
	2.8. ifid		3.8. ifid
	The "ifid" data type encodes an Interface-Id as an 8-octet string in		The "ifid" data type encodes an Interface-Id as an 8-octet string in
	network byte order.		network byte order.
	Name		Name
	ifid		ifid
	Number		Value
	8		8
	Length		Length
	Eight octets		Eight octets
	Format		Format
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface-ID ...		| Interface-ID ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Interface-ID |		... Interface-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.9. ipv6addr		3.9. ipv6addr
	The "ipv6addr" data type encodes an IPv6 address in network byte		The "ipv6addr" data type encodes an IPv6 address in network byte
	order. Where the range of address for a particular attribute is		order. Where the range of address for a particular attribute is
	limited to a sub-set of possible addresses, specifications MUST		limited to a sub-set of possible addresses, specifications MUST
	define the valid range(s). Attributes with Values outside of the		define the valid range(s). Attributes with Addresses outside of the
	allowed range(s) SHOULD be treated as "invalid attributes".		allowed range(s) SHOULD be treated as "invalid attributes".
	Name		Name
	ipv6addr		ipv6addr
	Number		Value
	9		9
	Length		Length
	Sixteen octets		Sixteen octets
	Format		Format
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Address ...		| Address ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Address ...		... Address ...
	skipping to change at page 14, line 20		skipping to change at page 18, line 33
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Address ...		| Address ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Address ...		... Address ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Address ...		... Address ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Address |		... Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.10. ipv6prefix		3.10. ipv6prefix
	The "ipv6prefix" data type encodes an IPv6 prefix, using both a		The "ipv6prefix" data type encodes an IPv6 prefix, using both a
	prefix length and an IPv6 address in network byte order. Where the		prefix length and an IPv6 address in network byte order. Where the
	range of prefixes for a particular attribute is limited to a sub-set		range of prefixes for a particular attribute is limited to a sub-set
	of possible prefixes, specifications MUST define the valid range(s).		of possible prefixes, specifications MUST define the valid range(s).
	Attributes with Values outside of the allowed range(s) SHOULD be		Attributes with Addresses outside of the allowed range(s) SHOULD be
	treated as "invalid attributes".		treated as "invalid attributes".
	Attributes with a Prefix-Length field having value greater than 128		Attributes with a Prefix-Length field having value greater than 128
	SHOULD be treated as "invalid attributes".		SHOULD be treated as "invalid attributes".
	Name		Name
	ipv6prefix		ipv6prefix
	Number		Value
	10		10
	Length		Length
	At least two, and no more than eighteen octets.		At least two, and no more than eighteen octets.
	Format		Format
	0 1 2 3		0 1 2 3
	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		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
	skipping to change at page 15, line 28		skipping to change at page 19, line 41
	Prefix-Length		Prefix-Length
	The length of the prefix, in bits. At least 0 and no larger		The length of the prefix, in bits. At least 0 and no larger
	than 128.		than 128.
	Prefix		Prefix
	The Prefix field is up to 16 octets in length. Bits outside of		The Prefix field is up to 16 octets in length. Bits outside of
	the Prefix-Length, if included, MUST be zero.		the Prefix-Length, if included, MUST be zero.
	2.11. ipv4prefix		3.11. ipv4prefix
	The "ipv4prefix" data type encodes an IPv4 prefix, using both a		The "ipv4prefix" data type encodes an IPv4 prefix, using both a
	prefix length and an IPv4 address in network byte order. Where the		prefix length and an IPv4 address in network byte order. Where the
	range of prefixes for a particular attribute is limited to a sub-set		range of prefixes for a particular attribute is limited to a sub-set
	of possible prefixes, specifications MUST define the valid range(s).		of possible prefixes, specifications MUST define the valid range(s).
	Attributes with Values outside of the allowed range(s) SHOULD be		Attributes with Addresses outside of the allowed range(s) SHOULD be
	treated as "invalid attributes".		treated as "invalid attributes".
	Attributes with a Prefix-Length field having value greater than 32		Attributes with a Prefix-Length field having value greater than 32
	SHOULD be treated as "invalid attributes".		SHOULD be treated as "invalid attributes".
	Name		Name
	ipv4prefix		ipv4prefix
	Number		Value
	11		11
	Length		Length
	At least two, and no more than eighteen octets.		At least two, and no more than eighteen octets.
	Format		Format
	0 1 2 3		0 1 2 3
	skipping to change at page 16, line 34		skipping to change at page 20, line 47
	A 6-bit unsigned integer containing the length of the prefix,		A 6-bit unsigned integer containing the length of the prefix,
	in bits. The values MUST be no larger than 32.		in bits. The values MUST be no larger than 32.
	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.
	2.12. integer64		3.12. integer64
	The "integer64" data type encodes a 64-bit unsigned integer in		The "integer64" data type encodes a 64-bit unsigned integer in
	network byte order. Where the range of values for a particular		network byte order. Where the range of values for a particular
	attribute is limited to a sub-set of the values, specifications MUST		attribute is limited to a sub-set of the values, specifications MUST
	define the valid range(s). Attributes with Values outside of the		define the valid range(s). Attributes with Values outside of the
	allowed range(s) SHOULD be treated as "invalid attributes".		allowed range(s) SHOULD be treated as "invalid attributes".
	Name		Name
	integer64		integer64
	Number		Value
	12		12
	Length		Length
	Eight octets		Eight octets
	Format		Format
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value ...		| Value ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Value |		... Value |
	skipping to change at page 17, line 16		skipping to change at page 21, line 30
	Format		Format
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value ...		| Value ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Value |		... Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.13. tlv		3.13. tlv
	The "tlv" data type encodes a type-length-value, as defined in		The "tlv" data type encodes a type-length-value, as defined in
	[RFC6929] Section 2.3.		[RFC6929] Section 2.3.
	Name		Name
	tlv		tlv
	Number		Value
	13		13
	Length		Length
	Three or more octets		Three or more octets
	Format		Format
	0 1 2 3		0 1 2 3
	skipping to change at page 17, line 47		skipping to change at page 22, line 15
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TLV-Type | TLV-Length | TLV-Data ...		| TLV-Type | TLV-Length | TLV-Data ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Subfields		Subfields
	TLV-Type		TLV-Type
	This field is one octet. Up-to-date values of this field are		This field is one octet. Up-to-date values of this field are
	specified according to the policies and rules described in		specified according to the policies and rules described in
	[RFC6929] Section 10. Values 254-255 are "Reserved" for use by		[RFC6929] Section 10. Values of 254-255 are "Reserved" for use
	future extensions to RADIUS. The value 26 has no special		by future extensions to RADIUS. The value 26 has no special
	meaning, and MUST NOT be treated as a Vendor Specific		meaning, and MUST NOT be treated as a Vendor Specific
	attribute.		attribute.
	The TLV-Type is meaningful only within the context defined by		The TLV-Type is meaningful only within the context defined by
	"Type" fields of the encapsulating Attributes, using the		"Type" fields of the encapsulating Attributes, using the
	dotted-number notation introduced in [RFC6929].		dotted-number notation introduced in [RFC6929].
	A RADIUS server MAY ignore Attributes with an unknown "TLV-		A RADIUS server MAY ignore Attributes with an unknown "TLV-
	Type".		Type".
	skipping to change at page 18, line 42		skipping to change at page 23, line 9
	The TLV-Data field is one or more octets and contains		The TLV-Data field is one or more octets and contains
	information specific to the Attribute. The format and length		information specific to the Attribute. The format and length
	of the TLV-Data field is determined by the TLV-Type and TLV-		of the TLV-Data field is determined by the TLV-Type and TLV-
	Length fields.		Length fields.
	The TLV-Data field MUST contain only known RADIUS data types.		The TLV-Data field MUST contain only known RADIUS data types.
	The TLV-Data field MUST NOT contain any of the following data		The TLV-Data field MUST NOT contain any of the following data
	types: "concat", "vsa", "extended", "long-extended", or "evs".		types: "concat", "vsa", "extended", "long-extended", or "evs".
	2.14. vsa		3.14. vsa
	The "vsa" data type encodes Vendor-Specific data, as given in		The "vsa" data type encodes Vendor-Specific data, as given in
	[RFC2865] Section 5.26. It is used only in the Attr-Data field of a		[RFC2865] Section 5.26. It is used only in the Attr-Data field of a
	Vendor-Specific Attribute. It MUST NOT appear in the contents of any		Vendor-Specific Attribute. It MUST NOT appear in the contents of any
	other data type.		other data type.
	Where an implementation determines that an attribute of data type		Where an implementation determines that an attribute of data type
	"vsa" contains data which does not match the expected format, it		"vsa" contains data which does not match the expected format, it
	SHOULD treat that attribute as being an "invalid attribute".		SHOULD treat that attribute as being an "invalid attribute".
	Name		Name
	vsa		vsa
	Number		Value
	14		14
	Length		Length
	Five or more octets		Five or more octets
	Format		Format
	0 1 2 3		0 1 2 3
	skipping to change at page 20, line 5		skipping to change at page 24, line 19
	outside the scope of this specification.		outside the scope of this specification.
	The "vsa" data type SHOULD contain as a sequence of "tlv" data		The "vsa" data type SHOULD contain as a sequence of "tlv" data
	types. The interpretation of the TLV-Type and TLV-Data fields		types. The interpretation of the TLV-Type and TLV-Data fields
	are dependent on the vendor's definition of that attribute.		are dependent on the vendor's definition of that attribute.
	The "vsa" data type MUST be used as contents of the Attr-Data		The "vsa" data type MUST be used as contents of the Attr-Data
	field of the Vendor-Specific attribute. The "vsa" data type		field of the Vendor-Specific attribute. The "vsa" data type
	MUST NOT appear in the contents of any other data type.		MUST NOT appear in the contents of any other data type.
	2.15. extended		3.15. extended
	The "extended" data type encodes the "Extended Type" format, as given		The "extended" data type encodes the "Extended Type" format, as given
	in [RFC6929] Section 2.1. It is used only in the Attr-Data field of		in [RFC6929] Section 2.1. It is used only in the Attr-Data field of
	an Attribute allocated from the "standard space". It MUST NOT appear		an Attribute allocated from the "standard space". It MUST NOT appear
	in the contents of any other data type.		in the contents of any other data type.
	Name		Name
	extended		extended
	Number		Value
	15		15
	Length		Length
	Two or more octets		Two or more octets
	Format		Format
	0 1 2 3		0 1 2 3
	skipping to change at page 21, line 18		skipping to change at page 25, line 34
	in the RADIUS Data Type registry. The Ext-Data field MUST NOT		in the RADIUS Data Type registry. The Ext-Data field MUST NOT
	contain any of the following data types: "concat", "vsa",		contain any of the following data types: "concat", "vsa",
	"extended", "long-extended", or "evs".		"extended", "long-extended", or "evs".
	The Ext-Data field is one or more octets.		The Ext-Data field is one or more octets.
	Implementations supporting this specification MUST use the		Implementations supporting this specification MUST use the
	Identifier of "Type.Extended-Type" to determine the		Identifier of "Type.Extended-Type" to determine the
	interpretation of the Ext-Data field.		interpretation of the Ext-Data field.
	2.16. long-extended		3.16. long-extended
	The "long-extended" data type encodes the "Long Extended Type"		The "long-extended" data type encodes the "Long Extended Type"
	format, as given in [RFC6929] Section 2.2. It is used only in the		format, as given in [RFC6929] Section 2.2. It is used only in the
	Attr-Data field of an Attribute. It MUST NOT appear in the contents		Attr-Data field of an Attribute. It MUST NOT appear in the contents
	of any other data type.		of any other data type.
	Name		Name
	long-extended		long-extended
	Number		Value
	16		16
	Length		Length
	Three or more octets		Three or more octets
	Format		Format
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Extended-Type |M| Reserved | Ext-Data ...		| Extended-Type |M| Reserved | Ext-Data ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 23, line 22		skipping to change at page 27, line 39
	occur after the fragments have been reassembled. If the		occur after the fragments have been reassembled. If the
	reassembled data does not match the expected format, each		reassembled data does not match the expected format, each
	fragment MUST be treated as an "invalid attribute", and the		fragment MUST be treated as an "invalid attribute", and the
	reassembled data MUST be discarded.		reassembled data MUST be discarded.
	We note that the maximum size of a fragmented attribute is		We note that the maximum size of a fragmented attribute is
	limited only by the RADIUS packet length limitation.		limited only by the RADIUS packet length limitation.
	Implementations MUST be able to handle the case where one		Implementations MUST be able to handle the case where one
	fragmented attribute completely fills the packet.		fragmented attribute completely fills the packet.
	2.17. evs		3.17. evs
	The "evs" data type encodes an "Extended Vendor-Specific" attribute,		The "evs" data type encodes an "Extended Vendor-Specific" attribute,
	as given in [RFC6929] Section 2.4. The "evs" data type is used		as given in [RFC6929] Section 2.4. The "evs" data type is used
	solely to extend the Vendor Specific space. It MAY appear inside of		solely to extend the Vendor Specific space. It MAY appear inside of
	an "extended" or a "long-extended" data type. It MUST NOT appear in		an "extended" or a "long-extended" data type. It MUST NOT appear in
	the contents of any other data type.		the contents of any other data type.
	Where an implementation determines that an attribute of data type		Where an implementation determines that an attribute of data type
	"evs" contains data which does not match the expected format, it		"evs" contains data which does not match the expected format, it
	SHOULD treat that attribute as being an "invalid attribute".		SHOULD treat that attribute as being an "invalid attribute".
	Name		Name
	evs		evs
	Number		Value
	17		17
	Length		Length
	Six or more octets		Six or more octets
	Format		Format
	0 1 2 3		0 1 2 3
	skipping to change at page 24, line 37		skipping to change at page 29, line 8
	The actual format of the information is site or application		The actual format of the information is site or application
	specific, and a robust implementation SHOULD support the field		specific, and a robust implementation SHOULD support the field
	as undistinguished octets. We recognise that Vendors have		as undistinguished octets. We recognise that Vendors have
	complete control over the contents and format of the Ext-Data		complete control over the contents and format of the Ext-Data
	field, while at the same time recommending that good practices		field, while at the same time recommending that good practices
	be followed.		be followed.
	Further codification of the range of allowed usage of this		Further codification of the range of allowed usage of this
	field is outside the scope of this specification.		field is outside the scope of this specification.
	3. Updated Registries		4. Updated Registries
	This section defines a new IANA registry for RADIUS data types, and		This section defines a new IANA registry for RADIUS data types, and
	updates the existing RADIUS Attribute Type registry.		updates the existing RADIUS Attribute Type registry.
	3.1. Create a Data Type Registry		4.1. Create a Data Type Registry
	This section defines a new RADIUS registry, called "Data Type".		This section defines a new RADIUS registry, called "Data Type".
	Allocation in this registry requires IETF Review. The "Registration		Allocation in this registry requires IETF Review. The "Registration
	Procedures" for this registry are "Standards Action".		Procedures" for this registry are "Standards Action".
	The registry contains three columns of data, as follows.		The registry contains three columns of data, as follows.
	Value		Value
	The number of the data type. The value field is an artifact of		The number of the data type. The value field is an artifact of
	the registry, and has no on-the-wire meaning.		the registry, and has no on-the-wire meaning.
	Description		Description
	The name of the data type. The name field is used only for the		The name of the data type. The name field is used only for the
	registry, and has no on-the-wire meaning.		registry, and has no on-the-wire meaning.
	Reference		Reference
	skipping to change at page 25, line 37		skipping to change at page 30, line 8
	8 ifid [RFC3162], TBD		8 ifid [RFC3162], TBD
	9 ipv6addr [RFC3162], TBD		9 ipv6addr [RFC3162], TBD
	10 ipv6prefix [RFC3162], TBD		10 ipv6prefix [RFC3162], TBD
	11 ipv4prefix [RFC6572], TBD		11 ipv4prefix [RFC6572], TBD
	12 integer64 [RFC6929], TBD		12 integer64 [RFC6929], TBD
	13 tlv [RFC6929], TBD		13 tlv [RFC6929], TBD
	14 evs [RFC6929], TBD		14 evs [RFC6929], TBD
	15 extended [RFC6929], TBD		15 extended [RFC6929], TBD
	16 long-extended [RFC6929], TBD		16 long-extended [RFC6929], TBD
	3.2. Updates to the Attribute Type Registry		4.2. Updates to the Attribute Type Registry
	This section updates the RADIUS Attribute Type Registry to have a new		This section updates the RADIUS Attribute Type Registry to have a new
	column, which is inserted in between the existing "Description" and		column, which is inserted in between the existing "Description" and
	"Reference" columns. The new column is named "Data Type". The		"Reference" columns. The new column is named "Data Type". The
	contents of that column are the name of a data type, corresponding to		contents of that column are the name of a data type, corresponding to
	the attribute in that row, or blank if the attribute type is		the attribute in that row, or blank if the attribute type is
	unassigned. The name of the data type is taken from the RADIUS Data		unassigned. The name of the data type is taken from the RADIUS Data
	Type registry, defined above.		Type registry, defined above.
	The updated registry follows in CSV format.		The updated registry follows in CSV format.
	skipping to change at page 30, line 37		skipping to change at page 35, line 8
	245.26,Extended-Vendor-Specific-5,evs,[RFC6929]		245.26,Extended-Vendor-Specific-5,evs,[RFC6929]
	245.{27-240},Unassigned,,		245.{27-240},Unassigned,,
	245.{241-255},Reserved,,[RFC6929]		245.{241-255},Reserved,,[RFC6929]
	246,Extended-Attribute-6,long-extended,[RFC6929]		246,Extended-Attribute-6,long-extended,[RFC6929]
	246.{1-25},Unassigned,,		246.{1-25},Unassigned,,
	246.26,Extended-Vendor-Specific-6,evs,[RFC6929]		246.26,Extended-Vendor-Specific-6,evs,[RFC6929]
	246.{27-240},Unassigned,,		246.{27-240},Unassigned,,
	246.{241-255},Reserved,,[RFC6929]		246.{241-255},Reserved,,[RFC6929]
	247-255,Reserved,,[RFC3575]		247-255,Reserved,,[RFC3575]
	4. Suggestions for Specifications
	We suggest that these data types be used in new RADIUS
	specifications. Attributes can usually be completely described
	through their Attribute Type code, name, and data type. The use of
	"ASCII art" is then limited only to the definition of new data types,
	and complex data types.
	Use of the new extended attributes [RFC6929] makes ASCII art even
	more problematic. An attribute can be allocated from the standard
	space, or from one of the extended spaces. This allocation decision
	is made after the specification has been accepted for publication.
	That allocation strongly affects the format of the attribute header,
	making it nearly 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.
	The following fields SHOULD be given when defining new attributes:
	Description
	A description of the meaning and interpretation of the attribute.
	Type
	The Attribute Type code, given in the "dotted number" notation
	from [RFC6929]. Specifications can often leave this as "TBD", and
	request that IANA fill in the allocated values.
	Length
	attributes of variable length, a maximum length SHOULD be given.
	Since the Length may depend on the Type, the definition of Length
	may be affected by IANA allocations.
	Data Type
	One of the named data types from the RADIUS Data Type registry.
	Value
	A description of any attribute-specific limitations on the values
	carried by the specified data type. If there are no attribute-
	specific limitations, then the description of this field can be
	omitted, so long as the Description field is sufficiently
	explanatory.
	Where the values are limited to a subset of the possible range,
	valid range(s) MUST be defined.
	For attributes of data type "enum", a list of enumerated values
	and names MUST be given, as with [RFC2865] Section 5.6.
	5. Security Considerations		5. Security Considerations
	This specification is concerned solely with updates to IANA		This specification is concerned solely with updates to IANA
	registries. As such, there are no security considerations with the		registries. As such, there are no security considerations with the
	document itself.		document itself.
	However, the use of inconsistent names and poorly-defined entities in		However, the use of inconsistent names and poorly-defined entities in
	a protocol is problematic. Inconsistencies in specifications can		a protocol is problematic. Inconsistencies in specifications can
	lead to security and interoperability problems in implementations.		lead to security and interoperability problems in implementations.
	Further, having one canonical source for the definition of data types		Further, having one canonical source for the definition of data types
	skipping to change at page 32, line 29		skipping to change at page 35, line 40
	the RFC number of this document when it is published.		the RFC number of this document when it is published.
	IANA is instructed to update the RADIUS Attribute Type registry, as		IANA is instructed to update the RADIUS Attribute Type registry, as
	described above in Section 3.2.		described above in Section 3.2.
	IANA is instructed to require that all allocation requests in the		IANA is instructed to require that all allocation requests in the
	RADIUS Attribute Type Registry contain a "Data Type" field. That		RADIUS Attribute Type Registry contain a "Data Type" field. That
	field is required to contain one of the "Data Type" names contained		field is required to contain one of the "Data Type" names contained
	in the RADIUS Data Type registry.		in the RADIUS Data Type registry.
			IANA is instructed to require that updates to the RADIUS Data Type
			registry contain the following fields, with the associated
			instructions:
			* Value. IANA is instructed to assign the next unused integer in
			sequence to new data type definitions.
			* Name. IANA is instructed to require that this name be unique
			in the registry.
			* Reference. IANA is instructed to update this field with a
			reference
			to the document which defines the data type.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119]		[RFC2119]
	Bradner, S., "Key words for use in RFCs to Indicate Requirement		Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March, 1997.		Levels", RFC 2119, March, 1997.
	[RFC2865]		[RFC2865]
	Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote		Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
End of changes. 69 change blocks.
	191 lines changed or deleted		331 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/