RFC 922:BROADCASTING INTERNET DATAGRAMS IN THE PRE...
RFC-Ref

datagram


Click on the red underlined text to get to the source

... We consider here only the case of unreliable, unsequenced, possibly duplicated datagram broadcasts (for a discussion of TCP ...
... broadcasting, see [10].) Even though unreliable and limited in length, datagram broadcasts are quite useful [1 ...
... We do not assume, however, that broadcasts are reliably delivered. (One might consider providing a reliable datagram broadcast protocol as a layer ...
... When a datagram is broadcast, it imposes a cost on every host that ...


... broadcasts are usually used where multicasts are what is wanted; datagrams are broadcast at the hardware level, ...


... Single-destination datagrams broadcast on the local hardware ...
... broadcast on the local hardware net: A datagram is destined for a specific IP host, but the ...
... IP layer is not involved, except that a host should discard datagram not meant for it without becoming flustered (i.e., printing an error message). ...
... case is the same as local-network broadcasts; the datagram is routed by normal mechanisms until it reaches a gateway attached ...


... broadcasting, a host determines if it is the recipient of a datagram by matching the destination address against all of its IP addresses ...
... broadcast need only specify the appropriate destination address and send the datagram as usual. Any sophisticated algorithms need only reside in gateways ...
... No modification of the IP datagram format. ...


... 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 ...
... The appropriate action to take on receipt of a broadcast datagram depends on several things: the subnet it was received on, the ...
... The primary rule for avoiding loops is "never broadcast a datagram on the hardware network it was received on". It is ...
... hardware network it was received on". It is not sufficient simply to avoid repeating datagram that a gateway has heard from itself; this still allows loops if ...
... If the datagram is received on the hardware network to which ...
... 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 ...
... gateway should consider itself a destination of the datagram. ...
... procedure to choose a subsequent gateway, and send the datagram along to it. ...
... method is simple: the gateway should forward copies of the datagram along all connected links, if and only if the datagram ...
... datagram along all connected links, if and only if the datagram arrived on the link which is part of the best route ...
... route between the gateway and the source of the datagram. Otherwise, the datagram should be discarded. ...
... gateway and the source of the datagram. Otherwise, the datagram should be discarded. ...


... source address of an ICMP Information Request datagram. However, as a notational convention, we refer to networks ...
... 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 ...



Google
Web
RFC-Ref