On 29-dec-04, at 22:25, Fred Baker wrote:
That said, RFC 1042 ("Standard for the transmission of IP datagrams over IEEE 802 networks.") notes that
Note that the MTU for the Ethernet allows a 1500 octet IP datagram, with the MTU for the 802.3 network allows only a 1492 octet IP datagram.
For an RFC to require an MTU of 1500 octets without fragmentation would imply requiring it to not use IEEE 802.3 framing,
:-) You've succeeded in making me laugh out loud, Fred.
Thinking that IP over Ethernet has _anything_ to do with 802.3 is such a rookie mistake... Does your employer even make gear that supports this? If they do, I've never seen it.
(For the record, the IP over Ethernet that we all know and love is is RFC 894, (don't let the april first publication date fool you) which specifies IP over "Ethernet II", a pre-IEEE incarnation of Ethernet. On a Cisco router this shows up as "Encapsulation ARPA". There is some stuff on MTU issues in this RFC too, but it's completely outdated of course.)
To be honest, I think we should be carefully considering Mathis' newer approach to Path MTU, described in http://www.psc.edu/~mathis/MTU/pmtud/draft-mathis-pmtud-method-00.txt and a more recent but expired internet draft.
Why reinvent a broken wheel?
Implementations just shouldn't send ALL packets with the DF bit set. Doing this for a few percent of all packets accomplishes PMTUD just as well without the nasty side effects. Alternatively, the right way to do PMTUD would be for the receiver to notify the sender of any fragmentation and how big the largest fragments or unfragmented packets were.
Regardless of this, it's probably a good idea to obsolete the original meaning of the DF bit.
