On Oct 13, 2022, at 4:11 AM, mohamed.boucad...@orange.com wrote: > > Hi Alan, all, > > FYI, we do already have the following in the draft to pass RADIUS attributes > in DHCPv6: > > In deployments where the NAS behaves as a DHCPv6 relay agent, the > procedure discussed in Section 3 of [RFC7037] can be followed. To > that aim, Section 6.3 updates the "RADIUS Attributes Permitted in > DHCPv6 RADIUS Option" registry ([DHCP-RADIUS]).
I was thinking of the other way around: allowing DHCPv6 options inside of a RADIUS attribute. > For the typical target deployment in the draft, I don' think we have a valid > case for long data. That's said, we may include a provision to allow for > multiple TLVs; each carrying self-contained key=value data. If that's the target deployment, then that works. I'd suggest updating the draft to explicitly mention this limitation, and describe why it's acceptable. I'd also suggest changing the RADIUS attribute space from 241.X to 245.X. See https://www.rfc-editor.org/rfc/rfc8044#section-3.16 With 241.X, the maximum amount of data which can be carried is 252 octets. This space has to encapsulate all child attributes, including headers and contents. Which means that each individual child attribute can carry much less than 253 octets. With 245.X, the maximum amount of data which can be carried is limited only by the RADIUS packet length. Each child attribute can then carry a full 253 octets of data. And there are no limits on the number of child attributes which ca be carried. Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
