IGMP/MLD Error Feedback

Requirements have been formulated for means to provide mutticast terminals with error feedback when the IGMP/MLD Querier did not or could not process an IGMP/MLD Membership Report message (, section 4). Operator's experience with IPTV deployments show that introducing such a feedback in IGMP exhanges between terminals and multicast access equipments would help provide a better service (e.g. a liaison between the IETF mboned working group and the DSLForum was made in December 2005 to discuss this issue, but didn't lead to a standardized solution). An examples case is when an IGMP Querier refuses to take into account an IGMP Membership Report because the number of multicast channels would outpass the allowed threshold for the service. Many other examples of the case where an IGMP error feedback channel would be useful are presented in . This document describes new message encodings and the associated procedures, all of which being optional and preserving full backward and forward compatibility, and details the impact on the host API for multicast subscriptions. This document doesn't state yet whether the messages should be carried over IGMP, ICMP or another protocol, but tries to document the pros and cons of the different alternatives, to guide the decision process.

The terminology in this document is the terminology used in and . For readability, "Querier" and "Host(s)" will be used thoughout this document, in place of "IGMP or MLD Querier" and "IGMP or MLD Host(s)".

The DSLForum expressed interest for such a feature, which was discussed in a liaison with the Magma IETF Working group. The specifications described in this document try to address the comments exchanged on the magma WG mailing-list.

The procedures described in this memo are fully optionnal : their only intent is to carry informative data from the IGMP/MLD Querier to the IGMP/MLD Hosts. Most specifically, the intent is that: the procedures don't change the state machine of the IGMP Querier or IGMP Host, the information carried is only meant to provide information to the application subscribed to multicast data an IGMP Host implementing these specifications will behave correctly in the absence of these informations. the behavior of an IGMP Querier implementing these specifications is unchanged whether or not the hosts implement these specs. Last, these specifications are not meant to carry information about transient errors that the network is supposed to recover from, like network outages.

The following procedures introduce a new type of message : the Feedback message. See section xxx for details about message encodings. Using these procedures a Querier can optionally emmit a Feedback message after receiving a Membership Report message that it can not process (see for example reasons on why a Querier would not process a Membership Report message). The Feedback message carries error type/sub-type field, and information about the group to which the error pertains. Optionally, if IGMPv3/MLDv2 is used, and if the error message pertains to some specific sources, the addresses of the sources to which the error pertains are included in the message. The address to which the Feedback message will be sent is determined as follows: if IGMPv3/MLDv2 is used and if the sender IP address is not 0.0.0.0 or 0000::/32, the address of sender of the IGMP Membership Report is used else, the group address that was mentioned in the Membership Report message is used The source address MUST be the same address as the address used for Query messages, and the TTL MUST be set to 1. If IGMPv2/MLDv1 is being used, only one feedback message should be sent for a said Membership Report message. If IGMPv3/MLDv2 is being used, only one feedback message should be sent for each (S,G) in the Membership Report message. In any case the amount of Feedback messages sent on a link MUST be rate-limited,

When a Host receives an Feedback message, it MAY process it. Processing a Feedback message consists in : MANDATORY checking that the TTL is set to 1 OPTIONALLY checking that the message source address is the address of a known Querier parsing the Feedback message determining the network sockets for which the Feedback message is relevant (G is the group address of the Feedback message) if no source address is included in the Feedback message, the sockets are the sockets that have some active forwarding state related to G (subscribed to G with a non-null include list) if some source addresses are indicated in the Feedback message, the sockets are the sockets to which traffic from at least one of these sources, and toward G, would be forwarded notifying these sockets of the error (see ) OPTIONALLY logging the error and/or doing any local action depending on policy

This document currently only proposes a base encoding for the Feedback message. Discussion is left open on the protocol on which these messages should be piggybacked on, though ICMP and IGMP/MLD are natural candidates. The definitive choice and exact detailed encodings will be detailed in a later revision.

Encoding of the error feedback message type, is as follows: error type (1 byte) error sub-type (1 bytes) group address (field length depends on IP protocol revision used) number of sources in error (possibly zero), followed by the source addresses in error (possibly none, field length depends on IP protocol revision used and number of sources) [ nice ASCII-art might be considered for future revisions ]

ICMP and IGMP/MLD are candidates for carrying the error feedback message. This section exposes the pros/cons of both alternatives, and ought to be removed once a decision is made on one of them.

The Feedback message could be an ICMP message that would use a new ICMP message type (or possibly reusing existing types and codes). Pros: ICMP is already used to carry error messages between routers and hosts (e.g.. port unreachable message) ICMP has an extensible format which could easily be reused for the Feedback function described in this memo Implementations of network socket APIs already take into account ICMP messages Cons: ICMP has currently nothing to do with multicast today some RFC explicitly forbid the sending of ICMP in reaction to receiving multicast packets, and IGMP/MLD Membership Reports are multicast packets ( section 7.2 and 3.2.2, section 4.3.2.7) (see ). ICMP messages are (currently) never sent toward multicast addresses, whereas that would be required to send Feedback messages to IGMPv2/MLDv1 hosts

The Feedback message could be an IGMP or MLD message that would use new IGMP/MLD message types. Pros: IGMP and MLD are the protocols used for all operations related to multicast subscription Cons: possibly more work to define the encodings a new IANA registry might be needed to manage Feedback error codes definition of how the network socket API will be used to carry the information to the applications has to be defined

This section describes some proposed based error types: improper message : the Membership Report message is improper (the group address is not in the 224/0 or FF00::/8 range, or specified sources are improper addresses) IGMP version not supported by querier wildcard on an SSM group : IGMPv2 or IGMPv3/MLDv2 with Exclude source filter mode was asked, but the group address is not in the SSM range of the Querier exclude source filter mode not supported by the Querier group administratively prohibited source(s) administratively prohibited resource limit reached multicast reception is disabled on the link [ This section will later be completed to include error type numbers ] Remind that the Feedback message is NOT meant to carry information about transient errors that the network is supposed to recover from, like for instance network outages. An IANA registry may be required to manage these and future error codes, and provide third party with the ability to define error codes for IGMP/MLD error feedback.

[ TBC : working group guidance is sought on how to link these specifications with possibly needed evolution of the POSIX network socket API ] This section describes how the information from Feedback messages is supplied to applications subscribed to multicast stream, and expecting the reception of multicast datagrams on a socket. A requirement is fully backward compatibility with applications not supporting these specifications : an application not supporting these specifications must not be affected by a Feedback message. For instance, a wrong solution would be to return an error on a read() or recv() call. A second requirement is to allow an application to keep receiving data on a socket, even if some error was reported through a Feedback message, for a group or channel joined on this socket. This is needed, for instance, in two cases : when a socket is used to join multiple distinct group or channels and only one of them is subject to an error ; when a socket is used to join only one multicast group, for which the Querier sends a Feedback message, but there are members for this group sending data on a directly connected link. A proposal is to rely on the use of the MSG_ERRQUEUE flag of the recvmsg()/recvfrom() POSIX calls. This call allows the socket user to retrieve the network errors queued for the socket. Further work is required to fully describe how information from the Feedback message would be mapped in the sock_extended_err structure. Another proposal would be to allow the setsockopt() and set(ipv4)sourcefilter() calls to return an error. That would require the local network stack to wait for some time after sending a Membership Report message, before being able to return from the setsockopt()/set(ipv4)sourcefilter() call, and would not easily allow to carry detailed information about the specific group or channel in error. Consequently, this approach doesn't seem a viable one.

To support this Feedback mechanism, an IGMP or MLD proxy SHOULD send Feedback messages received on its Host side toward its Querier side(s) that have matching multicast memberships. The procedures for sending the Feedback messages are then the same as for a normal Querier, as specified in : in particular the IGMP/MLD proxy MUST use its own address as the source address of the Feedback message. A new member of a multicast group already forwarded by the proxy on its Querier side, will have to wait for some time before having a chance to receive a Feedback message : timers will have to trigger before the Querier on the Host side of the proxy sends a Query, causing the proxy to send a Membership Report that may then cause the Querier on the Host side to send a Feedback message, and this Feedback message to be propagated to the new receiver. To quickly provide Feedback messages to receivers on its Querier side, the proxy MAY cache the Feedback messages that it receives on the Host side to later match them with Membership Report messages received on its Querier side, and send relevant Feedback messages in reaction to these. If doing Feedback message caching, the proxy MUST keep only one Feedback message per (S,G) entry or (*,G) entry. It MUST also remove a Feedback message from its cache, if a same Feedback message hasn't been sent in the last <> seconds by the Querier on its Host side. Last, an IGMP/MLD proxy MAY produce its own Feedback messages. In that case it MUST still respect procedures of .

IGMP/MLD snooping equipments are expected to transparently interoperate with the procedures described in this document, given that RFC 4541 section 2.2.1(3) states that "[a] switch that supports IGMP snooping must flood all unrecognized IGMP messages to all other ports".

Request to IANA for ICMP or IGMP code point allocation would expectedly be requested in the future for the messages defined in this document. [Note to RFC Editor: this section may be removed on publication as an RFC.]

Given that the specifications in this document do not change nor the state machine of the IGMP/MDLD Querier and Host stack, nor the datagrams that will be received by an application, they are not expected to introduce security issues not already existing with IGMP/MLD or the protocol used to carry the Feedback message. A possible issue would be to have wrong Feedback sent toward multicast applications. Such an issue could arise if spoofed Feedback messages are sent and interpreted by multicast receiver hosts. This issue is mitigated by the fact that IGMP/MLD Hosts MUST check that the TTL of the Feedback messages is 1, and MAY also check the source IP of the Feedback message against a list of known Queriers. Another possible issue is denial of service of the Querier function, that would be due to having the IGMP/MLD Querier be overloaded by Feedback messages to send. This is mitigated by allowing the Querier to rate-limit the flow of Feedback messages. On a LAN, such a rate-limiting would possibly result in some receivers not receiving the feedback message that they would have, which is a form of denial of service, but only on the Feedback function by itself, with no impact on the rest of the multicast group membership control protocol infrastructure. This later type of denial of service might be mitigated by doing rate-limiting based on the source address of the receivers (the source address of the Membership Report triggering the Feedback message); but such mechanism may themselves be subject to weaknesses due to Membership Report spoofing.

Acknowledgments go to DSLForum contributors who provided an initial proposal, to IETF participants that participated in the discussion on the magma WG list, from which guidance and inspiration was largely taken. Thank you to Bill Fenner for providing detailed information on issues related to ICMP errors in reaction to multicast datagrams.