Re: [PATCH v2 2/2] dhcpv6: Inject custom options into DHCPv6 replies

On Fri, 19 Jun 2026 14:03:10 +1000 David Gibson wrote:

On Thu, Jun 18, 2026 at 05:35:29PM +0530, Anshu Kumari wrote:

...

Append user-specified options from --dhcpv6-opt to DHCPv6 reply messages. Options are parsed from the stored string value at reply time using dhcpv6_opt_parse(), and skipped with a debug message if they exceed the available space.

Link: https://bugs.passt.top/show_bug.cgi?id=192 Signed-off-by: Anshu Kumari --- v2: - Updated dhcpv6_custom_opts_fill() to parse str at reply time using dhcpv6_opt_parse() instead of copying cached val/len.

As with DHCPv4, it's not that I'm against storing the parsed values persistently, just that I'm against storing them twice.

With this revision, they're not stored, but still parsed twice, and:

The existing data structures for DHCPv6 are different, so maybe there's not an obvious place to store pre-parsed options.

...yes, I guess this is one reason, but as we only let users specify options we have in the table, we could actually make space for that by declaring an array of 64 KiB * 84 entries. The highest option number we currently support is 83, and IANA only registered up to number 150, so I would expect it to remain within a reasonable range, and in any case only memory initialised here is actually used / allocated. Another bit missing would be the rendering of binary values back to human-readable ones for conf_print() purposes. That looks like a bit more effort. On the other hand, one day we'll probably want to have pesto(1) configure this stuff at runtime, and sharing binary values between processes looks more practical than sharing configuration strings... so I'd tend to say that it's effort we will need anyway at some point. If it's too complicated for whatever reason, I'm fine with the current approach as well. I'd just suggest to make enough room for all the options we support, because that part is simple. -- Stefano