[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <108170pq-83n6-4s97-q6n1-71525os6rpq6@vanv.qr>
Date: Fri, 13 Jun 2025 01:25:59 +0200 (CEST)
From: Jan Engelhardt <ej@...i.de>
To: Phil Sutter <phil@....cc>
cc: Klaus Frank <vger.kernel.org@...nk.fyi>,
Antonio Ojea <antonio.ojea.garcia@...il.com>,
netfilter-devel@...r.kernel.org, Pablo Neira Ayuso <pablo@...filter.org>,
Florian Westphal <fw@...len.de>, Lukas Wunner <lukas@...ner.de>,
netfilter@...r.kernel.org,
Maciej Żenczykowski <zenczykowski@...il.com>,
netdev@...r.kernel.org
Subject: Re: Status of native NAT64/NAT46 in Netfilter?
On Thursday 2025-06-12 23:55, Phil Sutter wrote:
>
>I don't comprehend: I have to use an IPv4 transfer net because I need to
>set a source address in the generated IPv4 header. The destination IPv4
>address is extracted from the IPv6 destination address. Simple example:
>
>IPv6-only internal: fec0::/64
>v6mapped: cafe::/96
>external IPv4: 1.2.3.4
>internal transfer IPv4: 10.64.64.0/24
Here's a thought (experiment)...
* make all conntrack entries and templates use IPPROTO_IPV6, even
for IPv4 (i.e. by representing those as ::ffff:0:0/96)
* at the time of NF_IP6_PRI_NAT_SRC or later, if a skbuff has a
::ffff:0:0/96 address in *both* srcaddr and dstaddr, replace the
skbuff by one with an IPv4 header.
* at the time of NF_IP_PRI_NAT_DST, if the ct entry is such that
the replacement dstaddr contains one non-ffff address, replace the
skbuff by one with an IPv6 header.
all in the hope of enabling
ip6tables -t nat -A POSTROUTING -s fec0::/64 -j SNAT --to ::ffff:1.2.3.4
so that you don't have to think about cafe::/96 or 10.64.64.0/24.
Powered by blists - more mailing lists