netdev - Re: [PATCH net v2 1/2] ipv6: Honor route mtu if it is within limit of dev mtu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANP3RGdRD=U7OAwrcdp1XUXFcb5b1zTfoy1fxa8JZUcnxBdsKg@mail.gmail.com>
Date:   Thu, 16 Jun 2022 00:33:02 -0700
From:   Maciej Żenczykowski <maze@...gle.com>
To:     "Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@...cinc.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        David Ahern <dsahern@...nel.org>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Linux NetDev <netdev@...r.kernel.org>,
        Stefano Brivio <sbrivio@...hat.com>,
        Kaustubh Pandey <quic_kapandey@...cinc.com>,
        Sean Tranchetti <quic_stranche@...cinc.com>
Subject: Re: [PATCH net v2 1/2] ipv6: Honor route mtu if it is within limit of
 dev mtu

On Wed, Jun 15, 2022 at 10:36 PM Subash Abhinov Kasiviswanathan (KS)
<quic_subashab@...cinc.com> wrote:
>
> >> CC maze, please add him if there is v3
> >>
> >> I feel like the problem is with the fact that link mtu resets protocol
> >> MTUs. Nothing we can do about that, so why not set link MTU to 9k (or
> >> whatever other quantification of infinity there is) so you don't have
> >> to touch it as you discover the MTU for v4 and v6?
>
> That's a good point.

Because link mtu affects rx mtu which affects nic buffer allocations.
Somewhere in the vicinity of mtu 1500..2048 your packets stop fitting
in 2kB of memory and need 4kB (or more)

> >> My worry is that the tweaking of the route MTU update heuristic will
> >> have no end.
> >>
> >> Stefano, does that makes sense or you think the change is good?
>
> The only concern is that current behavior causes the initial packets
> after interface MTU increase to get dropped as part of PMTUD if the IPv6
> PMTU itself didn't increase. I am not sure if that was the intended
> behavior as part of the original change. Stefano, could you please confirm?
>
> > I vaguely recall that if you don't want device mtu changes to affect
> > ipv6 route mtu, then you should set 'mtu lock' on the routes.
> > (this meaning of 'lock' for v6 is different than for ipv4, where
> > 'lock' means transmit IPv4/TCP with Don't Frag bit unset)
>
> I assume 'mtu lock' here refers to setting the PMTU on the IPv6 routes
> statically. The issue with that approach is that router advertisements
> can no longer update PMTU once a static route is configured.

yeah.   Hmm should RA generated routes use locked mtu too?
I think the only reason an RA generated route would have mtu information
is for it to stick...