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.