rfc919.txt

RFC 相关的技术文档

RFC 919                                                     October 1984
Broadcasting Internet Datagrams


6. Gateways and Broadcasts

   Most of the complexity in supporting broadcasts lies in gateways.  If
   a gateway receives a directed broadcast for a network to which it is
   not connected, it simply forwards it using the usual mechanism.
   Otherwise, it must do some additional work.

   When a gateway receives a local broadcast datagram, there are several
   things it might have to do with it.  The situation is unambiguous,
   but without due care it is possible to create infinite loops.

   The appropriate action to take on receipt of a broadcast datagram
   depends on several things: the subnet it was received on, the
   destination network, and the addresses of the gateway.

      - The primary rule for avoiding loops is "never broadcast a
        datagram on the hardware network it was received on". It is not
        sufficient simply to avoid repeating datagrams that a gateway
        has heard from itself; this still allows loops if there are
        several gateways on a hardware network.

      - If the datagram is received on the hardware network to which it
        is addressed, then it should not be forwarded.  However, the
        gateway should consider itself to be a destination of the
        datagram (for example, it might be a routing table update.)

      - Otherwise, if the datagram is addressed to a hardware network to
        which the gateway is connected, it should be sent as a (data
        link layer) broadcast on that network.  Again, the gateway
        should consider itself a destination of the datagram.

      - Otherwise, the gateway should use its normal routing procedure
        to choose a subsequent gateway, and send the datagram along to
        it.

7. Broadcast IP Addressing - Proposed Standards

   If different IP implementations are to be compatible, there must be a
   distinguished number to denote "all hosts".

   Since the local network layer can always map an IP address into data
   link layer address, the choice of an IP "broadcast host number" is
   somewhat arbitrary.  For simplicity, it should be one not likely to
   be assigned to a real host.  The number whose bits are all ones has
   this property; this assignment was first proposed in [6].  In the few
   cases where a host has been assigned an address with a host-number
   part of all ones, it does not seem onerous to require renumbering.


Mogul                                                           [Page 5]



RFC 919                                                     October 1984
Broadcasting Internet Datagrams


   The address 255.255.255.255 denotes a broadcast on a local hardware
   network, which must not be forwarded.  This address may be used, for
   example, by hosts that do not know their network number and are
   asking some server for it.

   Thus, a host on net 36, for example, may:

      - broadcast to all of its immediate neighbors by using
        255.255.255.255

      - broadcast to all of net 36 by using 36.255.255.255

   (Note that unless the network has been broken up into subnets, these
   two methods have identical effects.)

   If the use of "all ones" in a field of an IP address means
   "broadcast", using "all zeros" could be viewed as meaning
   "unspecified".  There is probably no reason for such addresses to
   appear anywhere but as the source address of an ICMP Information
   Request datagram.  However, as a notational convention, we refer to
   networks (as opposed to hosts) by using addresses with zero fields.
   For example, 36.0.0.0 means "network number 36" while 36.255.255.255
   means "all hosts on network number 36".

   7.1. ARP Servers and Broadcasts

      The Address Resolution Protocol (ARP) described in [12] can, if
      incorrectly implemented, cause problems when broadcasts are used
      on a network where not all hosts share an understanding of what a
      broadcast address is.  The temptation exists to modify the ARP
      server so that it provides the mapping between an IP broadcast
      address and the hardware broadcast address.

      This temptation must be resisted.  An ARP server should never
      respond to a request whose target is a broadcast address.  Such a
      request can only come from a host that does not recognize the
      broadcast address as such, and so honoring it would almost
      certainly lead to a forwarding loop.  If there are N such hosts on
      the physical network that do not recognize this address as a
      broadcast, then a datagram sent with a Time-To-Live of T could
      potentially give rise to T**N spurious re-broadcasts.








Mogul                                                           [Page 6]



RFC 919                                                     October 1984
Broadcasting Internet Datagrams


8. References

   1.   David Reeves Boggs.  Internet Broadcasting.  Ph.D. Th., Stanford
        University, January 1982.

   2.   D.D. Clark, K.T. Pogran, and D.P. Reed.  "An Introduction to
        Local Area Networks".  Proc. IEEE 66, 11, pp1497-1516, 1978.

   3.   Yogan Kantilal Dalal.  Broadcast Protocols in Packet Switched
        Computer Networks.  Ph.D. Th., Stanford University, April 1977.

   4.   Yogan K. Dalal and Robert M. Metcalfe.  "Reverse Path Forwarding
        of Broadcast Packets".  Comm. ACM 21, 12, pp1040-1048, December
        1978.

   5.   The Ethernet, A Local Area Network: Data Link Layer and Physical
        Layer Specifications.  Version 1.0, Digital Equipment
        Corporation, Intel, Xerox, September 1980.

   6.   Robert Gurwitz and Robert Hinden.  IP - Local Area Network
        Addressing Issues.  IEN-212, Bolt Beranek and Newman, September
        1982.

   7.    R.M. Metcalfe and D.R. Boggs. "Ethernet: Distributed Packet
        Switching for Local Computer Networks".  Comm. ACM 19, 7,
        pp395-404, July 1976.  Also CSL-75-7, Xerox Palo Alto Research
        Center, reprinted in CSL-80-2.

   8.   Jeffrey Mogul.  Internet Subnets.  RFC-917, Stanford University,
        October 1984.

   9.   Jeffrey Mogul.  Broadcasting Internet Packets in the Presence of
        Subnets.  RFC-922, Stanford University, October 1984.

   10.  David A. Moon.  Chaosnet.  A.I. Memo 628, Massachusetts
        Institute of Technology Artificial Intelligence Laboratory, June
        1981.

   11.  William W. Plummer.  Internet Broadcast Protocols.  IEN-10, Bolt
        Beranek and Newman, March 1977.

   12.  David Plummer.  An Ethernet Address Resolution Protocol.
        RFC-826, Symbolics, September 1982.

   13.  Jon Postel.  Internet Protocol.  RFC 791, ISI, September 1981.




Mogul                                                           [Page 7]



RFC 919                                                     October 1984
Broadcasting Internet Datagrams


   14.  David W. Wall.  Mechanisms for Broadcast and Selective
        Broadcast.  Ph.D. Th., Stanford University, June 1980.

   15.  David W. Wall and Susan S. Owicki.  Center-based Broadcasting.
        Computer Systems Lab Technical Report TR189, Stanford
        University, June 1980.











































Mogul                                                           [Page 8]