On 22/10/2019 20:41, Roy Marples wrote:
> On 22/10/2019 17:17, Normen Kowalewski wrote:
>> FAIW - i was curious to see if RFC 8415 of November 2018, the update
>> of the now officially obsoleted RFC 3315, uses some other wording, but
>> it also just speaks about 4 octets that jointly are an unsigned integer
>> https://tools.ietf.org/html/rfc8415#section-21.21
> 
> https://tools.ietf.org/html/rfc8415#section-8
> 
>    All values in the message header and in options are in network byte
>    order.
> 
> Pretty clear in my view.
> 
>> The RFC obviously expects an implementor to know which data type in
>> his specific environment and implementation would match this
>> requirement - obviously for example it would be good if the on the
>> wire format would not change by big endian/little endian diversions
>> and so on...
> 
> No, the RFC (unless otherwise noted) expects all unsigned integers to be
> used in ntohl(3) and htonl(3) (or equivalents thereof depending on
> platform and integer size) to ensure endian does not affect on wire format.
> 

In the dnsmasq case opt6_uint()  and put_opt6_long do the byte-order
swaps as the data in copied from/to packet data, so everywhere in the
code it's in host order. Not that is matters much as it's pretty much
treated as an opaque type, except where it's stored in the leasefile as
ascii number, where it's printed and read as unsigned.

I  think it gets logged somewhere too.


Simon.

> Roy
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to