Multicast Router Discovery
draft-ietf-idmr-igmp-mrdisc-10
Discuss
Yes
No Objection
No Record
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Alvaro Retana No Record
Andrew Alston No Record
Erik Kline No Record
Francesca Palombini No Record
John Scudder No Record
Lars Eggert No Record
Martin Duke No Record
Murray Kucherawy No Record
Paul Wouters No Record
Robert Wilton No Record
Roman Danyliw No Record
Warren Kumari No Record
Zaheduzzaman Sarker No Record
Éric Vyncke No Record
(Erik Nordmark; former steering group member) 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 (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 steering group member) 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).
(Bill Fenner; former steering group member) Yes
(Alex Zinin; former steering group member) No Objection
(Allison Mankin; former steering group member) No Objection
(Bert Wijnen; former steering group member) No Objection
(Harald Alvestrand; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Ned Freed; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Steven Bellovin; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
(Thomas Narten; former steering group member) No Objection