[sclug] Bizarre IMAP problem

[Alex Butcher]

On Thu, 25 Aug 2005, Roland Turner (SCLUG) wrote:

> Alex Butcher wrote:
>
>
>> On Thu, 25 Aug 2005, Roland Turner (SCLUG) wrote:
> ...
>>> without attribution. The google search "site:ietf.org mtu 576" yields
>>> _no_
>>> hits which suggests that, if it is a standard, it's certainly not a
>>> formal
>>> one.
>>
>> It is as formal as any other Internet standard:
>>
>> "All hosts must be prepared to accept datagrams of up to 576 octets
>> (whether
>>   they arrive whole or in fragments).  It is recommended that hosts only
>>   send datagrams larger than 576 octets if they have assurance that the
>>   destination is prepared to accept the larger datagrams."
>>   - RFC791, Internet Protocol
>
>
> I've just noticed that I mistyped "site:ietf.org" as "sit:ietf.org". Memo
> to Google - error messages are sometimes helpful! (0 hits really did seem
> a little low.)
>
>
> Thanks for the quote. I'd forgotten about this, but do note that it is
> about the minimum datagram size that hosts/routers are required to be able
> to deal with, not the minimum fragment size that links are required to
> carry. A complying link could still exist with, say, a 100 byte MTU, so
> long as the devices on each end of that link were still willing to receive
> 576 byte datagrams (and chop them into seven or eight fragments;
> reassembly can still be someone else's problem).

I thought that, when I first read the reference ("Oops, I got that wrong"),
but if you remember that a datagram can have the DF bit set and read the
quote as:

"All hosts must be prepared to accept datagrams of up to 576 octets [even
if] they arrive whole"

Then 576 is the minimum that hosts must accept.

Of course, there's nothing stopping either host voluntarily resetting the DF
bit on datagrams it transmits. Also, re-assembly /should/ only take place at
the endpoints (some firewalls and other security devices don't obey this -
at least internally - for obvious reasons).

> - Raz

Best Regards,
Alex.
-- 
Alex Butcher      Brainbench MVP for Internet Security: www.brainbench.com
Bristol, UK                      Need reliable and secure network systems?
PGP/GnuPG ID:0x271fd950                         <http://www.assursys.com/>