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=VJ05w1Ux; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 552A65A0652 for ; Fri, 19 Dec 2025 02:40:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1766108454; 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=5W0aGMOX0vOzkTeJwqRijHVCTEmy5IR4HGNCZEHASSM=; b=VJ05w1UxsWZCigkSPc8XxcFdm/Lbr1RZGdN9vFmsCgaVODvoRAv4oi/RzDeSWce7SgT8Eh eEJzFU6jSh9Cvmt0ZJk/TgZJIgLOOf2VRZTF1FW2zEhOvr4SKH8YeCFlb8k1tevux4RqRb z0ZHlnm9zGOfpxZ+F2ZBN/JvkTXVgcg= Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-694-5x8wa3tEPuWk3sCu13U0iA-1; Thu, 18 Dec 2025 20:40:51 -0500 X-MC-Unique: 5x8wa3tEPuWk3sCu13U0iA-1 X-Mimecast-MFC-AGG-ID: 5x8wa3tEPuWk3sCu13U0iA_1766108451 Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-29f177f4d02so26204965ad.2 for ; Thu, 18 Dec 2025 17:40:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766108450; x=1766713250; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5W0aGMOX0vOzkTeJwqRijHVCTEmy5IR4HGNCZEHASSM=; b=bndqGRgNpfQSjHZQZ1ipbMn1qtm3R9JhGaiDH0n170/qZsiOdda9le0cgCRYExGK6h MbBQFyqrxppyGfyXE8POIA2gpp+Yoio2oAJ+tggHHSxLDnbsAgiUj6ujgaEjqmHb/AyS N/ES8Hc0ChWzsKNTzQER31fTNtizJ5Y6HJ1dQXjhiegBNml7UUOY6JwYueFrHlksPuNA TrxyxTDGozKnq6nyDZb8eEygUy1XgleEjvgLQD5jRjzKwNfuEkPMJnvwChNzR7MS30ou Xxz4yG6xl43I5Boi6Dv7NrsWKSs4y4J8LhI6nwNHAkqvqBslqnMbeN64x5CKb7/8H4JR 1Viw== X-Forwarded-Encrypted: i=1; AJvYcCVqSz+cxDNsztwwl7A1QQbBd91oCfwOuPQCNuH7BNYADMUJq5YGafDTmOAQEC4KtYJceEILr6dtt/Y=@passt.top X-Gm-Message-State: AOJu0YwbKevCb9rHdGSMhEGtQeOx7Dmn4kuiJO8T4WIufYCTVtwFd8VE asotAeLGCSFZbTiZQvdY7DxLes1vrSHZLUV/nxpk0EQOnl0+gy6/6pm+dRbwJBYZOAT2XI2uRaU YOPtCsG6fLgIHRir/zi/HbumDXYYl8ZNC1Bjo3ljp2gM/BsJ6xiZ8fw== X-Gm-Gg: AY/fxX6lrjtHNTIzonEnOa8Rm5QTjq7mWH43JQ+qbvpHHWxJXu/53dITtgk9bx1Bir5 CUDucwROrIWhbk3LYfjHwOdm1ZHEAaUIzRcr3kUrPrXAQcKoTrGwv+n5WaNuAY/3KofosFb9jeA do10U1t9f/bZamvrfqvQXfd2zrOlB+dqyta1u6pebkpQm7Vde78fKIu5SrLJYsqE6Dcfecivqd6 izrtKjNPJ2t6W4yD8pYozPhe5VSN4aCixRF8ZF16FypZPUFANxzRl8rGp1kKWJJEthEwKWCzMME H59Y7ZPCLtmpnE0NKbyIVXCh2B5CsgKakJST89yANBACX6c6KOIP3ehAfGtWjbyQpn8eFrDsVro bdg17iGfrvCY8terhL0PgtLOxAgMNuTEPbKpXaaDQA8RnFc1OGNnXGRkCHPrALNLGvMZq0v7VMk nNkIF+ X-Received: by 2002:a05:7022:6988:b0:11b:ceee:b760 with SMTP id a92af1059eb24-121722de505mr1275920c88.23.1766108450325; Thu, 18 Dec 2025 17:40:50 -0800 (PST) X-Google-Smtp-Source: AGHT+IHnGwrtxeWn8igi28RKxIFJywTqi2fPMiwiOG7+cNQ/TlJTRmr2/BitRCSRfiL1DtCojnJAgw== X-Received: by 2002:a05:7022:6988:b0:11b:ceee:b760 with SMTP id a92af1059eb24-121722de505mr1275888c88.23.1766108449654; Thu, 18 Dec 2025 17:40:49 -0800 (PST) Received: from [192.168.2.15] (lnsm3-montreal02-142-116-222-198.internet.virginmobile.ca. [142.116.222.198]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-1217253c23csm3165874c88.9.2025.12.18.17.40.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Dec 2025 17:40:49 -0800 (PST) Message-ID: <7314536d-ecdd-4f72-9071-b3c38fd92abb@redhat.com> Date: Thu, 18 Dec 2025 20:40:45 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Thoughts on interface modes / multiple guest addresses To: David Gibson References: <20251217012936.5aefec93@elisabeth> From: Jon Maloy In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: S_xrHif3nFkKcGxc-uvfrijkThccb-FWsHOsaKodmb8_1766108451 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: P6G2YGOYM4HOCP72ZGLKBMUOIPT6D5TP X-Message-ID-Hash: P6G2YGOYM4HOCP72ZGLKBMUOIPT6D5TP X-MailFrom: jmaloy@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: Stefano Brivio , 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 2025-12-17 19:14, David Gibson wrote: > On Wed, Dec 17, 2025 at 03:01:31PM -0500, Jon Maloy wrote: >> >> >> On 2025-12-16 21:01, 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. >>> >>> 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. >> >> And the other way around, the guest should be able to set up whatever >> he wants if that is his choice, without affecting the host. Maybe >> even multiple interfaces, for whatever reason that might be. > > I'm not sure I follow. We can't change net config on the host, so > that's basically always true - in both proposed modes, and right now. > So maybe you're meaning something different? I'm not sure what, > though. No. I was just stating a fact. But if we want to give the guest full freedom to adapt or screw up his own namespace we may in the name of consistency allow him to create his own interfaces (dummy, veth, tun/tap?) > >> We could have two modes: "transparent" and "opaque" > > I'm not 100% sold, but I think those are at least a bit better than my > current names (doc updated). > >> In opaque mode we get basically what you describe above, plus that we allow >> the guest to add new addresses/routes in runtime. > > THe guest could always add extra routes at runtime. Adding extra > addresses... well, it always could, the question is what - if anything > - passt/pasta should do about it. What do you propose? Just allow it and handle it right, i.e., as expected by the guest. > >> So, we keep the multi-address configuration and and the nameaspace side >> subscription, but block host-side subscriptions in this mode. > > My intention was that we don't use a host-side *route* subscription in > this mode. We would still need a host-side address subscription to > implement '-a auto', which I was proposing to have allowed (and > enabled by default) in opaque mode. That beats the whole purpose of opaque mode, doesn't it? > >> Conversely, we are fully open to host-changes in transparent mode, we >> subscribe for host-side changes, forward those to the namespace, > > With --config-net, yes. For passt and !--config-net we can't control > the guest configuration; we can only reflect as much of the host state > as possible via DHCP and NDP, and hope the guest will consult that and > update itself. > >> However, we don't allow the guest user to manipulate anything in run-time. > > Well, we can't really prevent it. I guess you mean if the guest > reconfigures itself, then things might break entirely and it's not our > fault? Yes. Give him full freedom. To fix or break his own namespace. ///jon > >> Hybrid modes might be possible, > > I haven't (so far) seen a sensible way to hybridise these models. The > main sticking point is giving a consistent meaning to link-local > addresses when used by the guest. > >> e.g., that we allow one stable link local >> address even in transparent mode. > > That's allowed by the proposed model: transparent mode with '-a addr> -a auto'. > >> Would that make sense? >> >>> * 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. >>> 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. >> >> In transparent mode that would be a natural further step. > > Yes. Supporting multiple guest side pifs is a preqrequisite, though. > I'm working towards that, but it's a fair way off. > >> >> ///jon >> >>> 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: >>> >>> * 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. >>> * 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. >>> >>>> 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. >>> >>>>> I've now updated to cover some more things, and considering the >>>>> possibility of multiple guest addresses.. Turns out etherpad doesn't >>>>> really do tables, so it's two sections for the two suggested modes, >>>>> with matching subheadings. >>>> >>>> It does, but I disabled the plug-in as you reported an issue which >>>> turned out to be https://github.com/bitwarden/clients/issues/17598 >>>> instead, and I was trying to sort out other possible reasons. >>>> >>>> I just re-enabled it, tables are available from the toolbar, there's >>>> an icon just left of "Font Family". Note that it's still beta: >>>> >>>> https://www.npmjs.com/package/ep_data_tables >>>> >>>> and it has a couple of glitches. I just found one (which I didn't debug >>>> or report yet): don't start a page with a table, always write something >>>> before, otherwise it gets duplicated every time you load the document. >>>> >>>> Other than that it looks reasonably robust to me, maybe quickly try with >>>> a test pad first but I think it should be usable. >>> >>> Great, thanks. >>> >> >