From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine 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=B8F+95Ho; 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 ESMTPS id 3DED35A0625 for ; Thu, 18 Dec 2025 00:22:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1766013746; 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=EOwRgtkQgjCZPMZX4W3S5E8k+Iueo8dOplhU/eXqoXI=; b=B8F+95HoKh0TqVMqwbQo+LGdXICeOOfmBjxn9V/Hz+Jvn6YunWtgTu/uv2KRgcqcKZLit/ aHbrggjeZ2XIqyHu1oEw4ibt1K5lxOSfiBad7n7d+pa7q6RzPca1pv6xxiNRZEZrzbXNIv 8wqE/2u37S5070lRfrmA6pa7aIEDiok= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-261-tJlMfqkfOXyxzW6KocMxqQ-1; Wed, 17 Dec 2025 18:22:24 -0500 X-MC-Unique: tJlMfqkfOXyxzW6KocMxqQ-1 X-Mimecast-MFC-AGG-ID: tJlMfqkfOXyxzW6KocMxqQ_1766013743 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4775f51ce36so329145e9.1 for ; Wed, 17 Dec 2025 15:22:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766013743; x=1766618543; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EOwRgtkQgjCZPMZX4W3S5E8k+Iueo8dOplhU/eXqoXI=; b=N/sd+1nzwsYmK7Ck5N/JU7FOrkDRtPjqpvYcteVO6z3w7H+pL+Rx5wWoCNUm2tqEe/ EYINaZ9zI9YZ04VVPJ4uhTgJJWxX7G6TznC1RG67s+LU0AlGBVZYsvc8R5+mFT8KZY9w wV/pCqKIyQkn9ROrJFKfs2msLQ6zcpOhcnfXQrQZu0rwu9+kdYsAtPpvjtqs+pSYLdLo ZzqCdMwnKxKfZc2rZhG61FfDseOJRlHNLTOk/2wMGZfvSxb1QbCJ1+nMzVOvazucD3ke XNaLDBGUjsdVDfOhH++qtMN9qKGR8iBPToFw/yalK3i/k4swzW9orsfre5ISWu2xiApE QS7A== X-Forwarded-Encrypted: i=1; AJvYcCXQypd1TAZFUz+VPq2iyteEQNzXrF94N1kQ2OYZZ7FR2GAD0ZF9vyTKYigswoEui2B/nApYag0cv2Y=@passt.top X-Gm-Message-State: AOJu0Yx5UoZwrnS2vS0JxBDHO5fq2SQegV04mk6Jv+orMb02639uebju g211mGy8ViMrkOcnZn0cbhy9oSYcr1x3ljcZNv1Mw3UK4bngxHW9RpY3f7sqxGXOY8bYIYSGsPF 4vTpkLZzItYZCc/BjDUK+gl/CJvhLuAppJTm7yFFEC76D4pSqQ2rjxFOrOZb10g== X-Gm-Gg: AY/fxX5iXUuSPB8ZCqO8fqCKvwMfBbNRGya1jmu+iF3hO5ylijnemJ/rVcDrmTOrNo4 jeqd8Z3GByeT1VY4MGvUZsiabrvq8bePZShNRbgmy6MnHMSkMIAR5glSLPUBBctHCSKqVoe1EBO bU/JhLLzkPPk4qbcUty9ARDbbRBFzunk+qrePgfGi8NhOhj4h9YmwV9LW1mo+KrPFfT7FI80tcu dD0qwcsWmL/4hcv+AWgIUgg/8ZqqS/xmrlwh4wfEdBB/v+lTo2uAilwED7JjoDh6vR2RRkgFpOy nHBh3gTbWHtje2AzpG4pp+vHMehNE6i4dsHdvoGvo7D1r54OnEfXUaIjjDVf60+srWx3IybXVFm SURCbZXbNXBaU6oOmszcvnGLWXCBLukatgBGkpw== X-Received: by 2002:a05:600c:4711:b0:46e:4b79:551 with SMTP id 5b1f17b1804b1-47a8f90d1eemr201174905e9.31.1766013742825; Wed, 17 Dec 2025 15:22:22 -0800 (PST) X-Google-Smtp-Source: AGHT+IF46gt7nGhWFWo6RG+LR5SeZmzQVuvNUM0/KBBrCTKu09qLt+MO/K54jAsRgPRLXqumnTYnuA== X-Received: by 2002:a05:600c:4711:b0:46e:4b79:551 with SMTP id 5b1f17b1804b1-47a8f90d1eemr201174715e9.31.1766013742331; Wed, 17 Dec 2025 15:22:22 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432448ca8dbsm1596983f8f.0.2025.12.17.15.22.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Dec 2025 15:22:21 -0800 (PST) Date: Thu, 18 Dec 2025 00:22:20 +0100 From: Stefano Brivio To: David Gibson Subject: Re: Thoughts on interface modes / multiple guest addresses Message-ID: <20251218002220.18311a7b@elisabeth> In-Reply-To: References: <20251217012936.5aefec93@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: _UJa1B0Y-I0mZDv6VPGMQB8LGMn5mmIhY8CQpUa4SaU_1766013743 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: RRDAN7TY72I5E3RLU6YESA6CVE7EN2EK X-Message-ID-Hash: RRDAN7TY72I5E3RLU6YESA6CVE7EN2EK 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: Jon Maloy , 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 Wed, 17 Dec 2025 13:01:36 +1100 David Gibson wrote: > On Wed, Dec 17, 2025 at 01:29:36AM +0100, Stefano Brivio wrote: > > On Tue, 16 Dec 2025 16:53:49 +1100 > > David Gibson wrote: > > > > > Hi Jon, > > > > > > As discussed on the call yesterday, I've written up my thoughts on > > > what a bunch of the address semantics should be. Turns out I'd > > > already done some of this at: > > > https://pad.passt.top/p/InterfaceMode > > > > Two general comments: > > > > 1. local mode is already implemented, and some things such as the > > interface name ("tap0") are already defined, see man page and > > 'pasta -- pasta --config-net ip a' > > Yes, I'm aware. The two modes have the "normal" and "local" local to > indicate the existing modes they're more similar to (neither is > identical to current behaviour). Another point I left out is that > this is intended as an endpoint to aim at. Getting there I expect to > involve extra stuff for compatiblity along the way. > > > 2. I think it's more relevant to define the basics of how one switches > > between the existing local mode and a mode where we copy addresses > > and routes (as they become available on the host), rather than > > defining every single detail of these modes. > > Oh.. right. I guess I did't make this clear: these are modes set by > the command line (details TBD), we never switch between them at > runtime. They kind of have to be, because which mode we're in affects > how we respond to runtime changes. > > > In these terms, I think it would actually be helpful to *avoid* > > seeing them as separate modes. If there's no host connectivity, we'll > > start in local mode, and switch to the other mode as we get addresses > > and routes configured... just to switch back to the previous mode if > > we lose them. > > The whole point of all-interface mode (better name suggestions > welcome) is that the guest's routing configuration *doesn't* change, > even if the host's does. If that's what you mean, I think we're talking about two rather different things. At the moment, local mode is used if a given IP version doesn't have a configured address on the host, in that specific moment. This is what the netlink monitor needs to make independent of the timing. But if the user wants to specify addresses, or routes, we certainly don't want to override them. So we would rather have an "override" or "manual" mode (same as we already have now) as opposed to a "template" or "automatic" mode where we copy (at runtime, with a monitor) addresses and routes. It's actually rather simple to implement a netlink monitor on top of this, and that's for sure what we need to implement because it's rather broken in Podman and rootlesskit and it has been for a while. I think that's the priority and what Jon was about to do rather than spending now months to revise addressing and all possible defaults and command line options. I mean, feel free to do that of course but I think it needs to be implemented in parallel at that point. > Advantages: > * The host can have whatever source-dependent, multi-path, bizarro > routing configuration, changing as often as it likes and we (and > the guest) don't care. Guest routes to the host, host routes > onward from there. > * We have a consistent (link local) way of addressing the host > regardless of what changes happen on the host side > * We have the freedom to allocate link-local addresses if we want > them for any purpose > Disadvantages: > * No access to external peers via link-local address > * Guest's routing setup is visibly different from the host's (so less > L3 transparent) > > I actually think that's a more useful and robust way of operating for > most use cases and we should eventually make it the default. Making things look like they're on the host is a very fundamental feature that many users appreciate and use. I haven't reviewed the rest in detail but forcing users to specify a new option to go back to a convenient default they had for years now doesn't sound like a good idea. > One-interface mode is for the use cases where those disadvantages are > fatal. > > There is another possible option here: present multiple interfaces in > the guest, one for each host interface. I'm not including it, since > it's basically equivalent to having multiple pasta instances in > one-interface mode. To implement this, we'd basically have to > implement one-interface mode first. > > > So does it really help to have "modes" instead of just considering > > what addresses and routes are we going to delete, and when? Because > > that's what we'll need to do anyway (and that's what I think defines > > the design). > > I haven't seen a way to define coherent semantics that cover all the > use cases without introducing two modes. The overlapping constraints > here are: The two modes could be what we roughly have now: -a / -g imply that we don't copy addresses / routes, and we don't source them for DHCP / SLAAC / DHCPv6 either. The netlink monitor could simply be enabled when the user doesn't override things. > * With passt or !--config-net, we can't fully control the guest's > networking config. We both can't set things with arbitrary > precision, and we don't have a way of forcing an update when things > change. What is the problem with that? Nobody reported any issue with it. It's actually expected. > * If we're dealing with multiple host interfaces - either > concurrently or to a lesser extent over time, then there's no way > to coherently map host-side link-local addresses to the guest. Also never reported as an issue as far as I know. > > I see that this is not an explicit use case in Jon's list (which I > > still have to review), but it's one of the most two fundamental ones > > I think (that, and Podman Quadlets), also nicely described by a user > > at: > > > > https://github.com/containers/podman/discussions/22737#discussioncomment-9478727 > > Ah, yes, that is another case. I think it would work out equivalent > to one-interface mode attached to a dummy0 interface on the host. So, > it should be fairly easy to implement in terms of one-interface mode, > just pretending a dummy0 existed even if it doesn't. That's pretty much the most important / most frequently reported case, not just another case. But anyway, there's no need for dummy0 or suchlike, we can just keep what we use as "local mode" (which wouldn't be a mode anymore, rather a temporary state). -- Stefano