draft-ietf-radext-datatypes-00.txt		draft-ietf-radext-datatypes-01.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-00.txt>		<draft-ietf-radext-datatypes-01.txt>
	20 August 2015		4 September 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-00.txt		draft-ietf-radext-datatypes-01.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 February 20, 2016.		This Internet-Draft will expire on March 4, 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
	skipping to change at page 3, line 14		skipping to change at page 3, line 14
	Table of Contents		Table of Contents
	1. Introduction ............................................. 4		1. Introduction ............................................. 4
	1.1. Specification use of Data Types ..................... 4		1.1. Specification use of Data Types ..................... 4
	1.2. Implementation use of Data Types .................... 4		1.2. Implementation use of Data Types .................... 4
	1.3. Requirements Language ............................... 5		1.3. Requirements Language ............................... 5
	2. Data Type Definitions .................................... 6		2. Data Type Definitions .................................... 6
	2.1. integer ............................................. 7		2.1. integer ............................................. 7
	2.2. enum ................................................ 8		2.2. enum ................................................ 8
	2.3. ipv4addr ............................................ 8		2.3. ipv4addr ............................................ 9
	2.4. time ................................................ 9		2.4. time ................................................ 9
	2.5. text ................................................ 10		2.5. text ................................................ 10
	2.6. string .............................................. 10		2.6. string .............................................. 11
	2.7. concat .............................................. 11		2.7. concat .............................................. 12
	2.8. ifid ................................................ 12		2.8. ifid ................................................ 13
	2.9. ipv6addr ............................................ 13		2.9. ipv6addr ............................................ 13
	2.10. ipv6prefix ......................................... 14		2.10. ipv6prefix ......................................... 14
	2.11. ipv4prefix ......................................... 15		2.11. ipv4prefix ......................................... 15
	2.12. integer64 .......................................... 16		2.12. integer64 .......................................... 16
	2.13. tlv ................................................ 16		2.13. tlv ................................................ 17
	2.14. vsa ................................................ 18		2.14. vsa ................................................ 18
	2.15. extended ........................................... 19		2.15. extended ........................................... 20
	2.16. long-extended ...................................... 20		2.16. long-extended ...................................... 21
	2.17. evs ................................................ 22		2.17. evs ................................................ 23
	3. Updated Registries ....................................... 24		3. Updated Registries ....................................... 24
	3.1. Create a Data Type Registry ......................... 24		3.1. Create a Data Type Registry ......................... 24
	3.2. Updates to the Attribute Type Registry .............. 25		3.2. Updates to the Attribute Type Registry .............. 25
	4. Suggestions for Specifications ........................... 30		4. Suggestions for Specifications ........................... 30
	5. Security Considerations .................................. 31		5. Security Considerations .................................. 31
	6. IANA Considerations ...................................... 31		6. IANA Considerations ...................................... 32
	7. References ............................................... 31		7. References ............................................... 32
	7.1. Normative References ................................ 31		7.1. Normative References ................................ 32
	7.2. Informative References .............................. 32		7.2. Informative References .............................. 33
	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. This document defines an IANA registry for data types,
	and updates the RADIUS Attribute Type registry to use those newly		and updates the RADIUS Attribute Type registry to use those newly
	skipping to change at page 5, line 9		skipping to change at page 5, line 9
	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.
	This document requires 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
			defined here, in preference to any "ad hoc" data types currently in
			use. This suggestion should have minimal effect on implementations,
			as most "ad hoc" data types are compatible with the ones defined
			here. Any difference will typically be limited to the name of the
			data type.
	1.3. Requirements Language		1.3. 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. 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
	skipping to change at page 6, line 25		skipping to change at page 6, line 25
	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.		data type will never occur in a packet. It is RECOMMENDED that new
			implementations use the names defined herein, in order to avoid
			confusion. Existing implementations may choose to use the names
			defined herein, 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, as
	discussed in [RFC2868]. That specification defines the "tagged"		discussed 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.		defining additional data types for these attributes. We trust that
			implementors will be aware that tagged attributes must be treated
			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.
	Implementations not supporting a particular data type MUST treat		Implementations not supporting a particular data type MUST treat
	attributes of that data type as being of data type "string". See		attributes of that data type as being of data type "string", as
	Section 2.6, below for a definition of the "string" data type.		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		The definitions below use specialized names for various fields of
	attributes and data types. These names serve to address ambiguity of		attributes and data types. These names serve to address ambiguity of
	the field names in previous specifications. For example, the term		the field names in previous specifications. For example, the term
	"Value" is used in [RFC2865] Section 5 to define a field which		"Value" is used in [RFC2865] Section 5 to define a field which
	carries the contents of attribute. It is then used in later sections		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		as the sub-field of attribute contents. The result is that the field
	is defined as recursively containing itself. Similarly, "String" is		is defined as recursively containing itself. Similarly, "String" is
	used both as a data type, and as a sub-field of other data types.		used both as a data type, and as a sub-field of other data types.
	skipping to change at page 7, line 23		skipping to change at page 7, line 29
	is the following term:		is the following term:
	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 a valid data		Section 5. The contents of this field MUST be a valid data
	type as defined in the RADIUS Data Type registry.		type as defined in the RADIUS Data Type registry.
	In this document, we use the term "Value" only to refer to the		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		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 as		types. In other cases, we refer to the contents of a data type with
	"Type-Data", to distinguish it from data of other types. For		a type-specific name, in order to distinguish it from data of other
	example, a data type "vsa" will contain a data field called "VSA-		types. For example, the data type "vsa" will contain a data field
	Data".		called "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		used in multiple incompatible ways. It is RECOMMENDED that future
	specifications use the new terms in order to maintain consistent		specifications use these names, and the same naming scheme for new
	definitions, and to avoid ambiguities.		types, in order to maintain consistent definitions, and to avoid
			ambiguities.
	2.1. integer		2.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. Values outside of the allowed ranges SHOULD be treated		valid range. Attributes with Values outside of the allowed ranges
	as invalid.		SHOULD be treated as "invalid attributes".
	Name		Name
	integer		integer
	Number		Number
	1		1
	Length		Length
	skipping to change at page 8, line 19		skipping to change at page 8, line 27
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value |		| Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.2. enum		2.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.
	Specifications MUST define a valid set of enumerated values, along		Specifications MUST define a valid set of enumerated values, along
	with a unique name for each value.		with a unique name for each value. Attributes with Values outside of
			the allowed enumerations SHOULD be treated as "invalid attributes".
	Name		Name
	enum		enum
	Number		Number
	2		2
	Length		Length
	skipping to change at page 8, line 46		skipping to change at page 9, line 10
	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		2.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). Values outside of the allowed range		define the valid range(s). Attributes with Values outside of the
	SHOULD be treated as invalid.		allowed range(s) SHOULD be treated as "invalid attributes".
	Name		Name
	ipv4addr		ipv4addr
	Number		Number
	3		3
	Length		Length
	Four octets		Four octets
	skipping to change at page 9, line 26		skipping to change at page 9, line 37
	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		2.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 2013 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		Number
	skipping to change at page 10, line 11		skipping to change at page 10, line 20
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Time |		| Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.5. text		2.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).		range(s). Attributes with length outside of the allowed values
			SHOULD be treated as "invalid attributes".
	Note that the "text" type does not terminate with a NUL octet (hex		Where the text is intended to carry data in a particular format,
	00). The Attribute has a Length field and does not use a terminator.		(e.g. Framed-Route), the format MUST be given. The specification
	Texts of length zero (0) MUST NOT be sent; omit the entire attribute		SHOULD describe the format in a machine-readable way, such as via
	instead.		Augmented Backus-Naur Form (ABNF). Attributes with values not
			matching the defined format SHOULD be treated as "invalid
			attributes".
			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
			terminator. Texts of length zero (0) MUST NOT be sent; omit the
			entire attribute instead.
	Name		Name
	text		text
	Number		Number
	5		5
	Length		Length
	skipping to change at page 10, line 34		skipping to change at page 11, line 4
	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		2.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).		MUST define the valid range(s). Attributes with length outside of
			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
	entire attribute instead.		entire attribute instead.
	Where there is a need to encapsulate complex data structures, and		Where there is a need to encapsulate complex data structures, and
	TLVs cannot be used, the "string" data type MUST be used. This		TLVs cannot be used, the "string" data type MUST be used. This
	requirement include encapsulation of data structures defined outside		requirement include encapsulation of data structures defined outside
	of RADIUS, which are opaque to the RADIUS infrastucture. It also		of RADIUS, which are opaque to the RADIUS infrastucture. It also
	skipping to change at page 13, line 20		skipping to change at page 13, line 39
	| Interface-ID ...		| Interface-ID ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Interface-ID |		... Interface-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.9. ipv6addr		2.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).		define the valid range(s). Attributes with Values outside of the
			allowed range(s) SHOULD be treated as "invalid attributes".
	Name		Name
	ipv6addr		ipv6addr
	Number		Number
	9		9
	Length		Length
	skipping to change at page 14, line 8		skipping to change at page 14, line 23
	... Address ...		... Address ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Address ...		... Address ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... Address |		... Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.10. ipv6prefix		2.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.		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
			of possible prefixes, specifications MUST define the valid range(s).
			Attributes with Values outside of the allowed range(s) SHOULD be
			treated as "invalid attributes".
			Attributes with a Prefix-Length field having value greater than 128
			SHOULD be treated as "invalid attributes".
	Name		Name
	ipv6prefix		ipv6prefix
	Number		Number
	10		10
	Length		Length
	skipping to change at page 14, line 51		skipping to change at page 15, line 26
	set to zero.		set to zero.
	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		2.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.		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
			of possible prefixes, specifications MUST define the valid range(s).
			Attributes with Values outside of the allowed range(s) SHOULD be
			treated as "invalid attributes".
			Attributes with a Prefix-Length field having value greater than 32
			SHOULD be treated as "invalid attributes".
	Name		Name
	ipv4prefix		ipv4prefix
	Number		Number
	11		11
	Length		Length
	skipping to change at page 15, line 47		skipping to change at page 16, line 30
	set to zero.		set to zero.
	Prefix-Length		Prefix-Length
	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		2.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).		define the valid range(s). Attributes with Values outside of the
			allowed range(s) SHOULD be treated as "invalid attributes".
	Name		Name
	integer64		integer64
	Number		Number
	12		12
	Length		Length
	skipping to change at page 18, line 17		skipping to change at page 18, line 49
	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		2.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
			"vsa" contains data which does not match the expected format, it
			SHOULD treat that attribute as being an "invalid attribute".
	Name		Name
	vsa		vsa
	Number		Number
	14		14
	Length		Length
	skipping to change at page 19, line 9		skipping to change at page 19, line 44
	VSA-Data		VSA-Data
	The VSA-Data field is one or more octets. The actual format of		The VSA-Data field is one or more octets. The actual format of
	the information is site or application specific, and a robust		the information is site or application specific, and a robust
	implementation SHOULD support the field as undistinguished		implementation SHOULD support the field as undistinguished
	octets.		octets.
	The codification of the range of allowed usage of this field is		The codification of the range of allowed usage of this field is
	outside the scope of this specification.		outside the scope of this specification.
	It SHOULD be encoded as a sequence of "tlv" fields. The		The "vsa" data type SHOULD contain as a sequence of "tlv" data
	interpretation of the TLV-Type and TLV-Data fields are		types. The interpretation of the TLV-Type and TLV-Data fields
	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		2.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
	skipping to change at page 22, line 45		skipping to change at page 23, line 30
	fragmented attribute completely fills the packet.		fragmented attribute completely fills the packet.
	2.17. evs		2.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
			"evs" contains data which does not match the expected format, it
			SHOULD treat that attribute as being an "invalid attribute".
	Name		Name
	evs		evs
	Number		Number
	17		17
	Length		Length
	Six or more octets		Six 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
	skipping to change at page 25, line 18		skipping to change at page 25, line 50
	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.
	Value,Description,Data Type,Reference		Value,Description,Data Type,Reference
	1,User-Name,string,[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]
	7,Framed-Protocol,enum,[RFC2865]		7,Framed-Protocol,enum,[RFC2865]
	8,Framed-IP-Address,ipv4addr,[RFC2865]		8,Framed-IP-Address,ipv4addr,[RFC2865]
	9,Framed-IP-Netmask,ipv4addr,[RFC2865]		9,Framed-IP-Netmask,ipv4addr,[RFC2865]
	10,Framed-Routing,enum,[RFC2865]		10,Framed-Routing,enum,[RFC2865]
	11,Filter-Id,text,[RFC2865]		11,Filter-Id,text,[RFC2865]
	skipping to change at page 26, line 37		skipping to change at page 27, line 22
	59,User-Priority-Table,string,[RFC4675]		59,User-Priority-Table,string,[RFC4675]
	60,CHAP-Challenge,string,[RFC2865]		60,CHAP-Challenge,string,[RFC2865]
	61,NAS-Port-Type,enum,[RFC2865]		61,NAS-Port-Type,enum,[RFC2865]
	62,Port-Limit,integer,[RFC2865]		62,Port-Limit,integer,[RFC2865]
	63,Login-LAT-Port,text,[RFC2865]		63,Login-LAT-Port,text,[RFC2865]
	64,Tunnel-Type,enum,[RFC2868]		64,Tunnel-Type,enum,[RFC2868]
	65,Tunnel-Medium-Type,enum,[RFC2868]		65,Tunnel-Medium-Type,enum,[RFC2868]
	66,Tunnel-Client-Endpoint,text,[RFC2868]		66,Tunnel-Client-Endpoint,text,[RFC2868]
	67,Tunnel-Server-Endpoint,text,[RFC2868]		67,Tunnel-Server-Endpoint,text,[RFC2868]
	68,Acct-Tunnel-Connection,text,[RFC2867]		68,Acct-Tunnel-Connection,text,[RFC2867]
	69,Tunnel-Password,text,[RFC2868]		69,Tunnel-Password,string,[RFC2868]
	70,ARAP-Password,string,[RFC2869]		70,ARAP-Password,string,[RFC2869]
	71,ARAP-Features,string,[RFC2869]		71,ARAP-Features,string,[RFC2869]
	72,ARAP-Zone-Access,enum,[RFC2869]		72,ARAP-Zone-Access,enum,[RFC2869]
	73,ARAP-Security,integer,[RFC2869]		73,ARAP-Security,integer,[RFC2869]
	74,ARAP-Security-Data,text,[RFC2869]		74,ARAP-Security-Data,text,[RFC2869]
	75,Password-Retry,integer,[RFC2869]		75,Password-Retry,integer,[RFC2869]
	76,Prompt,enum,[RFC2869]		76,Prompt,enum,[RFC2869]
	77,Connect-Info,text,[RFC2869]		77,Connect-Info,text,[RFC2869]
	78,Configuration-Token,text,[RFC2869]		78,Configuration-Token,text,[RFC2869]
	79,EAP-Message,concat,[RFC2869]		79,EAP-Message,concat,[RFC2869]
	skipping to change at page 30, line 37		skipping to change at page 31, line 22
	A description of the meaning and interpretation of the attribute.		A description of the meaning and interpretation of the attribute.
	Type		Type
	The Attribute Type code, given in the "dotted number" notation		The Attribute Type code, given in the "dotted number" notation
	from [RFC6929]. Specifications can often leave this as "TBD", and		from [RFC6929]. Specifications can often leave this as "TBD", and
	request that IANA fill in the allocated values.		request that IANA fill in the allocated values.
	Length		Length
	A description of the length of the attribute. For attributes of		attributes of variable length, a maximum length SHOULD be given.
	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		Data Type
	One of the named data types from the RADIUS Data Type registry.		One of the named data types from the RADIUS Data Type registry.
	Value		Value
	A description of any attribute-specific limitations on the values		A description of any attribute-specific limitations on the values
	carried by the specified data type. If there are no attribute-		carried by the specified data type. If there are no attribute-
	specific limitations, then the description of this field can be		specific limitations, then the description of this field can be
	omitted.		omitted, so long as the Description field is sufficiently
			explanatory.
	Where the values are limited to a subset of the possible range,		Where the values are limited to a subset of the possible range,
	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.
	5. Security Considerations		5. Security Considerations
	This specification is concerned solely with updates to IANA		This specification is concerned solely with updates to IANA
	skipping to change at page 31, line 36		skipping to change at page 32, line 25
	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 3.1. The "TBD" text in that section should be replaced with		Section 3.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 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.
	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.
End of changes. 39 change blocks.
	55 lines changed or deleted		108 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/