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

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 19 Jun 2026 14:03:10 +1000
David Gibson <david@gibson.dropbear.id.au> 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 <anskuma@redhat.com>
> > ---
> > 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