nelson@sun.soe.clarkson.edu (Russ Nelson) (03/27/89)
The maximum safe assumption for acceptable IP datagram size on the Internet is 576 and this is documented both in the IP spec (under the definition of the Total Length field) and in the forthcoming Host Requirements RFC (draft obtainable from venera.isi.edu using anonymous ftp and pathname /pub/ietf-hosts.rfc.txt - see section 3.3.2 and 3.3.3 for a full discussion of the whole issue). The use of larger datagram sizes is permitted, but not guaranteed to work with all hosts. It is almost always safe to assume that a host can support what its connected networks support for an MTU, but even this is not *required*. The MTU of the BBN packet switching networks (Milnet, Arpanet) is 1007 octets, but there are some problems with the odd number on certain interface boards and it is widely assumed that the usable MTU is 1006. When you try to send 1500grams onto the Milnet (required to get to BRL and AMSAA I would think) the gateway is having to perform IP fragmentation to get down to the Milnet MTU. Almost certainly it fragments into a 1006 and a 534 or so (remember, the IP header is needed on each fragment). It may be the case that something further down the wire does not like the 1006gram because that is too big for it. Or it may be the case that your gateway into Milnet is making a 1007gram and BRL has one of the boards that does not speak 1007 successfully. There are many possibilities, but if you send 576's you should avoid all of them except truly broken systems. Everybody is required to be able to handle fragmentation, and maybe that is what Phil Karn was thinking of. That is not the same as saying that everybody is required to be able to reassemble the fragments of an arbitrarily large IP DG. They are required to be able to reassemble fragments to put together a 576 DG, and it is recommended that they handle the connected net(s) MTU, further recommended that the max should be configurable so you can make it even bigger, and yet further recommended that it handle unlimited sizes. But those are recommendations, not requirements. It is a bad idea from a performance perspective to cause IP fragmentation. The rationale has to do with source retransmissions causing cascades of fragments, most of which are not needed to recover the actual error. Also, it tends to cause more data copying in gateways and the destination IP. So, current thinking is that we should be trying to determine the smallest MTU of a path, and construct our DGs to that size. There are a couple of schemes for doing this dynamically, none of which are really standards at this point, but it is an active area of thought. The HR RFC alludes to some of this. Bill Barns / MITRE-Washington / barns@gateway.mitre.org -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) If you can, help others. If you can't, at least don't hurt others--the Dalai Lama