Vlad Yasevich <[EMAIL PROTECTED]> wrote on 12/19/2007 07:20:53 AM: > But this still requires either a SO_BINDTODEVICE or sin6_scope_id. This > means the an application can call BINDTODEVICE(eth0), MULTICAST_IF(eth1) > issue a connect on a UDP socket an succeed? Seems wrong to me. > > Can you check section 6.7 of RFC 3542.
No, it requires one of SO_BINDTODEVICE, sin6_scope_id, or IPV6_MULTICAST_IF. If you do an SO_BINDTODEVICE(eth0) and then an IPV6_MULTICAST_IF(eth1), the IPV6_MULTICAST_IF will fail in setsockopt (EINVAL), because it requires a match for bound sockets. I'm not sure if SO_BINDTODEVICE resets mcast_oif if you do them in the reverse order, but that would be a bug in SO_BINDTODEVICE. The precedence order as implemented already is: SO_BINDTODEVICE is highest and always wins sin6_scope_id next IPV6_MULTICAST_IF and the existing code has the rule that all link-local addresses require a sin6_scope_id. The change (intended) is to relax the sin6_scope_id rule only for link-local multicasts that have done either an SO_BINDTODEVICE or IPV6_MULTICAST_IF already. +-DLS -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html