On Tue, 19 Nov 2024 14:48:53 +0100 Enrique Llorente Pastora <ellorent(a)redhat.com> wrote:On Tue, Nov 19, 2024 at 1:01 AM Stefano Brivio <sbrivio(a)redhat.com> wrote:Logically, yes, but a client has to prefer DHCP option 81 if sent by the server, see below.Sorry for the delay. On Mon, 18 Nov 2024 13:20:03 +0100 Enrique Llorente Pastora <ellorent(a)redhat.com> wrote: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.[...] 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 ipv6Ouch. 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.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.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 therein 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.Okay, so far so good, except that here:Always FQDN, if users want just the hostname they can pass "passt1.local" is better to have just --fqdn option instead of -H/--hostnameso I think we should do the following: - Have only one argument -H/--hostname...taking a hostname or a FQDN?...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".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- Delegate the config to libvirt - For IPv4 Options(12) with itWhat would we send in this option if we're given a FQDN? We shouldn't (no MUST NOT, though) send a FQDN in it.--fqdn=host1.local - v4,opt12 = host1 - v6.opt39 = host1[.local] // not sure --fqdn=host1 [error]Fine, but again, we have other clients that might be more or less picky.At least NetworkManager does not care if it's fqdn or not and changes the VM's hostname.- 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....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.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.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)- 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- 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.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).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 DHCPstuff, 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