mills@DCN6.ARPA.UUCP (06/02/86)
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 -------