Multicast Router Discovery
draft-ietf-magma-mrdisc-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Alex Zinin |
2005-05-16
|
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2005-05-16
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2005-05-16
|
07 | Amy Vezza | IESG has approved the document |
2005-05-16
|
07 | Amy Vezza | Closed "Approve" ballot |
2005-05-16
|
07 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2005-05-16
|
07 | (System) | New version available: draft-ietf-magma-mrdisc-07.txt |
2005-05-13
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2005-05-13
|
06 | (System) | New version available: draft-ietf-magma-mrdisc-06.txt |
2005-05-13
|
07 | Margaret Cullen | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Margaret Wasserman |
2005-05-13
|
07 | Margaret Cullen | State Changes to IESG Evaluation::AD Followup from IESG Evaluation::Revised ID Needed by Margaret Wasserman |
2005-05-13
|
07 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
2005-05-13
|
07 | Margaret Cullen | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Margaret Wasserman |
2005-05-13
|
07 | Margaret Cullen | [Note]: 'Waiting for resolution of Thomas'' discuss issues.' added by Margaret Wasserman |
2005-05-13
|
07 | Margaret Cullen | State Changes to IESG Evaluation::AD Followup from Approved-announcement to be sent by Margaret Wasserman |
2005-05-13
|
07 | Margaret Cullen | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Margaret Wasserman |
2005-04-28
|
07 | Alex Zinin | [Ballot Position Update] Position for Alex Zinin has been changed to No Objection from Discuss by Alex Zinin |
2005-04-13
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2005-04-13
|
05 | (System) | New version available: draft-ietf-magma-mrdisc-05.txt |
2005-03-08
|
07 | Margaret Cullen | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Margaret Wasserman |
2005-02-25
|
07 | Thomas Narten | [Ballot discuss] > 1. For IPv4 it is the 16-bit one's complement of the one's > complement sum of the IGMP … [Ballot discuss] > 1. For IPv4 it is the 16-bit one's complement of the one's > complement sum of the IGMP message, starting with the Type field. > For computing the checksum, the checksum field is set to 0. > Checksum does not include any IPv4 header fields. This seems like a bad design choice. Note that in the IPv6 case, the checksum does include a pseudo-header. Why not be consistent? > 1. The expiration of the periodic advertisement interval timer. > Note that it this timer is not strictly periodic since it is a > random number between MaxAdvertisementInterval and > MinAdvertisementInterval. this doesn't seem good. The spread between these values can be pretty wide, I think. What you want is an average value with some randomness to prevent syncrhonization. You don't want the value to be completely random between (say) 3 and 180 seconds. |
2005-02-25
|
07 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
2005-02-24
|
07 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2005-02-22
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2005-02-22
|
04 | (System) | New version available: draft-ietf-magma-mrdisc-04.txt |
2004-12-05
|
07 | Margaret Cullen | [Note]: 'Waiting for a new version to address discusses from Thomas, Russ and Alex.' added by Margaret Wasserman |
2004-12-05
|
07 | Margaret Cullen | Send message to the authors (cc: wg) with IESG review comments. |
2004-12-02
|
07 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2004-12-02
|
07 | Bert Wijnen | [Ballot comment] !! Missing citation for Informative reference: P016 L030: [14] Bradner, S., "Intellectual Property Rights in IETF Technology", !! Missing citation for … [Ballot comment] !! Missing citation for Informative reference: P016 L030: [14] Bradner, S., "Intellectual Property Rights in IETF Technology", !! Missing citation for Informative reference: P016 L034: [15] Daigle, L. and Internet Architecture Board, "IETF ISOC Board of QUestion: is there a MIB doc (in development) for the management variables listed in the subsections of sect 3? Section "9 Authors" may be a bit confusing with the other heading "Authors' Addresses" further down ----------- Comment from OPSDIR (Pekka) review: Nit: Although MRD messages could be sent as ICMP messages, the group management protocols were chosen since this functionality is multicast specific. |
2004-12-02
|
07 | Alex Zinin | [Ballot discuss] Rather minor DISCUSS: > 2. Protocol Overview ... > All MRD messages are sent with an IPv4 TTL or IPv6 Hop Limit … [Ballot discuss] Rather minor DISCUSS: > 2. Protocol Overview ... > All MRD messages are sent with an IPv4 TTL or IPv6 Hop Limit of 1 and > contain the Router Alert Option[4][5]. All MRD messages SHOULD be > Advertisement and Termination messages are sent to the All-Snoopers > multicast address. To what rate? Same comment for other instances of rate limiting in the doc. > 3.1.2 MinAdvertisementInterval > Does this section specify intervals for unsolicited Ads only or for solicited as well? |
2004-12-02
|
07 | Alex Zinin | [Ballot Position Update] New position, Discuss, has been recorded for Alex Zinin by Alex Zinin |
2004-12-02
|
07 | Thomas Narten | [Ballot discuss] Note: some of these are weak discusses, but I'd like to at least hear back from the WG. > 3.1.1 MaxAdertisementInterval typo Also, … [Ballot discuss] Note: some of these are weak discusses, but I'd like to at least hear back from the WG. > 3.1.1 MaxAdertisementInterval typo Also, for 3.1.1, is this for all advertisements, or just unsolicited ones? I assume just the latter... actually, the document would benefit from saying "unsolicited" everywhere advertisement is used but unsolicited is what is intended. > 3.1.5 NeighborDeadInterval > > > The NeighborDeadInterval variable is the maximum time (in seconds) > allowed to elapse (after receipt of the last valid Advertisement) > before a neighboring router is declared unreachable. This variable > is maintained per neighbor. In order for all devices to have a > consistent state, it is necessary for the MaxAdvertisementInterval to > be configured consistently in all devices on the subnet. this seems like a not-so-good requirement. Wouldn't it be better to have the advertiser indicate what interval it is using, so that everything "just works"? This is no more work on a node since they are required to keep per-neighbor state anyway. Actually, such info is available (or is it? see later comment on Query Interval Field) ... Why not just make the default be roughly 3X the advertised interval? > 1. For IPv4 it is the 16-bit one's complement of the one's > complement sum of the IGMP message, starting with the Type field. > For computing the checksum, the checksum field is set to 0. > Checksum does not include any IPv4 header fields. This seems like a bad design choice. Note that in the IPv6 case, the checksum does include a pseudo-header. Why not be consistent? > 3.2.4 Query Interval Field How is this value used? Searching for "Query Interval Field", the document doesn't seem to say... > 3.3.4 IPv4 Protocol > > > The IPv4 Protocol field is set to IGMP (2). But you don't mention the IPv6 case here. Why? > 1. The expiration of the periodic advertisement interval timer. > Note that it this timer is not strictly periodic since it is a > random number between MaxAdvertisementInterval and > MinAdvertisementInterval. this doesn't seem good. The spread between these values can be pretty wide, I think. What you want is an average value with some randomness to prevent syncrhonization. You don't want the value to be completely random between (say) 3 and 180 seconds. |
2004-12-02
|
07 | Thomas Narten | [Ballot Position Update] Position for Thomas Narten has been changed to Discuss from Undefined by Thomas Narten |
2004-12-02
|
07 | Thomas Narten | [Ballot Position Update] New position, Undefined, has been recorded for Thomas Narten by Thomas Narten |
2004-12-02
|
07 | Bill Fenner | [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner by Bill Fenner |
2004-12-02
|
07 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin |
2004-12-02
|
07 | Michelle Cotton | IANA Comments: Upon approval of this document the IANA will register the following - 3 new IGMP type values at 3 new ICMPv6 type numbers … IANA Comments: Upon approval of this document the IANA will register the following - 3 new IGMP type values at 3 new ICMPv6 type numbers at 1 new IPv4 multicast address in the link local range at 1 new IPv6 multicast address (corresponding to the v4 address) at |
2004-12-01
|
07 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2004-12-01
|
07 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen |
2004-12-01
|
07 | Bert Wijnen | [Ballot comment] !! Missing citation for Informative reference: P016 L030: [14] Bradner, S., "Intellectual Property Rights in IETF Technology", !! Missing citation for … [Ballot comment] !! Missing citation for Informative reference: P016 L030: [14] Bradner, S., "Intellectual Property Rights in IETF Technology", !! Missing citation for Informative reference: P016 L034: [15] Daigle, L. and Internet Architecture Board, "IETF ISOC Board of QUestion: is there a MIB doc (in development) for the management variables listed in the subsections of sect 3? Section "9 Authors" may be a bit confusing with the other heading "Authors' Addresses" further down |
2004-12-01
|
07 | Bert Wijnen | [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen |
2004-12-01
|
07 | Harald Alvestrand | [Ballot comment] Reviewed by Mary Barnes, Gen-ART Her review: Draft is ready for publication as Proposed Standard. |
2004-12-01
|
07 | Harald Alvestrand | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand |
2004-11-30
|
07 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman |
2004-11-30
|
07 | Russ Housley | [Ballot discuss] Section 6 says: > > Another solution which supports both IPv4 and IPv6 is to use IPSec in > Authentication … [Ballot discuss] Section 6 says: > > Another solution which supports both IPv4 and IPv6 is to use IPSec in > Authentication Header mode[11] to protect against attacks by ensuring > that messages came from a system with the proper key. When using > IPSEC, the messages sent to the All-Snoopers address should be > authenticated using AH. For keying, a symmetric signature algorithm > with a single key for routers sending Advertisements. This allows > validation that the MRD message was sent by a system with the key. > It should be noted that this does not prevent a system with the key > from forging a message and it requires the disabling of IPSec's > Replay Protection. > First, AH does not generally employ a signature algorithm. It usually employs a symmetric authentication algorithm, such as HMAC-SHA-1. Second, ESP can be used in environments where AH cannot. This text should point out that ESP with a null encryption algorithm and a symmetric authentication algorithm, such as HMAC-SHA-1, is also viable. This is important because rfc2401bis (which just completed IETF Last Call) requires implementation of ESP, but makes support for AH optional. Third, something needs to be said about the manner in which the key is put in place. It seems that manual configuration of the same key is envisioned. Finally, please change "IPSEC" to "IPsec." |
2004-11-30
|
07 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley |
2004-11-24
|
07 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-11-22
|
07 | Margaret Cullen | Telechat date was changed to 2004-12-02 from by Margaret Wasserman |
2004-11-22
|
07 | Margaret Cullen | [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman |
2004-11-22
|
07 | Margaret Cullen | Ballot has been issued by Margaret Wasserman |
2004-11-22
|
07 | Margaret Cullen | Created "Approve" ballot |
2004-11-22
|
07 | Margaret Cullen | Telechat date was changed to 2004-12-02 from by Margaret Wasserman |
2004-11-22
|
07 | Margaret Cullen | State Changes to IESG Evaluation from Waiting for Writeup by Margaret Wasserman |
2004-11-22
|
07 | Margaret Cullen | Placed on agenda for telechat - 2004-12-02 by Margaret Wasserman |
2004-11-13
|
07 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2004-10-30
|
07 | Amy Vezza | Last call sent |
2004-10-30
|
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2004-10-28
|
07 | Margaret Cullen | Last Call was requested by Margaret Wasserman |
2004-10-28
|
07 | Margaret Cullen | State Changes to Last Call Requested from AD Evaluation::AD Followup by Margaret Wasserman |
2004-10-28
|
07 | (System) | Ballot writeup text was added |
2004-10-28
|
07 | (System) | Last call text was added |
2004-10-28
|
07 | (System) | Ballot approval text was added |
2004-10-21
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-10-21
|
03 | (System) | New version available: draft-ietf-magma-mrdisc-03.txt |
2004-10-01
|
07 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
2004-10-01
|
07 | Margaret Cullen | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Margaret Wasserman |
2004-10-01
|
07 | Margaret Cullen | Sent AD Review comments to authors: Substantive Comments: This draft introduces the concept of a "Multicast Router Termination" message, but the security considerations section doesn't … Sent AD Review comments to authors: Substantive Comments: This draft introduces the concept of a "Multicast Router Termination" message, but the security considerations section doesn't include any mention of this message and how/if spoofed Multicast Router Termination messages could be used in DoS attacks. In general, I think that the Security Considerations section is somewhat inadequate. If this mechanism introduces new security concerns that don't exist with existing mechanisms, I don't think it is good enough to simply declare them out of scope. Also, I don't fully understand how the SEND work would apply here to resolve the described problems. The SEND WG is done, so you would need to describe here how SEND can be used to mitigate the identified risks. Editorial Comments: 3.1.5 NeighborDeadInterval This variable is the maximum time (in seconds) allowed to elapse before a neighbor can be declared unreachable. In order for all devices to have a consistent state, it is necessary for the MaxAdvertisementInterval to be configured consistently in all devices on the subnet. >> This is referring specifically to when you will determine that a neighboring multicast router has become unreachable, right? If so, I think that could be clearer. All Advertisements are sent as IGMP (for IPv4) or MLD (for IPv6) messages to the All-Snoopers multicast address. These messages SHOULD be rate-limited. >> You include the above text for advertisement message, but not for solicitations or termination messages. I know it is kind of obvious, but I'd consider moving this text to the overview section and changing it to say that all MRD messages are sent this way. |
2004-09-20
|
07 | Margaret Cullen | State Changes to AD Evaluation from Publication Requested by Margaret Wasserman |
2004-09-20
|
07 | Margaret Cullen | 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the … 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? YES 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes, there has been a lot of review input during the document life in IDMR as well as after it was adopted by MAGMA. The chairs have no concerns with those reviews. 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? NO 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. NO 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document is strongly supported by the WG. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. NO 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). YES 8) For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: - Technical Summary The concept of Internet Group Membership Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors. This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols. - Working Group Summary The working group strongly supports the advancement of the Multicast Router Discovery draft. - Protocol Quality There were review comments for this document during WG discussion in both IDMP and MAGMA and clarification comments during WG last call. |
2004-09-20
|
07 | Dinara Suleymanova | State Changes to Publication Requested from AD is watching by Dinara Suleymanova |
2004-09-20
|
07 | Dinara Suleymanova | Intended Status has been changed to Proposed Standard from None |
2004-09-15
|
02 | (System) | New version available: draft-ietf-magma-mrdisc-02.txt |
2004-07-20
|
01 | (System) | New version available: draft-ietf-magma-mrdisc-01.txt |
2004-05-23
|
07 | Margaret Cullen | State Changes to AD is watching from Publication Requested by Margaret Wasserman |
2004-05-23
|
07 | Margaret Cullen | Draft never was in Publication Requested. I just made a mistake when I tried to move it to AD is Watching. |
2004-05-23
|
07 | Margaret Cullen | Draft Added by Margaret Wasserman |
2004-05-23
|
07 | Margaret Cullen | [Note]: 'The MRD SSM document is blocking on this one.' added by Margaret Wasserman |
2004-02-09
|
00 | (System) | New version available: draft-ietf-magma-mrdisc-00.txt |