Multicast Router Discovery
draft-ietf-idmr-igmp-mrdisc-10
Discuss
Yes
(Bill Fenner)
No Objection
(Alex Zinin)
(Allison Mankin)
(Bert Wijnen)
(Harald Alvestrand)
(Jon Peterson)
(Ned Freed)
(Russ Housley)
(Steven Bellovin)
(Ted Hardie)
(Thomas Narten)
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Erik Nordmark Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2003-06-17)
Unknown
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.
Randy Bush Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2003-06-17)
Unknown
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).
Bill Fenner Former IESG member
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Ned Freed Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Steven Bellovin Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown
Thomas Narten Former IESG member
No Objection
No Objection
()
Unknown