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