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

[Alexander Zubkov]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230612/be5170d3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: radv-custom.patch
Type: application/x-patch
Size: 6399 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230612/be5170d3/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bytestring-short.patch
Type: text/x-patch
Size: 2666 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230612/be5170d3/attachment-0001.bin>