Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU

Iljitsch van Beijnum iljitsch at muada.com
Mon Jan 10 08:08:22 UTC 2005


On 10-jan-05, at 1:54, Stephen J. Wilcox wrote:

>> With a 296 byte MTU I don't get answers from
>> (a|b|h|j).root-servers.net, *.gtld-servers.net, tld2.ultradns.net and
>> some lesser-known ccTLD servers.

> I thought 576 bytes was the minimum by way of largest initial packet 
> prior
> to negotiating MSS must not exceed 576 bytes.. altho i guess that 
> doesnt
> preclude fragmentation or pmtu?

Hosts are expected to be able to handle 576 byte IP packets = be able 
to reconstruct packets of that size from fragments if they are behind a 
< 576 MTU. For a long time, the TCP MSS would default to 536 (576 - IP 
- TCP) or 512. However, there is no real requirement about the minimum 
link MTU apart from the 68 bytes in RFC 791. People often attribute a 
296 byte MTU recommendation for slow links with header compression to 
RFC 1144. This isn't entirely unreasonable, but it's not explicitly in 
the text.

In any case, doing PMTUD for UDP in IPv4 doesn't make much sense. And 
having the kernel set the DF bit and then expecting the application is 
completely wrong, as many UDP applications can't reduce their packet 
size, or can't do this without serious loss of functionality, and 
fragmentation at the source host also can't be controlled by 
applications.




More information about the NANOG mailing list