DHCP Option encoding

[kattasrao]

Hi,
I have concern with the way Bootz is using DHCP options 143 for v4 and 136 for v6.
Since this is IETF standards based option, anyone who wants to use this option should
be in conformance with RFC.

This option is standardized by RFC 8572, section 8. In future, when DHCP servers starts
adding support for this option, they will follow IETF since it is standardized way.
So, bootz should also align with this uniform encoding so that both Secure-ZTP and
Bootz can work with same DHCP option type.

how it should be:
(full) option length should follow the type-143. Size 1-bytes.
(Section-8.1 of RFC 8572)

         0                             1
         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |   option-code (143)   |     option-length     |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        .                                               .
        .    bootstrap-server-list (variable length)    .
        .                                               .
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

        * option-code: OPTION_V4_SZTP_REDIRECT (143)
        * option-length: The option length in octets.
        * bootstrap-server-list: A list of servers for the
           client to attempt contacting, in order to obtain
           further bootstrapping data, in the format shown
           in [Section 8.3](https://datatracker.ietf.org/doc/html/rfc8572#section-8.3).

Then server-list is encoded like this (Section 8.3 of RFC 8572):

Both of the DHCPv4 and DHCPv6 options defined in this section encode
a list of bootstrap server URIs. The "URI" structure is a DHCP
option that can contain multiple URIs (see [RFC7227], Section 5.7).
Each URI entry in the bootstrap-server-list is structured as follows:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
|       uri-length              |          URI                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

* uri-length: 2 octets long; specifies the length of the URI data.
* URI: URI of the SZTP bootstrap server.

Since length is 2 bytes, it is will uint-short. This should be encoded in htons() format.
Also, this enables sending multiple servers as list for load balancing and redundancy.

Yes, it looks a bit silly since full option length is 8 bits thus max 255 bytes while each
URL length field is 16-bit which is sub-part of 255 bytes. But "this is the way" :-)

Not sure if following code from plugins/bootz/bootz.go is doing same as above. But wanted to
make sure we are doing right thing.

   ztpV4Opt = &dhcpv4.Option{
            Code:  dhcpv4.GenericOptionCode(OPTION_V4_SZTP_REDIRECT),
            Value: dhcpv4.String(url.String()),
    }

Thanks,
Katta

[sam-homa]

I agree, you are right. That logic does not seem to be following the standard.

In fact, we have only implemented our (Google) internal DHCP server to follow the bootstrap-server-list (note we only need V6 and implemented that only for now). This is the way Arista has also (historically) provided responses to us for sZTP (prior to Bootz).

The code comes from Cisco developers if I am not mistaken. We are not using that part of open source for our internal DHCP server. I am under the impression that the Cisco's DHCP agent's decoding logic won't work. We have just reached the point of testing with a CiscoXR device and we will likely have the same problem.

Let me cc a few people and try to get alignment across other vendors.

[sam-homa]

@mojiiba can you please take a look.

I had raised this with Aaron in the past b/309713621 and due to lack of the other Cisco-specific option (242), we were experiencing two problems. We fixed the default gateway (option 242) but I lost access to the lab device to verify that your agent is actually following the standard. But it seemed to me that it indeed had this problem.

[Ibrahim-402]

Bonjour je cherche un projet sur Bot réseaux de distribution automatique des adresses ip avec le protocole DHCP