Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ucla-cs!zen!ucbvax!PARK-STREET.BBN.COM!brescia
From: brescia@PARK-STREET.BBN.COM (Mike Brescia)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: EGP updates over the top
Message-ID: <8709141648.AA26872@ucbvax.Berkeley.EDU>
Date: Mon, 14-Sep-87 12:50:45 EDT
Article-I.D.: ucbvax.8709141648.AA26872
Posted: Mon Sep 14 12:50:45 1987
Date-Received: Tue, 15-Sep-87 06:24:36 EDT
References: <8709112213.aa23967@Huey.UDEL.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 21


The number of nets has indeed been sloshing about the arpanet update size
limit, the 1006 octet MTU.

The fragmenting of NR messages sent by core systems will be happenning with
the next release of software to the butterfly and lsi11 gateways.  If you want
to try some pre-release tests, we can send you some test gateway addresses to
try this week.

Re: the DON'T FRAGMENT (DF) bit in the IP header; a meaning has been assigned
for use of gateway implementations which do not initially do reassembly.  If a
poll message is received with the DF bit set, the NR message sent in reply
will be truncated to fit the (1006) MTU of the net.  Thus you can get SOME
info until the time when your gateway implements reassembly.
NOTE: This meaning is only in the new code which has the capability of doing
fragmentation and reassembly.  The current release which does not do
reassembly will only send as many nets as fit in 1000 (+/-) octets.

Look for announcements of debugging this week.

    Mike