On Oct 13, 2022, at 4:19 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > If I understand you correctly, the DHCPv6 option bytes would just be sliced > up into 253 byte fragments, and then reassembled into DHCPv6 options.
Largely, yes. > The radius part need not respect the DHCPv6 option boundaries, but can fill > each DHCPv6-Options with as much as the fragment as fits. Yes. Similar things happen already with EAP packets. These are ~1K or more. RADIUS is just a transport, so "EAP goes in" and "EAP comes out". The EAP contents are unmodified. > Does Radius over TCP relax any of the 4K issue? No. But it avoids fragmentation of UDP packets. Which is positive. And RADIUS/UDP needs to die anyways, so .... Taking a quick look, nothing else in RADIUS mandates support for longer than 4K packets. However, I believe that many implementations are happy to accept longer packets. i.e. it's 2022, I think that software can easily handle 64K buffers for network protocols. There's also RFC 7499 which supports fragmentation of CoA packets. Perhaps a similar method could be used here, if required? Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
