Re: Straw poll - All-interface broadcast/multicast

From: Bruce M Simpson (bms_at_spc.org)
Date: 11/18/03

  • Next message: Crist J. Clark: "Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess)" 
    Date: Tue, 18 Nov 2003 21:36:59 +0000
To: Barney Wolff <barney@databus.com>

    On Tue, Nov 18, 2003 at 12:19:00PM -0500, Barney Wolff wrote:
    > Some questions, because I'd like to be an educated voter.
    >
    > 1. How does multicast routing work now? Presumably something takes a
    > mcast packet and sends it out to every interface behind which some host
    > has indicated group membership. Is this kernel or userland? Does it
    > work at all?

    Kernel. Works. Right now, the default multicast route is via the interface
    with the default route; setting a route isn't necessary unless you need to
    force multicast to go via a particular interface by default, this is done
    by longest-prefix matching like all other IPv4 routing activities.

    Only one copy of the multicast datagram is sent.

    Running an MROUTER is a special case. The vif mechanism is used to forward
    multicast datagrams on multiple interfaces under mrouted(8) control.

    > 2. How is "appropriate" defined - by administrator choice or by some
    > inherent property of the interface hardware type?

    For the broadcast case, if IFF_BROADCAST is set on the interface, and it
    has AF_INET address[es] configured.

    For the multicast case, a membership must exist for the interface in question.
    [I haven't written the multicast hack yet, but mdodd@ requested it.]

    > 3. How do other OS's do it, if at all?

    Some broadcast on all interfaces, some don't. I'm awaiting more feedback on
    this, I haven't really researched this point.

    > 4. How will this interact with IPv6? IPsec?

    This purely affects IPv4. IPSEC encapsulation gets handled at the ip_output()
    level afterwards.

    fenner's objection to this has been noted, he suggests re-architecting my
    current patch to take place at a higher level.

    BMS
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Crist J. Clark: "Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess)"

    Relevant Pages

    • Re: Unexpected multicast IPv4 socket behavior
      ... Default route set, src INADDR_ANY: ... src bindto interface address: ... There's no way for the stack to know which interface to originate the traffic from in the case where there is no default route, and no IP layer source information elsewhere in the stack. ... the use of multicast requires that you create a socket and bind to the interface where you wish to send and receive the channel. ...
      (freebsd-net)
    • Unexpected multicast IPv4 socket behavior
      ... Default route set, src INADDR_ANY: ... src bind() to interface address: ... The check for a multicast destination address is run after the attempt ...
      (freebsd-net)
    • Re: Bind succeeded but not receiving mulitcast packets
      ... I have a mulitcast server program. ... I have added the interface to the ... programming the multicast filter correctly. ... VxWorks, ...
      (comp.os.vxworks)
    • Re: Bind succeeded but not receiving mulitcast packets
      ... I have a mulitcast server program. ... I have added the interface to the ... programming the multicast filter correctly. ... VxWorks, ...
      (comp.os.vxworks)
    • Re: Multicast question
      ... IT is synchronizing correctly but I cannot get it to multicast on any interface except the systems primary Ethernet interface, ... Multicast routing deamons then run the IGMP and other protocols to ... These packets are replicated to ...
      (comp.protocols.time.ntp)