IP-TCP ... incomplete implementation

["Eric S. Crawley" <Crawley@alderaan.scrc.symbolics.com>]

    Date: Wed, 20 Jul 88 22:56 EDT
    From: cjl@WHEATIES.AI.MIT.EDU (Chris Lindblad)

	Date: Wed, 20 Jul 88 19:05 EDT
	From: buff@upenn.warminster.cis.upenn.edu (Richard Billington)

	It appears that the version of IP-TCP we have loaded here doesn't handle IP
	fragmentation. We need a fix for this immediately. We are trying to get NFS to
	work, and our central UNIX file server sends a datagram containing all of the
	information in /etc/exports (which is considerable) in reponse to the RPC
	request mntproc-1-export. The resulting datagram is larger than an ethernet
	packet and is hence fragmented, and the Symbolics drops it on the floor. We
	don't believe that IP fragmentation is an optional portion of the IP protocol
	specification.

    Symbolics IP-TCP does do reassembly.  It just has a maximum packet size of an
    ethernet packet, 1500 bytes.  It will reassemble any fragments as long as the
    resulting packet is 1500 bytes or less.  I believe this is allowed by the IP
    protocol specification.

The IP protocol specification says that an implementation must be able
to reassemble packets of at least 576 or so bytes.  So, we are way above
the "minimum maximum transmission unit size".  Actually, we can
fragment and reassemble packets of up to 1920 bytes, the size of a
packet buffer (based on the size of 2 pages of memory minus some header
information).

    I agree that it should also do fragmentation and handle IP packets of up to 16
    kilobytes, but in terms of the IP specification, this is optional.

I also agree that we should do fragmentation and reassembly of larger IP
packets and it has been on my queue for some time.  Since this is an
optional item and can usually be worked around, other things have taken
higher priority.