On Oct 13, 2022, at 10:50 AM, Ben Schwartz <bem...@google.com> wrote: > Even if longer SvcParams aren't useful in DNR, creating an encoding that > can't carry them introduces a serious compatibility problem for systems that > copy between SVCB, DNR, and RADIUS. What is such a tool supposed to do when > a valid SVCB record or DNR option is unrepresentable in RADIUS? What is a > naive operator to do, faced with this error message?
The traditional RADIUS solution for encoding data which can't fit into an attribute is one of (a) truncation, or (b) dropping the attribute entirely. The standards are silent on this issue, so the behavior is entirely implementation-defined. As for this issue, it may be best to avoid it entirely with careful design, so that it's not possible for implementations to run into the problem. The only solution which entirely avoids the 253 octet limit is to just define a DHCPv6-Options attribute in RADIUS. It can carry a blob of DHCPv6 options, encoded as DHCPv6 options. This is behavior is permitted by https://www.rfc-editor.org/rfc/rfc6158#section-3.2.4: Another exception to the recommendation against complex types is for types that can be treated as opaque data by the RADIUS server. So just define a DHCPv6-Options attribute from the 245.X space. Allow it to contain any DHCPv6 option. Suggest that the switch / RADIUS client send the options in a DHCPv6 packet. And then it can carry the options needed here. Since the encoding is now DHCPv6 options, all limitations other than the 4K RADIUS "maximum packet size" limitation disappear. And many RADIUS implementations support packets larger than 4K, so that limit is not concrete either. The specification defining DHCPv6-Options could suggest that implementations SHOULD support 64K RADIUS packets. Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
