Re: The IPv4 Internet MTU

[james woodyatt <jhw@apple.com>]

On Sep 27, 2007, at 16:36, Christian Huitema wrote:
> That would not be too much of a problem if TCP implementations  
> could do MTU detection by just reacting to packet losses. But  
> today, many TCP implementations don't. The MTU discovery is  
> triggered by ICMP "packet too big" messages. These messages are not  
> generated if a UDP fragment is lost.
These messages are also sometimes not generated as a matter of  
deliberate policy.  I am aware of several popular PPPoE network  
operators who have deliberately chosen for their access concentrators  
to be IPv6 path MTU discovery black holes for reasons that have never  
been disclosed to me.  The software distributions they bundle with  
their service have elaborate mechanisms for configuring the MTU on  
the PPPoE interface properly, despite exchanging MTU options in the  
PPP negotiation with the PPPoE access concentrators that require  
MTU=1500, which can't work over ethernet.  There is no good reason  
for continuing to do this that I can see.
The result of these black holes being a permanent fixture in the IPv4  
Internet is that NAT gateways typically clamp the MSS field during  
TCP stateful connection tracking to prevent path MTU discovery  
brokenness from interfering with applications.  (Apple's AirPort base  
stations in PPPoE mode clamps the MSS on TCP streams to 1400 bytes.   
Larger values have proven perilous in the past.)
If I were more impolite, then I would do more than merely suggest  
that some people view the brokenness of IPv4 path MTU discovery as a  
feature rather than a bug.  I'm learning to be more polite.

--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering