From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF9863CA493 for ; Tue, 23 Jun 2026 08:05:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782201916; cv=none; b=V+hvho2Eyqo3sDzwMl1xCiGMJJKR3E16MEALNJj09uUMJE++RRnrqi8AVwZn7KX2nsdco4t0TGbGwJheardlPkuf91DbnjATkVtYNEx7d2U8MCmT3rfAVxLk7/rimOabO+Rt0/tbVNEOh0lRxIJCb0TuHbs0sODhloqUyVO9vEw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782201916; c=relaxed/simple; bh=z8RvWdot26AIdyqinmxjP1L72l87WKROiKfccjgBEn4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=A++ulkvQ4AweTw4HGaQeJCZD6006UWvW2U5eK895OzIrGLpI+fVVOUVrapfYBYJHfuWDdV4nvtgwzDZOBT8FsYx8jYlsrFSKFCk4lPktbU6T4IzYtAka3Vz6pzX1HPD4aoadMEsacTckw3h8SolCcZ20PO422CO51cTU3MNfRuo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Xz6pSkPV; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=j2QenRJh; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Xz6pSkPV"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="j2QenRJh" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782201912; 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: in-reply-to:in-reply-to:references:references; bh=H37DJNSgbktZvrq0/IUNk6TM3HwW87HOBuP9nTk2Et0=; b=Xz6pSkPVyB0FC4kttXGiLXA+JkdFqnISovPkUeHzLO/wvqqm/zAYQAyGcYmXLaV0evLWJ+ cjTN5q9slmlm1DiFUzoU47c7RjBWs7iSrAQcrTKLHcZJv1OqY2jlPhceGRLT3XF7EkSzpV W+biKdMfGOODOnpdnSS3lInS39N0mXc= 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-550-Z0GB41D2OdiUWruqwjHnyg-1; Tue, 23 Jun 2026 04:05:11 -0400 X-MC-Unique: Z0GB41D2OdiUWruqwjHnyg-1 X-Mimecast-MFC-AGG-ID: Z0GB41D2OdiUWruqwjHnyg_1782201910 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-49255558271so1726905e9.2 for ; Tue, 23 Jun 2026 01:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1782201910; x=1782806710; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=H37DJNSgbktZvrq0/IUNk6TM3HwW87HOBuP9nTk2Et0=; b=j2QenRJhEOPGgnh+J3gxg8uw8EW1Kjpl3/cb3QipSLmYbdFpN0eBSErTJM3oPm0d1I mGPpne7P4njoqD+HXqsAwvlCAIhQr/GJnM6WMRaQoVXEh5VMaHIrfDKxBwqq+26mzfIQ QmyKrYlXVlPEBnkxLp+bdN0/aSrpu3QmGXSp9Ac3Co7V78ts5Vu8zVA9QjKgnztdwBQq SsklGKGhwoGkX7OQraawiP2tZfanwPKFF4hP6rKj+f7SPn1W2gM2Wnw6c0Dg8DipS2WK m/sf6ycr1AbHZhKx5VrPeYKi2zxHna/wnH6RcQNm5kfcwo8rb6HzuDiRg0kuV4ZDW94b w9sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782201910; x=1782806710; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=H37DJNSgbktZvrq0/IUNk6TM3HwW87HOBuP9nTk2Et0=; b=KuuEP6uFIRL1EtQiwtoqF34w0RCabbZYUQZTJDX15+GtAf52BKsyxsarQwARvCVF5x HufUs2pxjFARTD9Ru46a011zJI2I+2cyRM8nrHN8UaVvnyYuGcn6sRGCIF1yGoGaOOdh EP1YweP6cpMUdYVprDDLNcMMf9BhT2DcRPDlGV16debXrq1P84/aoKR8esniJnvFnHb0 lgWIbS+Avx/DBvL/tS6LT3MuoHaPFYuDbYEYRDAUGyjoK8agASkB6rUrnKGeMOh7EaaH xISRQfcrvQzE5xiP1wsHk1MHi4ID1/7VH8vt1kRhPQIkKdyEfQ4nYlGscdMXUznag9Ee ub5A== X-Forwarded-Encrypted: i=1; AFNElJ+fj1tlykllNPf964O7hM8ozPaUuEoE/fTXCmUnbdzaxzgh/4CHh+L+mT8rFchNZPiDgFDo8JOiEd1fSOI=@vger.kernel.org X-Gm-Message-State: AOJu0Yw+TBMReNbsj0x6XOuBo5xX9qRW9sf66U7wZxi+5ve7Xb8OuWZ3 qtSz7Yp7X0nNpOVKR6Bev+vSavDPT8k7xneSZB2ZOaNNvjDisCvVOZpmhlP3ogQvD38dTTQ7gBn 80kBfpq79D2ueZhHUHNkoyV8IR+PHjztcs0FHMkS1wwGn2iCpY8mbzJq+BIRwIth4 X-Gm-Gg: AfdE7ck1axYYt6j7gpEiSAI3HUEqeCwQ1demHKo+0A6vEY0BmWn93Nj8yDE6/jM/+mj 04TruanJ7e5y2bA6ZVv8lXpYSRxOdEF6W0G9Riw/A+gDeSWIn6OVfI5zYs+Ap3dGVWb5eFGCod6 WepWHVhwX24ng92uih2z3J5GX0yBjD7UixjBv+Hc24uQ46GFGG9ih64jWbIW5GuLOHTfy0/SwTY Ojcj2RFujmebUX9MB32sD1F3h/p9GBSR0VNHhEN1qkcRzmwpLc5j/yr1Wg0fHuX4ZH1fRBAuEPM MBW1nB3N5BY2gzzdmfspSCL+gAbv/rntUSAHT1FQsQPOyhYS5wn8+WOyCS44lIwHwiYV+3pCBzN e X-Received: by 2002:a05:600c:4688:b0:492:4889:3d1c with SMTP id 5b1f17b1804b1-492598cacbamr26260955e9.3.1782201909564; Tue, 23 Jun 2026 01:05:09 -0700 (PDT) X-Received: by 2002:a05:600c:4688:b0:492:4889:3d1c with SMTP id 5b1f17b1804b1-492598cacbamr26260445e9.3.1782201908855; Tue, 23 Jun 2026 01:05:08 -0700 (PDT) Received: from tp ([2a02:29e1:404:f800:9fbc:ecd8:5c1a:509c]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49245a69f81sm333197965e9.1.2026.06.23.01.05.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jun 2026 01:05:08 -0700 (PDT) Date: Tue, 23 Jun 2026 10:05:06 +0200 From: Beniamino Galvani To: Ralf Lici Cc: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= , netdev@vger.kernel.org, Daniel =?iso-8859-1?Q?Gr=F6ber?= , Antonio Quartulli , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , linux-kernel@vger.kernel.org Subject: Re: [RFC net-next 08/15] ipxlat: add translation engine and dispatch core Message-ID: References: <20260622155612.591109-1-ralf@mandelbit.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260622155612.591109-1-ralf@mandelbit.com> On Mon, Jun 22, 2026 at 05:56:11PM +0200, Ralf Lici wrote: > > speaking as a maintainer of NetworkManager, I would also like to see > > this feature in the kernel! > > > > In NetworkManager currently we are using a BPF program [1] to > > implement the CLAT, but that approach comes with limitations: for > > example, we can't fragment v4->v6 packets if needed, and it's not > > possible to recompute checksums in certain cases (e.g. for v4->v6 UDP > > packets with zero checksum, and for fragmented ICMP). systemd-networkd > > is also adding CLAT support via BPF [2], with a fallback to userspace > > for the cases that can't be handled in kernel. > > > > It would be very useful to have a native in-kernel CLAT that solves > > the limitations of BPF-based solutions, and can be used by different > > tools without having to re-implement everything from scratch. > > > > Thanks, this is really useful context. > > CLAT is exactly the kind of consumer ipxlat aims to serve, and the gaps > you hit in BPF line up directly with paths ipxlat already handles. I'll > cite this as motivation in the next cover letter, if that's alright. Yes, please do! > While reading the BPF programs, two things stood out that would help > shape v2. On addressing, both implementations use a single NAT64/PLAT > prefix for destinations plus an explicit local_v4<>local_v6 mapping for > the host itself. ipxlat today maps both source and destination through > one RFC 6052 prefix, so this suggests v2 should probably support > explicit 1:1 address mappings (EAM, RFC 7757) alongside prefix > embedding. Is a single local mapping enough for your case, or do you > foresee needing several? Based on these: https://datatracker.ietf.org/doc/html/rfc6877#section-6.3 https://www.ietf.org/archive/id/draft-ietf-v6ops-claton-14.html#name-obtaining-clat-ipv6-address there are two cases to consider for CLAT. If the node doing CLAT extends the IPv4 connectivity downstream, it should acquire a dedicated prefix via DHCPv6-PD for the downstream network, and use this prefix to generate IPv4-Embedded IPv6 Addresses (RFC 6052 2.2) for downlink hosts. In this case, the ipxlat device would need to be configured with two prefixes: one is the NAT64 prefix used to synthesize IPv6 destinations for IPv4 Internet addresses, and the other is the delegated prefix used to synthesize IPv6 source addresses for hosts on the downstream IPv4 network. Ideally, the ipxlat device should also be aware of the address range of the downstream IPv4 network, and check that the source addresses of packets belong to that network. If the node doing CLAT does not extend IPv4 connectivity downstream (or it does, but it also uses NAT44), the "downstream network" is basically just one host. The CLAT only needs to map a single locally-generated IPv4 address (usually in the 192.0.0.0/29 range) to a single SLAAC IPv6 address reserved for the CLAT. In this case, the ipxlat device would need to know the CLAT IPv4 address, the CLAT IPv6 address and the NAT64 prefix. Currently, NetworkManager only uses a single IPv4 address and doesn't request a dedicated prefix via DHCPv6-PD for the CLAT. If it needs to provide downstream connectivity, it does IPv4 masquerading so that the traffic originates from a single IPv4 address. I think the ipxlat implementation should also support the delegated-prefix case, as this architecture is described in the standards. > On the consumer side, is there anything in how NM models a connection > that would make a particular kernel model awkward to drive, e.g. needing > to attach to an already-managed interface, or conversely being able to > create and own a dedicated device? We're still settling the > kernel-facing model for v2, so consumer input here is genuinely > valuable. Any of the solutions mentioned in the thread (dedicated device, netfilter, LWT) would be fine from NetworkManager's point of view. Compared to what we are doing now, they would be a great simplification ;) Beniamino