home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / tcpip / 3919 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  1.7 KB
  1. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!think.com!barmar
  2. From: barmar@think.com (Barry Margolin)
  3. Newsgroups: comp.protocols.tcp-ip
  4. Subject: Re: IP Directed Broadcast
  5. Date: 30 Jul 1992 19:54:39 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 26
  8. Message-ID: <159hdvINN6j7@early-bird.think.com>
  9. References: <11132@crackers.clearpoint.com>
  10. NNTP-Posting-Host: telecaster.think.com
  11.  
  12. In article <11132@crackers.clearpoint.com> martillo@stars.clearpoint.com (Joachim Martillo) writes:
  13. >If a networks gateways do not filter IP broadcasts and that network
  14. >has active loops in its subnet topology, and if someone extern to the
  15. >network sends a directed broadcast to that network with a TTL of 255,
  16. >the target network could easily suffer a major broadcast storm.
  17. >
  18. >Such a storm would seem a bad thing.  Maybe I am missing something,
  19. >but perhaps filterning directed broadcasts should be obligatory rather
  20. >than optional.
  21.  
  22. This is why they are allowed to filter them out.  They aren't required to
  23. filter them because they don't cause a problem on non-subnetted networks
  24. (e.g. directed broadcasts to a subnet of a subnetted network), networks
  25. without active loops, or networks where the routers compute a spanning tree
  26. to prevent broadcast loops (cisco Brouters have this option).  Why actively
  27. prohibit something when there are reasonable ways of making use of it?
  28.  
  29. Routers that support forwarding of directed broadcasts should have a way to
  30. disable it, so that networks where it will cause storms will not be
  31. susceptible to this.  It should probably even be off by default.  But
  32. network administrators should be able to enable it if they want.
  33. -- 
  34. Barry Margolin
  35. System Manager, Thinking Machines Corp.
  36.  
  37. barmar@think.com          {uunet,harvard}!think!barmar
  38.