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]

Date:   Wed, 15 Jun 2022 23:36:10 -0600
From:   "Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@...cinc.com>
To:     Maciej Żenczykowski <maze@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>
CC:     "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

>> 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.

>>
>> 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.