[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Questions on RADIUS Extended attributes
Bernard Aboba writes...
> Yes. So your proposal looks like this, no?
>
> 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length | Extended-Type |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Value...
> +-+-+-+-+-+-+-+-+
>
> Type
>
> TBD (not 26)
>
> Length
>
> >= 4
>
> Extended-Type
>
> Two octets.
>
> 0: Concatenation
> 1-255: Reserved
> 255-65530: Allocated by IANA
> 65531-65535: Reserved
>
> Value
>
> 0-251 octets (Length - 4).
>
> Only a single RADIUS Extended-Type attribute may be included
within
> a RADIUS attribute of Type TBD. Where the value of the
Extended-
> Type field is zero (0), this indicates that the content of the
value
> field is to be concatenated with the contents of the value field
in
> the previous attribute of Type TBD.
And we clearly require that attributes of type TBD never be re-ordered,
added or deleted by proxies.
This solves two problems:
(1) Exhaustion of ID space.
(2) A standard method of encoding "over-size" attributes (those greater
than 253 but less than the RADIUS PDU size).
I think this meets the requirements we've agreed to for Extended
Attributes.
There are other issues that we have *not* yet agreed to, such as how to
standardize structured data (grouping, sub-types, etc.).
While we agreed to solve one problem at a time, I note there are drafts
waiting in the wings that need to take advantage of grouping features,
or at least are currently designed to use them.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>