Inbound Broadcast IP Address Handling with Source Route Options
bra...@isi.edu
Gary,
These situations should not arise for multicasting, since Deering (wisely) specified in RFC-1112:
"A host group address must never be placed in the source address
field or anywhere in a source route or record route option of an
outgoing datagram".
I guess RFC-1122 should say in section 3.2.1.3 that the broadcast
addresses must not be used in source routes. In any case, use of
a broadcast address in a source route seems to be clearly contrary
to the intent of the protocols, so anyone who does it deserves to
get non-determinisitic behaviour. So, I would say that it does
not matter how you treat these strange cases.
Bob Braden
*> From gdi...@vnet.IBM.COM Tue May 25 07:18:12 1993
*> Reply-To: "Gary Diehl" <gdi...@vnet.IBM.COM>
*> Date: Tue, 25 May 1993 10:13:47 -0400 (EDT)
*> From: Gary Diehl <die...@rchland.ibm.com>
*> To: bra...@ISI.EDU (Bob Braden)
*> Subject: Inbound Broadcast IP Address Handling with Source Route Options
*> Cc: Carl Obert <obe...@rchland.ibm.com>, Dave Hall <dave...@rchland.ibm.com>,
*> Lee Sendelbach <sen...@rchland.ibm.com>
*> Content-Length: 1675
*> X-Lines: 38
*>
*> Bob -
*>
*> Carl Obert referred me to you as someone who might be able to clarify
*> something for us. The basic question is, do the rules for handling
*> broadcasts change when the datagram contains a source route option
*> string ? RFC's 919, 922, and 1122 spell out fairly clearly the rules
*> for accepting, discarding, or forwarding incoming broadcasts. And I
*> know you and Carl have exchanged a few notes on this subject. Now
*> what if a datagram is received with the destination address = a local
*> broadcast, but the source route string indicates the final
*> destination is on a different (sub)network ??? Do we essentially
*> ignore the broadcast and handle the datagram as if it had been received
*> with the destination address = that from the options string ??? Or
*> do we apply the rules in RFC 919 & 922, which state that a datagrams
*> received on the hardware network to which it is addressed "should not be
*> forwarded" ???
*>
*> And what about the reverse case -- datagram addressed to one of our
*> local IP addresses, but the source route options include a broadcast ??
*> Is the general rule again, replace the destination address with the
*> appropriate "next address" from the options string, and handle as if it
*> were received with this destination address ???
*>
*> Finally, what if both the destination address and the source route "next
*> address" were broadcasts - which would take precedence ???
*>
*> Thank you in advance for your help. Best Regards, Gary Diehl
*>
*>
*>
*>
*> Gary A. Diehl
*> AS/400 Connectivity Development
*> Department 40C / Building 16-2Q009
*> Endicott, New York
*> Phone:607-752-5505 or Tie Line 852-5505.
*> INTERNET: di...@rchland.vnet.ibm.com VNET: GDIEHL@RCHVMV
*>
*>