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

[Maria Matejka]

Hello!

I think using hex() and base64() with adding these two tokens to the 
"kw_sym:" non-terminal. This way, no current config should break.

Also it may be handy for both hex() and base64() to accept any number of 
whitespace inside the argument, to enable configs like hex(de ad be ef) 
or other direct pastes from hexdumps or base64 encoders. We could then 
e.g. add the SSH keys for RPKI inline to the config file.

I'd prefer keeping the IPv6 and bytestrings as they are now, possibly 
even deprecating the current bytestring format in future. (Weak opinion 
on this.)

Maria

On 6/12/23 14:24, Alexander Zubkov wrote:
> Hello, Maria!
>
> You suggestion for blob syntax seems good to me. I think I can try to 
> prepare patches for that. Only one concern is that it could break some 
> current configuration files, if they have functions with such names. 
> Maybe it is better to use some other "brackets" to make it less 
> possible to hit something? hex<deadbeef> or hex[deadbeef] maybe? Or 
> even something exotic like hex|deadbeef| ?
>
> Would you like to keep my proposed changes for IPv6 and bytestrings 
> too? Or just introduce the new syntax?
>
> On Mon, Jun 12, 2023 at 1:33 PM Maria Matejka <maria.matejka at nic.cz> 
> wrote:
>
>     Hello!
>
>     This looks like a clever solution for such a problem. Thank you
>     for the patch!
>
>     Regarding the bytestring syntax, what about adding some syntax
>     like hex(deadbeef12345678) or even base64(...) where the user
>     could write byte blob of any length?
>
>     Maria
>
>     On 6/12/23 13:08, 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.
>>
>>     This idea is inspired by presentation by Ondřej Caletka at CSNOG,
>>     in which he noticed the lack of either PREF64 option or
>>     possibility to add custom options in various software.
>>
>>     Attached patch [radv-custom.patch] makes it possible to define
>>     such options with the syntax:
>>
>>     other type <num> <bytestring>
>>
>>     I can also prepare a patch for documentation if it is to be merged.
>>
>>     But it does solve the question with PREF64 completely. Because
>>     currently bytestring minimal length is 16 bytes, but for PREF64
>>     we need to provide a 14-byte blob. And for minimal RA option, it
>>     have to be as short as 6 bytes.
>>
>>     So another patch [bytestring-short.patch] allows bytestrings to
>>     be as short as 6 bytes, when colon-notation is used:
>>     "01:02:03:04:05:06". And I kept the minimum size of 16 bytes
>>     without colons, because it can conflict with some symbol names.
>>
>>     The main concern is that a 6-byte bytestring conflicts with the
>>     MAC address representation. Bird does not have the type for it
>>     currently, but who knows, it might need it in the future. So we
>>     might need some new syntax for bytestring in that case. Or it can
>>     be postponed to later time. In this case introduction of
>>     MAC-address lexems would break configs that use 6-byte
>>     bytestrings (if we want to care much about those).
>>
>>     It is also not possible to define a 8-byte bytestring, because it
>>     conflicts with IPv6 address, but we are introducing short
>>     bytestrings for RA here, and 8-byte bytestrings are not strictly
>>     required for that, because possible option sizes are 8, 16, ...
>>     with payloads 2 bytes less: 6, 14, ... So if one needs a 8-byte
>>     payload, he can easily pad it with extra zeroes ":00" with the
>>     same on-the-wire result. But still, this gives one more reason
>>     for an additional syntax for bytestrings.
>>
>>     There also was possbility to explicitly allow only 6, 7, 9 and
>>     greater lengths of bytestrings. Or to move IPv6 regex definition
>>     before bytestring definition to make it more preferrable. I
>>     choose the second variant, but IPv6 regex is too loose now and
>>     match many things far from IPv6 notation. So I decided to provide
>>     a more strict regex definition for IPv6 addresses. Of course it
>>     is ugly, but I think it could be helpful anyway, because it does
>>     not conflict with other similar lexems, including MAC addresses.
>>
>>     As a downside for this, in case of some typo in IPv6 address,
>>     there will not be a meaningful error about bad IPv6 address. So I
>>     added an additional regex there, to catch lexems with hex digits
>>     and at least 2 colons to show more meaningful error for that. But
>>     I'm not sure about it.
>>
>>     If those changes for bytestrings are OK too, I also can prepare
>>     further patch for documentation.
>>
>>     Have a nice day,
>>     Alexander Zubkov
>
>     -- 
>     Maria Matejka | BIRD Team Leader | CZ.NIC, z.s.p.o.
>
-- 
Maria Matejka | BIRD Team Leader | CZ.NIC, z.s.p.o.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230612/bc4dc703/attachment.htm>