Wrong data layout for DHCPv6 option bootfile-param?

[Celelibi]

Hello,

I've seen that the DHCPv6 option 60 has been implemented. However, I
think the data layout sent on the network is wrong with respect to the
RFC 5970.

The current implementation send this option as a single string. I.e. a
16 bits integer representing the size of the string and the sequence
of bytes of the string.

The RFC 5970 say that the data layout of this option start with the
total byte size on a 16 bits integer, followed by a sequence of
strings (length + bytes).

Have I understood something wrong or is this really a bug from the dhcpd?


Best regards,
Celelibi
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Shawn Routhier]

> On Aug 26, 2015, at 4:35 PM, Celelibi <[hidden email]> wrote:
>
> Hello,
>
> I've seen that the DHCPv6 option 60 has been implemented. However, I
> think the data layout sent on the network is wrong with respect to the
> RFC 5970.
>
> The current implementation send this option as a single string. I.e. a
> 16 bits integer representing the size of the string and the sequence
> of bytes of the string.
>
> The RFC 5970 say that the data layout of this option start with the
> total byte size on a 16 bits integer, followed by a sequence of
> strings (length + bytes).
>
> Have I understood something wrong or is this really a bug from the dhcpd?

Neither.  This is a limitation of the description and parsing code used
to manage the options.  With the current description it isn’t possible
to represent the multiple variable length fields that the option describes.
The closest we currently have is X - ascii or binary - in which you would
need to pre-format the parameters into a single string.  

Or if you have
a well specified list (for example you have a single parameter) you could
undefine RFC5970 and add your own definition that is more restrictive
but allows you easier control.

>
>
> Best regards,
> Celelibi
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Celelibi]

2015-08-27 2:05 UTC+02:00, Shawn Routhier <[hidden email]>:

>
>> On Aug 26, 2015, at 4:35 PM, Celelibi <[hidden email]> wrote:
>>
>> Hello,
>>
>> I've seen that the DHCPv6 option 60 has been implemented. However, I
>> think the data layout sent on the network is wrong with respect to the
>> RFC 5970.
>>
>> The current implementation send this option as a single string. I.e. a
>> 16 bits integer representing the size of the string and the sequence
>> of bytes of the string.
>>
>> The RFC 5970 say that the data layout of this option start with the
>> total byte size on a 16 bits integer, followed by a sequence of
>> strings (length + bytes).
>>
>> Have I understood something wrong or is this really a bug from the dhcpd?
>
> Neither.  This is a limitation of the description and parsing code used
> to manage the options.  With the current description it isn’t possible
> to represent the multiple variable length fields that the option describes.
> The closest we currently have is X - ascii or binary - in which you would
> need to pre-format the parameters into a single string.

That's what I did. But I don't think it's the most readable or
maintainable thing ever.

option dhcp6.bootfile-param = concat(encode-int(3, 16), "ABC");

If it's not a bug, I guess there is no plan in adding the support for
a sequence of strings data type in the near future. Am I right?
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users