draft-ietf-radext-radius-fragmentation-10.txt		draft-ietf-radext-radius-fragmentation-11.txt
	RADIUS EXTensions Working Group A. Perez-Mendez		RADIUS EXTensions Working Group A. Perez-Mendez
	Internet-Draft R. Marin-Lopez		Internet-Draft R. Marin-Lopez
	Updates: 2865, 6158, 6929 F. Pereniguez-Garcia		Updates: 2865, 6158, 6929 F. Pereniguez-Garcia
	(if approved) G. Lopez-Millan		(if approved) G. Lopez-Millan
	Intended status: Experimental University of Murcia		Intended status: Experimental University of Murcia
	Expires: July 13, 2015 D. Lopez		Expires: July 24, 2015 D. Lopez
	Telefonica I+D		Telefonica I+D
	A. DeKok		A. DeKok
	Network RADIUS		Network RADIUS
	January 9, 2015		January 20, 2015
	Support of fragmentation of RADIUS packets		Support of fragmentation of RADIUS packets
	draft-ietf-radext-radius-fragmentation-10		draft-ietf-radext-radius-fragmentation-11
	Abstract		Abstract
	The Remote Authentication Dial-In User Service (RADIUS) protocol is		The Remote Authentication Dial-In User Service (RADIUS) protocol is
	limited to a total packet size of 4096 octets. Provisions exist for		limited to a total packet size of 4096 octets. Provisions exist for
	fragmenting large amounts of authentication data across multiple		fragmenting large amounts of authentication data across multiple
	packets, via Access-Challenge. No similar provisions exist for		packets, via Access-Challenge. No similar provisions exist for
	fragmenting large amounts of authorization data. This document		fragmenting large amounts of authorization data. This document
	specifies how existing RADIUS mechanisms can be leveraged to provide		specifies how existing RADIUS mechanisms can be leveraged to provide
	that functionality. These mechanisms are largely compatible with		that functionality. These mechanisms are largely compatible with
	skipping to change at page 1, line 44		skipping to change at page 1, line 44
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on July 13, 2015.		This Internet-Draft will expire on July 24, 2015.
	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 2, line 36		skipping to change at page 2, line 36
	7. Allowed large packet size . . . . . . . . . . . . . . . . . . 21		7. Allowed large packet size . . . . . . . . . . . . . . . . . . 21
	8. Handling special attributes . . . . . . . . . . . . . . . . . 22		8. Handling special attributes . . . . . . . . . . . . . . . . . 22
	8.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 22		8.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 22
	8.2. State attribute . . . . . . . . . . . . . . . . . . . . . 23		8.2. State attribute . . . . . . . . . . . . . . . . . . . . . 23
	8.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 24		8.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 24
	8.4. Rebuilding the original large packet . . . . . . . . . . . 24		8.4. Rebuilding the original large packet . . . . . . . . . . . 24
	9. New flag T field for the Long Extended Type attribute		9. New flag T field for the Long Extended Type attribute
	definition . . . . . . . . . . . . . . . . . . . . . . . . . . 24		definition . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	10. New attribute definition . . . . . . . . . . . . . . . . . . . 25		10. New attribute definition . . . . . . . . . . . . . . . . . . . 25
	10.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 25		10.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 25
	10.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 26		10.2. Proxy-State-Length attribute . . . . . . . . . . . . . . . 26
	10.3. Table of attributes . . . . . . . . . . . . . . . . . . . 27		10.3. Table of attributes . . . . . . . . . . . . . . . . . . . 27
	11. Operation with proxies . . . . . . . . . . . . . . . . . . . . 27		11. Operation with proxies . . . . . . . . . . . . . . . . . . . . 27
	11.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 27		11.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 27
	11.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 28		11.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 28
	12. General considerations . . . . . . . . . . . . . . . . . . . . 29		12. General considerations . . . . . . . . . . . . . . . . . . . . 29
	12.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 29		12.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	12.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 30		12.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 30
	12.3. Proxying based on User-Name . . . . . . . . . . . . . . . 30		12.3. Proxying based on User-Name . . . . . . . . . . . . . . . 30
	12.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 30		12.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 30
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 31		13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	skipping to change at page 8, line 12		skipping to change at page 8, line 12
	typically composed of many small updates. That is, there is no		typically composed of many small updates. That is, there is no
	demonstrated need to send indivisible blocks of more than 4 kilo-		demonstrated need to send indivisible blocks of more than 4 kilo-
	octets of data. The need to send large amounts of data per user		octets of data. The need to send large amounts of data per user
	session often originates from the need for flow-based accounting. In		session often originates from the need for flow-based accounting. In
	this use-case, the RADIUS Client may send accounting data for many		this use-case, the RADIUS Client may send accounting data for many
	thousands of flows, where all those flows are tied to one user		thousands of flows, where all those flows are tied to one user
	session. The existing Acct-Multi-Session-Id attribute defined in		session. The existing Acct-Multi-Session-Id attribute defined in
	[RFC2866] Section 5.11 has been proven to work here.		[RFC2866] Section 5.11 has been proven to work here.
	Similarly, there is no need to fragment Change of Authorization (CoA)		Similarly, there is no need to fragment Change of Authorization (CoA)
	[RFC5176] packets. Instead, the CoA client MUST send a CoA-Request		[RFC5176] packets. Instead, according to [RFC5176] the CoA client
	packet containing session identification attributes, along with		will send a CoA-Request packet containing session identification
	Service-Type = Additional-Authorization, and a State attribute.		attributes, along with Service-Type = Additional-Authorization, and a
	Implementations not supporting fragmentation will respond with a CoA-		State attribute. Implementations not supporting fragmentation will
	NAK, and an Error-Cause of Unsupported-Service.		respond with a CoA-NAK, and an Error-Cause of Unsupported-Service.
	The above requirement does not assume that the CoA client and the		The above requirement does not assume that the CoA client and the
	RADIUS Server are co-located. They may, in fact be run on separate		RADIUS Server are co-located. They may, in fact be run on separate
	parts of the infrastructure, or even by separate administrators.		parts of the infrastructure, or even by separate administrators.
	There is, however, a requirement that the two communicate. We can		There is, however, a requirement that the two communicate. We can
	see that the CoA client needs to send session identification		see that the CoA client needs to send session identification
	attributes in order to send CoA packets. These attributes cannot be		attributes in order to send CoA packets. These attributes cannot be
	known a priori by the CoA client, and can only come from the RADIUS		known a priori by the CoA client, and can only come from the RADIUS
	Server. Therefore, even when the two systems are not co-located,		Server. Therefore, even when the two systems are not co-located,
	they must be able to communicate in order to operate in unison. The		they must be able to communicate in order to operate in unison. The
	skipping to change at page 8, line 38		skipping to change at page 8, line 38
	users authorization parameters, which is a security disaster.		users authorization parameters, which is a security disaster.
	This specification does not allow for fragmentation of CoA packets.		This specification does not allow for fragmentation of CoA packets.
	Allowing for fragmented CoA packets would involve changing multiple		Allowing for fragmented CoA packets would involve changing multiple
	parts of the RADIUS protocol, with the corresponding possibility for		parts of the RADIUS protocol, with the corresponding possibility for
	implementation issues, mistakes, etc.		implementation issues, mistakes, etc.
	Where CoA clients (i.e. RADIUS Servers) need to send large amounts		Where CoA clients (i.e. RADIUS Servers) need to send large amounts
	of authorization data to a CoA server (i.e. RADIUS Client), they		of authorization data to a CoA server (i.e. RADIUS Client), they
	need only send a minimal CoA-Request packet, containing Service-Type		need only send a minimal CoA-Request packet, containing Service-Type
	of Authorize-Only, as per RFC 5176, along with session identification		of Authorize-Only, as per [RFC5176], along with session
	attributes. This CoA packet serves as a signal to the RADIUS Client		identification attributes. This CoA packet serves as a signal to the
	that the users' session requires re-authorization. When the RADIUS		RADIUS Client that the users' session requires re-authorization.
	Client re-authorizes the user via Access-Request, the RADIUS Server		When the RADIUS Client re-authorizes the user via Access-Request, the
	can perform fragmentation, and send large amounts of authorization		RADIUS Server can perform fragmentation, and send large amounts of
	data to the RADIUS Client.		authorization data to the RADIUS Client.
	The assumption in the above scenario is that the CoA client and		The assumption in the above scenario is that the CoA client and
	RADIUS Server are co-located, or at least strongly coupled. That is,		RADIUS Server are co-located, or at least strongly coupled. That is,
	the path from CoA client to CoA server SHOULD be the exact reverse of		the path from CoA client to CoA server SHOULD be the exact reverse of
	the path from RADIUS Client to RADIUS Server. The following diagram		the path from RADIUS Client to RADIUS Server. The following diagram
	will hopefully clarify the roles:		will hopefully clarify the roles:
	+---------------------+		+----------------+
	| RADIUS |		| RADIUS CoA |
	| Client CoA Server |		| Client Server |
	+---------------------+		+----------------+
	| ^		| ^
	Access-Request | | CoA-Request		Access-Request | | CoA-Request
	v |		v |
	+---------------------+		+----------------+
	| RADIUS CoA client |		| RADIUS CoA |
	| Server |		| Server Client |
	+---------------------+		+----------------+
	Where there is a proxy involved:		Where there is a proxy involved:
	+---------------------+		+----------------+
	| RADIUS |		| RADIUS CoA |
	| Client CoA Server |		| Client Server |
	+---------------------+		+----------------+
	| ^		| ^
	Access-Request | | CoA-Request		Access-Request | | CoA-Request
	v |		v |
	+---------------------+		+----------------+
	| RADIUS CoA |		| RADIUS CoA |
	| Proxy Proxy |		| Proxy Proxy |
	+---------------------+		+----------------+
	| ^		| ^
	Access-Request | | CoA-Request		Access-Request | | CoA-Request
	v |		v |
	+---------------------+		+----------------+
	| RADIUS CoA client |		| RADIUS CoA |
	| Server |		| Server Client |
	+---------------------+		+----------------+
	That is, the RADIUS and CoA subsystems at each hop are strongly		That is, the RADIUS and CoA subsystems at each hop are strongly
	connected. Where they are not strongly connected, it will be		connected. Where they are not strongly connected, it will be
	impossible to use CoA-Request packets to transport large amounts of		impossible to use CoA-Request packets to transport large amounts of
	authorization data.		authorization data.
	This design is more complicated than allowing for fragmented CoA		This design is more complicated than allowing for fragmented CoA
	packets. However, the CoA client and the RADIUS Server must		packets. However, the CoA client and the RADIUS Server must
	communicate even when not using this specification. We believe that		communicate even when not using this specification. We believe that
	standardizing that communication, and using one method for exchange		standardizing that communication, and using one method for exchange
	skipping to change at page 23, line 16		skipping to change at page 23, line 16
	1. When a RADIUS Client does not know how much space will be		1. When a RADIUS Client does not know how much space will be
	required by intermediate proxies for including their Proxy-State		required by intermediate proxies for including their Proxy-State
	attributes, it SHOULD start using a conservative value (e.g. 1024		attributes, it SHOULD start using a conservative value (e.g. 1024
	octets) as the chunk size.		octets) as the chunk size.
	2. When the RADIUS Server receives a chunk from the RADIUS Client,		2. When the RADIUS Server receives a chunk from the RADIUS Client,
	it can calculate the total size of the Proxy-State attributes		it can calculate the total size of the Proxy-State attributes
	that have been introduced by intermediary proxies along the path.		that have been introduced by intermediary proxies along the path.
	This information MUST be returned to the RADIUS Client in the		This information MUST be returned to the RADIUS Client in the
	next reply packet, encoded into a new attribute called Proxy-		next reply packet, encoded into a new attribute called Proxy-
	State-Len. The RADIUS Server MAY artificially increase this		State-Length. The RADIUS Server MAY artificially increase this
	quantity in order to handle with situations where proxies behave		quantity in order to handle with situations where proxies behave
	inconsistently (e.g. they generate Proxy-State attributes with a		inconsistently (e.g. they generate Proxy-State attributes with a
	different size for each packet), or for situations where		different size for each packet), or for situations where
	intermediary proxies remove Proxy-State attributes generated by		intermediary proxies remove Proxy-State attributes generated by
	other proxies. Increasing this value would make the RADIUS		other proxies. Increasing this value would make the RADIUS
	Client to leave some free space for these situations.		Client to leave some free space for these situations.
	3. The RADIUS Client SHOULD react upon the reception of this		3. The RADIUS Client SHOULD react upon the reception of this
	attribute by adjusting the maximum size for the next chunk		attribute by adjusting the maximum size for the next chunk
	accordingly. However, as the Proxy-State-Len offers just an		accordingly. However, as the Proxy-State-Length offers just an
	estimation of the space required by the proxies, the RADIUS		estimation of the space required by the proxies, the RADIUS
	Client MAY select a smaller amount in environments known to be		Client MAY select a smaller amount in environments known to be
	problematic.		problematic.
	8.2. State attribute		8.2. State attribute
	This RADIUS fragmentation mechanism makes use of the State attribute		This RADIUS fragmentation mechanism makes use of the State attribute
	to link all the chunks belonging to the same fragmented packet.		to link all the chunks belonging to the same fragmented packet.
	However, some considerations are required when the RADIUS Server is		However, some considerations are required when the RADIUS Server is
	fragmenting a packet that already contains a State attribute for		fragmenting a packet that already contains a State attribute for
	skipping to change at page 24, line 32		skipping to change at page 24, line 32
	MUST NOT be stored in this list, as they have been introduced as part		MUST NOT be stored in this list, as they have been introduced as part
	of the fragmentation signalling and hence, they are not part of the		of the fragmentation signalling and hence, they are not part of the
	original packet.		original packet.
	o State (except the one in the last chunk, if present)		o State (except the one in the last chunk, if present)
	o Service-Type = Additional-Authorization		o Service-Type = Additional-Authorization
	o Frag-Status		o Frag-Status
	o Proxy-State-Len		o Proxy-State-Length
	Similarly, the RADIUS Server MUST NOT store the following attributes		Similarly, the RADIUS Server MUST NOT store the following attributes
	as part of the original large packet:		as part of the original large packet:
	o State (except the one in the first chunk, if present)		o State (except the one in the first chunk, if present)
	o Service-Type = Additional-Authorization		o Service-Type = Additional-Authorization
	o Frag-Status		o Frag-Status
	skipping to change at page 25, line 30		skipping to change at page 25, line 30
	| Type | Length | Extended-Type |M|T| Reserved |		| Type | Length | Extended-Type |M|T| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value ...		| Value ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 12: Updated Long Extended Type attribute format		Figure 12: Updated Long Extended Type attribute format
	10. New attribute definition		10. New attribute definition
	This document proposes the definition of two new extended type		This document proposes the definition of two new extended type
	attributes, called Frag-Status and Proxy-State-Len. The format of		attributes, called Frag-Status and Proxy-State-Length. The format of
	these attributes follows the indications for an Extended Type		these attributes follows the indications for an Extended Type
	attribute defined in [RFC6929].		attribute defined in [RFC6929].
	10.1. Frag-Status attribute		10.1. Frag-Status attribute
	This attribute is used for fragmentation signalling, and its meaning		This attribute is used for fragmentation signalling, and its meaning
	depends on the code value transported within it. The following		depends on the code value transported within it. The following
	figure represents the format of the Frag-Status attribute.		figure represents the format of the Frag-Status attribute.
	1 2 3		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Extended-Type | Code		| Type | Length | Extended-Type | Code
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Code (cont) |		Code (cont) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 13: Frag-Status format		Figure 13: Frag-Status format
	Type		Type
	To be assigned (TBA)		241 (To be confirmed by IANA)
	Length		Length
	7		7
	Extended-Type		Extended-Type
	To be assigned (TBA).		TBD1
	Code		Code
	4 byte. Integer indicating the code. The values defined in this		4 byte. Integer indicating the code. The values defined in this
	specifications are:		specifications are:
	0 - Reserved		0 - Reserved
	1 - Fragmentation-Supported		1 - Fragmentation-Supported
	skipping to change at page 26, line 34		skipping to change at page 26, line 34
	3 - More-Data-Request		3 - More-Data-Request
	This attribute MAY be present in Access-Request, Access-Challenge and		This attribute MAY be present in Access-Request, Access-Challenge and
	Access-Accept packets. It MUST NOT be included in Access-Reject		Access-Accept packets. It MUST NOT be included in Access-Reject
	packets. RADIUS Clients supporting this specification MUST include a		packets. RADIUS Clients supporting this specification MUST include a
	Frag-Status = Fragmentation-Supported attribute in the first Access-		Frag-Status = Fragmentation-Supported attribute in the first Access-
	Request sent to the RADIUS Server, in order to indicate they would		Request sent to the RADIUS Server, in order to indicate they would
	accept fragmented data from the sever.		accept fragmented data from the sever.
	10.2. Proxy-State-Len attribute		10.2. Proxy-State-Length attribute
	This attribute indicates to the RADIUS Client the length of the		This attribute indicates to the RADIUS Client the length of the
	Proxy-State attributes received by the RADIUS Server. This		Proxy-State attributes received by the RADIUS Server. This
	information is useful to adjust the length of the chunks sent by the		information is useful to adjust the length of the chunks sent by the
	RADIUS Client. The format of this Proxy-State-Len attribute is the		RADIUS Client. The format of this Proxy-State-Length attribute is
	following:		the following:
	1 2 3		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Extended-Type | Value		| Type | Length | Extended-Type | Value
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Value (cont) |		Value (cont) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 14: Proxy-State-Len format		Figure 14: Proxy-State-Length format
	Type		Type
	To be assigned (TBA)		241 (To be confirmed by IANA)
	Length		Length
	7		7
	Extended-Type		Extended-Type
	To be assigned (TBA).		TBD2
	Value		Value
	4 octets. Total length (in octets) of received Proxy-State		4 octets. Total length (in octets) of received Proxy-State
	attributes (including headers).		attributes (including headers).
	This attribute MAY be present in Access-Challenge and Access-Accept		This attribute MAY be present in Access-Challenge and Access-Accept
	packets. It MUST NOT be included in Access-Request or Access-Reject		packets. It MUST NOT be included in Access-Request or Access-Reject
	packets.		packets.
	skipping to change at page 27, line 38		skipping to change at page 27, line 38
	The following table shows the different attributes defined in this		The following table shows the different attributes defined in this
	document related with the kind of RADIUS packets where they can be		document related with the kind of RADIUS packets where they can be
	present.		present.
	| Kind of packet |		| Kind of packet |
	+-----+-----+-----+-----+		+-----+-----+-----+-----+
	Attribute Name | Req | Acc | Rej | Cha |		Attribute Name | Req | Acc | Rej | Cha |
	----------------------+-----+-----+-----+-----+		----------------------+-----+-----+-----+-----+
	Frag-Status | 0-1 | 0-1 | 0 | 0-1 |		Frag-Status | 0-1 | 0-1 | 0 | 0-1 |
	----------------------+-----+-----+-----+-----+		----------------------+-----+-----+-----+-----+
	Proxy-State-Len | 0 | 0-1 | 0 | 0-1 |		Proxy-State-Length | 0 | 0-1 | 0 | 0-1 |
	----------------------+-----+-----+-----+-----+		----------------------+-----+-----+-----+-----+
	11. Operation with proxies		11. Operation with proxies
	The fragmentation mechanism defined above is designed to be		The fragmentation mechanism defined above is designed to be
	transparent to legacy proxies, as long as they do not want to modify		transparent to legacy proxies, as long as they do not want to modify
	any fragmented attribute. Nevertheless, updated proxies supporting		any fragmented attribute. Nevertheless, updated proxies supporting
	this specification can even modify fragmented attributes.		this specification can even modify fragmented attributes.
	11.1. Legacy proxies		11.1. Legacy proxies
	skipping to change at page 31, line 41		skipping to change at page 31, line 41
	The authors request that Attribute Types and Attribute Values defined		The authors request that Attribute Types and Attribute Values defined
	in this document be registered by the Internet Assigned Numbers		in this document be registered by the Internet Assigned Numbers
	Authority (IANA) from the RADIUS namespaces as described in the "IANA		Authority (IANA) from the RADIUS namespaces as described in the "IANA
	Considerations" section of [RFC3575], in accordance with BCP 26		Considerations" section of [RFC3575], in accordance with BCP 26
	[RFC5226]. For RADIUS packets, attributes and registries created by		[RFC5226]. For RADIUS packets, attributes and registries created by
	this document IANA is requested to place them at		this document IANA is requested to place them at
	http://www.iana.org/assignments/radius-types.		http://www.iana.org/assignments/radius-types.
	In particular, this document defines two new RADIUS attributes,		In particular, this document defines two new RADIUS attributes,
	entitled "Frag-Status" and "Proxy-State-Len" (see section 9),		entitled "Frag-Status" and "Proxy-State-Length" (see Section 10),
	assigned values of TBD1 and TBD2 from the Long Extended Space of		with assigned values of 241.TBD1 and 241.TBD2 from the Short Extended
	[RFC6929]:		Space of [RFC6929]:
	Tag Name Length Meaning		Type Name Length Meaning
	---- ---- ------ -------		---- ---- ------ -------
	TBD1 Frag-Status 7 Signals fragmentation		241.TBD1 Frag-Status 7 Signals fragmentation
	TBD2 Proxy-State-Len 7 Indicates the length of the		241.TBD2 Proxy-State-Length 7 Indicates the length of the
	received Proxy-State attributes		received Proxy-State attributes
	The Frag-Status attribute also defines a 8-bit "Code" field, for		The Frag-Status attribute also defines a 8-bit "Code" field, for
	which the IANA is to create and maintain a new sub-registry entitled		which the IANA is to create and maintain a new sub-registry entitled
	"Code values" under the RADIUS "Frag-Status" attribute. Initial		"Code values" under the RADIUS "Frag-Status" attribute. Initial
	values for the RADIUS Frag-Status "Code" registry are given below;		values for the RADIUS Frag-Status "Code" registry are given below;
	future assignments are to be made through "RFC required" [RFC5226].		future assignments are to be made through "RFC required" [RFC5226].
	Assignments consist of a Frag-Status "Code" name and its associated		Assignments consist of a Frag-Status "Code" name and its associated
	value.		value.
	Value Frag-Status Code Name Definition		Value Frag-Status Code Name Definition
	---- ------------------------ ----------		---- ------------------------ ----------
	0 Reserved See Section 9.1		0 Reserved See Section 10.1
	1 Fragmentation-Supported See Section 9.1		1 Fragmentation-Supported See Section 10.1
	2 More-Data-Pending See Section 9.1		2 More-Data-Pending See Section 10.1
	3 More-Data-Request See Section 9.1		3 More-Data-Request See Section 10.1
	4-255 Unassigned		4-255 Unassigned
	Additionally, allocation of a new Service-Type value for "Additional-		Additionally, allocation of a new Service-Type value for "Additional-
	Authorization" is requested.		Authorization" is requested.
	Value Service Type Value Definition		Value Service Type Value Definition
	---- ------------------------ ----------		---- ------------------------ ----------
	TBA Additional-Authorization See section 4.1		TBA Additional-Authorization See Section 5.1
	15. Acknowledgements		15. Acknowledgements
	The authors would like to thank the members of the RADEXT working		The authors would like to thank the members of the RADEXT working
	group who have contributed to the development of this specification,		group who have contributed to the development of this specification,
	either by participating on the discussions on the mailing lists or by		either by participating on the discussions on the mailing lists or by
	sending comments about our RFC.		sending comments about our RFC.
	The authors also thank David Cuenca (University of Murcia) for		The authors also thank David Cuenca (University of Murcia) for
	implementing a proof of concept implementation of this RFC that has		implementing a proof of concept implementation of this RFC that has
End of changes. 28 change blocks.
	65 lines changed or deleted		65 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/