Multicast Router Discovery
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
(Randy Bush) Discuss
i am not impressed by The following are justifications for inventing another router discovery protocol: ¡ Using ICMP router discovery is not an appropriate solution for multicast router discovery because: 1.) It may confuse hosts listening to ICMP router advertisements; unicast and multicast topologies may not be congruent. 2.) There is no way to tell from an ICMP router advertisement if a router is running a multicast routing protocol. but an icmp-based protocol could work ¡ By making multicast router discovery messages extensible, future enhancements can be made. completely bogus ¡ By inventing a generic IP layer message, multiple types of messages per link layer are not needed (i.e. including this functionality as part of IP is better than inventing N discovery protocols for N layer-2 technologies). agree, but a new icmp could do it what could be said is that, because this discovery mechanism uses multicast, discovery problems will be congruent with payload problems, which is cool. but the following is just way to bogus, and is worth a discuss 9. Security Considerations The Multicast Router Advertisement message may allow rogue machines to masquerade as multicast routers. This could allow those machines to eavesdrop on multicast data transmission or create a denial of service attack on multicast flows. However, these new messages are extensible and that allows for the introduction of security associations into the protocol. These security extensions could be used to authenticate or encrypt the messages. ------ further comment on this from ops-dir reviewer. randy --- - the document does not conform to editorial guidelines (use of some '¡' instead of '-') - I dislike IPv6 sections being only waved off in one section even though the rest; also, the technical solution needs justification, as it was stated that: --8<-- The following are justifications for inventing another router discovery protocol: ¡ Using ICMP router discovery is not an appropriate solution for multicast router discovery because: 1.) It may confuse hosts listening to ICMP router advertisements; unicast and multicast topologies may not be congruent. 2.) There is no way to tell from an ICMP router advertisement if a router is running a multicast routing protocol. [...] --8<-- .. it appears to me that (ab)using NDP falls within this category (at least sub-item 1). - Also, this consumes 2 precious bits from IPv6 router advertisement messages; if this is really the approach that seems best, at least it needs a round of review in e.g. IPv6 w.g. or the like.. - as an operational/security aspect, security considerations lists the possibility of rogue nodes masquarading as multicast routers to get all data. This should be expanded a bit. The reason for this seems to be that snooping switches would mark the incoming port of such advertisements as "router port" and push all the multicast there. Additionally, one might explicitly say something to the extent of "Therefore, administratively disabling Multicast Router Advertisement processing SHOULD be possible." (or MAY).
(Erik Nordmark) Discuss
The options defined in section 7 doesn't match the option format used in RFC 2461. The draft has an option length measured in bytes while RFC 2461 has: Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value 0 is invalid. Nodes MUST silently discard an ND packet that contains an option with length zero. I don't understand my the IPv4 messages need to be sent to all-hosts (220.127.116.11) when only the snooping switches want the messages. Why not define a all-snoopers multicast address? At a meta-level I also have a question about whether this and magma-snoop-06 is sufficient to get the snooping switches under control or whether we are likely to continue to inject clue and help to those building snooping switches.