Skip to main content

Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast
draft-holbrook-idmr-igmpv3-ssm-08

Revision differences

Document history

Date Rev. By Action
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2004-10-12
08 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-10-11
08 Amy Vezza IESG state changed to Approved-announcement sent
2004-10-11
08 Amy Vezza IESG has approved the document
2004-10-11
08 Amy Vezza Closed "Approve" ballot
2004-10-06
08 Margaret Cullen State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Margaret Wasserman
2004-10-04
08 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2004-10-04
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-10-04
08 (System) New version available: draft-holbrook-idmr-igmpv3-ssm-08.txt
2004-10-01
08 Margaret Cullen State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Margaret Wasserman
2004-09-03
08 (System) Removed from agenda for telechat - 2004-09-02
2004-09-02
08 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2004-09-02
08 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Amy Vezza
2004-09-02
08 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten
2004-09-02
08 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2004-09-02
08 Harald Alvestrand
[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

Review copied below.

This specification, taken on its own, is mostly ready for publication
as a proposed standard. …
[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

Review copied below.

This specification, taken on its own, is mostly ready for publication
as a proposed standard. I could implement the protocol from the
specification, and it's reasonably clear what's going on.

My only question is (echoing Margaret's question in the ID Tracker),
"why was this specification not written as updates to RFC 3376 and
MLDv2, especially since MLDv2 wasn't an RFC yet?"

Call me sensitive, but we have an entire working group figuring out
what TCP really is beneath all the independent specifications that
change TCP behavior as specified in RFC 793. Do we want to go here
again?

MLDv2 has been published as RFC 3810 (in June), so the reference needs
to be updated.

I guess I'm also curious about why hosts SHOULD log errors, but
routers MAY log errors. I'm guessing that the idea was that the hosts
are the ones causing the problems, so they should work harder to make
sure someone notices logged errors, but this seems like a throwback to
a simpler time - we can't get people to stop clicking on .pif files,
or .scr files, or .zip files, so shouldn't we try harder to make sure
network operators know there's a problem? But I thought SHOULD was "in
most cases, MUST, but this doesn't make sense in all cases", and am
trying to figure out what the corner cases might be.
2004-09-02
08 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand
2004-09-02
08 Bill Fenner [Ballot comment]
The reference to [IANA-ALLOCATION] should probably be to http://www.iana.org/assignments/multicast-addresses ; I dunno if the RFC 3553 namespace is usable in this context.
2004-09-02
08 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2004-09-02
08 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2004-09-02
08 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2004-09-01
08 David Kessens [Ballot comment]
From Pekka Savola, ops directorate:

Was OK when I last took a look at it prior to being shipped to the
IESG.
2004-09-01
08 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2004-09-01
08 Russ Housley [Ballot comment]
Please create a subsection in section 1 that references RFC 2119 and
  defines the use of the MODIFICATION tag.
2004-09-01
08 Russ Housley [Ballot discuss]
This document updates IGMPv3 and MLDv2.  The header needs to indicate
  which RFCs are being updated by this document.
2004-09-01
08 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley
2004-08-31
08 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2004-08-30
08 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Amy Vezza
2004-08-26
08 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Undefined by Scott Hollenbeck
2004-08-26
08 Scott Hollenbeck [Ballot comment]
Section 6 typo:

s/and Pekka Savola and/and Pekka Savola/
2004-08-26
08 Scott Hollenbeck [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-08-26
08 Margaret Cullen Placed on agenda for telechat - 2004-09-02 by Margaret Wasserman
2004-08-26
08 Margaret Cullen State Changes to IESG Evaluation from Waiting for Writeup by Margaret Wasserman
2004-08-26
08 Margaret Cullen [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman
2004-08-26
08 Margaret Cullen Ballot has been issued by Margaret Wasserman
2004-08-26
08 Margaret Cullen Created "Approve" ballot
2004-08-23
08 (System) State has been changed to Waiting for Writeup from In Last Call by system
2004-08-19
08 Michelle Cotton IANA Last Call Comments:
Per the IANA Considerations section of this document, we
understand there to be NO IANA Actions.
2004-08-09
08 Amy Vezza Last call sent
2004-08-09
08 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2004-08-08
08 Margaret Cullen State Changes to Last Call Requested from AD Evaluation::AD Followup by Margaret Wasserman
2004-08-08
08 Margaret Cullen Last Call was requested by Margaret Wasserman
2004-08-08
08 (System) Ballot writeup text was added
2004-08-08
08 (System) Last call text was added
2004-08-08
08 (System) Ballot approval text was added
2004-07-26
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-07-26
07 (System) New version available: draft-holbrook-idmr-igmpv3-ssm-07.txt
2004-05-22
08 Margaret Cullen State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Margaret Wasserman
2004-05-10
08 Margaret Cullen State Changes to AD Evaluation from Publication Requested by Margaret Wasserman
2004-05-10
08 Margaret Cullen
Sent questions to authors.  Not clear whether an update will be needed.  Questions:

Hi Hugh, Brad and Brian,

I have performed my AD review of …
Sent questions to authors.  Not clear whether an update will be needed.  Questions:

Hi Hugh, Brad and Brian,

I have performed my AD review of draft-holbrook-idmr-igmpv3-ssm-06.txt.  In general, I think that this document looks pretty good.  However, I do have a few questions.

Section 2.1 says:

>On a non-SSM-aware host, an application that
>uses the wrong API (e.g., "join(G)", "IPMulticastListen(G,EXCLUDE(S1))"
...snip...
>process the request, and the application will receive no indication
>other than a failure to receive the requested traffic.

Is this a new requirement (imposed by this document) on SSM-aware routers?  What happens if the routers between the non-SSM-aware host and the source of the multicast traffic are not SSM-aware?

Also, given the number of modifications that this document makes to IGMPv3 and MLDv2, was any thought given to updating those documents, rather than publishing the modifications in this separate document?

Section 4 (Security Considerations) says:

>It is important that a router not accept non-source-specific reception
>requests for an SSM destination address.  The rules of [IGMPv3] and
...snip...
>address, thus creating a potential for an attacker to deny SSM service
>to other hosts on the same link.

This seems (to me, anyway) to be a very subtle point...  Could you explain how a router that reverts to earlier version compatibility would prevent an ICMPv3-capable host from receiving SSM service?  Is this condition specific to the modifications in this draft, or also present in the original IGMPv3/MLDv2 specifications?

Section 5 says:

>[To be removed before going to the IESG.]

But, the section has not been removed.  Do you wish to publish a new I-D to remove this section before we go to IETF Last Call?

Thanks,
Margaret
2004-04-14
08 Barbara Fuller Draft Added by Barbara Fuller
2004-02-17
06 (System) New version available: draft-holbrook-idmr-igmpv3-ssm-06.txt
2003-10-27
05 (System) New version available: draft-holbrook-idmr-igmpv3-ssm-05.txt
2003-03-05
04 (System) New version available: draft-holbrook-idmr-igmpv3-ssm-04.txt
2002-11-07
03 (System) New version available: draft-holbrook-idmr-igmpv3-ssm-03.txt
2001-11-30
02 (System) New version available: draft-holbrook-idmr-igmpv3-ssm-02.txt
2001-03-08
01 (System) New version available: draft-holbrook-idmr-igmpv3-ssm-01.txt
2000-07-14
00 (System) New version available: draft-holbrook-idmr-igmpv3-ssm-00.txt