Proxy Query Messages

Introduction IGMP snooping is a feature included in many managed switches that provides optimal distribution of multicast traffic on the LAN. It works by having the switch, which typically operates at the data link layer, observe IGMP Membership Report messages to learn which link(s) are interested in a given multicast group and adjust an internal forwarding database according. The IPv6 equivalent, MLD snooping, behaves in a similar manner, observing Multicast Listener Report messages. This operation blurs the functional boundaries between layers in the network stack. It also involves standards from two organizations: IEEE and IETF. Unfortunately, there is no authoritative specification for this operation. Instead, it was developed by vendors and later documented in , an Informational RFC that describes the operation and records differences in vendor implementations. , list item 4 describes a Proxy Query, a special-purpose Membership Query message with an IPv4 source address of 0.0.0.0. A Proxy Query is a Membership Query message that must not be included in Querier election, but are otherwise handled as a normal Query. describes the equivalent message in MLD and indicates that it should use the IPv6 unspecified address (::). However, several documents prohibit this:

requires all MLD messages to be sent with an IPv6 link-local source address
requires MLD Query messages to be sent with a valid IPv6 link-local source address
requires both that 1) MLD Query messages be sent with a valid IPv6 link-local source address and that 2) nodes discard Query messages without a valid IPv6 link-local source address

Because the recommendation to use the IPv6 unspecified address came from an Informational RFC, it does not overrule the precedent established in these authoritative documents. This raises the question of how Proxy Query messages should be implemented in MLD. Similarly, because the concept of a Proxy Query message is only described in an Informational RFC, both the authority and applicability of this message are uncertain. This document does the following to resolve these concerns:

Updates and to specify operation of a Proxy Query
Formally removes the recommendation to use the IPv6 unspecified address for Proxy Query messages in MLD

Unlike , this document can be considered authoritative because it affects and , both IETF protocols.

Terminology 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 when, and only when, they appear in all capitals, as shown here.

IGMP Proxy Query If an IPv4 multicast router receives an IGMP Membership Query with its IPv4 source address set to 0.0.0.0, then it MUST NOT use that message in the querier election process described in . If the IPv4 source address is not set to 0.0.0.0, then the multicast router MUST use that message in the querier election process. All other handling for this message remains unchanged.

MLD Proxy Query Instead of working against precedent established by the documents listed in , this document requests assignment of a new flag in the "IGMP/MLD Query Message Flags" registry: the P (Proxy Query) flag. To conserve flags and avoid duplicate functionality, this assignment is only made for MLD Query messages; the flag remains unassigned for IGMP Query messages. If an IPv6 multicast router receives an MLD Multicast Listener Query with the P flag set to 1, then it MUST NOT use that message in the querier election process described in . If the P flag is set to 0, then the multicast router MUST use that message in the querier election process. All other handling for this message remains unchanged. This document updates to formally withdraw the recommendation to use the IPv6 unspecified address for Proxy Query messages in MLD.

Operational Considerations The attributes that identify a Proxy Query were chosen such that no updates are needed for networks that do not use Proxy Query messages. Operators deploying devices that send IGMP Proxy Query messages MUST ensure that any IPv4 multicast router they want to serve as Querier processes IGMP Membership Query messages as per of this document, which is based on the recommendation in , list item 4. This ensures that the appropriate router will participate in Querier election and continue to send IGMP Membership Query messages as per . Operators deploying devices that send MLD Proxy Query messages onto a network with one or more IPv6 multicast routers that do not support these messages MUST ensure that any router they want to serve as Querier is given a lower IPv6 address than any device that sends Proxy Query messages. This ensures that the appropriate router will participate in Querier election and continue to send MLD Multicast Listener Query messages as per .

Security Considerations TODO

IANA Considerations IANA should allocate a new flag in the IGMP/MLD Query Message Flags Registry with the following properties:

Flags Bit: 1
Short Name: P
Description: "Proxy Query"
Reference: this document