From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=DXxb6R6M; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTP id 40DBA5A061A for ; Tue, 19 Nov 2024 19:31:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1732041095; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZvPGmC3GjLvTIBIqq+dJEHsqXFD7faK2787jJwBQ4O0=; b=DXxb6R6MEK74pZPz6RCl1H+aPH4YLDIbr0B0slgJf9hCvkTynlgq9QSHbUtY/9fs+g7xpH +yDPsLRQjwujE4765YdH202k/JEbDSsORBK0HioEQIc43sSTz9biYv8acL2j7GKD6L7jja QlkkVglJJsScghUiVTNFqbT6TzWG0vU= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-359-SBv3SI9dMhmwNUdWUAvcAQ-1; Tue, 19 Nov 2024 13:31:34 -0500 X-MC-Unique: SBv3SI9dMhmwNUdWUAvcAQ-1 X-Mimecast-MFC-AGG-ID: SBv3SI9dMhmwNUdWUAvcAQ Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-38245ddf59fso965605f8f.0 for ; Tue, 19 Nov 2024 10:31:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732041092; x=1732645892; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IWObBLvSJ+x9dbMyzWlAi6gIpRe7dNt+CqNWHC0hB5A=; b=OCz6wUDT69z4gtPZJzU6b4i6GIc0owA0y21HvPuEeM2cVGOqjKTDPTx1rW7PPaLId4 YonAmhTaOllAbnWu8lkZ8q2Y3fl6+eCSlzynBPjUIxc3uigIE8t1pByQdV2IPrjvtPLI hzXZdYsV58vf2Epzx6mCLSwpZ+urvEeke0aO3Q79K/mdAcPAwiUzyQvowVYYwc2WKBnY 3ZjwxiS/TkH9zECiEm8pYRgJZOQQ9dRGpcyOXNcZ2NbOOQBskhz+WEh5WXJ3CtgHi/kd Tji/w84qDVPERicAfs/AkIiF/LiNcw5PvTD5l3X6rST3UMNtuLSN1YHChJEV8f05l/GZ IGDQ== X-Gm-Message-State: AOJu0YyV/wOTCCgdIo7iDpcxIgDbxor1MJeQCXBLv2/8H75octTPpD8U Qv3nnMlBH7bkG4F7Fcu86UrneE+7i0aAuidWTQjEwlZOfNyCmxTpIU3i6N3IMJ0j04zX3YYxSx4 OTUQttw6K/O8/0evy4VMzRMSwOV4ib7zvT31R6CszWNi+Ut/KtyS+/fTgMVJLSFX9ew1zUS2Pn+ oapIBsCMsJTTd29T/jsYL9tmc+O2wNgrud X-Received: by 2002:a5d:6dad:0:b0:382:4b69:9c75 with SMTP id ffacd0b85a97d-3824b699f93mr4935678f8f.43.1732041092213; Tue, 19 Nov 2024 10:31:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IEHCudO/ZAjJv6bN4kRkCG+iZ/9N1VOH8j40u2mtYU++XEEvn1TbIq2acE1P2T204PtGc0AwA== X-Received: by 2002:a5d:6dad:0:b0:382:4b69:9c75 with SMTP id ffacd0b85a97d-3824b699f93mr4935646f8f.43.1732041091676; Tue, 19 Nov 2024 10:31:31 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3824946166bsm6338276f8f.85.2024.11.19.10.31.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Nov 2024 10:31:30 -0800 (PST) Date: Tue, 19 Nov 2024 19:31:29 +0100 From: Stefano Brivio To: Enrique Llorente Pastora Subject: Re: [PATCH v2] dhcp, dhcpv6: Add hostname and client fqdn ops Message-ID: <20241119193129.44cc2725@elisabeth> In-Reply-To: References: <20241114084727.37263-1-ellorent@redhat.com> <20241114181323.14fd3d36@elisabeth> <20241115122857.7bf2b8e2@elisabeth> <20241119010115.77f7fcba@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: dkRqjxl7GtQl0hRvNiEvRO5ZstashF8haBSdRu000xY_1732041093 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 4NQTNIRCRVEEBJFMDYSJWKPYOX7PUJUE X-Message-ID-Hash: 4NQTNIRCRVEEBJFMDYSJWKPYOX7PUJUE X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, 19 Nov 2024 14:48:53 +0100 Enrique Llorente Pastora wrote: > On Tue, Nov 19, 2024 at 1:01=E2=80=AFAM Stefano Brivio wrote: > > > > Sorry for the delay. > > > > On Mon, 18 Nov 2024 13:20:03 +0100 > > Enrique Llorente Pastora wrote: > > =20 > > > [...] > > > > > > 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 =20 > > > > 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. =20 >=20 > 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. >=20 > 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. >=20 > 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 =20 > > > > ...taking a hostname or a FQDN? =20 >=20 > 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 =20 > > > > 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. =20 >=20 > So some examples and what may mean at DHCPv4 (option 12 and option 15) > and DHCPv6 (option 39) >=20 > --fqdn=3Dhost1.passt.net > - v4,opt12 =3D host1 > - v4,opt15 =3D passt.net > - v6.opt39 =3D 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=3Dhost1.local > - v4,opt12 =3D host1 > - v6.opt39 =3D host1[.local] // not sure >=20 > --fqdn=3Dhost1 > [error] >=20 > > =20 > > > - For IPv6 Option(39) with flags S and O <- so we can totally ignore = the client =20 > > > > ...and what would we send in this option if we're given a hostname? > > Here, we MUST send a FQDN, not an unqualified hostname. =20 >=20 > 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. =20 >=20 > Right, make sense, let's follow RFC's. >=20 > > > - 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). = =20 > > > > 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 =20 >=20 > The alternative I was thinking (In case 81 is not really doing what we ne= ed) > 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) >=20 > > - ask libvirt to take zero, one or two different attributes between > > "fqdn" (setting --fqdn) and "hostname" (setting --hostname) > > > > ? =20 >=20 > 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: > > > > abcd.example.comabcd > > > > 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 at that point. >=20 > Make sense. >=20 > > Side note: with this item from the feature list on the website, at > > https://passt.top/#services: > > > > =E2=8C=9A 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 reques= t > > 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). =20 >=20 > 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 --=20 Stefano