Bug 42599 - Allow Path MTU Discovery to reduce the IPv6 Path MTU to values below 1280
Summary: Allow Path MTU Discovery to reduce the IPv6 Path MTU to values below 1280
Status: RESOLVED OBSOLETE
Alias: None
Product: Networking
Classification: Unclassified
Component: IPV6 (show other bugs)
Hardware: All Linux
: P1 enhancement
Assignee: Hideaki YOSHIFUJI
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-18 12:38 UTC by Tore Anderson
Modified: 2012-08-30 13:49 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.2.0
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Tore Anderson 2012-01-18 12:38:12 UTC
Quoting RFC 2460 section 5:

> In response to an IPv6 packet that is sent to an IPv4 destination
> (i.e., a packet that undergoes translation from IPv6 to IPv4), the
> originating IPv6 node may receive an ICMP Packet Too Big message
> reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
> is not required to reduce the size of subsequent packets to less than
> 1280, but must include a Fragment header in those packets so that the
> IPv6-to-IPv4 translating router can obtain a suitable Identification
> value to use in resulting IPv4 fragments.  Note that this means the
> payload may have to be reduced to 1232 octets (1280 minus 40 for the
> IPv6 header and 8 for the Fragment header), and smaller still if
> additional extension headers are used.

Currently, the Linux kernel implements this, i.e., it will never reduce the IPv6 Path MTU (the mtu value reported by "ip -6 route show table cache") for a destination to a value less than 1280, opting instead to include a Fragment header in all subsequent packets (by setting the RTAX_FEATURE_ALLFRAG on the host route in the routing cache).

While this is quite permitted by the RFC, it appears to be operationally more error-prone than simply lowering the IPv6 Path MTU to whatever value the ICMPv6 Packet Too Big message indicated, even though this is value is lower than 1280. Bug #42595 is one example of such an operational problem happening.

Furthermore, the current implementation of the RTAX_FEATURE_ALLFRAG causes inefficiencies, as it makes a Fragment header included in *every* outbound IPv6 packet, including those that are smaller than the actual IPv6 Path MTU.

I would therefore very much like to see a new sysctl under net/ipv6 called for example "min_pmtu", that would allow a server administrator to set the minimum Path MTU value (as indicated by a received ICMPv6 Packet Too Big) the IPv6 stack is willing to use. By setting this to the minimum IPv4 MTU + 20 bytes (the difference in size between an IPv4 and an IPv6 header), I would then be able to completely avoid RTAX_FEATURE_ALLFRAG and the operational problems that comes with its use.

Tore
Comment 1 Alan 2012-08-30 13:49:37 UTC
Obsoleting. If you want to take this further discuss it on netdev@vger.kernel.org

Thanks

Note You need to log in before you can comment on or make changes to this bug.