RFC 3376, "Internet Group Management Protocol, Version 3", October 2002

Note: This RFC has been updated by RFC 4604

Errata ID: 7575
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Aymen Lahouel
Date Reported: 2023-07-26
Rejected by: John Scudder
Date Rejected: 2024-02-14

Section 5.1 says:

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

It should say:

If more changes to the same interface state entry occur before all
the retransmissions of the State-Change Report for the first change
have been completed, each such additional change triggers the
immediate transmission of a new State-Change Report only if the 
new change is of the same type as the current change.

Notes:

Section 5.1 says: "If the interface reception-state change that triggers the new report is a filter-mode change, then the next [Robustness Variable] State-Change Reports will include a Filter-Mode-Change record. This applies even if any number of source-list changes occur in that period. The host has to maintain retransmission state for the group until the [Robustness Variable] State-Change reports have been sent.".

It is clearly stated that if a source-list changes occur before all the retransmissions of the State-Change Report for the filter-mode change have been completed, The host has to maintain retransmission state for the group until the [Robustness Variable] State-Change reports have been sent. Therefore, in this case it must not immediately send a new State-Change Report.
--VERIFIER NOTES--
RFC 3376 author Bill Fenner said (private email, Feb 9 2024, shared with permission):

Hi Aymen,

Thanks for your interest in IGMPv3. I don't think your proposed change is correct, because one of the fundamental goals of IGMP is to communicate about changes immediately, so a change to say that you don't notify about a change immediately is against that goal.

One thing that makes IGMPv3 a little hard to understand is the complete separation between the interface (see section 2 - the IPMulticastListen() primitives) and the protocol. When nothing complicated is happening, a call to IPMulticastListen() will be tightly tied with a similar message, which makes it even harder to understand the behavior when something complicated happens.

Let's start with the API calls that invoke a set of messages: I think a sequence that is covered by the paragraph in question is:

1. at time T: IPMulticastListen( socket, interface, multicast-address, INCLUDE, { A } );
2. at time T1, where T1-T is less than the robustness interval: IPMulticastListen( socket, interface, multicast-address, INCLUDE, { A, B } )
(Alternatively, this could be a different socket, IPMulticastListen( socket2, interface, multicast-address, INCLUDE, { B } ) since the socket interface has to create a union of all includes to communicate to the router)

I think this is the case that you propose not to send - the first one is a filter mode change, and the second one is a source list change, and those changes are of different types.

However, the intent of section 5.1 is that you *do* send a message at time T1; it's just still TO_IN because you're not done with the robustness count of sending the filter mode change.

A high level view of the processing, assuming a robustness variable of 3, is:
Time T: 3 tramsissions total of IS_IN state scheduled, first one sent as TO_IN(A)
Time T1: 3 transmissions total of "add B" scheduled, first one sent as TO_IN(A,B)
Time T2: TO_IN(A,B)
Time T3: ALLOW(B)

This results in 3 transmissions of the filter mode change, and also 3 transmissions of the source list change. They're bundled together in the transmissions at time T1 and T2; that's the goal of section 5.1.

Please let us know if you have any more questions.

Thanks,
Bill

Report New Errata