Multicast Router Discovery
draft-ietf-idmr-igmp-mrdisc-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
10 | (System) | Notify list changed from , , to , |
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Ted Hardie |
2005-05-26
|
10 | (System) | State Changes to Dead from AD is watching by IESG Secretary |
2004-01-15
|
10 | (System) | Document has expired |
2003-08-08
|
10 | Bill Fenner |
|
2003-08-08
|
10 | Bill Fenner | State Changes to AD is watching from IESG Evaluation::Revised ID Needed by Bill Fenner |
2003-08-08
|
10 | Bill Fenner | Back to working group, per Brian's note. Will move to MAGMA with INT ADs approval. |
2003-08-08
|
10 | Bill Fenner | State Change Notice email list have been change to , , from |
2003-06-17
|
10 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2003-06-17
|
10 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson |
2003-06-17
|
10 | (System) | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from No Record |
2003-06-17
|
10 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin |
2003-06-17
|
10 | (System) | [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner |
2003-06-17
|
10 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Ned Freed |
2003-06-17
|
10 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Steven Bellovin |
2003-06-17
|
10 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen |
2003-06-17
|
10 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten |
2003-06-17
|
10 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin |
2003-06-17
|
10 | (System) | [Ballot Position Update] Position for Randy Bush has been changed to Discuss from No Record |
2003-06-17
|
10 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand |
2003-06-17
|
10 | (System) | [Ballot Position Update] Position for Erik Nordmark has been changed to Discuss from No Record |
2003-06-17
|
10 | Erik Nordmark | [Ballot discuss] The options defined in section 7 doesn't match the option format used in RFC 2461. The draft has an option length measured … [Ballot 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. |
2003-06-17
|
10 | Ted Hardie | [Ballot discuss] Two things, both pretty minor. The first is that the Introduction and protocol overview deal pretty much entirely with the IGMP mechanism described; … [Ballot discuss] Two things, both pretty minor. The first is that the Introduction and protocol overview deal pretty much entirely with the IGMP mechanism described; the mechanism described in section 8 is pretty much left out of both. Fixing that would help scope the document. Similarly, a reader may assume that IGMP snooping will work in all multicast environments; note that some vendors have PIM-snooping switches to deal with environments like exchange points. An applicability statement on those environments would be useful. |
2003-06-17
|
10 | (System) | Ballot has been issued |
2003-06-17
|
10 | Randy Bush | [Ballot discuss] i am not impressed by The following are justifications for inventing another router discovery protocol: ¡ Using … [Ballot 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). |
2003-06-17
|
10 | Randy Bush | Created "Approve" ballot |
2003-06-17
|
10 | (System) | Ballot writeup text was added |
2003-06-17
|
10 | (System) | Last call text was added |
2003-06-17
|
10 | (System) | Ballot approval text was added |
2003-04-11
|
10 | Bill Fenner | Subject: draft-ietf-idmr-igmp-mrdisc progress Date: Fri, 11 Apr 2003 12:38:35 -0700 To: bkhabs@nc.rr.com Reviewing the messages, it looks like they all made it into the ballot … Subject: draft-ietf-idmr-igmp-mrdisc progress Date: Fri, 11 Apr 2003 12:38:35 -0700 To: bkhabs@nc.rr.com Reviewing the messages, it looks like they all made it into the ballot ( http://www.ietf.org/IESG/EVALUATIONS/draft-ietf-idmr-igmp-mrdisc.bal ). Ted has withdrawn his DISCUSS, so those are not blocking comments, but still worth mentioning. Here's my summary; for details check the ballot: - Security. Actually, one comment that Steve had that didn't make it into the ballot: the document could mention that since the messages are sent to a group that the routers listen to, the routers can detect forged or conflicting messages so that alleviates some of the concerns - so mentioning that would be a great help. Otherwise, I think following Russ's comments makes sense. (The TTL = 1 instead of = 255 thing was because there was never a real spec that defined the IPv4 link-local multicast groups so sending with TTL=255 was not guaranteed to stay on the link) - v6 stuff. - Ted: abstract and intro shouldn't be v6-specific. - Erik: check router discovery option format. - ops-reviewer and Harald: has this been run by v6 wg? (It's been so long that I don't remember the answer to that question) - ops-reviewer: justify why it's not OK to use ICMP and is OK to use ND - why-not-ICMP stuff. The real reason why not ICMP is that IGMP originally wanted to be part of ICMP, but Jon Postel didn't want to allow that (I don't know the exact reason, whether it was that he didn't want to allocate ICMP type codes or he was worried about the semantics of multicasted ICMP). The rest kind of follows -- multicast uses IGMP, unicast uses ICMP. That's not a real strong thing to put in a spec, but that history might be enough to address Randy's (or his reviewer's) concerns. Other stuff: I talked with Erik about the 224.0.0.1 thing being because it can supply info like SSM range to hosts; he kind of said "hmm" so I'm not sure if that means he's OK with it or wants to talk more. To move forward, I think you should update the draft with security and v6 stuff and run it by the ADs who have put in comments. I'm going to be out next week. I'm sorry for not getting to this sooner so that we could have more time to converge. Bill |
2003-04-11
|
10 | Bill Fenner | State Changes to IESG Evaluation :: Revised ID Needed from IESG Evaluation :: Point Raised - writeup needed by Fenner, Bill |
2003-04-11
|
10 | Bill Fenner | To: cotton@icann.org Subject: Re: draft-ietf-idmr-igmp-mrdisc-10.txt Cc: iesg@ietf.org iana@iana.org Fcc: +outgoing Michelle, This document needs a couple of *registrations* from igmp-type-numbers (and I requested specific values; … To: cotton@icann.org Subject: Re: draft-ietf-idmr-igmp-mrdisc-10.txt Cc: iesg@ietf.org iana@iana.org Fcc: +outgoing Michelle, This document needs a couple of *registrations* from igmp-type-numbers (and I requested specific values; even though it's an IANA registry this document dates from when I was the de facto IGMP registrar and I had given out values to it -- so if it's not too out of proper could you assign 0x24 for Multicast Router Advertisement Message, 0x25 for Multicast Router Solicitation Message, 0x26 for Multicast Router Termination Message?) It needs a new registry, for IPv4 Multicast Router Discovery message options. The document registers 1 and 2 (Query Interval Advertisement and Robustness Variable Advertisement) and requests that the space be allocated using IESG Approval or Standards Action. This space is 0-255, presumably with 0 and 255 reserved. It requests two Neighbor Discovery Option Types (this is the subheading "IPv6 NEIGHBOR DISCOVERY OPTION FORMATS" in http://www.iana.org/assignments/icmpv6-parameters) be assigned for the Query Interval Advertisement and Robustness Variable Advertisement in IPv6. Finally, it requests a new IANA registry for the Multicast Router Discovery Code Values. This would probably actually belong in http://www.iana.org/assignments/igmp-type-numbers -- e.g. type 0x11, 0x13 and 0x14 have codes registered, so that seems to make sense; so this fourth request is probably just estabilshing the policy for such allocations. Bill |
2003-04-10
|
10 | Bill Fenner | Security considerations, other minor issues - need to make sure all issues are written up then forward to author. |
2003-04-10
|
10 | Bill Fenner | State Changes to IESG Evaluation :: Point Raised - writeup needed from IESG Evaluation by Fenner, Bill |
2003-03-25
|
10 | Bill Fenner | The last call ended 3 weeks ago. I have submitted the writeup. |
2003-03-25
|
10 | Bill Fenner | Status date has been changed to 2003-04-03 from 2003-03-07 |
2003-03-25
|
10 | Bill Fenner | State Changes to IESG Evaluation from In Last Call by Fenner, Bill |
2003-02-21
|
10 | Stephen Coya | Status date has been changed to 2003-03-07 from 2002-07-15 |
2003-02-21
|
10 | Stephen Coya | State Changes to In Last Call from Last Call Requested by Coya, Steve |
2003-02-21
|
10 | (System) | Last call sent |
2003-02-09
|
10 | Bill Fenner | State Changes to Last Call Requested from AD Evaluation :: AD Followup by Fenner, Bill |
2003-01-28
|
10 | Bill Fenner | Don't forget to ask IANA for assignments from draft -05 (0x24 for Multicast Router Advertisement Message, 0x25 for Multicast Router Solicitation Message, 0x26 for Multicast … Don't forget to ask IANA for assignments from draft -05 (0x24 for Multicast Router Advertisement Message, 0x25 for Multicast Router Solicitation Message, 0x26 for Multicast Router Termination Message) |
2003-01-08
|
10 | (System) | New version available: draft-ietf-idmr-igmp-mrdisc-10.txt |
2002-11-04
|
10 | Bill Fenner | New draft submitted, need to review |
2002-11-04
|
10 | Bill Fenner | by Fenner, Bill |
2002-11-04
|
10 | Bill Fenner | State Changes to AD Evaluation :: AD Followup from AD Evaluation :: External Party by Fenner, Bill |
2002-09-26
|
09 | (System) | New version available: draft-ietf-idmr-igmp-mrdisc-09.txt |
2002-07-08
|
10 | Bill Fenner | Sent feedback to the author |
2002-07-08
|
10 | Bill Fenner | Due date has been changed to 07/15/2002 from 03/15/2002 A new comment added by fenner |
2002-07-08
|
10 | Bill Fenner | State Changes to New Version Needed (WG/Author) from AD Evaluation … State Changes to New Version Needed (WG/Author) from AD Evaluation by fenner |
2002-02-28
|
10 | (System) | Bill needs to get comments back to author. |
2002-02-28
|
10 | (System) | State Changes to AD Evaluation from Token@wg or … State Changes to AD Evaluation from Token@wg or Author by IESG Member |
2002-02-01
|
08 | (System) | New version available: draft-ietf-idmr-igmp-mrdisc-08.txt |
2001-06-27
|
07 | (System) | New version available: draft-ietf-idmr-igmp-mrdisc-07.txt |
2001-05-08
|
06 | (System) | New version available: draft-ietf-idmr-igmp-mrdisc-06.txt |
2000-10-05
|
05 | (System) | New version available: draft-ietf-idmr-igmp-mrdisc-05.txt |
2000-07-13
|
04 | (System) | New version available: draft-ietf-idmr-igmp-mrdisc-04.txt |
2000-06-14
|
03 | (System) | New version available: draft-ietf-idmr-igmp-mrdisc-03.txt |
1999-08-27
|
02 | (System) | New version available: draft-ietf-idmr-igmp-mrdisc-02.txt |
1999-02-19
|
01 | (System) | New version available: draft-ietf-idmr-igmp-mrdisc-01.txt |
1998-04-07
|
00 | (System) | New version available: draft-ietf-idmr-igmp-mrdisc-00.txt |