[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aCL5hZdbbXi8g4Ua@greenie.muc.de>
Date: Tue, 13 May 2025 09:49:25 +0200
From: Gert Doering <gert@...enie.muc.de>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Antonio Quartulli <antonio@...nvpn.net>, netdev@...r.kernel.org,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
Sabrina Dubroca <sd@...asysnail.net>,
Gert Doering <gert@...enie.muc.de>
Subject: Re: [PATCH net-next 03/10] ovpn: set skb->ignore_df = 1 before
sending IPv6 packets out
Hi,
On Tue, May 13, 2025 at 09:37:33AM +0200, Paolo Abeni wrote:
> On 5/9/25 4:26 PM, Antonio Quartulli wrote:
> > IPv6 user packets (sent over the tunnel) may be larger than
> > the outgoing interface MTU after encapsulation.
> > When this happens ovpn should allow the kernel to fragment
> > them because they are "locally generated".
> >
> > To achieve the above, we must set skb->ignore_df = 1
> > so that ip6_fragment() can be made aware of this decision.
>
> Why the above applies only to IPv6? AFAICS the same could happen even
> for IPv4.
Without having a detailed understanding of the kernel code paths (I'm
the userspace developer that breaks this stuff from the outside), the
v4/v6 logic seems different enough - possibly based on differences in
fragment handling in the relevant RFCs - that this is not a problem.
I am testing "3000 byte IPv4 and IPv6 packets over OpenVPN over IPv4 and
IPv6", intentionally creating both inside and outside fragmentation,
and without this patch "... over IPv6" was broken, while "... over IPv4"
worked all the time. With the patch, all 4 combinations pass.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@...enie.muc.de
Powered by blists - more mailing lists