netdev - Re: [PATCH net-next] ipv6: RTAX_FEATURE_ALLFRAG causes inefficient TCP segment sizing

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, 25 Apr 2012 12:04:54 +0200
From:	Tore Anderson <tore@....no>
To:	Maciej Żenczykowski <maze@...gle.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Tom Herbert <therbert@...gle.com>
Subject: Re: [PATCH net-next] ipv6: RTAX_FEATURE_ALLFRAG causes inefficient TCP segment sizing

* Maciej Żenczykowski

>> That is a different issue entirely, but I don't disagree with you. A
>> "min_pmtu" sysctl or something like that would be useful.
>
> I don't really know what the default value should be?  Something 
> around 500?
> [to handle IPv4s min mtu of 576?]

The sensible default would be either 1280 (and keep allfrag feature), 
or
the minimum IPv4 PMTU currently enforced by the kernel + 20 bytes (to
compensate for the larger IPv6 header size). I don't know what the 
current
minimum PMTU is.

Also, I'm not really sure if the IPv4 minimum PMTU is defined as 576 or
68 bytes. There are some conflicting information out there, and nothing 
really
authoritative either way (that I've found at least).

> Do we have any idea what values of small mtu actually show up in 
> practice?

I have no data on this, I'm afraid. But I believe small MTUs (<1260, 
which
currently triggers the need for allfrag), are very rare - at least 
where I'm
from. Anectdotal, but - we've been running our corporate web site 
IPv6-only
with IPv4 access through stateless translation on a Linux server with 
the
buggy allfrag feature for several months, and there has been no 
complaints.

>> However, the use case for the allfrag feature is not handling 
>> tunnels,
>> but IPv4<->IPv6 translation. The issue is that a IPv6 host may very 
>> well
>> receive an ICMPv6 Packet Too Big indicating a PMTU of <1280 that was
>> originally transmitted by an IPv4 router (as an ICMPv4 Need To 
>> Fragment)
>> and underwent translation to IPv6.
>
> Very good point, although that's basically kind of like half a tunnel 
> ;-)

Yup, only difference is that an IPv6 tunnel is guaranteed to have a MTU 
of
1280, so no need for allfrag or dropping PMTU below 1280. No such 
guarantees
exist for IPv4 links.

Tore
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html