[PATCH] adding custom options in radv protocol, strict ipv6 regex

[Alexander Zubkov]

On Fri, Jun 23, 2023, 17:47 Ondrej Zajicek <santiago at crfreenet.org> wrote:

> On Mon, Jun 12, 2023 at 01:08:15PM +0200, Alexander Zubkov via Bird-users
> wrote:
> > Hi,
> >
> > Currently one can use only a predefined set of advertised options in radv
> > protocol, that are supported by bird's configuration. It would be
> > convenient to be able to specify other possible options at least manually
> > as a blob so one should not wait until it is supported in the code,
> > released, etc.
>
> Hi
>
> Merged:
>
>
> https://gitlab.nic.cz/labs/bird/-/commit/9c81250c04798fd274ae9d77380e93b941ac2d7f
>
> Hopefully there is no requirement for RA options to be sorted by type, at
> least i did not find it in RFC 4861.
>
> The only objection from me is that 'other type' option name is kind of
> non-descriptive, does not indicate it is related to RA options (nor it is
> implicated by context). I do not really have a good idea for alternative,
> perhaps just 'custom option'? What do you think?
>

Yes, I was thinking about "custom" too. But it introduces a new keyword. So
I tried too choose something suitable from available keywords. But if it is
not a problem, I would prefer "custom" too as more descriptive.


> Could you prepare a patch for documentation?
>

Sure, just will wait for the final decision about the syntax ("other" vs
"custom").


> BTW, why not to use WALK_LIST() in radv_prepare_custom()?
> (just noticed in now)
>

That is a good question. Actually I just used the structure of the similar
function for the predefined option and didn't thought much about it. Now
that you pointed that out, I remember that macro from the other parts of
the code. And it seems reasonable to use it here, and probably in the
"source" function too. I can prepare a patch for that.


> --
> Elen sila lumenn' omentielvo
>
> Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230624/56557ec4/attachment.htm>