Hey Lukas,
On 4/23/20 6:05 PM, Lukas Wunner wrote:
On Thu, Apr 23, 2020 at 04:44:44PM +0200, Laura Garcia wrote:
On Sun, Mar 15, 2020 at 2:29 PM Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
On Sat, Mar 14, 2020 at 01:12:02AM +0100, Daniel Borkmann wrote:
On 3/13/20 3:55 PM, Pablo Neira Ayuso wrote:
We have plans to support for NAT64 and NAT46, this is the right spot
to do this mangling. There is already support for the tunneling
But why is existing local-out or post-routing hook _not_ sufficient for
NAT64 given it being IP based?
Those hooks are not coming at the end of the IP processing. There is
very relevant IP code after those hooks that cannot be bypassed such
as fragmentation, tunneling and neighbour output. Such transformation
needs to happen after the IP processing, exactly from where Lukas is
proposing.
[...]
infrastructure in netfilter from ingress, this spot from egress will
allow us to perform the tunneling from here. There is also no way to
drop traffic generated by dhclient, this also allow for filtering such
locally generated traffic. And many more.
Any chance to continue with this approach? I'm afraid outbound
af_packets also could not be filtered without this hook.
Thanks Laura, good to hear there's interest in the functionality.
Daniel submitted a revert of this series but didn't cc me:
https://lore.kernel.org/netdev/bbdee6355234e730ef686f9321bd072bcf4bb232.1584523237.git.daniel@xxxxxxxxxxxxx/
In the ensuing discussion it turned out that the performance argument
may be addressed by a rearrangement of sch_handle_egress() and
nf_egress() invocations. I could look into amending the series
accordingly and resubmitting, though I'm currently swamped with
other work.
The rework of these hooks is still on my todo list, too swamped with
other stuff as well right now, but I'll see to have a prototype this
net-next development cycle.
Thanks,
Daniel
