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: <762a0384-e233-2107-16ef-1510ad2e82c8@quicinc.com>
Date:   Tue, 14 Jun 2022 12:34:08 -0600
From:   "Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@...cinc.com>
To:     Stefano Brivio <sbrivio@...hat.com>,
        Kaustubh Pandey <quic_kapandey@...cinc.com>
CC:     <davem@...emloft.net>, <dsahern@...nel.org>,
        <yoshfuji@...ux-ipv6.org>, <kuba@...nel.org>,
        <netdev@...r.kernel.org>,
        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

> I read this a few times but I still fail to understand what issue
> you're actually fixing -- what makes this new MTU "wrong"?
> 
> The idea behind the original implementation is that, when an interface
> MTU is administratively updated, we should allow PMTU updates, if the
> old PMTU was matching the interface MTU, because the old MTU setting
> might have been the one limiting the MTU on the whole path.

Hi Stefano

Here is some additional background on the observations - consider a case
where an interface is brought up with IPv6 connection first with PMTU 
1280 (set via the MTU option of a router advertisement) followed by an 
IPv4 connection with PMTU 1700. An userspace management entity sets the 
link MTU to the maximum of IPv4 and IPv6 PMTUs.

When the IPv4 connection is brought up, the link MTU changes to 1700 
(max of IPv4 & IPv6 PMTUs in this case) which unnecessarily causes the 
PMTUD to occur for the IPv6 case.

> That is, if you lower the MTU on an interface, and then increase it
> back, a permanently lower PMTU is somewhat unexpected. As far as I can
> see, this behaviour persists with this patch, but:

I agree that this would indeed occur after the patch. The assumption 
here is that there would be an update from a router via a new router
advertisement if the IPv6 PMTU has to be increased / updated.

> ...I'm not sure what you really mean by "incoming dev mtu". Is it the
> newly configured one?

Yes, this is the new MTU configured by userspace.