On Etherbunnies and swamp creatures


mills@dcn6.arpa
02-Jun-86 18:45:15-UT


Folks,

You may know the Vitalink TransLAN satellite network architecture consists of
a broadcast-type satellite channel connecting a (perhaps large) number of
local Ethernets and forming one grand and glorious global Ethernet. Clever
filtering attempts to keep local traffic off`the broadcast channel, but
Ethernet broadcast-type packets are heard everywhere. The natural, but naive,
urge is to simply splice the channel directly to the local Ethernet, which may
or may not have a path to the Internet, and watch the Etherbunnies pop out.

Hans-Werner Braun at U Michigan has been trying to connect the USAN network,
which uses TransLAN architecture, to the world with a fuzzball gateway. As
could be predicted with any Internet community where local nets and subnets
can join and leave the system willy-nilly without telling anybody about
hosts, gateways or anything, the poor fuzzball quickly drowned in the swamp.
Following is a summary of some of the issues, together with a proposal how
some of them can be resolved.

The biggest swamprat turns out to be pesky broadcasts (rwho, etc.) so beloved
by Unix hosts. One of these splashes on the local cable, probably tossed by a
j-random host on a j-random net half-way across the country with a net number
nobody ever heard before. We all know this is not an uncommon occurance even
without TransLAN.

Now, fuzzballs and probably other swamp creatures can deal with multiple
subnets on the same cable and even multiple nets on the same cable, but can't
pull Etherbunnies from a hat unless told what to do with them. Since
Hans-Werner's fuzzy was 800 miles and two networks downstream from the nearest
EGP-speaking gateway, he simply tossed the packets upstream to that gateway,
which promptly blat an ICMP unreachable back (oops) down a black hole, since
it never heard of the drat net. Well, there were quite a number of these
things, so the EGP gateway (also a fuzzy) hollered mayhem to its log file.

This experience and previous experience with Martians (bogus packets to and/or
from address 127.0.0.0) suggests that it's a mighty bad thing to allow
strictly local creatures, broadcasts or otherwise, to escape their native
swamps. I propose that a filtering mechanism be included in the gateway
requirements specified in RFC-985. The mechanisms amounts to deleting packets
with IP destination addresses falling into certain ranges. A gateway receiving
such a packet would not forward it or return any packet whatsoever in
response. This means no ICMP messages, no ARPs replies or nothin'. If the
gateway is also acting as a local host, it may in fact take action, but only
in a context strictly local to the same network.

Following is a list of these addresses. Some of these are called out in
RFC-960 and designated "reserved." Others are called out in RFC-922 and
elsewhere and designated "local broadcast." The remaining are called out in
RFC-960 and designated "local use." These are intended for use by diskless
things that may come on-cable with incomplete configuration information and
need to determine their particular environment by interaction with a local
agent. The interpretation and use of the address and mask are described in
RFC-950, among other places.

(* = "don't care") 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class/Description Address Mask
----------------- ------- ----
A reserved 000.000.000.000 255.000.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|* * * * * * * *|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A reserved 127.000.000.000 255.000.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1|* * * * * * * *|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A local use 000.000.000.000 128.255.255.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-k-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 * * * * * * *|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A local broadcast 000.255.255.255 128.255.255.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 * * * * * * *|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B reserved 128.000.000.000 255.255.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B reserved 191.255.000.000 255.255.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 1 1 1 1 1 1|1 1 1 1 1 1 1 1|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B local use 128.000.000.000 192.000.255.255
+-+-+m+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 * * * * * *|* * * * * * * *|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B local broadcast 128.000.255.255 192.000.255.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 * * * * * *|* * * * * * * *|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C reserved 192.000.000.000 255.255.255.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C reserved 223.255.255.000 255.255.255.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 1 1 1 1 1|1 1 1 1 1 1 1 1|1 1 1 1 1 1 1 1|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C local use 192.00p.000.000 224.000.000.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 * * * * *|* * * * * * * *|* * * * * * * *|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C local broadcast 192.000.000.255 224.000.000.255
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 * * * * *|* * * * * * * *|* * * * * * * *|1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D reserved 224.000.000.000 224.000.000.000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 * * * * *|* * * * * * * *|* * * * * * * *|* * * * * * * *|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that the above has no provision for subnets as described in RFC-950.
Assuming the gateway configuration includes the subnet address(es) and
mask(s), one simply adds entries to the above list in the obvious way.

There has been some discussion on how to deal with proliferated broadcasts
by using information implicit in the local-net (subnetwork) address. I believe
on the basis of clarity, simplicity and separation of function that this is
not the right answer.

Dave
-------



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:33 GMT