Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!genrad!decvax!ucbvax!UDEL.EDU!Mills
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: On broadcasts, congestion and gong
Message-ID: <8710241521.aa29606@Huey.UDEL.EDU>
Date: Sat, 24-Oct-87 15:21:17 EST
Article-I.D.: Huey.8710241521.aa29606
Posted: Sat Oct 24 15:21:17 1987
Date-Received: Tue, 27-Oct-87 04:48:15 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 36

Folks,

It so happens that two of the five NSFNET gateways to ARPANET are broken just
now (PSNs seem to be down), so the remaining three have to carry the load. At
one of them (linkabit-gw) the traffic is so heavy that source-quench messages
are being sent regularily (see my recent note on how the fuzzballs now do
selective-preemption and source-quench generation). Looking through the logs I
see the single most persistent abuser is host 128.220.2.1, which is sending
gobs of packets to 128.220.0.0, evidently the broadcast address on net
128.220. I did not capture the data portion of these packets, but I strongly
suspect they are Unix rhos that never, never, never should be allowed outside
of that net. Now, not only are broadcasts considered rude to the max outside
the local net, but in this case those broadcasts are severly impacting service
for many other users. At one point 35 packets were queued with the source and
destination addresses shown. If it were not for their selective-preemption
policy, the fuzzballs would be choked with these things and nobody would be
getting good service at all.

While host 128.220.2.1 might be considered borderline bogus, the 128.220
gateway must be considered clearly over the edge. Why did it allow any traffic
for local-net destinations outside that net at all, much less allow
128.220.0.0 bogons to escape to ARPANET? I suspect the problem is a mixture of
subnetted 4.2 and 4.3 Unix systems with different broadcast addresses. In any
case, RFC-1009 clearly advises the all-zeros and all-ones variant of local
addresses to be drop-kicked at the gateway. Will the operator of that gateway
reveal the vendor so we can send the gongfermers after them? Better yet,
compile a list of vendors known to be noncompliant with RFC-1009 and post at
the upcoming INENG meeting and TCP/IP conference.

RFC-1009 expresses a significant amount os sweat, experience and gong and was
not intended to be taken lightly. Has anybody incorporated it as part of an
RFP? Has any vendor claimed compliance? If the lessons therein are not taken
seriously, we will continue to see problems as above and an inexorable decline
in service quality throughout the Internet community.

Dave