rfc922.txt

RFC 相关的技术文档

RFC 922                                                     October 1984
Broadcasting Internet Datagrams in the Presence of Subnets


   6.2. Multi-subnet broadcasts

      When a gateway receives a broadcast meant for all subnets of an IP
      network, it must use the Reverse Path Forwarding algorithm to
      decide what to do.  The method is simple: the gateway should
      forward copies of the datagram along all connected links, if and
      only if the datagram arrived on the link which is part of the best
      route between the gateway and the source of the datagram.
      Otherwise, the datagram should be discarded.

      This algorithm may be improved if some or all of the gateways
      exchange among themselves additional information; this can be done
      transparently from the point of view of other hosts and even other
      gateways.  See [4, 3] for details.

   6.3. Pseudo-Algol Routing Algorithm

      This is a pseudo-Algol description of the routing algorithm a
      gateway should use.  The algorithm is shown in figure 1.  Some
      definitions are:

      RouteLink(host)

         A function taking a host address as a parameter and returning
         the first-hop link from the gateway to the host.

      RouteHost(host)

         As above but returns the first-hop host address.

      ResolveAddress(host)

         Returns the hardware address for an IP host.

      IncomingLink

         The link on which the packet arrived.

      OutgoingLinkSet

         The set of links on which the packet should be sent.

      OutgoingHardwareHost

         The hardware host address to send the packet to.




Mogul                                                           [Page 7]



RFC 922                                                     October 1984
Broadcasting Internet Datagrams in the Presence of Subnets


      Destination.host

         The host-part of the destination address.

      Destination.subnet

         The subnet-part of the destination address.

      Destination.ipnet

         The IP-network-part of the destination address.






































Mogul                                                           [Page 8]



RFC 922                                                     October 1984
Broadcasting Internet Datagrams in the Presence of Subnets

BEGIN
   IF Destination.ipnet IN AllLinks THEN
      BEGIN
         IF IsSubnetted(Destination.ipnet) THEN
            BEGIN
               IF Destination.subnet = BroadcastSubnet THEN
                  BEGIN      /* use Reverse Path Forwarding algorithm */
                     IF IncomingLink = RouteLink(Source) THEN
                        BEGIN IF Destination.host = BroadcastHost THEN
                              OutgoingLinkSet <- AllLinks -
                           IncomingLink;
                           OutgoingHost <- BroadcastHost;
                           Examine packet for possible internal use;
                        END
                     ELSE  /* duplicate from another gateway, discard */
                        Discard;
                  END
               ELSE
                  IF Destination.subnet = IncomingLink.subnet THEN
                     BEGIN           /* forwarding would cause a loop */
                        IF Destination.host = BroadcastHost THEN
                           Examine packet for possible internal use;
                        Discard;
                     END
                  ELSE BEGIN    /* forward to (possibly local) subnet */
                        OutgoingLinkSet <- RouteLink(Destination);
                        OutgoingHost <- RouteHost(Destination);
                     END
            END
         ELSE BEGIN         /* destined for one of our local networks */
               IF Destination.ipnet = IncomingLink.ipnet THEN
                  BEGIN              /* forwarding would cause a loop */
                     IF Destination.host = BroadcastHost THEN
                        Examine packet for possible internal use;
                     Discard;
                  END
               ELSE BEGIN                     /* might be a broadcast */
                     OutgoingLinkSet <- RouteLink(Destination);
                     OutgoingHost <- RouteHost(Destination);
                  END
            END
      END
   ELSE BEGIN                    /* forward to a non-local IP network */
         OutgoingLinkSet <- RouteLink(Destination);
         OutgoingHost <- RouteHost(Destination);
      END
   OutgoingHardwareHost <- ResolveAddress(OutgoingHost);
END

Figure 1: Pseudo-Algol algorithm for routing broadcasts by gateways

Mogul                                                           [Page 9]



RFC 922                                                     October 1984
Broadcasting Internet Datagrams in the Presence of Subnets


7. Broadcast IP Addressing - Conventions

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

   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.

   The "all subnets" number is also all ones; this means that a host
   wishing to broadcast to all hosts on a remote IP network need not
   know how the destination address is divided up into subnet and host
   fields, or if it is even divided at all.  For example, 36.255.255.255
   may denote all the hosts on a single hardware network, or all the
   hosts on a subnetted IP network with 1 byte of subnet field and 2
   bytes of host field, or any other possible division.

   The address 255.255.255.255 denotes a broadcast on a local hardware
   network that 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

   without knowing if the net is subnetted; if it is not, then both
   addresses have the same effect. A robust application might try the
   former address, and if no response is received, then try the latter.
   See [1] for a discussion of such "expanding ring search" techniques.

   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".


Mogul                                                          [Page 10]



RFC 922                                                     October 1984
Broadcasting Internet Datagrams in the Presence of Subnets


   7.1. ARP Servers and Broadcasts

      The Address Resolution Protocol (ARP) described in [11] 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.

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,
        November 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, BBN, 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.




Mogul                                                          [Page 11]



RFC 922                                                     October 1984
Broadcasting Internet Datagrams in the Presence of Subnets


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

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

   10.  William W. Plummer.  Internet Broadcast Protocols.  IEN-10, BBN,
        March 1977.

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

   12.  Jon Postel.  Internet Protocol.  RFC-791, ISI, September 1981.

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

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




























Mogul                                                          [Page 12]