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]

Message-ID: <4b7a2708fd4545ac65cfef6561e7f02a@greed.fud.no>
Date:	Wed, 25 Apr 2012 13:49:19 +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

>> I think you forgot to include the explanation why. :-)
>
> I did try, I just didn't do a very good job.

Oh, because of IPv6-in-IPv4 tunnel encap overhead, I get it now.

>> I suppose. This would be invisible to IPv6, though - the 
>> fragmentation and
>> reassembly happens at a lower layer than IPv6. Same as ATM for 
>> example. Situation is
>> described by RFC 2460:
>
> It would be invisible (*), and you probably wouldn't really need the
> frag header in the ipv6 packet,
> but it would still be desirable to have ipv6 already have packets
> smaller than ipv4
> mtu - 20, rather than have to frag/unfrag at the tunnel endpoint.
> Since it is always more efficient to have fragmented correctly in the
> first place.
>
> (*) Would it be legal for a tunnel endpoint to support ipv6 packets 
> up
> to 1280 bytes in size
> but still send back a 'packet to big please use 1K mtu' message?

I don't think this is a valid thing to do - either the tunnel server 
would
forward the packet through the tunnel (fragmenting the underlaying IPv4 
if
necessary), and *not* send back a ICMPv6 PTB error at the same time, 
OR: it
would need to drop the packet and *do* send back the ICMPv6 PTB. Not 
both
at the same time.

However, if it is going to drop the large packets and reply with the 
PTB, it
will cause a blackhole with current Linux, because if it get the PTB 
with
MTU=1000, it will include the frag header, but *not* reduce the actual 
packet
size. And since this is pure IPv6 routing, the tunnel server will not 
be able
to fragment the IPv6 packets, since IPv6 routers don't do that (the 
presense
of the Fragmentation header does not change this fact).

So the tunnel routers pretty much *must* support an IPv6 MTU of 1280, 
either
by ensuring the outer IPv4 MTU is 1300 or larger, or by performing IPv4
fragmentation and reassembly "under the hood".

I don't think it is worth while (or even appropriate) for the Linux 
IPv6 stack
to try to optimize for this.

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