<div dir="ltr"><div>Hello, Maria!</div><div><br></div><div>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<<font face="Gentium">deadbeef</font>> or hex[<font face="Gentium">deadbeef</font>] maybe? Or even something exotic like hex|<font face="Gentium">deadbeef</font>| ?<br></div><div><br></div><div>Would you like to keep my proposed changes for IPv6 and bytestrings too? Or just introduce the new syntax?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 12, 2023 at 1:33 PM Maria Matejka <<a href="mailto:maria.matejka@nic.cz" target="_blank">maria.matejka@nic.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><font face="Gentium">Hello!</font></p>
<p><font face="Gentium">This looks like a clever solution for such a
problem. Thank you for the patch!<br>
</font></p>
<p><font face="Gentium">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?</font></p>
<p><font face="Gentium">Maria</font><br>
</p>
<div>On 6/12/23 13:08, Alexander Zubkov via
Bird-users wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Attached patch [radv-custom.patch] makes it possible to
define such options with the syntax:</div>
<div><br>
</div>
<div>other type <num> <bytestring></div>
<div><br>
</div>
<div>I can also prepare a patch for documentation if it is to be
merged.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>If those changes for bytestrings are OK too, I also can
prepare further patch for documentation.</div>
<div><br>
</div>
<div>Have a nice day,</div>
<div>Alexander Zubkov<br>
</div>
</div>
</blockquote>
<pre cols="72">--
Maria Matejka | BIRD Team Leader | CZ.NIC, z.s.p.o.</pre>
</div>
</blockquote></div>