Re: broadcast to internet?

From: Barry Margolin (barmar_at_alum.mit.edu)
Date: 10/14/04

  • Next message: Kerodo: "Re: Question about Outpost's statefull inspection"
    Date: Wed, 13 Oct 2004 20:46:15 -0400
    
    

    In article <slrncmqss2.64o.eirik@kain.mi.uib.no>,
     Eirik Seim <eirik@mi.uib.no> wrote:

    > On 13 Oct 2004 11:05:03 -0500, briggs@encompasserve.org wrote:
    > > In article <slrncmqeif.3kq.eirik@kain.mi.uib.no>, Eirik Seim
    > > <eirik@mi.uib.no> writes:
    > > > On 13 Oct 2004 06:06:37 -0700, Bernd M?ller wrote:
    > > >> Tauno Voipio <tauno.voipio@iki.fi.NOSPAM.invalid> wrote in message
    > > >> news:<tgdad.229$xb5.195@read3.inet.fi>...
    > > >
    > > > [snip]
    > > >
    > > >> > The address 255.255.255.255 is the local link broadcast address.
    > > >> >
    > > >> you mean: 255.255.255.1 !
    > > >
    > > > Actually, I don't think he do. But "255.255.255.255" is bougus,
    > > > and says really nothing of IP layer broadcasts. It's simply how
    > > > applications interpret the local link layer broadcast address,
    > > > which is ff:ff:ff:ff:ff:ff.
    > >
    > > No. 255.255.255.255 is a real, honest to goodness IP address. It
    > > fits into 32 bits in the destination address field in the IP header
    > > just like an IP address should. And that's where it is placed.
    > >
    > > IP applications should never see the link layer source address
    > > or the link layer destination address, even assuming that
    > > there is such a thing as a link layer source address or link
    > > layer destination address on the network in question. There
    > > may not be. Don't let your parochial "everything is on Ethernet"
    > > point of view mislead you.
    >
    > I'm not sure who sold you my point of views, but apparently
    > you should claim a refund. My point was to illustrate that
    > several applications (and operating systems, whatever) translates
    > the link layer broadcast address into "IP address" 255.255.255.255

    This is *not* what happens. Briggs is correct that applications never
    see the link layer address. The packet doesn't get to the application
    unless the IP layer has already accepted the packet, which happens only
    if the destination IP address is one of the host's unicast addresses, a
    multicast address that the host has joined, or a broadcast address.

    The translation you're talking about happens in the other direction. If
    an application sends a packet to IP 255.255.255.255, the IP stack should
    transmit it as a link layer broadcast. Also, RFC 1122 says that a host
    should (but is not required to) ignore a packet received via a link
    layer broadcast if the IP destination is a unicast address.

    > because it's a packet, and for whatever reason their way of
    > representing this does not fit for a packet (or frame, actually)
    > without any IP information. I never said anything about Ethernet.

    You said ff:ff:ff:ff:ff:ff, which looks like an Ethernet address.
    Actually, it's an 802.x address -- a number of LAN technologies
    (Ethernet, FDDI, Token Ring, etc.) share the same link layer addressing
    scheme. But it's certainly not the only link layer addressing scheme
    there is; for instance, ATM and Frame Relay don't use that address
    format.

    >
    > The rest is of course valid with regard to IP, but I'm pretty
    > sure IP has nothing to do with this. As far as I can see, this is
    > normal behaviour of a protocol considered non-routable. Perhaps
    > I should have said "bougus in this context".

    What protocol and context are you talking about? The OP mentioned a
    firewall log that showed IP packets destined to 255.255.255.255. Since
    this is IP, it's a routable protocol.

    -- 
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    

  • Next message: Kerodo: "Re: Question about Outpost's statefull inspection"

    Relevant Pages

    • Re: broadcast to internet?
      ... > applications interpret the local link layer broadcast address, ... fits into 32 bits in the destination address field in the IP header ... IP applications should never see the link layer source address ... One can have a packet which is broadcast on the link layer but which ...
      (comp.security.firewalls)
    • Re: Changes in the network interface queueing handoff model
      ... significant numbers of additional allocations and frees for each packet, as well as walking link lists. ... It's fine for occasional discretionary use, but I worry about cases where it is used with every packet, and we start seeing moderately non-zero numbers of tags on every packet. ... I think I would be more comfortable with an explicit queue identifier argument to if_start, where the link layer and driver layer agree on how to identify queues. ... the mbuf header. ...
      (freebsd-arch)
    • Re: Changes in the network interface queueing handoff model
      ... significant numbers of additional allocations and frees for each packet, as well as walking link lists. ... It's fine for occasional discretionary use, but I worry about cases where it is used with every packet, and we start seeing moderately non-zero numbers of tags on every packet. ... I think I would be more comfortable with an explicit queue identifier argument to if_start, where the link layer and driver layer agree on how to identify queues. ... the mbuf header. ...
      (freebsd-net)
    • Re: broadcast to internet?
      ... >> applications interpret the local link layer broadcast address, ... > layer destination address on the network in question. ... the link layer broadcast address into "IP address" 255.255.255.255 ...
      (comp.security.firewalls)
    • Re: VXWORKS 6.0 :From vxworks sending a layer2 packet ( USING ONLY MAC ADDRESS )
      ... X86 machine loaded with vxworks image. ... AXEL_X network processor code is included into my vxworks image. ... I have my linux x86 OS from which I am sending a packet using ... Vxworks 6.x doesn't support sockaddr_ll structure and link layer ...
      (comp.os.vxworks)