[pim] WGLC feedback for draft-ietf-pim-3376bis (was: Re: pim wglc for 3228bis, 3376bis and 3810bis)

[Toerless Eckert <[e-mail]>]

Dear Brian,

Thanks a lot for all this meticulous work! I've just sent another related email
to one set of possible change requests i didn't want to propose without other
peoples feedback (changing automatic fallback for older router presence).

The following feedback is marked question/nit/minor/myor/comment.
It is also numbered for easier referencing if necessary later.

1.question:

I am not sure what the current BCP is wrt. to authorship of a bis that
maintains most of the original text. Was this discussed and concluded that
there was evidence/opinion that it is BCP to remove all the original authors ?

Just wondering. I do understand it could be painful to go through the IETF
review/AUTH48 process if any of the prior author is listed and is unresponsive.

2.minor:

Should we not have a way for operators to determine which revision of
IGMP version 3 an implementation claims to be conformant to ? Something
like: Implementations of IGMP version 3 that are conforming to this
specification (as opposed to [RFC3376]) SHOULD have an operator interface
indication for this (such as a CLI show command or a YANG element).

Rest of review in inline into idnits formatted draft:

idnits 2.17.1 

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document updates RFC2236, but the
     abstract doesn't seem to mention this, which it should.

3.comment: see suggested fix below.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
     it appears to use RFC 2119 keywords. 

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).
     (Using the creation date from RFC2236, updated by this document, for
     RFC5378 checks: 1995-08-28)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

4.comment: see suggested fix below

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '1' on line 691

  -- Looks like a reference, but probably isn't: '2' on line 693

  == Missing Reference: 'N' is mentioned on line 699, but not defined

  == Missing Reference: 'M' is mentioned on line 677, but not defined

  ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305)

5.comment: I haven't tried to validate/falsify the above. Pretty sure you
can to or did this yourself.

--------------------------------------------------------------------------------


2	Network Working Group                                   B. Haberman, Ed.
3	Internet-Draft                                                   JHU APL
4	Obsoletes: 3376 (if approved)                            9 November 2023
5	Updates: 2236 (if approved)

5. comment:

rfc-index.txt says:

  Generally, only immediately succeeding and/or preceding RFCs are indicated, not
  the entire history of each related earlier or later RFC in a related series

Given how rfc3376 already updates rfc2236, this text would suggest we do not
include "updates: 2236", but given how we obsolete 3376, it seems we do must
include "updates 2236", so this seems to be correct. Just commenting here
because it took me a while to get to this conclusion, and RFC editor might ask later too.

6.minor:

I think we need to add "Updates: RFC4604". See discussion after line 192.

6	Intended status: Standards Track
7	Expires: 12 May 2024

9	             Internet Group Management Protocol, Version 3
10	                       draft-ietf-pim-3376bis-08

12	Abstract

14	   This document specifies a revised Version 3 of the Internet Group
15	   Management Protocol, IGMPv3.  IGMP is the protocol used by IPv4

7.nit:

I think this reads more correct if you s/IGMPv3/IGMP/. Because right now
it read like "third version of IGMPv3". Or alternatively some different sentence
structure:

  This document revises Version 3 of the Internet Group Management Protocol (IGMPv3),
  RFC3376, but maintains full interoperability with existing IGMPv3 deployments.

However you want to do it, i think the interoperability statement would be nice
for reconfirmation to the reader even though keeping the version number might be
a sufficient indicator for the more enlightened process fetishist.

16	   systems to report their IP multicast group memberships to neighboring
17	   multicast routers.  Version 3 of IGMP adds support for source
18	   filtering, that is, the ability for a system to report interest in
19	   receiving packets only from specific source addresses, or from all
20	   but specific source addresses, sent to a particular multicast
21	   address.  That information may be used by multicast routing protocols
22	   to avoid delivering multicast packets from specific sources to
23	   networks where there are no interested receivers.

8.nit:

Nice explanations. I would love to see a sentence like the following added to the
end.: but fully optional.

  It also enables support of Source Specific Multicast (SSM).


25	   This document obsoletes RFC 3376.

9.nit:

  This document obsoletes RFC3376 and updates RFC2276.

27	Status of This Memo

29	   This Internet-Draft is submitted in full conformance with the
30	   provisions of BCP 78 and BCP 79.

32	   Internet-Drafts are working documents of the Internet Engineering
33	   Task Force (IETF).  Note that other groups may also distribute
34	   working documents as Internet-Drafts.  The list of current Internet-
35	   Drafts is at https://datatracker.ietf.org/drafts/current/.

37	   Internet-Drafts are draft documents valid for a maximum of six months
38	   and may be updated, replaced, or obsoleted by other documents at any
39	   time.  It is inappropriate to use Internet-Drafts as reference
40	   material or to cite them other than as "work in progress."

42	   This Internet-Draft will expire on 12 May 2024.

44	Copyright Notice

46	   Copyright (c) 2023 IETF Trust and the persons identified as the
47	   document authors.  All rights reserved.

49	   This document is subject to BCP 78 and the IETF Trust's Legal
50	   Provisions Relating to IETF Documents (https://trustee.ietf.org/
51	   license-info) in effect on the date of publication of this document.
52	   Please review these documents carefully, as they describe your rights
53	   and restrictions with respect to this document.  Code Components
54	   extracted from this document must include Revised BSD License text as
55	   described in Section 4.e of the Trust Legal Provisions and are
56	   provided without warranty as described in the Revised BSD License.

10.nit:

idnits reminded us that we need to insert the appropriate disclaimer here
because rfc3376 is before 2008:

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

In XML:
   <rfc category="std" docName="draft-ietf-pim-3376bis-08" ipr="pre5378Trust200902" updates="2236" obsoletes="3376">
                                                                ^^^^^^^^^^^^^^^^^^

58	Table of Contents

60	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
61	   2.  The Service Interface for Requesting IP Multicast
62	           Reception . . . . . . . . . . . . . . . . . . . . . . . .   5
63	   3.  Multicast Reception State Maintained by Systems . . . . . . .   6
64	     3.1.  Socket State  . . . . . . . . . . . . . . . . . . . . . .   6
65	     3.2.  Interface State . . . . . . . . . . . . . . . . . . . . .   7
66	   4.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .   9
67	     4.1.  Membership Query Message  . . . . . . . . . . . . . . . .  10
68	       4.1.1.  Max Resp Code . . . . . . . . . . . . . . . . . . . .  11
69	       4.1.2.  Checksum  . . . . . . . . . . . . . . . . . . . . . .  12
70	       4.1.3.  Group Address . . . . . . . . . . . . . . . . . . . .  12
71	       4.1.4.  Flags . . . . . . . . . . . . . . . . . . . . . . . .  12
72	       4.1.5.  S Flag (Suppress Router-Side Processing)  . . . . . .  12
73	       4.1.6.  QRV (Querier's Robustness Variable) . . . . . . . . .  12
74	       4.1.7.  QQIC (Querier's Query Interval Code)  . . . . . . . .  12
75	       4.1.8.  Number of Sources (N) . . . . . . . . . . . . . . . .  13
76	       4.1.9.  Source Address [i]  . . . . . . . . . . . . . . . . .  13
77	       4.1.10. Additional Data . . . . . . . . . . . . . . . . . . .  13
78	       4.1.11. Query Variants  . . . . . . . . . . . . . . . . . . .  14
79	       4.1.12. IP Destination Addresses for Queries  . . . . . . . .  14
80	     4.2.  Version 3 Membership Report Message . . . . . . . . . . .  14
81	       4.2.1.  Reserved  . . . . . . . . . . . . . . . . . . . . . .  16
82	       4.2.2.  Checksum  . . . . . . . . . . . . . . . . . . . . . .  16
83	       4.2.3.  Flags . . . . . . . . . . . . . . . . . . . . . . . .  16
84	       4.2.4.  Number of Group Records (M) . . . . . . . . . . . . .  16
85	       4.2.5.  Group Record  . . . . . . . . . . . . . . . . . . . .  17
86	       4.2.6.  Record Type . . . . . . . . . . . . . . . . . . . . .  17
87	       4.2.7.  Aux Data Len  . . . . . . . . . . . . . . . . . . . .  17
88	       4.2.8.  Number of Sources (N) . . . . . . . . . . . . . . . .  17
89	       4.2.9.  Multicast Address . . . . . . . . . . . . . . . . . .  17
90	       4.2.10. Source Address [i]  . . . . . . . . . . . . . . . . .  17
91	       4.2.11. Auxiliary Data  . . . . . . . . . . . . . . . . . . .  17
92	       4.2.12. Additional Data . . . . . . . . . . . . . . . . . . .  18
93	       4.2.13. Group Record Types  . . . . . . . . . . . . . . . . .  18
94	       4.2.14. IP Source Addresses for Reports . . . . . . . . . . .  20
95	       4.2.15. IP Destination Addresses for Reports  . . . . . . . .  20
96	       4.2.16. Notation for Group Records  . . . . . . . . . . . . .  20
97	       4.2.17. Membership Report Size  . . . . . . . . . . . . . . .  21
98	   5.  Description of the Protocol for Group Members . . . . . . . .  21
99	     5.1.  Action on Change of Interface State . . . . . . . . . . .  22
100	     5.2.  Action on Reception of a Query  . . . . . . . . . . . . .  25
101	   6.  Description of the Protocol for Multicast Routers . . . . . .  27
102	     6.1.  Conditions for IGMP Queries . . . . . . . . . . . . . . .  28
103	     6.2.  IGMP State Maintained by Multicast Routers  . . . . . . .  29
104	       6.2.1.  Definition of Router Filter-Mode  . . . . . . . . . .  29
105	       6.2.2.  Definition of Group Timers  . . . . . . . . . . . . .  30
106	       6.2.3.  Definition of Source Timers . . . . . . . . . . . . .  31
107	     6.3.  IGMPv3 Source-Specific Forwarding Rules . . . . . . . . .  32
108	     6.4.  Action on Reception of Reports  . . . . . . . . . . . . .  33
109	       6.4.1.  Reception of Current-State Records  . . . . . . . . .  33
110	       6.4.2.  Reception of Filter-Mode-Change and Source-List-Change
111	               Records . . . . . . . . . . . . . . . . . . . . . . .  35
112	     6.5.  Switching Router Filter-Modes . . . . . . . . . . . . . .  36
113	     6.6.  Action on Reception of Queries  . . . . . . . . . . . . .  37
114	       6.6.1.  Timer Updates . . . . . . . . . . . . . . . . . . . .  37
115	       6.6.2.  Querier Election  . . . . . . . . . . . . . . . . . .  37
116	       6.6.3.  Building and Sending Specific Queries . . . . . . . .  38
117	   7.  Interoperation With Older Versions of IGMP  . . . . . . . . .  39
118	     7.1.  Query Version Distinctions  . . . . . . . . . . . . . . .  39
119	     7.2.  Group Member Behavior . . . . . . . . . . . . . . . . . .  39
120	       7.2.1.  In the Presence of Older Version Queriers . . . . . .  39
121	       7.2.2.  In the Presence of Older Version Group Members  . . .  41
122	     7.3.  Multicast Router Behavior . . . . . . . . . . . . . . . .  41
123	       7.3.1.  In the Presence of Older Version Queriers . . . . . .  41
124	       7.3.2.  In the Presence of Older Version Group Members  . . .  41
125	   8.  List of Timers, Counters and Their Default Values . . . . . .  43
126	     8.1.  Robustness Variable . . . . . . . . . . . . . . . . . . .  44
127	     8.2.  Query Interval  . . . . . . . . . . . . . . . . . . . . .  44
128	     8.3.  Query Response Interval . . . . . . . . . . . . . . . . .  44
129	     8.4.  Group Membership Interval . . . . . . . . . . . . . . . .  44
130	     8.5.  Other Querier Present Interval  . . . . . . . . . . . . .  44
131	     8.6.  Startup Query Interval  . . . . . . . . . . . . . . . . .  45
132	     8.7.  Startup Query Count . . . . . . . . . . . . . . . . . . .  45
133	     8.8.  Last Member Query Interval  . . . . . . . . . . . . . . .  45
134	     8.9.  Last Member Query Count . . . . . . . . . . . . . . . . .  45
135	     8.10. Last Member Query Time  . . . . . . . . . . . . . . . . .  45
136	     8.11. Unsolicited Report Interval . . . . . . . . . . . . . . .  45
137	     8.12. Older Version Querier Present Interval  . . . . . . . . .  46
138	     8.13. Older Host Present Interval . . . . . . . . . . . . . . .  46
139	     8.14. Configuring Timers  . . . . . . . . . . . . . . . . . . .  46
140	       8.14.1.  Robustness Variable  . . . . . . . . . . . . . . . .  46
141	       8.14.2.  Query Interval . . . . . . . . . . . . . . . . . . .  47
142	       8.14.3.  Max Response Time  . . . . . . . . . . . . . . . . .  47
143	   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  47
144	     9.1.  Query Message . . . . . . . . . . . . . . . . . . . . . .  48
145	     9.2.  Current-State Report messages . . . . . . . . . . . . . .  48
146	     9.3.  State-Change Report Messages  . . . . . . . . . . . . . .  49
147	     9.4.  9.4.  IPSEC Usage . . . . . . . . . . . . . . . . . . . .  50
148	   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  50
149	   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  51
150	   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  51
151	   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  51
152	     13.1.  Normative References . . . . . . . . . . . . . . . . . .  51
153	     13.2.  Informative References . . . . . . . . . . . . . . . . .  52
154	   Appendix A.  Design Rationale . . . . . . . . . . . . . . . . . .  52
155	     A.1.  The Need for State-Change Messages  . . . . . . . . . . .  52
156	     A.2.  Host Suppression  . . . . . . . . . . . . . . . . . . . .  53
157	     A.3.  Switching Router Filter Modes from EXCLUDE to INCLUDE . .  53
158	   Appendix B.  Summary of Changes from IGMPv2 . . . . . . . . . . .  54
159	   Appendix C.  Summary of Changes from RFC 3376 . . . . . . . . . .  54
160	   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  55

162	1.  Introduction

164	   The Internet Group Management Protocol (IGMP) is used by IPv4 systems
165	   (hosts and routers) to report their IP multicast group memberships to
166	   any neighboring multicast routers.  Note that an IP multicast router
167	   may itself be a member of one or more multicast groups, in which case
168	   it performs both the multicast router part of the protocol (to
169	   collect the membership information needed by its multicast routing
170	   protocol) and the group member part of the protocol (to inform itself
171	   and other, neighboring multicast routers of its memberships).

11.nit: i would also remove the parenthesis around the the two explanations.

173	   IGMP is also used for other IP multicast management functions, using
174	   message types other than those used for group membership reporting.
175	   This document specifies only the group membership reporting functions
176	   and messages.

178	   This document specifies Version 3 of IGMP.  Version 1, specified in
179	   [RFC1112], was the first widely-deployed version and the first
180	   version to become an Internet Standard.  Version 2, specified in
181	   [RFC2236], added support for low leave latency, that is, a reduction
182	   in the time it takes for a multicast router to learn that there are
183	   no longer any members of a particular group present on an attached
184	   network.  Version 3 adds support for source filtering, that is, the
185	   ability for a system to report interest in receiving packets only
186	   from specific source addresses, as required to support Source-
187	   Specific Multicast [RFC3569], or from all but specific source

12.minor:

s/RFC3569/RFC4607/

I think we should consider RFC3569 only further reading, but the requirements
are from RFC4607. Could even be 4604, i am not 100% sure, but 4607 sounds
better to me.

188	   addresses, sent to a particular multicast address.  Version 3 is
189	   designed to be interoperable with Versions 1 and 2.

191	   This document uses SSM-aware to refer to systems that support Source-
192	   Specific Multicast (SSM) as defined in [RFC4607].

13.minor:

Given how RFC4604 is an update to RFC3376, and given how this draft inlines
several core requirements for SSM groups, which i think are from RFC4604,
and/or hopefully do not conflict with RFC4604, i think we need to explicitly refer
to RFC4604. Suggested rewrite:

  This document uses SSM-aware to refer to systems that support Source-Specific
  Multicast (SSM) as defined in [RFC4607] for IP. In addition to the
  requirements in this document, SSM-aware systems must also support [RFC4607]
  which defines additional requirements for use of IGMPv1, IGMPv2, IGMPv3 with
  SSM.  This document inherits and updates the core requirements of [RFC4607].
  For further information on SSM refer to [RFC3569].


194	   This document obsoletes [RFC3376].

196	   The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
197	   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
198	   "OPTIONAL" in this document are to be interpreted as described in
199	   [RFC2119].

14.minor:
Use the new template text:

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in
  BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
  when, they appear in all capitals, as shown here.

201	2.  The Service Interface for Requesting IP Multicast Reception

203	   Within an IP system, there is (at least conceptually) a service
204	   interface used by upper-layer protocols or application programs to
205	   ask the IP layer to enable and disable reception of packets sent to
206	   specific IP multicast addresses.  In order to take full advantage of
207	   the capabilities of IGMPv3, a system's IP service interface must
208	   support the following operation:

210	         IPMulticastListen ( socket, interface, multicast-address,
211	                             filter-mode, source-list )

213	   where:

215	   *  "socket" is an implementation-specific parameter used to
216	      distinguish among different requesting entities (e.g., programs or
217	      processes) within the system; the socket parameter of BSD Unix
218	      system calls is a specific example.

220	   *  "interface" is a local identifier of the network interface on
221	      which reception of the specified multicast address is to be
222	      enabled or disabled.  Interfaces may be physical (e.g., an
223	      Ethernet interface) or virtual (e.g., the endpoint of a Frame
224	      Relay virtual circuit or the endpoint of an IP-in-IP "tunnel").
225	      An implementation may allow a special "unspecified" value to be
226	      passed as the interface parameter, in which case the request would
227	      apply to the "primary" or "default" interface of the system
228	      (perhaps established by system configuration).  If reception of
229	      the same multicast address is desired on more than one interface,
230	      IPMulticastListen is invoked separately for each desired
231	      interface.

233	   *  "multicast-address" is the IP multicast address, or group, to
234	      which the request pertains.  If reception of more than one
235	      multicast address on a given interface is desired,
236	      IPMulticastListen is invoked separately for each desired multicast
237	      address.

239	   *  "filter-mode" may be either INCLUDE or EXCLUDE.  In INCLUDE mode,
240	      reception of packets sent to the specified multicast address is
241	      requested only from those IP source addresses listed in the
242	      source-list parameter.  In EXCLUDE mode, reception of packets sent
243	      to the given multicast address is requested from all IP source
244	      addresses except those listed in the source-list parameter.

246	   *  "source-list" is an unordered list of zero or more IP unicast
247	      addresses from which multicast reception is desired or not
248	      desired, depending on the filter mode.  An implementation MAY
249	      impose a limit on the size of source lists, but that limit MUST
250	      NOT be less than 64 addresses per list.  When an operation causes
251	      the source list size limit to be exceeded, the service interface
252	      MUST return an error.

254	   For a given combination of socket, interface, and multicast address,
255	   only a single filter mode and source list can be in effect at any one
256	   time.  However, either the filter mode or the source list, or both,
257	   may be changed by subsequent IPMulticastListen requests that specify
258	   the same socket, interface, and multicast address.  Each subsequent
259	   request completely replaces any earlier request for the given socket,
260	   interface and multicast address.

262	   Previous versions of IGMP did not support source filters and had a
263	   simpler service interface consisting of Join and Leave operations to
264	   enable and disable reception of a given multicast address (from all
265	   sources) on a given interface.  The equivalent operations in the new
266	   service interface follow:

268	   The Join operation is equivalent to:

270	         IPMulticastListen ( socket, interface, multicast-address,
271	                             EXCLUDE, {} )

273	   and the Leave operation is equivalent to:

275	         IPMulticastListen ( socket, interface, multicast-address,
276	                             INCLUDE, {} )

278	   where {} is an empty source list.

280	   An example of an API providing the capabilities outlined in this
281	   service interface is in [RFC3678].

283	3.  Multicast Reception State Maintained by Systems

285	3.1.  Socket State

287	   For each socket on which IPMulticastListen has been invoked, the
288	   system records the desired multicast reception state for that socket.
289	   That state conceptually consists of a set of records of the form:

291	         (interface, multicast-address, filter-mode, source-list)

293	   The socket state evolves in response to each invocation of
294	   IPMulticastListen on the socket, as follows:

296	   *  If the requested filter mode is INCLUDE and the requested source
297	      list is empty, then the entry corresponding to the requested
298	      interface and multicast address is deleted if present.  If no such
299	      entry is present, the request is ignored.

301	   *  If the requested filter mode is EXCLUDE or the requested source
302	      list is non-empty, then the entry corresponding to the requested
303	      interface and multicast address, if present, is changed to contain
304	      the requested filter mode and source list.  If no such entry is
305	      present, a new entry is created, using the parameters specified in
306	      the request.

308	3.2.  Interface State

310	   In addition to the per-socket multicast reception state, a system
311	   must also maintain or compute multicast reception state for each of
312	   its interfaces.  That state conceptually consists of a set of records
313	   of the form:

315	           (multicast-address, filter-mode, source-list)

317	   At most one record per multicast-address exists for a given
318	   interface.  This per-interface state is derived from the per-socket
319	   state, but may differ from the per-socket state when different
320	   sockets have differing filter modes and/or source lists for the same
321	   multicast address and interface.  For example, suppose one
322	   application or process invokes the following operation on socket s1:

324	           IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )

326	   requesting reception on interface i of packets sent to multicast
327	   address m, only if they come from source a, b, or c.  Suppose another
328	   application or process invokes the following operation on socket s2:

330	           IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )

332	   requesting reception on the same interface i of packets sent to the
333	   same multicast address m, only if they come from sources b, c, or d.
334	   In order to satisfy the reception requirements of both sockets, it is
335	   necessary for interface i to receive packets sent to m from any one
336	   of the sources a, b, c, or d.  Thus, in this example, the reception
337	   state of interface i for multicast address m has filter mode INCLUDE
338	   and source list {a, b, c, d}.

340	   After a multicast packet has been accepted from an interface by the
341	   IP layer, its subsequent delivery to the application or process
342	   listening on a particular socket depends on the multicast reception
343	   state of that socket [and possibly also on other conditions, such as
344	   what transport-layer port the socket is bound to].  So, in the above
345	   example, if a packet arrives on interface i, destined to multicast
346	   address m, with source address a, it will be delivered on socket s1
347	   but not on socket s2.  Note that IGMP Queries and Reports are not
348	   subject to source filtering and must always be processed by hosts and
349	   routers.

351	   Filtering of packets based upon a socket's multicast reception state
352	   is a new feature of this service interface.  The previous service
353	   interface [RFC1112] described no filtering based upon multicast join
354	   state; rather, a join on a socket simply caused the host to join a
355	   group on the given interface, and packets destined for that group
356	   could be delivered to all sockets whether they had joined or not.

358	   The general rules for deriving the per-interface state from the per-
359	   socket state are as follows: For each distinct (interface, multicast-
360	   address) pair that appears in any socket state, a per- interface
361	   record is created for that multicast address on that interface.
362	   Considering all socket records containing the same (interface,
363	   multicast-address) pair,

365	   *  if any such record has a filter mode of EXCLUDE, then the filter
366	      mode of the interface record is EXCLUDE, and the source list of
367	      the interface record is the intersection of the source lists of
368	      all socket records in EXCLUDE mode, minus those source addresses
369	      that appear in any socket record in INCLUDE mode.  For example, if
370	      the socket records for multicast address m on interface i are:

372	         from socket s1: ( i, m, EXCLUDE, {a, b, c, d} )

374	         from socket s2: ( i, m, EXCLUDE, {b, c, d, e} )

376	         from socket s3: ( i, m, INCLUDE, {d, e, f} )

378	      then the corresponding interface record on interface i is:

380	         ( m, EXCLUDE, {b, c} )

382	      If a fourth socket is added, such as:

384	         from socket s4: ( i, m, EXCLUDE, {} )

386	      then the interface record becomes:

388	         ( m, EXCLUDE, {} )

390	   *  if all such records have a filter mode of INCLUDE, then the filter
391	      mode of the interface record is INCLUDE, and the source list of
392	      the interface record is the union of the source lists of all the
393	      socket records.  For example, if the socket records for multicast
394	      address m on interface i are:

396	         from socket s1: ( i, m, INCLUDE, {a, b, c} )

398	         from socket s2: ( i, m, INCLUDE, {b, c, d} )

400	         from socket s3: ( i, m, INCLUDE, {e, f} )

402	      then the corresponding interface record on interface i is:

404	         ( m, INCLUDE, {a, b, c, d, e, f} )

406	      An implementation MUST NOT use an EXCLUDE interface record to
407	      represent a group when all sockets for this group are in INCLUDE
408	      state.  If system resource limits are reached when an interface
409	      state source list is calculated, an error MUST be returned to the
410	      application which requested the operation.

412	   The above rules for deriving the interface state are (re-)evaluated
413	   whenever an IPMulticastListen invocation modifies the socket state by
414	   adding, deleting, or modifying a per-socket state record.  Note that
415	   a change of socket state does not necessarily result in a change of
416	   interface state.

418	4.  Message Formats

420	   IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol
421	   number of 2.  Every IGMP message described in this document is sent
422	   with an IP Time-to-Live of 1, IP Precedence of Internetwork Control
423	   (e.g., Type of Service 0xc0), and carries an IP Router Alert option
424	   [RFC2113] in its IP header.  IGMP message types are registered per
425	   [I-D.ietf-pim-3228bis].

427	   There are two IGMP message types of concern to the IGMPv3 protocol
428	   described in this document:

430	            +===================+=============================+
431	            | Type Number (hex) |         Message Name        |
432	            +===================+=============================+
433	            |        0x11       |       Membership Query      |
434	            +-------------------+-----------------------------+
435	            |        0x22       | Version 3 Membership Report |
436	            +-------------------+-----------------------------+

438	                 Table 1: New messages introduced by IGMP3

15.minor:

This should reflect the format of the IANA "IGMP Type Numbers" table:

     +===================+=============================+===========+
     | Type Number (hex) |         Message Name        | Reference |
     +===================+=============================+-----------+
     |        0x11       |       Membership Query      | [RFC1112] |
     +-------------------+-----------------------------+-----------+
     |        0x22       | Version 3 Membership Report | [ThisRFC] |
     +-------------------+-----------------------------+-----------+


440	   An implementation of IGMPv3 MUST also support the following three
441	   message types, for interoperation with previous versions of IGMP (see
442	   Section 7):

444	      +===================+=============================+===========+
445	      | Type Number (hex) |         Message Name        | Reference |
446	      +===================+=============================+===========+
447	      |        0x12       | Version 1 Membership Report | [RFC1112] |
448	      +-------------------+-----------------------------+-----------+
449	      |        0x16       | Version 2 Membership Report | [RFC2236] |
450	      +-------------------+-----------------------------+-----------+
451	      |        0x17       |    Version 2 Leave Group    | [RFC2236] |
452	      +-------------------+-----------------------------+-----------+

454	                       Table 2: Legacy IGMP messages

456	   Unrecognized message types MUST be silently ignored.  Other message
457	   types may be used by newer versions or extensions of IGMP, by
458	   multicast routing protocols, or for other uses.

460	   In this document, unless otherwise qualified, the capitalized words
461	   "Query" and "Report" refer to IGMP Membership Queries and IGMP
462	   Version 3 Membership Reports, respectively.

464	4.1.  Membership Query Message

466	   Membership Queries are sent by IP multicast routers to query the
467	   multicast reception state of neighboring interfaces.  Queries have
468	   the following format:

470	        0                   1                   2                   3
471	        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
472	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
473	       |  Type = 0x11  | Max Resp Code |           Checksum            |
474	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
475	       |                         Group Address                         |
476	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
477	       | Flags |S| QRV |     QQIC      |     Number of Sources (N)     |
478	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
479	       |                       Source Address [1]                      |
480	       +-                                                             -+
481	       |                       Source Address [2]                      |
482	       +-                              .                              -+
483	       .                               .                               .
484	       .                               .                               .
485	       +-                                                             -+
486	       |                       Source Address [N]                      |
487	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

489	                       Figure 1: IGMPv3 Query Message

491	4.1.1.  Max Resp Code

493	   The Max Resp Code field specifies the maximum time allowed before
494	   sending a responding report.  The actual time allowed, called the Max
495	   Resp Time, is represented in units of 1/10 second and is derived from
496	   the Max Resp Code as follows:

498	   If Max Resp Code < 128, Max Resp Time = Max Resp Code

500	   If Max Resp Code >= 128, Max Resp Code represents a floating-point
501	   value as follows:

503	          0 1 2 3 4 5 6 7
504	         +-+-+-+-+-+-+-+-+
505	         |1| exp | mant  |
506	         +-+-+-+-+-+-+-+-+

508	      Max Resp Time = (mant | 0x10) << (exp + 3)

510	                   Figure 2: Max Resp Code Representation

512	   Small values of Max Resp Time allow IGMPv3 routers to tune the "leave
513	   latency" (the time between the moment the last host leaves a group
514	   and the moment the routing protocol is notified that there are no
515	   more members).  Larger values, especially in the exponential range,
516	   allow tuning of the burstiness of IGMP traffic on a network.

518	4.1.2.  Checksum

520	   The Checksum is the 16-bit one's complement of the one's complement
521	   sum of the whole IGMP message (the entire IP payload).  For computing
522	   the checksum, the Checksum field is set to zero.  When receiving
523	   packets, the checksum MUST be verified before processing a packet
524	   [RFC1071].

526	4.1.3.  Group Address

528	   The Group Address field is set to zero when sending a General Query,
529	   and set to the IP multicast address being queried when sending a
530	   Group-Specific Query or Group-and-Source-Specific Query (see
531	   Section Section 4.1.9, below).

16.nit: duplicate "Section Section"

533	4.1.4.  Flags

535	   The Flags field is a bitstring managed by an IANA registry defined in
536	   [I-D.ietf-pim-3228bis].

17.minor: I think we need to add to that paragraph:

  Unused/undefined Flag are set to zero on transmission and ignored on receipt. 
  This specification does not specify or use any Flags.

Reasoning: neither this draft nor rfc3228 specifies the set-to-zero-ignore-on-receipt.
That is a candidte for backward compatibility issues, because rfc3367 says this.
The "not specify any flags" is somewhat reconfirming, but i think its helpful so
readers don't wonder.

Alternatively we could not write all or some of this here but in rfc3228bis, which might
suffice but would be harder to read.
   

538	4.1.5.  S Flag (Suppress Router-Side Processing)

540	   When set to one, the S Flag indicates to any receiving multicast
541	   routers that they are to suppress the normal timer updates they
542	   perform upon hearing a Query.  It does not, however, suppress the
543	   querier election or the normal "host-side" processing of a Query that
544	   a router may be required to perform as a consequence of itself being
545	   a group member.

547	4.1.6.  QRV (Querier's Robustness Variable)

549	   If non-zero, the QRV field contains the [Robustness Variable] value
550	   used by the querier, i.e., the sender of the Query.  If the querier's
551	   [Robustness Variable] exceeds 7, the maximum value of the QRV field,
552	   the QRV is set to zero.  Routers adopt the QRV value from the most
553	   recently received Query as their own [Robustness Variable] value,
554	   unless that most recently received QRV was zero, in which case the
555	   receivers use the default [Robustness Variable] value specified in
556	   section Section 8.1 or a statically configured value.

558	4.1.7.  QQIC (Querier's Query Interval Code)

560	   The Querier's Query Interval Code field specifies the [Query
561	   Interval] used by the querier.  The actual interval, called the
562	   Querier's Query Interval (QQI), is represented in units of seconds
563	   and is derived from the Querier's Query Interval Code as follows:

565	   If QQIC < 128, QQI = QQIC
566	   If QQIC >= 128, QQIC represents a floating-point value as follows:

568	          0 1 2 3 4 5 6 7
569	         +-+-+-+-+-+-+-+-+
570	         |1| exp | mant  |
571	         +-+-+-+-+-+-+-+-+

573	      QQI = (mant | 0x10) << (exp + 3)

575	                       Figure 3: QQIC Representation

577	   Multicast routers that are not the current querier adopt the QQI
578	   value from the most recently received Query as their own [Query
579	   Interval] value, unless that most recently received QQI was zero, in
580	   which case the receiving routers use the default [Query Interval]
581	   value specified in Section 8.2.

583	4.1.8.  Number of Sources (N)

585	   The Number of Sources (N) field specifies how many source addresses
586	   are present in the Query.  This number is zero in a General Query or
587	   a Group-Specific Query, and non-zero in a Group-and-Source-Specific
588	   Query.  This number is limited by the MTU of the network over which
589	   the Query is transmitted.  For example, on an Ethernet with an MTU of
590	   1500 octets, the IP header including the Router Alert option consumes
591	   24 octets, and the IGMP fields up to including the Number of Sources
592	   (N) field consume 12 octets, leaving 1464 octets for source
593	   addresses, which limits the number of source addresses to 366
594	   (1464/4).

596	4.1.9.  Source Address [i]

598	   The Source Address [i] fields are a vector of n IP unicast addresses,
599	   where n is the value in the Number of Sources (N) field.

601	4.1.10.  Additional Data

603	   If the Packet Length field in the IP header of a received Query
604	   indicates that there are additional octets of data present, beyond
605	   the fields described here, IGMPv3 implementations MUST include those
606	   octets in the computation to verify the received IGMP Checksum, but
607	   MUST otherwise ignore those additional octets.  When sending a Query,
608	   an IGMPv3 implementation MUST NOT include additional octets beyond
609	   the fields described here.

611	4.1.11.  Query Variants

613	   There are three variants of the Query message:

615	   1.  A General Query is sent by a multicast router to learn the
616	       complete multicast reception state of the neighboring interfaces
617	       (that is, the interfaces attached to the network on which the
618	       Query is transmitted).  In a General Query, both the Group
619	       Address field and the Number of Sources (N) field are zero.

621	   2.  A Group-Specific Query is sent by a multicast router to learn the
622	       reception state, with respect to a single multicast address, of
623	       the neighboring interfaces.  In a Group-Specific Query, the Group
624	       Address field contains the multicast address of interest, and the
625	       Number of Sources (N) field contains zero.

627	   3.  A Group-and-Source-Specific Query is sent by a multicast router
628	       to learn if any neighboring interface desires reception of
629	       packets sent to a specified multicast address, from any of a
630	       specified list of sources.  In a Group-and-Source-Specific Query,
631	       the Group Address field contains the multicast address of
632	       interest, and the Source Address [i] fields contain the source
633	       address(es) of interest.

635	4.1.12.  IP Destination Addresses for Queries

637	   In IGMPv3, General Queries are sent with an IP destination address of
638	   224.0.0.1, the all-systems multicast address.  Group-Specific and
639	   Group-and-Source-Specific Queries are sent with an IP destination
640	   address equal to the multicast address of interest.  However, a
641	   system MUST accept and process any Query whose IP Destination Address
642	   field contains any of the addresses (unicast or multicast) assigned
643	   to the interface on which the Query arrives.

645	4.2.  Version 3 Membership Report Message

647	   Version 3 Membership Reports are sent by IP systems to report (to
648	   neighboring routers) the current multicast reception state, or
649	   changes in the multicast reception state, of their interfaces.
650	   Reports have the following format:

652	        0                   1                   2                   3
653	        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
654	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
655	       |  Type = 0x22  |    Reserved   |           Checksum            |
656	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
657	       |             Flags             |  Number of Group Records (M)  |
658	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
659	       |                                                               |
660	       .                                                               .
661	       .                        Group Record [1]                       .
662	       .                                                               .
663	       |                                                               |
664	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
665	       |                                                               |
666	       .                                                               .
667	       .                        Group Record [2]                       .
668	       .                                                               .
669	       |                                                               |
670	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
671	       |                               .                               |
672	       .                               .                               .
673	       |                               .                               |
674	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
675	       |                                                               |
676	       .                                                               .
677	       .                        Group Record [M]                       .
678	       .                                                               .
679	       |                                                               |
680	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

682	                      Figure 4: IGMPv3 Report Message

684	   where each Group Record has the following internal format:

686	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
687	       |  Record Type  |  Aux Data Len |     Number of Sources (N)     |
688	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
689	       |                       Multicast Address                       |
690	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
691	       |                       Source Address [1]                      |
692	       +-                                                             -+
693	       |                       Source Address [2]                      |
694	       +-                                                             -+
695	       .                               .                               .
696	       .                               .                               .
697	       .                               .                               .
698	       +-                                                             -+
699	       |                       Source Address [N]                      |
700	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
701	       |                                                               |
702	       .                                                               .
703	       .                         Auxiliary Data                        .
704	       .                                                               .
705	       |                                                               |
706	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

708	                    Figure 5: IGMPv3 Report Group Record

710	4.2.1.  Reserved

712	   The Reserved field is set to zero on transmission, and ignored on
713	   reception.

715	4.2.2.  Checksum

717	   The Checksum is the 16-bit one's complement of the one's complement
718	   sum of the whole IGMP message (the entire IP payload).  For computing
719	   the checksum, the Checksum field is set to zero.  When receiving
720	   packets, the checksum MUST be verified before processing a message.

722	4.2.3.  Flags

724	   The Flags field is a bitstring managed by an IANA registry defined in
725	   [I-D.ietf-pim-3228bis].

18.minor: I think we need to add to that paragraph:

  Unused/undefined Flag are set to zero on transmission and ignored on receipt. 
  This specification does not specify or use any Flags.

same reasoning as in 4.1.4

727	4.2.4.  Number of Group Records (M)

729	   The Number of Group Records (M) field specifies how many Group
730	   Records are present in this Report.

732	4.2.5.  Group Record

734	   Each Group Record is a block of fields containing information
735	   pertaining to the sender's membership in a single multicast group on
736	   the interface from which the Report is sent.

738	4.2.6.  Record Type

740	   See section Section 4.2.13, below.

742	4.2.7.  Aux Data Len

744	   The Aux Data Len field contains the length of the Auxiliary Data
745	   field in this Group Record, in units of 32-bit words.  It may contain
746	   zero, to indicate the absence of any auxiliary data.

748	4.2.8.  Number of Sources (N)

750	   The Number of Sources (N) field specifies how many source addresses
751	   are present in this Group Record.

753	4.2.9.  Multicast Address

755	   The Multicast Address field contains the IP multicast address to
756	   which this Group Record pertains.

758	4.2.10.  Source Address [i]

760	   The Source Address [i] fields are a vector of n IP unicast addresses,
761	   where n is the value in this record's Number of Sources (N) field.

763	4.2.11.  Auxiliary Data

765	   The Auxiliary Data field, if present, contains additional information
766	   pertaining to this Group Record.  The protocol specified in this
767	   document, IGMPv3, does not define any auxiliary data.  Therefore,
768	   implementations of IGMPv3 MUST NOT include any auxiliary data (i.e.,
769	   MUST set the Aux Data Len field to zero) in any transmitted Group
770	   Record, and MUST ignore any auxiliary data present in any received
771	   Group Record.  The semantics and internal encoding of the Auxiliary
772	   Data field are to be defined by any future version or extension of
773	   IGMP that uses this field.

775	4.2.12.  Additional Data

777	   If the Packet Length field in the IP header of a received Report
778	   indicates that there are additional octets of data present, beyond
779	   the last Group Record, IGMPv3 implementations MUST include those
780	   octets in the computation to verify the received IGMP Checksum, but
781	   MUST otherwise ignore those additional octets.  When sending a
782	   Report, an IGMPv3 implementation MUST NOT include additional octets
783	   beyond the last Group Record.

785	4.2.13.  Group Record Types

787	   There are a number of different types of Group Records that may be
788	   included in a Report message:

790	   *  A Current-State Record is sent by a system in response to a Query
791	      received on an interface.  It reports the current reception state
792	      of that interface, with respect to a single multicast address.
793	      The Record Type of a Current-State Record may be one of the
794	      following two values:

796	      1 -  MODE_IS_INCLUDE - indicates that the interface has a filter
797	           mode of INCLUDE for the specified multicast address.  The
798	           Source Address [i] fields in this Group Record contain the
799	           interface's source list for the specified multicast address,
800	           if it is non-empty.

802	      2 -  MODE_IS_EXCLUDE - indicates that the interface has a filter
803	           mode of EXCLUDE for the specified multicast address.  The
804	           Source Address [i] fields in this Group Record contain the
805	           interface's source list for the specified multicast address,
806	           if it is non-empty.  An SSM-aware host SHOULD NOT send a
807	           MODE_IS_EXCLUDE record type for multicast addresses that fall
808	           within the SSM address range.

810	   *  A Filter-Mode-Change Record is sent by a system whenever a local
811	      invocation of IPMulticastListen causes a change of the filter mode
812	      (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to
813	      INCLUDE), of the interface-level state entry for a particular
814	      multicast address.  The Record is included in a Report sent from
815	      the interface on which the change occurred.  The Record Type of a
816	      Filter-Mode-Change Record may be one of the following two values:

818	      3 -  CHANGE_TO_INCLUDE_MODE - indicates that the interface has
819	           changed to INCLUDE filter mode for the specified multicast
820	           address.  The Source Address [i] fields in this Group Record
821	           contain the interface's new source list for the specified
822	           multicast address, if it is non-empty.

824	      4 -  CHANGE_TO_EXCLUDE_MODE - indicates that the interface has
825	           changed to EXCLUDE filter mode for the specified multicast
826	           address.  The Source Address [i] fields in this Group Record
827	           contain the interface's new source list for the specified
828	           multicast address, if it is non-empty.  An SSM-aware host
829	           SHOULD NOT send a CHANGE_TO_EXCLUDE_MODE record type for
830	           multicast addresses that fall within the SSM address range.

832	   *  A Source-List-Change Record is sent by a system whenever a local
833	      invocation of IPMulticastListen causes a change of source list
834	      that is not coincident with a change of filter mode, of the
835	      interface-level state entry for a particular multicast address.
836	      The Record is included in a Report sent from the interface on
837	      which the change occurred.  The Record Type of a Source-List-
838	      Change Record may be one of the following two values:

840	      5 -  ALLOW_NEW_SOURCES - indicates that the Source Address [i]
841	           fields in this Group Record contain a list of the additional
842	           sources that the system wishes to hear from, for packets sent
843	           to the specified multicast address.  If the change was to an
844	           INCLUDE source list, these are the addresses that were added
845	           to the list; if the change was to an EXCLUDE source list,
846	           these are the addresses that were deleted from the list.

848	      6 -  BLOCK_OLD_SOURCES - indicates that the Source Address [i]
849	           fields in this Group Record contain a list of the sources
850	           that the system no longer wishes to hear from, for packets
851	           sent to the specified multicast address.  If the change was
852	           to an INCLUDE source list, these are the addresses that were
853	           deleted from the list; if the change was to an EXCLUDE source
854	           list, these are the addresses that were added to the list.

856	   If a change of source list results in both allowing new sources and
857	   blocking old sources, then two Group Records are sent for the same
858	   multicast address, one of type ALLOW_NEW_SOURCES and one of type
859	   BLOCK_OLD_SOURCES.

861	   We use the term State-Change Record to refer to either a Filter-
862	   Mode-Change Record or a Source-List-Change Record.

864	   Unrecognized Record Type values MUST be silently ignored.

866	4.2.14.  IP Source Addresses for Reports

868	   An IGMP report is sent with a valid IP source address for the
869	   destination subnet.  The 0.0.0.0 source address may be used by a
870	   system that has not yet acquired an IP address.  Note that the
871	   0.0.0.0 source address may simultaneously be used by multiple systems
872	   on a LAN.  Routers MUST accept a report with a source address of
873	   0.0.0.0.

875	4.2.15.  IP Destination Addresses for Reports

877	   Version 3 Reports are sent with an IP destination address of
878	   224.0.0.22, to which all IGMPv3-capable multicast routers listen.  A
879	   system that is operating in version 1 or version 2 compatibility
880	   modes sends version 1 or version 2 Reports to the multicast group
881	   specified in the Group Address field of the Report.  In addition, a
882	   system MUST accept and process any version 1 or version 2 Report
883	   whose IP Destination Address field contains any of the addresses
884	   (unicast or multicast) assigned to the interface on which the Report
885	   arrives.

887	4.2.16.  Notation for Group Records

889	   In the rest of this document, we use the following notation to
890	   describe the contents of a Group Record pertaining to a particular
891	   multicast address:

893	         IS_IN ( x )  -  Type MODE_IS_INCLUDE, source addresses x
894	         IS_EX ( x )  -  Type MODE_IS_EXCLUDE, source addresses x
895	         TO_IN ( x )  -  Type CHANGE_TO_INCLUDE_MODE, source addresses x
896	         TO_EX ( x )  -  Type CHANGE_TO_EXCLUDE_MODE, source addresses x
897	         ALLOW ( x )  -  Type ALLOW_NEW_SOURCES, source addresses x
898	         BLOCK ( x )  -  Type BLOCK_OLD_SOURCES, source addresses x

900	   where x is either:

902	   *  a capital letter (e.g., "A") to represent the set of source
903	      addresses, or

905	   *  a set expression (e.g., "A+B"), where "A+B" means the union of
906	      sets A and B, "A*B" means the intersection of sets A and B, and
907	      "A-B" means the removal of all elements of set B from set A.

909	4.2.17.  Membership Report Size

911	   If the set of Group Records required in a Report does not fit within
912	   the size limit of a single Report message (as determined by the MTU
913	   of the network on which it will be sent), the Group Records are sent
914	   in as many Report messages as needed to report the entire set.

916	   If a single Group Record contains so many source addresses that it
917	   does not fit within the size limit of a single Report message, if its
918	   Type is not MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, it is split
919	   into multiple Group Records, each containing a different subset of
920	   the source addresses and each sent in a separate Report message.  If
921	   its Type is MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, a single Group
922	   Record is sent, containing as many source addresses as can fit, and

924	   the remaining source addresses are not reported; though the choice of
925	   which sources to report is arbitrary, it is preferable to report the
926	   same set of sources in each subsequent report, rather than reporting
927	   different sources each time.

929	5.  Description of the Protocol for Group Members

931	   IGMP is an asymmetric protocol, specifying separate behaviors for
932	   group members -- that is, hosts or routers that wish to receive
933	   multicast packets -- and multicast routers.  This section describes
934	   the part of IGMPv3 that applies to all group members.  (Note that a
935	   multicast router that is also a group member performs both parts of
936	   IGMPv3, receiving and responding to its own IGMP message
937	   transmissions as well as those of its neighbors.  The multicast
938	   router part of IGMPv3 is described in Section 6.)

940	   A system performs the protocol described in this section over all
941	   interfaces on which multicast reception is supported, even if more
942	   than one of those interfaces is connected to the same network.

944	   For interoperability with multicast routers running older versions of
945	   IGMP, systems maintain a MulticastRouterVersion variable for each
946	   interface on which multicast reception is supported.  This section
947	   describes the behavior of group member systems on interfaces for
948	   which MulticastRouterVersion = 3.  The algorithm for determining
949	   MulticastRouterVersion, and the behavior for versions other than 3,
950	   are described in Section 7.

952	   The all-systems multicast address, 224.0.0.1, is handled as a special
953	   case.  On all systems -- that is all hosts and routers, including
954	   multicast routers -- reception of packets destined to the all-systems
955	   multicast address, from all sources, is permanently enabled on all
956	   interfaces on which multicast reception is supported.  No IGMP
957	   messages are ever sent regarding the all-systems multicast address.

959	   There are two types of events that trigger IGMPv3 protocol actions on
960	   an interface:

962	   *  a change of the interface reception state, caused by a local
963	      invocation of IPMulticastListen.

965	   *  reception of a Query.

967	   (Received IGMP messages of types other than Query are silently
968	   ignored, except as required for interoperation with earlier versions
969	   of IGMP.)

971	   The following subsections describe the actions to be taken for each
972	   of these two cases.  In those descriptions, timer and counter names
973	   appear in square brackets.  The default values for those timers and
974	   counters are specified in Section 8.

976	5.1.  Action on Change of Interface State

978	   An invocation of IPMulticastListen may cause the multicast reception
979	   state of an interface to change, according to the rules in
980	   Section Section 3.2.  Each such change affects the per-interface
981	   entry for a single multicast address.

983	   A change of interface state causes the system to immediately transmit
984	   a State-Change Report from that interface.  The type and contents of
985	   the Group Record(s) in that Report are determined by comparing the
986	   filter mode and source list for the affected multicast address before
987	   and after the change, according to the table below.  If no interface
988	   state existed for that multicast address before the change (i.e., the
989	   change consisted of creating a new per-interface record), or if no
990	   state exists after the change (i.e., the change consisted of deleting
991	   a per-interface record), then the "non-existent" state is considered
992	   to have a filter mode of INCLUDE and an empty source list.

994	         +=============+=============+==========================+
995	         |  Old State  |  New State  | State-Change Record Sent |
996	         +=============+=============+==========================+
997	         | INCLUDE (A) | INCLUDE (B) | ALLOW (B-A), BLOCK (A-B) |
998	         +-------------+-------------+--------------------------+
999	         | EXCLUDE (A) | EXCLUDE (B) | ALLOW (A-B), BLOCK (B-A) |
1000	         +-------------+-------------+--------------------------+
1001	         | INCLUDE (A) | EXCLUDE (B) |        TO_EX (B)         |
1002	         +-------------+-------------+--------------------------+
1003	         | EXCLUDE (A) | INCLUDE (B) |        TO_IN (B)         |
1004	         +-------------+-------------+--------------------------+

1006	                                 Table 3

1008	   If the computed source list for either an ALLOW or a BLOCK State-
1009	   Change Record is empty, that record is omitted from the Report
1010	   message.

1012	   To cover the possibility of the State-Change Report being missed by
1013	   one or more multicast routers, it is retransmitted [Robustness
1014	   Variable] - 1 more times, at intervals chosen at random from the
1015	   range (0, [Unsolicited Report Interval]).

1017	   If more changes to the same interface state entry occur before all
1018	   the retransmissions of the State-Change Report for the first change
1019	   have been completed, each such additional change triggers the
1020	   immediate transmission of a new State-Change Report.

1022	   The contents of the new transmitted report are calculated as follows.
1023	   As was done with the first report, the interface state for the
1024	   affected group before and after the latest change is compared.  The
1025	   report records expressing the difference are built according to the
1026	   table above.  However these records are not transmitted in a message
1027	   but instead merged with the contents of the pending report, to create
1028	   the new State-Change report.  The rules for merging the difference
1029	   report resulting from the state change and the pending report are
1030	   described below.

1032	   The transmission of the merged State-Change Report terminates
1033	   retransmissions of the earlier State-Change Reports for the same
1034	   multicast address, and becomes the first of [Robustness Variable]
1035	   transmissions of State-Change Reports.

1037	   Each time a source is included in the difference report calculated
1038	   above, retransmission state for that source needs to be maintained
1039	   until [Robustness Variable] State-Change reports have been sent by
1040	   the host.  This is done in order to ensure that a series of
1041	   successive state changes do not break the protocol robustness.

1043	   If the interface reception-state change that triggers the new report
1044	   is a filter-mode change, then the next [Robustness Variable] State-
1045	   Change Reports will include a Filter-Mode-Change record.  This
1046	   applies even if any number of source-list changes occur in that
1047	   period.  The host has to maintain retransmission state for the group
1048	   until the [Robustness Variable] State-Change reports have been sent.
1049	   When [Robustness Variable] State-Change reports with Filter-Mode-
1050	   Change records have been transmitted after the last filter-mode
1051	   change, and if source-list changes to the interface reception have
1052	   scheduled additional reports, then the next State-Change report will
1053	   include Source-List-Change records.

1055	   Each time a State-Change Report is transmitted, the contents are
1056	   determined as follows.  If the report should contain a Filter-Mode-
1057	   Change record, then if the current filter-mode of the interface is
1058	   INCLUDE, a TO_IN record is included in the report, otherwise a TO_EX
1059	   record is included.  If instead the report should contain Source-
1060	   List-Change records, an ALLOW and a BLOCK record are included.  The
1061	   contents of these records are built according to the table below.

1063	                 +========+==============================+
1064	                 | Record |       Sources Included       |
1065	                 +========+==============================+
1066	                 | TO_IN  | All in the current interface |
1067	                 |        | state that must be forwarded |
1068	                 +--------+------------------------------+
1069	                 | TO_EX  | All in the current interface |
1070	                 |        |  state that must be blocked  |
1071	                 +--------+------------------------------+
1072	                 | ALLOW  |   All with retransmission    |
1073	                 |        | state that must be forwarded |
1074	                 +--------+------------------------------+
1075	                 | BLOCK  |   All with retransmission    |
1076	                 |        |  state that must be blocked  |
1077	                 +--------+------------------------------+

1079	                                  Table 4

1081	   If the computed source list for either an ALLOW or a BLOCK record is
1082	   empty, that record is omitted from the State-Change report.

1084	   Note: When the first State-Change report is sent, the non-existent
1085	   pending report to merge with, can be treated as a source-change
1086	   report with empty ALLOW and BLOCK records (no sources have
1087	   retransmission state).

1089	5.2.  Action on Reception of a Query

1091	   When a system receives a Query, it does not respond immediately.
1092	   Instead, it delays its response by a random amount of time, bounded
1093	   by the Max Resp Time value derived from the Max Resp Code in the
1094	   received Query message.  A system may receive a variety of Queries on
1095	   different interfaces and of different kinds (e.g., General Queries,
1096	   Group-Specific Queries, and Group-and-Source-Specific Queries), each
1097	   of which may require its own delayed response.

1099	   Before scheduling a response to a Query, the system must first
1100	   consider previously scheduled pending responses and in many cases
1101	   schedule a combined response.  Therefore, the system must be able to
1102	   maintain the following state:

1104	   *  A timer per interface for scheduling responses to General Queries.

1106	   *  A per-group and interface timer for scheduling responses to Group-
1107	      Specific and Group-and-Source-Specific Queries.

1109	   *  A per-group and interface list of sources to be reported in the
1110	      response to a Group-and-Source-Specific Query.

1112	   When a new Query with the Router-Alert option arrives on an
1113	   interface, provided the system has state to report, a delay for a
1114	   response is randomly selected in the range (0, [Max Resp Time]) where
1115	   Max Resp Time is derived from Max Resp Code in the received Query
1116	   message.  The following rules are then used to determine if a Report
1117	   needs to be scheduled and the type of Report to schedule.  The rules
1118	   are considered in order and only the first matching rule is applied.

1120	   1.  If there is a pending response to a previous General Query
1121	       scheduled sooner than the selected delay, no additional response
1122	       needs to be scheduled.

1124	   2.  If the received Query is a General Query, the interface timer is
1125	       used to schedule a response to the General Query after the
1126	       selected delay.  Any previously pending response to a General
1127	       Query is canceled.

1129	   3.  If the received Query is a Group-Specific Query or a Group-and-
1130	       Source-Specific Query and there is no pending response to a
1131	       previous Query for this group, then the group timer is used to
1132	       schedule a report.  If the received Query is a Group-and-Source-
1133	       Specific Query, the list of queried sources is recorded to be
1134	       used when generating a response.

1136	   4.  If there already is a pending response to a previous Query
1137	       scheduled for this group, and either the new Query is a Group-
1138	       Specific Query or the recorded source-list associated with the
1139	       group is empty, then the group source-list is cleared and a
1140	       single response is scheduled using the group timer.  The new
1141	       response is scheduled to be sent at the earliest of the remaining
1142	       time for the pending report and the selected delay.

1144	   5.  If the received Query is a Group-and-Source-Specific Query and
1145	       there is a pending response for this group with a non-empty
1146	       source-list, then the group source list is augmented to contain
1147	       the list of sources in the new Query and a single response is
1148	       scheduled using the group timer.  The new response is scheduled
1149	       to be sent at the earliest of the remaining time for the pending
1150	       report and the selected delay.

1152	   When the timer in a pending response record expires, the system
1153	   transmits, on the associated interface, one or more Report messages
1154	   carrying one or more Current-State Records (see section
1155	   Section 4.2.13), as follows:

1157	   1.  If the expired timer is the interface timer (i.e., it is a
1158	       pending response to a General Query), then one Current-State
1159	       Record is sent for each multicast address for which the specified
1160	       interface has reception state, as described in Section 3.2.  The
1161	       Current- State Record carries the multicast address and its
1162	       associated filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and
1163	       source list.  Multiple Current-State Records are packed into
1164	       individual Report messages, to the extent possible.

1166	       This naive algorithm may result in bursts of packets when a
1167	       system is a member of a large number of groups.  Instead of using
1168	       a single interface timer, implementations are recommended to
1169	       spread transmission of such Report messages over the interval (0,
1170	       [Max Resp Time]).  Note that any such implementation MUST avoid
1171	       the "ack-implosion" problem, i.e., MUST NOT send a Report
1172	       immediately on reception of a General Query.

1174	   2.  If the expired timer is a group timer and the list of recorded
1175	       sources for the that group is empty (i.e., it is a pending
1176	       response to a Group-Specific Query), then if and only if the
1177	       interface has reception state for that group address, a single
1178	       Current-State Record is sent for that address.  The Current-State
1179	       Record carries the multicast address and its associated filter
1180	       mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and source list.

1182	   3.  If the expired timer is a group timer and the list of recorded
1183	       sources for that group is non-empty (i.e., it is a pending
1184	       response to a Group-and-Source-Specific Query), then if and only
1185	       if the interface has reception state for that group address, the
1186	       contents of the responding Current-State Record is determined
1187	       from the interface state and the pending response record, as
1188	       specified in the following table:

1190	     +=====================+=========================+===============+
1191	     | Per-Interface State |  Set of Sources in the  | Current-State |
1192	     |                     | Pending Response Record |     Record    |
1193	     +=====================+=========================+===============+
1194	     |     INCLUDE (A)     |            B            |  IS_IN (A*B)  |
1195	     +---------------------+-------------------------+---------------+
1196	     |     EXCLUDE (A)     |            B            |  IS_IN (B-A)  |
1197	     +---------------------+-------------------------+---------------+

1199	                                  Table 5

1201	   If the resulting Current-State Record has an empty set of source
1202	   addresses, then no response is sent.

1204	   Finally, after any required Report messages have been generated, the
1205	   source lists associated with any reported groups are cleared.

1207	6.  Description of the Protocol for Multicast Routers

1209	   The purpose of IGMP is to enable each multicast router to learn, for
1210	   each of its directly attached networks, which multicast addresses are
1211	   of interest to the systems attached to those networks.  IGMP version
1212	   3 adds the capability for a multicast router to also learn which
1213	   sources are of interest to neighboring systems, for packets sent to
1214	   any particular multicast address.  The information gathered by IGMP
1215	   is provided to whichever multicast routing protocol is being used by
1216	   the router, in order to ensure that multicast packets are delivered
1217	   to all networks where there are interested receivers.

1219	   This section describes the part of IGMPv3 that is performed by
1220	   multicast routers.  Multicast routers may also themselves become
1221	   members of multicast groups, and therefore also perform the group
1222	   member part of IGMPv3, described in Section 5.

1224	   A multicast router performs the protocol described in this section
1225	   over each of its directly-attached networks.  If a multicast router
1226	   has more than one interface to the same network, it only needs to
1227	   operate this protocol over one of those interfaces.  On each
1228	   interface over which this protocol is being run, the router MUST
1229	   enable reception of multicast address 224.0.0.22, from all sources
1230	   (and MUST perform the group member part of IGMPv3 for that address on
1231	   that interface).

1233	   Multicast routers need to know only that at least one system on an
1234	   attached network is interested in packets to a particular multicast
1235	   address from a particular source; a multicast router is not required
1236	   to keep track of the interests of each individual neighboring system.
1237	   (However, see Appendix A.2 point 1 for discussion.)

1239	   IGMPv3 is backward compatible with previous versions of the IGMP
1240	   protocol.  In order to remain backward compatible with older IGMP
1241	   systems, IGMPv3 multicast routers MUST also implement versions 1 and
1242	   2 of the protocol (see section Section 7).

1244	6.1.  Conditions for IGMP Queries

1246	   Multicast routers send General Queries periodically to request group
1247	   membership information from an attached network.  These queries are
1248	   used to build and refresh the group membership state of systems on
1249	   attached networks.  Systems respond to these queries by reporting
1250	   their group membership state (and their desired set of sources) with
1251	   Current-State Group Records in IGMPv3 Membership Reports.

1253	   As a member of a multicast group, a system may express interest in
1254	   receiving or not receiving traffic from particular sources.  As the
1255	   desired reception state of a system changes, it reports these changes
1256	   using Filter-Mode-Change Records or Source-List-Change Records.
1257	   These records indicate an explicit state change in a group at a
1258	   system in either the group record's source list or its filter-mode.
1259	   When a group membership is terminated at a system or traffic from a
1260	   particular source is no longer desired, a multicast router must query
1261	   for other members of the group or listeners of the source before
1262	   deleting the group (or source) and pruning its traffic.

1264	   To enable all systems on a network to respond to changes in group
1265	   membership, multicast routers send specific queries.  A Group-
1266	   Specific Query is sent to verify there are no systems that desire
1267	   reception of the specified group or to "rebuild" the desired
1268	   reception state for a particular group.  Group-Specific Queries are
1269	   sent when a router receives a State-Change record indicating a system
1270	   is leaving a group.

1272	   A Group-and-Source Specific Query is used to verify there are no
1273	   systems on a network which desire to receive traffic from a set of
1274	   sources.  Group-and-Source Specific Queries list sources for a
1275	   particular group which have been requested to no longer be forwarded.
1276	   This query is sent by a multicast router to learn if any systems
1277	   desire reception of packets to the specified group address from the
1278	   specified source addresses.  Group-and-Source Specific Queries are
1279	   only sent in response to State-Change Records and never in response
1280	   to Current-State Records.  Section 4.1.11 describes each query in
1281	   more detail.

1283	6.2.  IGMP State Maintained by Multicast Routers

1285	   Multicast routers implementing IGMPv3 keep state per group per
1286	   attached network.  This group state consists of a filter-mode, a list
1287	   of sources, and various timers.  For each attached network running
1288	   IGMP, a multicast router records the desired reception state for that
1289	   network.  That state conceptually consists of a set of records of the
1290	   form:

1292	         (multicast address, group timer, filter-mode, (source records))

1294	   Each source record is of the form:

1296	         (source address, source timer)

1298	   If all sources within a given group are desired, an empty source
1299	   record list is kept with filter-mode set to EXCLUDE.  This means
1300	   hosts on this network want all sources for this group to be
1301	   forwarded.  This is the IGMPv3 equivalent to a IGMPv1 or IGMPv2 group
1302	   join.

1304	6.2.1.  Definition of Router Filter-Mode

1306	   To reduce internal state, IGMPv3 routers keep a filter-mode per group
1307	   per attached network.  This filter-mode is used to condense the total
1308	   desired reception state of a group to a minimum set such that all
1309	   systems' memberships are satisfied.  This filter-mode may change in
1310	   response to the reception of particular types of group records or
1311	   when certain timer conditions occur.  In the following sections, we
1312	   use the term "router filter-mode" to refer to the filter-mode of a
1313	   particular group within a router.  Section 6.4 describes the changes
1314	   of a router filter-mode per group record received.

1316	   Conceptually, when a group record is received, the router filter-mode
1317	   for that group is updated to cover all the requested sources using
1318	   the least amount of state.  As a rule, once a group record with a
1319	   filter-mode of EXCLUDE is received, the router filter-mode for that
1320	   group will be EXCLUDE.

1322	   When a router filter-mode for a group is EXCLUDE, the source record
1323	   list contains two types of sources.  The first type is the set which
1324	   represents conflicts in the desired reception state; this set must be
1325	   forwarded by some router on the network.  The second type is the set
1326	   of sources which hosts have requested to not be forwarded.
1327	   Appendix A describes the reasons for keeping two different sets when
1328	   in EXCLUDE mode.

1330	   When a router filter-mode for a group is INCLUDE, the source record
1331	   list is the list of sources desired for the group.  This is the total
1332	   desired set of sources for that group.  Each source in the source
1333	   record list must be forwarded by some router on the network.

1335	   Because a reported group record with a filter-mode of EXCLUDE will
1336	   cause a router to transition its filter-mode for that group to
1337	   EXCLUDE, a mechanism for transitioning a router's filter-mode back to
1338	   INCLUDE must exist.  If all systems with a group record in EXCLUDE
1339	   filter-mode cease reporting, it is desirable for the router filter-
1340	   mode for that group to transition back to INCLUDE mode.  This
1341	   transition occurs when the group timer expires and is explained in
1342	   detail in Section 6.5.

1344	6.2.2.  Definition of Group Timers

1346	   The group timer is only used when a group is in EXCLUDE mode and it
1347	   represents the time for the filter-mode of the group to expire and
1348	   switch to INCLUDE mode.  We define a group timer as a decrementing
1349	   timer with a lower bound of zero kept per group per attached network.
1350	   Group timers are updated according to the types of group records
1351	   received.

1353	   A group timer expiring when a router filter-mode for the group is
1354	   EXCLUDE means there are no listeners on the attached network in
1355	   EXCLUDE mode.  At this point, a router will transition to INCLUDE
1356	   filter-mode.  Section 6.5 describes the actions taken when a group
1357	   timer expires while in EXCLUDE mode.

1359	   The following table summarizes the role of the group timer.
1360	   Section Section 6.4 describes the details of setting the group timer
1361	   per type of group record received.

1363	     +=============+=======+========================================+
1364	     |    Group    | Group |            Actions/Comments            |
1365	     | Filter-Mode | Timer |                                        |
1366	     |             | Value |                                        |
1367	     +=============+=======+========================================+
1368	     |   INCLUDE   | Timer |      All members in INCLUDE mode.      |
1369	     |             |  >= 0 |                                        |
1370	     +-------------+-------+----------------------------------------+
1371	     |   EXCLUDE   | Timer |  At least one member in EXCLUDE mode.  |
1372	     |             |  > 0  |                                        |
1373	     +-------------+-------+----------------------------------------+
1374	     |   EXCLUDE   | Timer |  No more listeners to group.  If all   |
1375	     |             |  == 0 | source timers have expired then delete |
1376	     |             |       |   Group Record.  If there are still    |
1377	     |             |       |  source record timers running, switch  |
1378	     |             |       |   to INCLUDE filter-mode using those   |
1379	     |             |       | source records with running timers as  |
1380	     |             |       |    the INCLUDE source record state.    |
1381	     +-------------+-------+----------------------------------------+

1383	                                 Table 6

1385	6.2.3.  Definition of Source Timers

1387	   A source timer is kept per source record and is a decrementing timer
1388	   with a lower bound of zero.  Source timers are updated according to
1389	   the type and filter-mode of the group record received.  Source timers
1390	   are always updated (for a particular group) whenever the source is
1391	   present in a received record for that group.  Section 6.4 describes
1392	   the setting of source timers per type of group records received.

1394	   A source record with a running timer with a router filter-mode for
1395	   the group of INCLUDE means that there is currently one or more
1396	   systems (in INCLUDE filter-mode) which desire to receive that source.
1397	   If a source timer expires with a router filter-mode for the group of
1398	   INCLUDE, the router concludes that traffic from this particular
1399	   source is no longer desired on the attached network, and deletes the
1400	   associated source record.

1402	   Source timers are treated differently when a router filter-mode for a
1403	   group is EXCLUDE.  If a source record has a running timer with a
1404	   router filter-mode for the group of EXCLUDE, it means that at least
1405	   one system desires the source.  It should therefore be forwarded by a
1406	   router on the network.  Appendix A describes the reasons for keeping
1407	   state for sources that have been requested to be forwarded while in
1408	   EXCLUDE state.

1410	   If a source timer expires with a router filter-mode for the group of
1411	   EXCLUDE, the router informs the routing protocol that there is no
1412	   longer a receiver on the network interested in traffic from this
1413	   source.

1415	   When a router filter-mode for a group is EXCLUDE, source records are
1416	   only deleted when the group timer expires.  Section 6.3 describes the
1417	   actions that should be taken dependent upon the value of a source
1418	   timer.

1420	6.3.  IGMPv3 Source-Specific Forwarding Rules

1422	   When a multicast router receives a datagram from a source destined to
1423	   a particular group, a decision has to be made whether to forward the
1424	   datagram onto an attached network or not.  The multicast routing
1425	   protocol in use is in charge of this decision, and should use the
1426	   IGMPv3 information to ensure that all sources/groups desired on a
1427	   subnetwork are forwarded to that subnetwork.  IGMPv3 information does
1428	   not override multicast routing information; for example, if the
1429	   IGMPv3 filter-mode group for G is EXCLUDE, a router may still forward
1430	   packets for excluded sources to a transit subnet.

1432	   To summarize, the following table describes the forwarding
1433	   suggestions made by IGMP to the routing protocol for traffic
1434	   originating from a source destined to a group.  It also summarizes
1435	   the actions taken upon the expiration of a source timer based on the
1436	   router filter-mode of the group.

1438	    +=============+==========+=======================================+
1439	    |    Group    |  Group   |                 Action                |
1440	    | Filter-Mode |  Timer   |                                       |
1441	    |             |  Value   |                                       |
1442	    +=============+==========+=======================================+
1443	    |   INCLUDE   | TIMER >  |    Suggest to forward traffic from    |
1444	    |             |    0     |                 source                |
1445	    +-------------+----------+---------------------------------------+
1446	    |   INCLUDE   | TIMER == |   Suggest to stop forwarding traffic  |
1447	    |             |    0     | from source and remove source record. |
1448	    |             |          |  If there are no more source records  |
1449	    |             |          |  for the group, delete group record.  |
1450	    +-------------+----------+---------------------------------------+
1451	    |   INCLUDE   |    No    |     Suggest to not forward source     |
1452	    |             |  Source  |                                       |
1453	    |             | Elements |                                       |
1454	    +-------------+----------+---------------------------------------+
1455	    |   EXCLUDE   | TIMER >  |    Suggest to forward traffic from    |
1456	    |             |    0     |                 source                |
1457	    +-------------+----------+---------------------------------------+
1458	    |   EXCLUDE   | TIMER == |  Suggest to not forward traffic from  |
1459	    |             |    0     |     source (DO NOT remove record)     |
1460	    +-------------+----------+---------------------------------------+
1461	    |   EXCLUDE   |    No    |    Suggest to forward traffic from    |
1462	    |             |  Source  |                 source                |
1463	    |             | Elements |                                       |
1464	    +-------------+----------+---------------------------------------+

1466	                                 Table 7

1468	6.4.  Action on Reception of Reports

1470	   SSM-aware routers SHOULD ignore records that contain multicast
1471	   addresses in the SSM address range if the record type is
1472	   MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE.  SSM-aware routers SHOULD
1473	   ignore IGMPv1/IGMPv2 Report and IGMPv2 DONE messages that contain
1474	   multicast addresses in the SSM address range, SHOULD NOT use such
1475	   Reports to establish IP forwarding state, and MAY log an error if it
1476	   receives such a message.

1478	6.4.1.  Reception of Current-State Records

1480	   When receiving Current-State Records, a router updates both its group
1481	   and source timers.  In some circumstances, the reception of a type of
1482	   group record will cause the router filter-mode for that group to
1483	   change.  The table below describes the actions, with respect to state
1484	   and timers that occur to a router's state upon reception of Current-
1485	   State Records.

1487	   The following notation is used to describe the updating of source
1488	   timers.  The notation ( A, B ) will be used to represent the total
1489	   number of sources for a particular group, where

1491	    A = set of source records whose source timers > 0 (Sources that at
1492	        least one host has requested to be forwarded)
1493	    B = set of source records whose source timers = 0 (Sources that IGMP
1494	        will suggest to the routing protocol not to forward)

1496	   Note that there will only be two sets when a router's filter-mode for
1497	   a group is EXCLUDE.  When a router's filter-mode for a group is
1498	   INCLUDE, a single set is used to describe the set of sources
1499	   requested to be forwarded (e.g., simply (A)).

1501	   In the following tables, abbreviations are used for several variables
1502	   (all of which are described in detail in Section 8).  The variable
1503	   GMI is an abbreviation for the Group Membership Interval, which is
1504	   the time in which group memberships will time out.  The variable LMQT
1505	   is an abbreviation for the Last Member Query Time, which is the total
1506	   time spent after Last Member Query Count retransmissions.  LMQT
1507	   represents the "leave latency", or the difference between the
1508	   transmission of a membership change and the change in the information
1509	   given to the routing protocol.

1511	   Within the "Actions" section of the router state tables, we use the
1512	   notation 'A=J', which means that the set A of source records should
1513	   have their source timers set to value J.  'Delete A' means that the
1514	   set A of source records should be deleted.  'Group Timer=J' means
1515	   that the Group Timer for the group should be set to value J.

1517	   Router State   Report Rec'd  New Router State         Actions
1518	   ------------   ------------  ----------------         -------

1520	   INCLUDE (A)    IS_IN (B)     INCLUDE (A+B)            (B)=GMI

1522	   INCLUDE (A)    IS_EX (B)     EXCLUDE (A*B,B-A)        (B-A)=0
1523	                                                         Delete (A-B)
1524	                                                         Group Timer=GMI

1526	   EXCLUDE (X,Y)  IS_IN (A)     EXCLUDE (X+A,Y-A)        (A)=GMI

1528	   EXCLUDE (X,Y)  IS_EX (A)     EXCLUDE (A-Y,Y*A)        (A-X-Y)=GMI
1529	                                                         Delete (X-A)
1530	                                                         Delete (Y-A)
1531	                                                         Group Timer=GMI

1533	6.4.2.  Reception of Filter-Mode-Change and Source-List-Change Records

1535	   When a change in the global state of a group occurs in a system, the
1536	   system sends either a Source-List-Change Record or a Filter-Mode-
1537	   Change Record for that group.  As with Current-State Records, routers
1538	   must act upon these records and possibly change their own state to
1539	   reflect the new desired membership state of the network.

1541	   Routers must query sources that are requested to be no longer
1542	   forwarded to a group.  When a router queries or receives a query for
1543	   a specific set of sources, it lowers its source timers for those
1544	   sources to a small interval of Last Member Query Time seconds.  If
1545	   group records are received in response to the queries which express
1546	   interest in receiving traffic from the queried sources, the
1547	   corresponding timers are updated.

1549	   Similarly, when a router queries a specific group, it lowers its
1550	   group timer for that group to a small interval of Last Member Query
1551	   Time seconds.  If any group records expressing EXCLUDE mode interest
1552	   in the group are received within the interval, the group timer for
1553	   the group is updated and the suggestion to the routing protocol to
1554	   forward the group stands without any interruption.

1556	   During a query period (i.e., Last Member Query Time seconds), the
1557	   IGMP component in the router continues to suggest to the routing
1558	   protocol that it forwards traffic from the groups or sources that it
1559	   is querying.  It is not until after Last Member Query Time seconds
1560	   without receiving a record expressing interest in the queried group
1561	   or sources that the router may prune the group or sources from the
1562	   network.

1564	   The following table describes the changes in group state and the
1565	   action(s) taken when receiving either Filter-Mode-Change or Source-
1566	   List-Change Records.  This table also describes the queries which are
1567	   sent by the querier when a particular report is received.

1569	   We use the following notation for describing the queries which are
1570	   sent.  We use the notation 'Q(G)' to describe a Group-Specific Query
1571	   to G.  We use the notation 'Q(G,A)' to describe a Group-and-Source
1572	   Specific Query to G with source-list A.  If source-list A is null as
1573	   a result of the action (e.g., A*B) then no query is sent as a result
1574	   of the operation.

1576	   In order to maintain protocol robustness, queries sent by actions in
1577	   the table below need to be transmitted [Last Member Query Count]
1578	   times, once every [Last Member Query Interval].

1580	   If while scheduling new queries, there are already pending queries to
1581	   be retransmitted for the same group, the new and pending queries have
1582	   to be merged.  In addition, received host reports for a group with
1583	   pending queries may affect the contents of those queries.
1584	   Section Section 6.6.3 describes the process of building and
1585	   maintaining the state of pending queries.

1587	   Router State   Report Rec'd New Router State      Actions
1588	   ------------   ------------ ----------------      -------

1590	   INCLUDE (A)    ALLOW (B)    INCLUDE (A+B)         (B)=GMI

1592	   INCLUDE (A)    BLOCK (B)    INCLUDE (A)           Send Q(G,A*B)

1594	   INCLUDE (A)    TO_EX (B)    EXCLUDE (A*B,B-A)     (B-A)=0
1595	                                                     Delete (A-B)
1596	                                                     Send Q(G,A*B)
1597	                                                     Group Timer=GMI

1599	   INCLUDE (A)    TO_IN (B)    INCLUDE (A+B)         (B)=GMI
1600	                                                     Send Q(G,A-B)

1602	   EXCLUDE (X,Y)  ALLOW (A)    EXCLUDE (X+A,Y-A)     (A)=GMI

1604	   EXCLUDE (X,Y)  BLOCK (A)    EXCLUDE (X+(A-Y),Y)   (A-X-Y)=Group Timer
1605	                                                     Send Q(G,A-Y)

1607	   EXCLUDE (X,Y)  TO_EX (A)    EXCLUDE (A-Y,Y*A)     (A-X-Y)=Group Timer
1608	                                                     Delete (X-A)
1609	                                                     Delete (Y-A)
1610	                                                     Send Q(G,A-Y)
1611	                                                     Group Timer=GMI

1613	   EXCLUDE (X,Y)  TO_IN (A)    EXCLUDE (X+A,Y-A)     (A)=GMI
1614	                                                     Send Q(G,X-A)
1615	                                                     Send Q(G)

1617	6.5.  Switching Router Filter-Modes

1619	   The group timer is used as a mechanism for transitioning the router
1620	   filter-mode from EXCLUDE to INCLUDE.

1622	   When a group timer expires with a router filter-mode of EXCLUDE, a
1623	   router assumes that there are no systems with a filter-mode of
1624	   EXCLUDE present on the attached network.  When a router's filter-mode
1625	   for a group is EXCLUDE and the group timer expires, the router
1626	   filter-mode for the group transitions to INCLUDE.

1628	   A router uses source records with running source timers as its state
1629	   for the switch to a filter-mode of INCLUDE.  If there are any source
1630	   records with source timers greater than zero (i.e., requested to be
1631	   forwarded), a router switches to filter-mode of INCLUDE using those
1632	   source records.  Source records whose timers are zero (from the
1633	   previous EXCLUDE mode) are deleted.

1635	   For example, if a router's state for a group is EXCLUDE(X,Y) and the
1636	   group timer expires for that group, the router switches to filter-
1637	   mode of INCLUDE with state INCLUDE(X).

1639	6.6.  Action on Reception of Queries

1641	6.6.1.  Timer Updates

1643	   When a router sends or receives a query with a clear Suppress Router-
1644	   Side Processing flag, it must update its timers to reflect the
1645	   correct timeout values for the group or sources being queried.  The
1646	   following table describes the timer actions when sending or receiving
1647	   a Group-Specific or Group-and-Source Specific Query with the Suppress
1648	   Router-Side Processing flag not set.

1650	      +========+===================================================+
1651	      | Query  |                       Action                      |
1652	      +========+===================================================+
1653	      | Q(G,A) | Source Timer for sources in A are lowered to LMQT |
1654	      +--------+---------------------------------------------------+
1655	      |  Q(G)  |           Group Timer is lowered to LMQT          |
1656	      +--------+---------------------------------------------------+

1658	                                 Table 8

1660	   When a router sends or receives a query with the Suppress Router-Side
1661	   Processing flag set, it will not update its timers.

1663	6.6.2.  Querier Election

1665	   IGMPv3 elects a single querier per subnet using the same querier
1666	   election mechanism as IGMPv2, namely by IP address.  When a router
1667	   receives a general query with a lower IP address, it sets the Other-
1668	   Querier- Present timer to Other Querier Present Interval and ceases
1669	   to send general queries on the network if it was the previously
1670	   elected querier.  After its Other-Querier Present timer expires, it
1671	   should begin sending General Queries.

1673	   If a router receives an older version general query, it MUST use the
1674	   oldest version of IGMP on the network.  For a detailed description of
1675	   compatibility issues between IGMP versions see section Section 7.

1677	6.6.3.  Building and Sending Specific Queries

1679	6.6.3.1.  Building and Sending Group Specific Queries

1681	   When a table action "Send Q(G)" is encountered, then the group timer
1682	   must be lowered to LMQT.  The router must then immediately send a
1683	   group specific query as well as schedule [Last Member Query Count -
1684	   1] query retransmissions to be sent every [Last Member Query
1685	   Interval] over [Last Member Query Time].

1687	   When transmitting a group specific query, if the group timer is
1688	   larger than LMQT, the "Suppress Router-Side Processing" bit is set in
1689	   the query message.

1691	6.6.3.2.  Building and Sending Group and Source Specific Queries

1693	   When a table action "Send Q(G,X)" is encountered by a querier in the
1694	   table in Section 6.4.2, the following actions must be performed for
1695	   each of the sources in X of group G, with source timer larger than
1696	   LMQT:

1698	   *  Set number of retransmissions for each source to [Last Member
1699	      Query Count].

1701	   *  Lower source timer to LMQT.

1703	   The router must then immediately send a group and source specific
1704	   query as well as schedule [Last Member Query Count - 1] query
1705	   retransmissions to be sent every [Last Member Query Interval] over
1706	   [Last Member Query Time].  The contents of these queries are
1707	   calculated as follows.

1709	   When building a group and source specific query for a group G, two
1710	   separate query messages are sent for the group.  The first one has
1711	   the "Suppress Router-Side Processing" bit set and contains all the
1712	   sources with retransmission state and timers greater than LMQT.  The
1713	   second has the "Suppress Router-Side Processing" bit clear and
1714	   contains all the sources with retransmission state and timers lower
1715	   or equal to LMQT.  If either of the two calculated messages does not
1716	   contain any sources, then its transmission is suppressed.

1718	   Note: If a group specific query is scheduled to be transmitted at the
1719	   same time as a group and source specific query for the same group,
1720	   then transmission of the group and source specific message with the
1721	   "Suppress Router-Side Processing" bit set may be suppressed.

1723	7.  Interoperation With Older Versions of IGMP

1725	   IGMP version 3 hosts and routers interoperate with hosts and routers
1726	   that have not yet been upgraded to IGMPv3.  This compatibility is
1727	   maintained by hosts and routers taking appropriate actions depending
1728	   on the versions of IGMP operating on hosts and routers within a
1729	   network.

1731	7.1.  Query Version Distinctions

1733	   The IGMP version of a Membership Query message is determined as
1734	   follows:

1736	      IGMPv1 Query: length = 8 octets AND Max Resp Code field is zero

1738	      IGMPv2 Query: length = 8 octets AND Max Resp Code field is non-
1739	      zero

1741	      IGMPv3 Query: length >= 12 octets

1743	   Query messages that do not match any of the above conditions (e.g., a
1744	   Query of length 10 octets) MUST be silently ignored.

1746	7.2.  Group Member Behavior

1748	7.2.1.  In the Presence of Older Version Queriers

1750	   In order to be compatible with older version routers, IGMPv3 hosts
1751	   MUST operate in version 1 and version 2 compatibility modes.  IGMPv3
1752	   hosts MUST keep state per local interface regarding the compatibility
1753	   mode of each attached network.  A host's compatibility mode is
1754	   determined from the Host Compatibility Mode variable which can be in
1755	   one of three states: IGMPv1, IGMPv2 or IGMPv3.  This variable is kept
1756	   per interface and is dependent on the version of General Queries
1757	   heard on that interface as well as the Older Version Querier Present
1758	   timers for the interface.

1760	   In order to switch gracefully between versions of IGMP, hosts keep
1761	   both an IGMPv1 Querier Present timer and an IGMPv2 Querier Present
1762	   timer per interface.  IGMPv1 Querier Present is set to Older Version
1763	   Querier Present Timeout seconds whenever an IGMPv1 Membership Query
1764	   is received.  IGMPv2 Querier Present is set to Older Version Querier
1765	   Present Timeout seconds whenever an IGMPv2 General Query is received.

19.nit:

s/Present Timeout/Present Interval/

1767	   The Host Compatibility Mode of an interface changes whenever an older
1768	   version query (than the current compatibility mode) is heard or when
1769	   certain timer conditions occur.  When the IGMPv1 Querier Present
1770	   timer expires, a host switches to Host Compatibility mode of IGMPv2
1771	   if it has a running IGMPv2 Querier Present timer.  If it does not
1772	   have a running IGMPv2 Querier Present timer then it switches to Host
1773	   Compatibility of IGMPv3.  When the IGMPv2 Querier Present timer
1774	   expires, a host switches to Host Compatibility mode of IGMPv3.

1776	   The Host Compatibility Mode variable is based on whether an older
1777	   version General query was heard in the last Older Version Querier
1778	   Present Timeout seconds.  The Host Compatibility Mode is set

20.nit:

s/Present Timeout/Present Interval/

1779	   depending on the following:

1781	   +=========================+========================================+
1782	   | Host Compatibility Mode |              Timer State               |
1783	   +=========================+========================================+
1784	   |     IGMPv3 (default)    | IGMPv2 Querier Present not running and |
1785	   |                         |   IGMPv1 Querier Present not running   |
1786	   +-------------------------+----------------------------------------+
1787	   |          IGMPv2         |   IGMPv2 Querier Present running and   |
1788	   |                         |   IGMPv1 Querier Present not running   |
1789	   +-------------------------+----------------------------------------+
1790	   |          IGMPv1         |     IGMPv1 Querier Present running     |
1791	   +-------------------------+----------------------------------------+

1793	                                 Table 9

1795	   If a host receives a query which causes its Querier Present timers to
1796	   be updated and correspondingly its compatibility mode, it should
1797	   switch compatibility modes immediately.

1799	   When Host Compatibility Mode is IGMPv3, a host acts using the IGMPv3
1800	   protocol on that interface.  When Host Compatibility Mode is IGMPv2,
1801	   a host acts in IGMPv2 compatibility mode, using only the IGMPv2
1802	   protocol, on that interface.  When Host Compatibility Mode is IGMPv1,
1803	   a host acts in IGMPv1 compatibility mode, using only the IGMPv1
1804	   protocol on that interface.

1806	   An IGMPv1 router will send General Queries with the Max Resp Code set
1807	   to 0.  This MUST be interpreted as a value of 100 (10 seconds).

1809	   An IGMPv2 router will send General Queries with the Max Resp Code set
1810	   to the desired Max Resp Time, i.e., the full range of this field is
1811	   linear and the exponential algorithm described in Section 4.1.1 is
1812	   not used.

1814	   Whenever a host changes its compatibility mode, it cancels all its
1815	   pending response and retransmission timers.

1817	   An SSM-aware host that receives an IGMPv1 Query, an IGMPv2 General
1818	   Query, or an IGMPv2 Group Specific Query for a multicast address in
1819	   the SSM range SHOULD log an error.

1821	7.2.2.  In the Presence of Older Version Group Members

1823	   An IGMPv3 host may be placed on a network where there are hosts that
1824	   have not yet been upgraded to IGMPv3.  A host MAY allow its IGMPv3
1825	   Membership Record to be suppressed by either a Version 1 Membership
1826	   Report, or a Version 2 Membership Report.  SSM-aware hosts MUST NOT
1827	   allow its IGMPv3 Membership Record to be suppressed.

21.mayor:

The last sentence looks like being copied from RFC4604. But it does not copy
the explanation sentence from RFC4604:

   Suppressing reports in this scenario would provide an avenue for an attacker
   to deny SSM service to other hosts on the link.

The correct requirement just to protect SSM  would be:

SSM-aware hosts MUST NOT allow their IGMPv3 Membership Records for groups
in the SSM address tange to be suppressed.  Suppressing such records would
make SSM fail in the presence of older hosts, malicious or not.

BUT: I would love to change the whole paragraph to be changed to:

  An IGMPv3 host may be placed on a network where there are hosts that
  have not yet been upgraded to IGMPv3.  A host MUST NOT allow its IGMPv3
  Membership Records to be suppressed by either a Version 1 Membership
  Report, or a Version 2 Membership Report.  See A.2 for explanations.

Aka: There is IMHO no reason whatsoever to ever think about report suppression.
The only reason for report suppression where shared (non-switched) LANs or
todays equivalent, ad-hoc WiFi (AP-mode is like a switch), but it absolutely
does make no sense whatsoever to only have a MAY for such scenarios in the
presence of older hosts.

1829	7.3.  Multicast Router Behavior

1831	7.3.1.  In the Presence of Older Version Queriers

1833	   IGMPv3 routers may be placed on a network where at least one router
1834	   on the network has not yet been upgraded to IGMPv3.  The following
1835	   requirements apply:

1837	   *  If any older versions of IGMP are present on routers, the querier
1838	      MUST use the lowest version of IGMP present on the network.  This
1839	      must be administratively assured; routers that desire to be
1840	      compatible with IGMPv1 and IGMPv2 MUST have a configuration option
1841	      to act in IGMPv1 or IGMPv2 compatibility modes.  When in IGMPv1
1842	      mode, routers MUST send Periodic Queries with a Max Resp Code of 0
1843	      and truncated at the Group Address field (i.e., 8 bytes long), and
1844	      MUST ignore Leave Group messages.  They SHOULD also warn about
1845	      receiving an IGMPv2 or IGMPv3 query, although such warnings MUST
1846	      be rate-limited.  When in IGMPv2 mode, routers MUST send Periodic
1847	      Queries truncated at the Group Address field (i.e., 8 bytes long),
1848	      and SHOULD also warn about receiving an IGMPv3 query (such
1849	      warnings MUST be rate-limited).  They also MUST fill in the Max
1850	      Resp Time in the Max Resp Code field, i.e., the exponential
1851	      algorithm described in Section 4.1.1 is not used.

1853	   *  If a router is not explicitly configured to use IGMPv1 or IGMPv2
1854	      and hears an IGMPv1 Query or IGMPv2 General Query, it SHOULD log a
1855	      warning.  These warnings MUST be rate-limited.

1857	7.3.2.  In the Presence of Older Version Group Members

1859	   IGMPv3 routers may be placed on a network where there are hosts that
1860	   have not yet been upgraded to IGMPv3.  In order to be compatible with
1861	   older version hosts, IGMPv3 routers MUST operate in version 1 and
1862	   version 2 compatibility modes.  IGMPv3 routers keep a compatibility
1863	   mode per group record.  A group's compatibility mode is determined
1864	   from the Group Compatibility Mode variable which can be in one of
1865	   three states: IGMPv1, IGMPv2 or IGMPv3.  This variable is kept per
1866	   group record and is dependent on the version of Membership Reports
1867	   heard for that group as well as the Older Version Host Present timer
1868	   for the group.

1870	   In order to switch gracefully between versions of IGMP, routers keep
1871	   an IGMPv1 Host Present timer and an IGMPv2 Host Present timer per
1872	   group record.  The IGMPv1 Host Present timer is set to Older Version
1873	   Host Present Timeout seconds whenever an IGMPv1 Membership Report is
1874	   received.  The IGMPv2 Host Present timer is set to Older Version Host
1875	   Present Timeout seconds whenever an IGMPv2 Membership Report is
1876	   received.

1878	   The Group Compatibility Mode of a group record changes whenever an
1879	   older version report (than the current compatibility mode) is heard
1880	   or when certain timer conditions occur.  When the IGMPv1 Host Present
1881	   timer expires, a router switches to Group Compatibility mode of
1882	   IGMPv2 if it has a running IGMPv2 Host Present timer.  If it does not
1883	   have a running IGMPv2 Host Present timer then it switches to Group
1884	   Compatibility of IGMPv3.  When the IGMPv2 Host Present timer expires
1885	   and the IGMPv1 Host Present timer is not running, a router switches
1886	   to Group Compatibility mode of IGMPv3.  Note that when a group
1887	   switches back to IGMPv3 mode, it takes some time to regain source-
1888	   specific state information.  Source-specific information will be
1889	   learned during the next General Query, but sources that should be
1890	   blocked will not be blocked until [Group Membership Interval] after
1891	   that.

1893	   The Group Compatibility Mode variable is based on whether an older
1894	   version report was heard in the last Older Version Host Present
1895	   Timeout seconds.  The Group Compatibility Mode is set depending on
1896	   the following:

1898	    +==========================+=====================================+
1899	    | Group Compatibility Mode |             Timer State             |
1900	    +==========================+=====================================+
1901	    |     IGMPv3 (default)     | IGMPv2 Host Present not running and |
1902	    |                          |   IGMPv1 Host Present not running   |
1903	    +--------------------------+-------------------------------------+
1904	    |          IGMPv2          |   IGMPv2 Host Present running and   |
1905	    |                          |   IGMPv1 Host Present not running   |
1906	    +--------------------------+-------------------------------------+
1907	    |          IGMPv1          |     IGMPv1 Host Present running     |
1908	    +--------------------------+-------------------------------------+

1910	                                 Table 10

1912	   If a router receives a report which causes its older Host Present
1913	   timers to be updated and correspondingly its compatibility mode, it
1914	   SHOULD switch compatibility modes immediately.

1916	   When Group Compatibility Mode is IGMPv3, a router acts using the
1917	   IGMPv3 protocol for that group.

1919	   When Group Compatibility Mode is IGMPv2, a router internally
1920	   translates the following IGMPv2 messages for that group to their
1921	   IGMPv3 equivalents:

1923	                  +================+===================+
1924	                  | IGMPv2 Message | IGMPv3 Equivalent |
1925	                  +================+===================+
1926	                  |     Report     |    IS_EX( {} )    |
1927	                  +----------------+-------------------+
1928	                  |     Leave      |    TO_IN( {} )    |
1929	                  +----------------+-------------------+

1931	                                 Table 11

1933	   IGMPv3 BLOCK messages are ignored, as are source-lists in TO_EX()
1934	   messages (i.e., any TO_EX() message is treated as TO_EX( {} )).

1936	   When Group Compatibility Mode is IGMPv1, a router internally
1937	   translates the following IGMPv1 and IGMPv2 messages for that group to
1938	   their IGMPv3 equivalents:

1940	                  +================+===================+
1941	                  | IGMPv2 Message | IGMPv3 Equivalent |
1942	                  +================+===================+
1943	                  |   v1 Report    |    IS_EX( {} )    |
1944	                  +----------------+-------------------+
1945	                  |   v2 Report    |    IS_EX( {} )    |
1946	                  +----------------+-------------------+

1948	                                 Table 12

1950	   In addition to ignoring IGMPv3 BLOCK messages and source-lists in
1951	   TO_EX() messages as in IGMPv2 Group Compatibility Mode, IGMPv2 Leave
1952	   messages and IGMPv3 TO_IN() messages are also ignored.

1954	8.  List of Timers, Counters and Their Default Values

1956	   Most of these timers are configurable.  If non-default settings are
1957	   used, they MUST be consistent among all systems on a single link.
1958	   Note that parentheses are used to group expressions to make the
1959	   algebra clear.

1961	8.1.  Robustness Variable

1963	   The Robustness Variable allows tuning for the expected packet loss on
1964	   a network.  If a network is expected to be lossy, the Robustness
1965	   Variable may be increased.  IGMP is robust to (Robustness Variable -
1966	   1) packet losses.  The Robustness Variable MUST NOT be zero, and
1967	   SHOULD NOT be one.  Default: 2

1969	8.2.  Query Interval

1971	   The Query Interval is the interval between General Queries sent by
1972	   the Querier.  Default: 125 seconds.

1974	   By varying the [Query Interval], an administrator may tune the number
1975	   of IGMP messages on the network; larger values cause IGMP Queries to
1976	   be sent less often.

1978	8.3.  Query Response Interval

1980	   The Max Response Time used to calculate the Max Resp Code inserted
1981	   into the periodic General Queries.  Default: 100 (10 seconds)

1983	   By varying the [Query Response Interval], an administrator may tune
1984	   the burstiness of IGMP messages on the network; larger values make
1985	   the traffic less bursty, as host responses are spread out over a
1986	   larger interval.  The number of seconds represented by the [Query
1987	   Response Interval] must be less than the [Query Interval].

1989	8.4.  Group Membership Interval

1991	   The Group Membership Interval is the amount of time that must pass
1992	   before a multicast router decides there are no more members of a
1993	   group or a particular source on a network.

1995	   This value MUST be ((the Robustness Variable) times (the Query
1996	   Interval)) plus (2 * Query Response Interval).

1998	8.5.  Other Querier Present Interval

2000	   The Other Querier Present Interval is the length of time that must
2001	   pass before a multicast router decides that there is no longer
2002	   another multicast router which should be the querier.  This value
2003	   MUST be ((the Robustness Variable) times (the Query Interval)) plus
2004	   (one half of one Query Response Interval).

2006	8.6.  Startup Query Interval

2008	   The Startup Query Interval is the interval between General Queries
2009	   sent by a Querier on startup.  Default: 1/4 the Query Interval.

2011	8.7.  Startup Query Count

2013	   The Startup Query Count is the number of Queries sent out on startup,
2014	   separated by the Startup Query Interval.  Default: the Robustness
2015	   Variable.

2017	8.8.  Last Member Query Interval

2019	   The Last Member Query Interval is the Max Response Time used to
2020	   calculate the Max Resp Code inserted into Group-Specific Queries sent
2021	   in response to Leave Group messages.  It is also the Max Response
2022	   Time used in calculating the Max Resp Code for Group-and-Source-
2023	   Specific Query messages.  Default: 10 (1 second)

2025	   Note that for values of LMQI greater than 12.8 seconds, a limited set
2026	   of values can be represented, corresponding to sequential values of
2027	   Max Resp Code.  When converting a configured time to a Max Resp Code
2028	   value, it is recommended to use the exact value if possible, or the
2029	   next lower value if the requested value is not exactly representable.

2031	   This value may be tuned to modify the "leave latency" of the network.
2032	   A reduced value results in reduced time to detect the loss of the
2033	   last member of a group or source.

2035	8.9.  Last Member Query Count

2037	   The Last Member Query Count is the number of Group-Specific Queries
2038	   sent before the router assumes there are no local members.  The Last
2039	   Member Query Count is also the number of Group-and-Source-Specific
2040	   Queries sent before the router assumes there are no listeners for a
2041	   particular source.  Default: the Robustness Variable.

2043	8.10.  Last Member Query Time

2045	   The Last Member Query Time is the time value represented by the Last
2046	   Member Query Interval, multiplied by the Last Member Query Count.  It
2047	   is not a tunable value, but may be tuned by changing its components.

2049	8.11.  Unsolicited Report Interval

2051	   The Unsolicited Report Interval is the time between repetitions of a
2052	   host's initial report of membership in a group.  Default: 1 second.

2054	8.12.  Older Version Querier Present Interval

22.minor:

Googling the Internet, it seems as if some CLI have used OVQPT to refer to
the rfc3376 name "Older Version Querier Present Timeout", which you renamed
to "Older Version Querier Present Interval", probably because 8.12 in rfc3376
also uses the term "Older Version Querier Interval" as a synonym for
"Older Version Querier Present Interval" - to confuse the heck out of everybody.

Anyhow. To put a better stake into the ground, i would suggest to change title to:

  Older Version Querier Present Interval (OVQPI)

aka: seed the abbreviation to the right term.

2056	   The Older Version Querier Present Interval is the timeout for

23.nit:

  And/or add (OVQPI) on the above line

2057	   transitioning a host back to IGMPv3 mode once an older version query
2058	   is heard.  When an older version query is received, hosts set their
2059	   Older Version Querier Present Timer to Older Version Querier Present
2060	   Interval.

24.nit:

And put (OVQPT) behind the term, so that any CLI that wants to use abbreviation
has a normative one. This may annoy the CLI i found on google
which used OVQPT for the Timeout, but obviously, we can not have OVQPT to
describe both a timeout and a timer, so there is no way to make those folks happy.


2062	   It is RECOMMENDED to use the default values for calculating the
2063	   interval value as hosts do not know the values configured on the
2064	   querying routers.  This value SHOULD be [Robustness Variable] times

25.nit:

  ... quering routers, because QQIC is not present in version 1 or version 2 queries.

Just a suggestion for readers to more easily understand the problem.

2065	   [Query Interval] plus (10 times the Max Resp Time in the last
2066	   received query message).

26.nit:

A short rationale for the magical value 10 would be nice.

2068	8.13.  Older Host Present Interval

2070	   The Older Host Present Interval is the time-out for transitioning a
2071	   group back to IGMPv3 mode once an older version report is sent for
2072	   that group.  When an older version report is received, routers set
2073	   their Older Host Present Timer to Older Host Present Interval.

2075	   This value MUST be ((the Robustness Variable) times (the Query
2076	   Interval)) plus (one Query Response Interval).

2078	8.14.  Configuring Timers

2080	   This section is meant to provide advice to network administrators on
2081	   how to tune these settings to their network.  Ambitious router
2082	   implementations might tune these settings dynamically based upon
2083	   changing characteristics of the network.

2085	8.14.1.  Robustness Variable

2087	   The Robustness Variable tunes IGMP to expected losses on a link.
2088	   IGMPv3 is robust to (Robustness Variable - 1) packet losses, e.g., if
2089	   the Robustness Variable is set to the default value of 2, IGMPv3 is
2090	   robust to a single packet loss but may operate imperfectly if more
2091	   losses occur.  On lossy subnetworks, the Robustness Variable should
2092	   be increased to allow for the expected level of packet loss.
2093	   However, increasing the Robustness Variable increases the leave
2094	   latency of the subnetwork.  (The leave latency is the time between
2095	   when the last member stops listening to a source or group and when
2096	   the traffic stops flowing.)

2098	8.14.2.  Query Interval

2100	   The overall level of periodic IGMP traffic is inversely proportional
2101	   to the Query Interval.  A longer Query Interval results in a lower
2102	   overall level of IGMP traffic.  The Query Interval MUST be equal to
2103	   or longer than the Max Response Time inserted in General Query
2104	   messages.

2106	8.14.3.  Max Response Time

2108	   The burstiness of IGMP traffic is inversely proportional to the Max
2109	   Response Time.  A longer Max Response Time will spread Report
2110	   messages over a longer interval.  However, a longer Max Response Time
2111	   in Group-Specific and Source-and-Group-Specific Queries extends the
2112	   leave latency.  (The leave latency is the time between when the last
2113	   member stops listening to a source or group and when the traffic
2114	   stops flowing.)  The expected rate of Report messages can be
2115	   calculated by dividing the expected number of Reporters by the Max
2116	   Response Time.  The Max Response Time may be dynamically calculated
2117	   per Query by using the expected number of Reporters for that Query as
2118	   follows:

2120	       +===========================+===============================+
2121	       |         Query Type        |  Expected number of Reporters |
2122	       +===========================+===============================+
2123	       |       General Query       |   All systems on subnetwork   |
2124	       +---------------------------+-------------------------------+
2125	       |    Group-Specific Query   |      All systems that had     |
2126	       |                           |   expressed interest in the   |
2127	       |                           |    group on the subnetwork    |
2128	       +---------------------------+-------------------------------+
2129	       | Source-and-Group-Specific | All systems on the subnetwork |
2130	       |           Query           |  that had expressed interest  |
2131	       |                           |    in the source and group    |
2132	       +---------------------------+-------------------------------+

2134	                                  Table 13

2136	   A router is not required to calculate these populations or tune the
2137	   Max Response Time dynamically; these are simply guidelines.

2139	9.  Security Considerations

2141	   We consider the ramifications of a forged message of each type, and
2142	   describe the usage of IPSEC AH to authenticate messages if desired.

2144	9.1.  Query Message

2146	   A forged Query message from a machine with a lower IP address than
2147	   the current Querier will cause Querier duties to be assigned to the
2148	   forger.  If the forger then sends no more Query messages, other
2149	   routers' Other Querier Present timer will time out and one will
2150	   resume the role of Querier.  During this time, if the forger ignores
2151	   Leave Messages, traffic might flow to groups with no members for up
2152	   to [Group Membership Interval].

2154	   A DoS attack on a host could be staged through forged Group-and-
2155	   Source-Specific Queries.  The attacker can find out about membership
2156	   of a specific host with a general query.  After that it could send a
2157	   large number of Group-and-Source-Specific queries, each with a large
2158	   source list and the Maximum Response Time set to a large value.  The
2159	   host will have to store and maintain the sources specified in all of
2160	   those queries for as long as it takes to send the delayed response.
2161	   This would consume both memory and CPU cycles in order to augment the
2162	   recorded sources with the source lists included in the successive
2163	   queries.

2165	   To protect against such a DoS attack, a host stack implementation
2166	   could restrict the number of Group-and-Source-Specific Queries per
2167	   group membership within this interval, and/or record only a limited
2168	   number of sources.

2170	   Forged Query messages from the local network can be easily traced.
2171	   There are three measures necessary to defend against externally
2172	   forged Queries:

2174	   *  Routers SHOULD NOT forward Queries.  This is easier for a router
2175	      to accomplish if the Query carries the Router-Alert option.

2177	   *  Hosts SHOULD ignore v2 or v3 Queries without the Router-Alert
2178	      option.

2180	   *  Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a
2181	      multicast address other than 224.0.0.1, the all-systems address.

2183	9.2.  Current-State Report messages

2185	   A forged Report message may cause multicast routers to think there
2186	   are members of a group on a network when there are not.  Forged
2187	   Report messages from the local network are meaningless, since joining
2188	   a group on a host is generally an unprivileged operation, so a local
2189	   user may trivially gain the same result without forging any messages.
2190	   Forged Report messages from external sources are more troublesome;
2191	   there are two defenses against externally forged Reports:

2193	   *  Ignore the Report if you cannot identify the source address of the
2194	      packet as belonging to a network assigned to the interface on
2195	      which the packet was received.  This solution means that Reports
2196	      sent by mobile hosts without addresses on the local network will
2197	      be ignored.  Report messages with a source address of 0.0.0.0
2198	      SHOULD be accepted on any interface.

2200	   *  Ignore Report messages without Router Alert options [RFC2113], and
2201	      require that routers not forward Report messages.  (The
2202	      requirement is not a requirement of generalized filtering in the
2203	      forwarding path, since the packets already have Router Alert
2204	      options in them.)  This solution breaks backwards compatibility
2205	      with implementations of IGMPv1 or earlier versions of IGMPv2 which
2206	      did not require Router Alert.

2208	   A forged Version 1 Report Message may put a router into "version 1
2209	   members present" state for a particular group, meaning that the
2210	   router will ignore Leave messages.  This can cause traffic to flow to
2211	   groups with no members for up to [Group Membership Interval].  This
2212	   can be solved by providing routers with a configuration switch to
2213	   ignore Version 1 messages completely.  This breaks automatic
2214	   compatibility with Version 1 hosts, so should only be used in
2215	   situations where "fast leave" is critical.

2217	   A forged Version 2 Report Message may put a router into "version 2
2218	   members present" state for a particular group, meaning that the
2219	   router will ignore IGMPv3 source-specific state messages.  This can
2220	   cause traffic to flow from unwanted sources for up to [Group
2221	   Membership Interval].  This can be solved by providing routers with a
2222	   configuration switch to ignore Version 2 messages completely.  This
2223	   breaks automatic compatibility with Version 2 hosts, so should only
2224	   be used in situations where source include and exclude is critical.

2226	9.3.  State-Change Report Messages

2228	   A forged State-Change Report message will cause the Querier to send
2229	   out Group-Specific or Source-and-Group-Specific Queries for the group
2230	   in question.  This causes extra processing on each router and on each
2231	   member of the group, but can not cause loss of desired traffic.
2232	   There are two defenses against externally forged State-Change Report
2233	   messages:

2235	   *  Ignore the State-Change Report message if you cannot identify the
2236	      source address of the packet as belonging to a subnet assigned to
2237	      the interface on which the packet was received.  This solution
2238	      means that State-Change Report messages sent by mobile hosts
2239	      without addresses on the local subnet will be ignored.  State-
2240	      Change Report messages with a source address of 0.0.0.0 SHOULD be
2241	      accepted on any interface.

2243	   *  Ignore State-Change Report messages without Router Alert options
2244	      [RFC2113], and require that routers not forward State-Change
2245	      Report messages.  (The requirement is not a requirement of
2246	      generalized filtering in the forwarding path, since the packets
2247	      already have Router Alert options in them.)

2249	9.4.  9.4.  IPSEC Usage

2251	   In addition to these measures, IPSEC in Authentication Header mode
2252	   [RFC2402] may be used to protect against remote attacks by ensuring
2253	   that IGMPv3 messages came from a system on the LAN (or, more
2254	   specifically, a system with the proper key).  When using IPSEC, the
2255	   messages sent to 224.0.0.1 and 224.0.0.22 should be authenticated
2256	   using AH.  When keying, there are two possibilities:

2258	   1.  Use a symmetric signature algorithm with a single key for the LAN
2259	       (or a key for each group).  This allows validation that a packet
2260	       was sent by a system with the key.  This has the limitation that
2261	       any system with the key can forge a message; it is not possible
2262	       to authenticate the individual sender precisely.  It also
2263	       requires disabling IPSec's Replay Protection.

2265	   2.  When appropriate key management standards have been developed,
2266	       use an asymmetric signature algorithm.  All systems need to know
2267	       the public key of all routers, and all routers need to know the
2268	       public key of all systems.  This requires a large amount of key
2269	       management but has the advantage that senders can be
2270	       authenticated individually so e.g., a host cannot forge a message
2271	       that only routers should be allowed to send.

2273	   This solution only directly applies to Query and Leave messages in
2274	   IGMPv1 and IGMPv2, since Reports are sent to the group being reported
2275	   and it is not feasible to agree on a key for host-to-router
2276	   communication for arbitrary multicast groups.

2278	10.  IANA Considerations

2280	   All IGMP types described in this document are managed via
2281	   [I-D.ietf-pim-3228bis].

27.minor: I think we need to add the following text:

  IANA is asked to update the registration for the IGMP messages type as
  shown in Table 1 to refer to [ThisRFC] instead of [RFC3376].

2283	11.  Contributors

2285	   Brad Cain, Steve Deering, Isidor Kouvelas, Bill Fenner, and Ajit
2286	   Thyagarajan are the authors of RFC 3376, which forms the bulk of the
2287	   content contained herein.

2289	   Anuj Budhiraja, Toerless Eckert, Olufemi Komolafe and Tim Winters
2290	   have contributed valuable content to this version of the
2291	   specification.

2293	12.  Acknowledgments

2295	   We would like to thank Ran Atkinson, Luis Costa, Toerless Eckert,
2296	   Dino Farinacci, Serge Fdida, Wilbert de Graaf, Sumit Gupta, Mark
2297	   Handley, Bob Quinn, Michael Speer, Dave Thaler and Rolland Vida for
2298	   comments and suggestions on RFC 3376.

2300	   Stig Venaas, Hitoshi Asaeda, and Mike McBride have provided valuable
2301	   feedback on this version of the specification and we thank them for
2302	   their input.

2304	13.  References

2306	13.1.  Normative References

2308	   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
2309	              RFC 1112, DOI 10.17487/RFC1112, August 1989,
2310	              <https://www.rfc-editor.org/info/rfc1112>.

2312	   [RFC2113]  Katz, D., "IP Router Alert Option", RFC 2113,
2313	              DOI 10.17487/RFC2113, February 1997,
2314	              <https://www.rfc-editor.org/info/rfc2113>.

2316	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
2317	              Requirement Levels", BCP 14, RFC 2119,
2318	              DOI 10.17487/RFC2119, March 1997,
2319	              <https://www.rfc-editor.org/info/rfc2119>.

2321	   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
2322	              2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
2323	              <https://www.rfc-editor.org/info/rfc2236>.

2325	   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header",
2326	              RFC 2402, DOI 10.17487/RFC2402, November 1998,
2327	              <https://www.rfc-editor.org/info/rfc2402>.

2329	   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
2330	              IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
2331	              <https://www.rfc-editor.org/info/rfc4607>.

2333	13.2.  Informative References

2335	   [I-D.ietf-pim-3228bis]
2336	              Haberman, B., "IANA Considerations for Internet Group
2337	              Management Protocols", Work in Progress, Internet-Draft,
2338	              draft-ietf-pim-3228bis-02, 23 October 2023,
2339	              <https://datatracker.ietf.org/doc/html/draft-ietf-pim-
2340	              3228bis-02>.

2342	   [RFC1071]  Braden, R., Borman, D., and C. Partridge, "Computing the
2343	              Internet checksum", RFC 1071, DOI 10.17487/RFC1071,
2344	              September 1988, <https://www.rfc-editor.org/info/rfc1071>.

2346	   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
2347	              Thyagarajan, "Internet Group Management Protocol, Version
2348	              3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
2349	              <https://www.rfc-editor.org/info/rfc3376>.

2351	   [RFC3569]  Bhattacharyya, S., Ed., "An Overview of Source-Specific
2352	              Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July
2353	              2003, <https://www.rfc-editor.org/info/rfc3569>.

2355	   [RFC3678]  Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
2356	              Extensions for Multicast Source Filters", RFC 3678,
2357	              DOI 10.17487/RFC3678, January 2004,
2358	              <https://www.rfc-editor.org/info/rfc3678>.

2360	Appendix A.  Design Rationale

2362	A.1.  The Need for State-Change Messages

2364	   IGMPv3 specifies two types of Membership Reports: Current-State and
2365	   State Change.  This section describes the rationale for the need for
2366	   both these types of Reports.

2368	   Routers need to distinguish Membership Reports that were sent in
2369	   response to Queries from those that were sent as a result of a change
2370	   in interface state.  Membership reports that are sent in response to
2371	   Membership Queries are used mainly to refresh the existing state at
2372	   the router; they typically do not cause transitions in state at the
2373	   router.  Membership Reports that are sent in response to changes in
2374	   interface state require the router to take some action in response to
2375	   the received report (see Section 6.4).

2377	   The inability to distinguish between the two types of reports would
2378	   force a router to treat all Membership Reports as potential changes
2379	   in state and could result in increased processing at the router as
2380	   well as an increase in IGMP traffic on the network.

2382	A.2.  Host Suppression

2384	   In IGMPv1 and IGMPv2, a host would cancel sending a pending
2385	   membership reports if a similar report was observed from another
2386	   member on the network.  In IGMPv3, this suppression of host
2387	   membership reports has been removed.  The following points explain
2388	   the reasons behind this decision.

2390	   1.  Routers may want to track per-host membership status on an
2391	       interface.  This allows routers to implement fast leaves (e.g.,
2392	       for layered multicast congestion control schemes) as well as
2393	       track membership status for possible accounting purposes.

28.minor:

Could we add the following at the end, please:

  See [draft-ietf-pim-explicit-tracking] for details on such procedures.

Yes, we did let that draft expire and that pains me, and we should get back to it,
but i think that it deserves mentioning especially given how there are existing
explicit tracking implementations in widely deployed products.

2395	   2.  Membership Report suppression does not work well on bridged LANs.
2396	       Many bridges and Layer2/Layer3 switches that implement IGMP
2397	       snooping do not forward IGMP messages across LAN segments in
2398	       order to prevent membership report suppression.  Removing
2399	       membership report suppression eases the job of these IGMP
2400	       snooping devices.

2402	   3.  By eliminating membership report suppression, hosts have fewer
2403	       messages to process; this leads to a simpler state machine
2404	       implementation.

2406	   4.  In IGMPv3, a single membership report now bundles multiple
2407	       multicast group records to decrease the number of packets sent.
2408	       In comparison, the previous versions of IGMP required that each
2409	       multicast group be reported in a separate message.

2411	A.3.  Switching Router Filter Modes from EXCLUDE to INCLUDE

2413	   If there exist hosts in both EXCLUDE and INCLUDE modes for a single
2414	   multicast group in a network, the router must be in EXCLUDE mode as
2415	   well (see section 6.2.1).  In EXCLUDE mode, a router forwards traffic
2416	   from all sources unless that source exists in the exclusion source
2417	   list.  If all hosts in EXCLUDE mode cease to exist, it would be
2418	   desirable for the router to switch back to INCLUDE mode seamlessly
2419	   without interrupting the flow of traffic to existing receivers.

2421	   One of the ways to accomplish this is for routers to keep track of
2422	   all sources desired by hosts that are in INCLUDE mode even though the
2423	   router itself is in EXCLUDE mode.  If the group timer now expires in
2424	   EXCLUDE mode, it implies that there are no hosts in EXCLUDE mode on
2425	   the network (otherwise a membership report from that host would have
2426	   refreshed the group timer).  The router can then switch to INCLUDE
2427	   mode seamlessly with the list of sources currently being forwarded in
2428	   its source list.

2430	Appendix B.  Summary of Changes from IGMPv2

2432	   While the main additional feature of IGMPv3 is the addition of source
2433	   filtering, the following is a summary of other changes from RFC 2236.

2435	   *  State is maintained as Group + List-of-Sources, not simply Group
2436	      as in IGMPv2.

2438	   *  Interoperability with IGMPv1 and IGMPv2 systems is defined as
2439	      operations on the IGMPv3 state.

2441	   *  The IP Service Interface has changed to allow specification of
2442	      source-lists.

2444	   *  The Querier includes its Robustness Variable and Query Interval in
2445	      Query packets to allow synchronization of these variables on non-
2446	      Queriers.

2448	   *  The Max Response Time in Query messages has an exponential range,
2449	      changing the maximum from 25.5 seconds to about 53 minutes, for
2450	      use on links with huge numbers of systems.

2452	   *  Hosts retransmit state-change messages for increased robustness.

2454	   *  Additional data sections are defined to allow later extensions.

2456	   *  Report packets are sent to 224.0.0.22, to assist layer-2 switches
2457	      in snooping.

2459	   *  Report packets can contain multiple group records, to allow
2460	      reporting of full current state using fewer packets.

2462	   *  Hosts no longer perform suppression, to simplify implementations
2463	      and permit explicit membership tracking.

2465	   *  New Suppress Router-Side Processing (S) flag in Query messages
2466	      fixes robustness issues which were also present in IGMPv2.

2468	Appendix C.  Summary of Changes from RFC 3376

2470	   The following is a list of changes made since RFC 3376.

2472	   *  Modified definition of Older Version Querier Present Interval to
2473	      address Erratum 4375.

2475	   *  Modified metadata to fix Obsoletes vs Updates relationship with
2476	      RFC 2236 per Erratum 1501.

2478	   *  Updated Group Membership Interval definition to address Erratum
2479	      6725.

2481	   *  Updated text for Router Filter-Mode to address Erratum 5562.

29.minor:

I could actually not find any text changes for this. There seem to be none functionally
relevant in the sections mentioned in thre erratum. Could you add some pointer to
the section(s) with changes because of this erratum here please ?

2483	   *  Clarified the use of General Queries in the Querier election
2484	      process.

30.minor:

Please add: 

           * Inherited and rephrased core requirements text from RFC4604 for SSM-aware systems.

           * Changed ambiguous naming "Older Version Querier Present Interval" / "Older Version Querier Interval" to "Older Version Querier Present Interval" (OVQPI). Removed Term "Older Version Querier Present Timeout", because its abbreviation would clash with the necessary "Older Version Querier Present Timer" (OVQPT).

           * Changed a MAY for host record report suppression in the presence of older hosts to a MUST NOT to better protect good IGMPv3 behavior in the presence of older hosts.

That previous line of course only if/when the suggested change by me is used.

           * Improved formatting and copyright statement.

31.minor:

  Appendix D. Summary of Updates to RFC4604

      * For ease readability and completeness of this specification, it inherits
        the core requirements of RFC4604 for the IGMPv3 protocol behavior. No
        changes in requirements over RFC4604 are intended. RFC4604 also specifies
        additional behavior for IGMPv1/IGMPv2 backward compatibility behavior for
        SSM groups not covered in this document as well as configuration options.

I hope this is correct and explans the situation sufficiently.

2486	Author's Address

2488	   Brian Haberman (editor)
2489	   Johns Hopkins University Applied Physics Lab
2490	   Email: [e-mail]

--- EOF - Thanks again!

On Wed, Dec 13, 2023 at 01:08:13PM -0800, Stig Venaas wrote:
> Hi again
> 
> Hoping we can get some more responses here.
> 
> I've reviewed it myself, but would be great to have more people
> reviewing the updates.
> 
> WGLC ends in 2 days (the 15th).
> 
> Thanks,
> Stig
> 
> On Tue, Nov 28, 2023 at 2:59 PM Stig Venaas <[e-mail]> wrote:
> >
> > Dear working group
> >
> > We have been working on progressing these core documents to Internet Standard.
> >
> > The documents are
> >
> > IANA Considerations for Internet Group Management Protocols
> > https://datatracker.ietf.org/doc/draft-ietf-pim-3228bis/
> >
> > Internet Group Management Protocol, Version 3
> > https://datatracker.ietf.org/doc/draft-ietf-pim-3376bis/
> >
> > Multicast Listener Discovery Version 2 (MLDv2) for IPv6
> > https://datatracker.ietf.org/doc/draft-ietf-pim-3810bis/
> >
> > As these are important documents, I am hoping we will get some people
> > to review these drafts and give us feedback. We did not get any
> > responses to the previous wglc for these documents.
> >
> > Please respond by December 15th 2023 whether you believe these
> > documents are ready for publication, and any comments or concerns you
> > may have. Any input is helpful.
> >
> > Regards,
> > Stig
>