On Oct 12, 2022, at 1:53 PM, Ben Schwartz <[email protected]> wrote: > > A practical limit of around 4000 octets for SvcParams seems likely to be > fine. A hard limit of 250 octets has a real chance of becoming a practical > problem. I would encourage you to reconsider the format.
There are a number of limitations which all have to be addressed in order for any solution to work. :( This specification requires "grouped" data, which generally means TLVs in RADIUS. However, it also requires "long" data, which is forbidden to be used in TLVs by https://www.rfc-editor.org/rfc/rfc8044#section-3.16 As the author of RFC 8044, I can say that there are good reasons for that prohibition. I can also say that there are good reasons why the prohibited functionality is needed by this standard. I'm not sure there are any perfect solutions. There's only varying amounts of holding your nose, and going with something which is the lesser of two evils. Off of the top of my head, one approach is to simply give up on transporting the DHCPv6 data as RADIUS attributes, and instead just define a DHCPv6-Options attribute in RADIUS, which carries raw DHCPv6 options. This attribute could carry ~4K of data, and be in a format which complies with RFC 8044. That would solve the problem not only for this use-case, but for any future one, too. Just define the DHCPv6 option, and then say "carry it in RADIUS attribute DHCPv6-Options" That makes it difficult for administrators to configure, as the RADIUS configuration now has to carry "raw" DHCPv6 data. But... it's RADIUS. That's the least of its ugliness. There's already something similar in DHCPv4: https://datatracker.ietf.org/doc/html/rfc4014 i.e. DHCPv4 carries RADIUS attributes. So there's reasonable precedent. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
