Re: [PATCH v2] dhcp, dhcpv6: Add hostname and client fqdn ops

[Stefano Brivio <sbrivio@redhat.com>]

On Tue, 19 Nov 2024 14:48:53 +0100
Enrique Llorente Pastora <ellorent@redhat.com> wrote:

> On Tue, Nov 19, 2024 at 1:01 AM Stefano Brivio <sbrivio@redhat.com> wrote:
> >
> > Sorry for the delay.
> >
> > On Mon, 18 Nov 2024 13:20:03 +0100
> > Enrique Llorente Pastora <ellorent@redhat.com> wrote:
> >  
> > > [...]
> > >
> > > From some experiments I have do with networkmanager at a fedora 41,
> > > the DHCPv4 client fqdn is only used
> > > for clients to state the fqdn but never for client to configure it's
> > > own hostname
> > >
> > > But the DHCPv6 client does update the client's hostname with single
> > > stack ipv6  
> >
> > Ouch. Of course we have to consider this for compatibility reasons, but
> > it's obviously inconsistent: RFC 4704 is without a doubt equivalent
> > to RFC 4702 for IPv6.  
> 
> Well from what I have read around IPv6 option 39 can be considered as
> IPv4 option 12 + option 15
> Where you use option 12 to send the hostname part and option 15 the
> rest of the fqdn.

Logically, yes, but a client has to prefer DHCP option 81 if sent by
the server, see below.

> > Neither says that a client must update its hostname, but if DHCPv6
> > option 39 causes NetworkManager to, it doesn't make a lot of sense to
> > me that DHCP option 81 doesn't.
> >
> > I think support for option 39 (in the sense of setting the hostname,
> > not in general) was simply added later, by commit 1f74ea52f581
> > ("policy: get the DHCPv6 hostname from the FQDN option"), and that
> > might simply be the reason.
> >
> > Well, regardless of whether it makes sense to propose to change this
> > for NetworkManager, we have to deal with existing versions anyway.
> 
> Well looks like option DHCPv4 81 was never intended for that since you
> have the option 12 and 15 already there

That's not true, see RFC 4702 3.1:

3.1.  Interaction with Other Options

   Other DHCP options MAY carry data that is related to the Domain Name
   field of the Client FQDN option.  The Host Name option [12], for
   example, contains an ASCII string representation of the client's host
   name.  In general, a client does not need to send redundant data, and
   therefore clients that send the Client FQDN option in their messages
   MUST NOT also send the Host Name option.  Clients that receive both
   the Host Name option and the Client FQDN option from a server SHOULD
   prefer Client FQDN option data.  Section 4 instructs servers to
   ignore the Host Name option in client messages that include the
   Client FQDN option.

and later, in 3.5:

   The server MAY be configured to use the name supplied in the client's
   Client FQDN option, or it MAY be configured to modify the supplied
   name or to substitute a different name.  The server SHOULD send its
   notion of the complete FQDN for the client in the Domain Name field.

So, yes, NetworkManager doesn't take the hostname from it, but that's
just one possible client for passt. I'd stick to normative references.

> in the case of DHCPv6 you just have option 39.
> 
> But I will ask NM maintainers about why NetworkManager do not update
> client's fqdn with DHCPv4 81.

Thanks. Regardless of that, even if NetworkManager decides to just take
option 81, we'll have to support existing versions as well, so it
doesn't change things much, I guess.

> > > so I think we should do the following:
> > > - Have only one argument -H/--hostname  
> >
> > ...taking a hostname or a FQDN?  
> 
> Always FQDN, if users want just the hostname they can pass "passt1.local"
> is better to have just --fqdn option instead of -H/--hostname

Okay, so far so good, except that here:

> > > - Delegate the config to libvirt
> > > - For IPv4 Options(12) with it  
> >
> > What would we send in this option if we're given a FQDN? We shouldn't
> > (no MUST NOT, though) send a FQDN in it.  
> 
> So some examples and what may mean at DHCPv4 (option 12 and option 15)
> and DHCPv6 (option 39)
> 
> --fqdn=host1.passt.net
> - v4,opt12 = host1
> - v4,opt15 = passt.net
> - v6.opt39 = host1.passt.net

...this is unexpected. If I didn't know what NetworkManager does with
it, I would expect --fqdn to set DHCP option 81. It's in its name:
"Fully Qualified Domain Name (FQDN) Option".

> --fqdn=host1.local
> - v4,opt12 = host1
> - v6.opt39 = host1[.local] // not sure
> 
> --fqdn=host1
> [error]
> 
> >  
> > > - For IPv6 Option(39) with flags S and O <- so we can totally ignore the client  
> >
> > ...and what would we send in this option if we're given a hostname?
> > Here, we MUST send a FQDN, not an unqualified hostname.  
> 
> At least NetworkManager does not care if it's fqdn or not and changes
> the VM's hostname.

Fine, but again, we have other clients that might be more or less picky.

> > By the way, if the client sets 'S' to 0, I think that we should (even
> > though it's not a MUST) set 'O' to 0, because we're not overriding it.
> >
> > It's not needed but it's less likely to cause issues with a buggy
> > DHCPv6 client.  
> 
> Right, make sense, let's follow RFC's.
> 
> > > - Document this and if someone is not happy, don't use that option.
> > >
> > > Also for DHCPv4 we have also the option (15) for domain names, so
> > > maybe if we detect that -H has a domain name we also add option(15).  
> >
> > I'm not sure if we should try to be clever about it. In general I agree
> > it's a good idea, but: 1. we can't fix the inconsistencies I presented
> > above (I think) and 2. we're actually losing generality because there
> > are configurations that a user can't cover this way, such as:
> >
> > - setting DHCP option 81 itself
> >
> > - setting hostname only, without FQDN, or FQDN without hostname
> >
> > - setting both FQDN and hostname to different (non-conflicting) values
> >
> > - setting a different domain for the guests (it's not possible at the
> >   moment but it could become a bit complicated to add this option in
> >   the future), say, the host is called "x" and we would like to call
> >   the guest "x.guests".
> >
> > The RFCs are doing us a big favour by not coupling options together and
> > letting us do pretty much what we want.
> >
> > Do you think it would be problematic to do this instead:
> >
> > - -H / --hostname sets DHCP option 12
> >
> > - --fqdn sets DHCP option 81 and DHCPv6 option 39  
> 
> The alternative I was thinking (In case 81 is not really doing what we need)
> is just having --fqdn and for DHCPv4 use option 12 and 15
> and for DHPv6 option 39 and force users to always pass a fqdn (it can
> be hostname.local)
> 
> > - ask libvirt to take zero, one or two different attributes between
> >   "fqdn" (setting --fqdn) and "hostname" (setting --hostname)
> >
> > ?  
> 
> If we go with just --fqdn then this would be better.

...why is it better? I mean, I understand that it would make libvirt's
XML shorter, but I don't expect the matching libvirt implementation to
be significantly more complicated.

That would also risk being at the expense of any other user that's not
libvirt/KubeVirt plus NetworkManager, by the way.

> > In the use case that KubeVirt needs the most (if I understood
> > correctly), the domain XML would include something like:
> >
> >   <fqdn>abcd.example.com</fqdn><hostname>abcd</hostname>
> >
> > which is not ideal, but we have a configuration front-end for it, and,
> > if NetworkManager ever changes to handling --fqdn as it handles
> > --hostname, we could skip <fqdn/> at that point.
> 
> Make sense.
> 
> > Side note: with this item from the feature list on the website, at
> > https://passt.top/#services:
> >
> >   ⌚ fine-grained configurability of DHCP, NDP, DHCPv6 options
> >
> > ...I was actually thinking of a mechanism where users could set
> > arbitrary options, some of which with type validation, in a similar
> > way as what dhcpcd (as client) supports:
> >
> > $ /sbin/dhcpcd -V
> > [...]
> > DHCPv4 options:
> > [...]
> > 001 subnet_mask                                  ipaddress request
> > 121 classless_static_routes                      string rfc3442
> > 002 time_offset                                  int32
> > 003 routers                                      array ipaddress request
> > 004 time_servers                                 array ipaddress
> > [...]
> > DHCPv6 options:
> > 00001 client_id                                  binhex
> > 00002 server_id                                  binhex
> > 00003 ia_na                                      embed index norequest
> > [...]
> >
> > but without support for fancy attributes such as "embed" or "index".
> >
> > That is, supporting arbitrary "ia_na" options would be way too
> > complicated, but simple strings (such as the ones we have in option 12)
> > or numbers would be okay. Say: '--dhcp-opt 12 abcd'.
> >
> > On the other hand, this doesn't solve the problem for FQDN options
> > because they have flags which need some logic in the server itself,
> > so... yes, this is just a side note, and I'm not saying we should
> > implement this now (or ever).  
> 
> Well we didn't have many customers asking for super specific DHCP

Yes, I understand that's good enough for KubeVirt, but we have other
users.

In any case, this was asked a couple of times but I can't remember
really fundamental use cases around it that couldn't be solved
otherwise, and we have a long list of features we never seem to be
getting to.

This was just a side note because it's one possible direction/future
implementation, but again, I'm not saying it will come soon (or ever).

> stuff, not sure if
> it's worth it, like users that do really need to configure their own
> network just use layer2 with their own
> DHCP server and network infra.

It depends if privileges and other features matter to you. I've also
seen users experimenting with passt on Android, and there you can't
just use a DHCP server. Or muvm. Or:

  https://github.com/siderolabs/talos/issues/9725

-- 
Stefano