draft-ietf-radext-datatypes-06.txt		draft-ietf-radext-datatypes-07.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-06.txt>		<draft-ietf-radext-datatypes-07.txt>
	3 August 2016		24 August 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-06.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 the
	2865. We provide an IANA registry for the data types, and update the		publication of RFC 2865. We provide an IANA registry for the data
	RADIUS Attribute Type registry to include a "Data Type" field for		types, and update the RADIUS Attribute Type registry to include a
	each attribute. Finally, we recommend that authors of RADIUS		"Data Type" field for each attribute. Finally, we recommend that
	specifications use these types in preference to existing practice.		authors of RADIUS specifications use these types in preference to
	This document updates RFC 2865, 3162, 6158, and 6572.		existing practice. This document updates RFC 2865, 3162, 6158, and
			6572.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	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 3, 2017.		This Internet-Draft will expire on April 24, 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 25 ¶		skipping to change at page 3, line 25 ¶
	2.1.2. Attribute Definitions using Data Types ......... 7		2.1.2. Attribute Definitions using Data Types ......... 7
	2.1.3. Format of Attribute Definitions ................ 7		2.1.3. Format of Attribute Definitions ................ 7
	2.1.4. Defining a New Data Type ....................... 8		2.1.4. Defining a New Data Type ....................... 8
	2.2. Implementation Use of Data Types .................... 9		2.2. Implementation Use of Data Types .................... 9
	3. Data Type Definitions .................................... 11		3. Data Type Definitions .................................... 11
	3.1. integer ............................................. 12		3.1. integer ............................................. 12
	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 .............................................. 16
	3.7. ifid ................................................ 16		3.7. ifid ................................................ 16
	3.8. ipv4addr ............................................ 17		3.8. ipv4addr ............................................ 17
	3.9. ipv6addr ............................................ 17		3.9. ipv6addr ............................................ 18
	3.10. ipv6prefix ......................................... 18		3.10. ipv6prefix ......................................... 18
	3.11. ipv4prefix ......................................... 19		3.11. ipv4prefix ......................................... 20
	3.12. integer64 .......................................... 21		3.12. integer64 .......................................... 21
	3.13. tlv ................................................ 21		3.13. tlv ................................................ 22
	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 ...................................... 26
	3.17. evs ................................................ 28		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 ...................................... 36
	7. References ............................................... 36		7. References ............................................... 36
	7.1. Normative References ................................ 36		7.1. Normative References ................................ 36
	7.2. Informative References .............................. 37		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, value, and data type. Of these three pieces of information,
	information, only the type value is managed by IANA. There is no		the name is recorded by IANA in the RADIUS Attribute Type registry,
	management of, or restriction on, the attribute name, as discussed in		but not otherwise managed or restricted, as discussed in [RFC6929]
	[RFC6929] Section 2.7.1. There is no management of data type name or		Section 2.7.1. The value is managed by IANA, and recorded in that
	definition. Experience has shown that there is a need for well		registry. The data type is not managed or recorded in the RADIUS
	defined data types.		Attribute Type registry. Experience has shown that there is a need
			to create well known data types, and have them managed by IANA.
	This document defines an IANA registry for data types, and updates		This document defines an IANA RADIUS Data Type registry, and updates
	the RADIUS Attribute Type registry to use those newly defined data		the RADIUS Attribute Type registry to use those newly defined data
	types. It recommends how both specifications and implementations		types. It recommends how both specifications and implementations
	should use the data types. It extends the RADIUS Attribute Type		should use the data types. It extends the RADIUS Attribute Type
	registry to have a data type for each assigned attribute.		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 Problems with Data Types		1.1. Specification Problems with Data Types
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 36 ¶
	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.
			This document updates [RFC6158] to permit the data types defined in
			the "Data Type registry" as "basic data types", as per Section 2.1 of
			that document. The recommendations of [RFC6158] are otherwise
			unchanged.
	1.4. 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. Use of Data Types		2. Use of Data Types
	The Data Types can be used in two places: specifications, and		The Data Types can be used in two places: specifications, and
	implementations. This section discusses both uses, and gives		implementations. This section discusses both uses, and gives
	skipping to change at page 6, line 52 ¶		skipping to change at page 6, line 52 ¶
	Attr-Data		Attr-Data
	The "Value" field of an Attribute as defined in [RFC2865]		The "Value" field of an Attribute as defined in [RFC2865]
	Section 5. The contents of this field MUST be of a valid data		Section 5. The contents of this field MUST be of a valid data
	type as defined in the RADIUS Data Type registry.		type as defined in the RADIUS Data Type registry.
	We consistently use "Attr-Data" to refer to the contents of an		We consistently use "Attr-Data" to refer to the contents of an
	attribute, instead of the more ambiguous name "Value". It is		attribute, instead of the more ambiguous name "Value". It is
	RECOMMENDED that new specifications follow this practice.		RECOMMENDED that new specifications follow this practice.
	In this document, we use the term "Value" to refer to the contents of		We consistently use "Value" to refer to the contents of a data type,
	a data type, where that data type cannot carry other data types. In		where that data type is simple. For example, an "integer" can have a
	other cases, we refer to the contents of a data type with a type-		"Value". In contrast, a Vendor-Specific attribute carries complex
	specific name, in order to distinguish it from data of other types.		information, and thus cannot have a "Value".
	For example, the data type "vsa" will contain a data field called
	"VSA-Data".		For data types which carry complex information, we name the fields
			based on the data type. For example, a Vendor-Specific attribute is
			defined to carry a "vsa" data type, and the contents of that data
			type are described herein as "VSA-Data".
	These terms are used in preference to the term "String", which was		These terms are used in preference to the term "String", which was
	used in multiple incompatible ways. It is RECOMMENDED that future		previously used in ambiguous ways. It is RECOMMENDED that future
	specifications use type-specific names, and the same naming scheme		specifications use type-specific names, and the same naming scheme
	for new types. This use will maintain consistent definitions, and		for new types. This use will maintain consistent definitions, and
	avoid ambiguities.		help to avoid ambiguities.
	2.1.2. Attribute Definitions using Data Types		2.1.2. Attribute Definitions using Data Types
	New RADIUS specifications MUST define attributes using data types		New RADIUS specifications MUST define attributes using data types
	from the RADIUS Data Type registry. The specification may, of		from the RADIUS Data Type registry. The specification may, of
	course, define a new data type and use it in the same document. The		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		guidelines given in [RFC6929] MUST be followed when defining a new
	data type.		data type.
	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		value, 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 essentially 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
	skipping to change at page 7, line 47 ¶		skipping to change at page 8, line 4 ¶
	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
	When defining a new attribute, the following fields SHOULD be given:		When defining a new attribute, the following fields SHOULD be given:
	Description		Description
	A description of the meaning and interpretation of the		A description of the meaning and interpretation of the
	attribute.		attribute.
	Type		Type
	The Attribute Type code, given in the "dotted number" notation		The Attribute Type value, given in the "dotted number" notation
	from [RFC6929]. Specifications can often leave this as "TBD",		from [RFC6929]. Specifications can often leave this as "TBD",
	and request that IANA fill in the allocated values.		and request that IANA fill in the allocated values.
	Length		Length
	A description of the length of the attribute. For attributes		A description of the length of the attribute. For attributes
	of variable length, a maximum length SHOULD be given. Since		of variable length, a maximum length SHOULD be given. Since
	the Length may depend on the Type, the definition of Length may		the Length may depend on the Type, the definition of Length may
	be affected by IANA allocations.		be affected by IANA allocations.
	skipping to change at page 8, line 41 ¶		skipping to change at page 8, line 43 ¶
	valid range(s) MUST be defined.		valid range(s) MUST be defined.
	For attributes of data type "enum", a list of enumerated values		For attributes of data type "enum", a list of enumerated values
	and names MUST be given, as with [RFC2865] Section 5.6.		and names MUST be given, as with [RFC2865] Section 5.6.
	Using a consistent format for attribute definitions helps to make the		Using a consistent format for attribute definitions helps to make the
	definitions clearer.		definitions clearer.
	2.1.4. Defining a New Data Type		2.1.4. Defining a New Data Type
	When a specification needs to define a new data type, it should		When a specification needs to define a new data type, it SHOULD
	follow the format used by the definitions in Section 3 of this		follow the format used by the definitions in Section 3 of this
	document. The text at the start of the data type definition MUST		document. The text at the start of the data type definition MUST
	describe the data type, including the expected use, and why a new		describe the data type, including the expected use, and why a new
	data type is required. That text SHOULD include limits on expected		data type is required. That text SHOULD include limits on expected
	values, and why those limits exist. The fields "Name", "Value",		values, and why those limits exist. The field's "Name", "Value",
	"Length", and "Format", MUST be given, along with values.		"Length", and "Format", MUST be given, along with values.
	The "Name" field SHOULD be a single name, all lower-case.		The "Name" field SHOULD be a single name, all lower-case.
	Contractions such as "ipv4addr" are RECOMMENDED where they add		Contractions such as "ipv4addr" are RECOMMENDED where they add
	clarity.		clarity.
	We note that the use of "Value" in the RADIUS Data Type registry can		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		be confusing. That name is also used in attribute definitions, but
	with a different meaning. We trust that the meaning here is clear		with a different meaning. We trust that the meaning here is clear
	from the context.		from the context.
	The "Value" field should be given as to be determined or "TBD" in		The "Value" field SHOULD be given as to be determined or "TBD" in
	specifications. That number is assigned by IANA.		specifications. That number is assigned by IANA.
	The "Format" field SHOULD be defined with "ASCII art" in order to		The "Format" field SHOULD be defined with "ASCII art" in order to
	have a precise definition. Machine-readable formats are also		have a precise definition. Machine-readable formats are also
	RECOMMENDED.		RECOMMENDED.
	The definition of a new data type should be done only when absolutely		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		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]		types. When defining a new data type, the guideliness of [RFC6929]
	with respect to data types MUST be followed.		with respect to data types MUST be followed.
	skipping to change at page 10, line 7 ¶		skipping to change at page 10, line 10 ¶
	format,		format,
	* Attributes where the length is shorter or longer than the allowed		* Attributes where the length is shorter or longer than the allowed
	length(s) for the given data type,		length(s) for the given data type,
	The requirements for "reserved" fields are more difficult to		The requirements for "reserved" fields are more difficult to
	quantify. Implementations SHOULD be able to receive and process		quantify. Implementations SHOULD be able to receive and process
	attributes where "reserved" fields are non-zero. We do not, however,		attributes where "reserved" fields are non-zero. We do not, however,
	define any "correct" processing of such attributes. Instead,		define any "correct" processing of such attributes. Instead,
	specifications which define new meaning for "reserved" fields SHOULD		specifications which define new meaning for "reserved" fields SHOULD
	describe how older implementations process those fields. We expect		describe how the new meaning is compatible with older
	that such descriptions are derived from practice. Implementations		implementations. We expect that such descriptions are derived from
	MUST set "reserved" fields to zero when creating attributes.		practice. Implementations MUST set "reserved" fields to zero when
			creating attributes.
	3. Data Type Definitions		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.
	skipping to change at page 14, line 7 ¶		skipping to change at page 14, line 7 ¶
	3.4. text		3.4. 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".
			Attributes of type "text" which are allocated in the standard space
			(Section 1.2 of [RFC6929]) are limited to no more than 253 octets of
			data. Attributes of type "text" which are allocated in the extended
			space can be longer. In both cases, these limits are reduced when
			the data is encapsulated inside of an another attribute.
	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
	SHOULD describe the format in a machine-readable way, such as via		SHOULD describe the format in a machine-readable way, such as via
	Augmented Backus-Naur Form (ABNF). Attributes with values not		Augmented Backus-Naur Form (ABNF) [RFC5234]. Attributes with values
	matching the defined format SHOULD be treated as "invalid		not matching the defined format SHOULD be treated as "invalid
	attributes".		attributes".
	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
	skipping to change at page 14, line 47 ¶		skipping to change at page 15, line 6 ¶
	+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-
	3.5. string		3.5. 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".
			Attributes of type "string" which are allocated in the standard space
			(Section 1.2 of [RFC6929]) are limited to no more than 253 octets of
			data. Attributes of type "string" which are allocated in the
			extended space can be longer. In both cases, these limits are
			reduced when the data is encapsulated inside of an another attribute.
	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
	entire attribute instead.		entire attribute instead. a Where there is a need to encapsulate
			complex data structures, and TLVs cannot be used, the "string" data
	Where there is a need to encapsulate complex data structures, and		type MUST be used. This requirement includes encapsulation of data
	TLVs cannot be used, the "string" data type MUST be used. This		structures defined outside of RADIUS, which are opaque to the RADIUS
	requirement include encapsulation of data structures defined outside		infrastucture. It also includes encapsulation of some data
	of RADIUS, which are opaque to the RADIUS infrastucture. It also		structures which are not opaque to RADIUS, such as the contents of
	includes encapsulation of some data structures which are not opaque		CHAP-Password.
	to RADIUS, such as the contents of CHAP-Password.
	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.
	skipping to change at page 16, line 38 ¶		skipping to change at page 16, line 50 ¶
	Format		Format
	0		0
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-
	| Octets ...		| Octets ...
	+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-
	3.7. ifid		3.7. 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 IPv6
	network byte order.		Interface Identifier network byte order.
	Name		Name
	ifid		ifid
	Value		Value
	7		7
	Length		Length
	skipping to change at page 18, line 42 ¶		skipping to change at page 19, line 6 ¶
	3.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 Addresses 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".		MUST be treated as "invalid attributes".
	Name		Name
	ipv6prefix		ipv6prefix
	Value		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Prefix-Length | Prefix ...		| Reserved | Prefix-Length | Prefix ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Prefix ...		... Prefix ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Prefix ...		... Prefix ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Prefix |		... Prefix |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Subfields		Subfields
	skipping to change at page 19, line 40 ¶		skipping to change at page 19, line 51 ¶
	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.
			The Prefix field SHOULD NOT contain more octets than necessary
			to encode the Prefix.
	3.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 Addresses 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".		MUST be treated as "invalid attributes".
	Name		Name
	ipv4prefix		ipv4prefix
	Value		Value
	11		11
	Length		Length
	six octets		six 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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. This field is one octet in length.		set to zero. This field is one octet in length.
	skipping to change at page 26, line 30 ¶		skipping to change at page 26, line 39 ¶
	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 ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Subfields		Subfields
	Extended-Type		Extended-Type
	This field is identical to the Extended-Type field defined		This field is identical to the Extended-Type field defined
	above in Section 2.13.		above in Section 3.15.
	M (More)		M (More)
	The More field is one (1) bit in length, and indicates whether		The More field is one (1) bit in length, and indicates whether
	or not the current attribute contains "more" than 251 octets of		or not the current attribute contains "more" than 251 octets of
	data. The More field MUST be clear (0) if the Length field has		data. The More field MUST be clear (0) if the Length field has
	value less than 255. The More field MAY be set (1) if the		value less than 255. The More field MAY be set (1) if the
	Length field has value of 255.		Length field has value of 255.
	If the More field is set (1), it indicates that the Ext-Data		If the More field is set (1), it indicates that the Ext-Data
	skipping to change at page 29, line 27 ¶		skipping to change at page 29, line 37 ¶
	field is outside the scope of this specification.		field is outside the scope of this specification.
	4. 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
	then updates the existing RADIUS Attribute Type registry to use the		then updates the existing RADIUS Attribute Type registry to use the
	data types from the new registry.		data types from the new registry.
	4.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 registry located under "RADIUS Types",
	Allocation in this registry requires IETF Review. The "Registration		called "Data Type". Allocation in this registry requires IETF
	Procedures" for the Data Type Registry are "Standards Action".		Review. The "Registration Procedures" for the Data Type registry are
			"Standards Action".
	The Data Type Registry contains three columns of data, as follows.		The Data Type 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.
	skipping to change at page 30, line 23 ¶		skipping to change at page 30, line 33 ¶
	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
	4.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, as defined above.
	The existing registration requirements for the Attribute Type		The existing registration requirements for the RADIUS Attribute Type
	Registry are unchanged.		registry are otherwise unchanged.
			NOTE TO RFC EDITOR: Before the document is published, please remove this
			note, and the following text in this section.
	The updated registry follows in CSV format.		The updated registry follows in CSV format.
	Value,Description,Data Type,Reference		Value,Description,Data Type,Reference
	1,User-Name,text,[RFC2865]		1,User-Name,text,[RFC2865]
	2,User-Password,string,[RFC2865]		2,User-Password,string,[RFC2865]
	3,CHAP-Password,string,[RFC2865]		3,CHAP-Password,string,[RFC2865]
	4,NAS-IP-Address,ipv4addr,[RFC2865]		4,NAS-IP-Address,ipv4addr,[RFC2865]
	5,NAS-Port,integer,[RFC2865]		5,NAS-Port,integer,[RFC2865]
	6,Service-Type,enum,[RFC2865]		6,Service-Type,enum,[RFC2865]
	skipping to change at page 36, line 6 ¶		skipping to change at page 36, line 19 ¶
	6. IANA Considerations		6. IANA Considerations
	IANA is instructed to create one new registry as described above in		IANA is instructed to create one new registry as described above in
	Section 4.1. The "TBD" text in that section should be replaced with		Section 4.1. The "TBD" text in that section should be replaced with
	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 4.2.		described above in Section 4.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		IANA is instructed to require that updates to the RADIUS Data Type
	registry contain the following fields, with the associated		registry contain the following fields, with the associated
	instructions:		instructions:
	* Value. IANA is instructed to assign the next unused integer in		* Value. IANA is instructed to assign the next unused integer in
	sequence to new data type definitions.		sequence to new data type definitions.
	* Name. IANA is instructed to require that this name be unique		* Name. IANA is instructed to require that this name be unique
	in the registry.		in the registry.
	* Reference. IANA is instructed to update this field with a		* Reference. IANA is instructed to update this field with a
	reference		reference to the document which defines the data type.
	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]
	skipping to change at page 37, line 19 ¶		skipping to change at page 37, line 31 ¶
	7.2. Informative References		7.2. Informative References
	[RFC2868]		[RFC2868]
	Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I.		Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I.
	Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868,		Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868,
	June 2000.		June 2000.
	[RFC2869]		[RFC2869]
	Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000.		Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000.
			[RFC5234]
			Crocker, D. and P. Overell, "Augmented BNF for Syntax
			Specifications: ABNF", RFC 5234, January 2008.
	[RFC6929]		[RFC6929]
	DeKok, A., and Lior, A., "Remote Authentication Dial In User		DeKok, A., and Lior, A., "Remote Authentication Dial In User
	Service (RADIUS) Protocol Extensions", RFC 6929, April 2013.		Service (RADIUS) Protocol Extensions", RFC 6929, April 2013.
	[RFC7268]		[RFC7268]
	Aboba, B, et al, "RADIUS Attributes for IEEE 802 Networks", RFC		Aboba, B, et al, "RADIUS Attributes for IEEE 802 Networks", RFC
	7268, July 2015.		7268, July 2015.
	[RFC7499]		[RFC7499]
	Perez-Mendez A., et al, "Support of Fragmentation of RADIUS		Perez-Mendez A., et al, "Support of Fragmentation of RADIUS
End of changes. 43 change blocks.
	68 lines changed or deleted		99 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/