Multicast Router Discovery
draft-ietf-idmr-igmp-mrdisc-10

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 (224.0.0.1) 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.

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).