RE: Meaning of "backward compatible" WAS RE: Consensus Call on RADEXT WG re-charter

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Glen Zorn writes...

>  One example: the maximum length of 4096 octets for a Radius packet
> was chosen (IIRC) based upon the maximum size of a _UDP_ frame that
> could be reliably transmitted w/o fragmentation _in the access 
> networks of the day_.

I've forgotten that discussion.  Isn't 4096 the maximum size *any* UDP
frame, IP fragmentation and reassembly notwithstanding?

> It doesn't seem to be very smart to go to all the trouble of 
> defining RADIUSoTCP while leaving this kind of unnecessary, 
> UDP-specific limitation in place.

I recall that you have many times advocated the need for longer RADIUS
packets and/or more/longer RADIUS attributes.

It is true that any RADSEC to RADIUS gateway needs to address what is to be
done about larger than UDP-size RADSEC messages in translating them to
RADIUS messages.

I need to see if that issue is covered in the "AAA Transports" RFC...

I believe that addressing this issue ought to be another element of our
definition of backwards compatibility for RADIUS over non-UDP transports.



--
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/>