Re: Inbound Broadcast IP Address Handling with Source Route Options

braden@isi.edu Wed, 26 May 1993 19:03 UTC

Date: Wed, 26 May 1993 11:51:46 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: braden@isi.edu
Posted-Date: Wed, 26 May 1993 11:51:46 -0700
Message-Id: <199305261851.AA06681@can.isi.edu>
To: braden@isi.edu, gdiehl@vnet.ibm.com
Subject: Re: Inbound Broadcast IP Address Handling with Source Route Options
Cc: ietf-hosts@isi.edu, obert+@rchland.ibm.com, davehall+@rchland.ibm.com, sendel+@rchland.ibm.com

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 gdiehl@vnet.IBM.COM Tue May 25 07:18:12 1993
  *> Reply-To: "Gary Diehl" <gdiehl@vnet.IBM.COM>
  *> Date: Tue, 25 May 1993 10:13:47 -0400 (EDT)
  *> From: Gary Diehl <diehl+@rchland.ibm.com>
  *> To: braden@ISI.EDU (Bob Braden)
  *> Subject: Inbound Broadcast IP Address Handling with Source Route Options
  *> Cc: Carl Obert <obert+@rchland.ibm.com>, Dave Hall <davehall+@rchland.ibm.com>,
  *>         Lee Sendelbach <sendel+@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: diehl@rchland.vnet.ibm.com           VNET: GDIEHL@RCHVMV
  *> 
  *>

Re: Inbound Broadcast IP Address Handling with So… braden