Proxy Query Messages

Status of This Memo

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

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

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

This Internet-Draft will expire on 6 May 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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

Table of Contents

1. 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 [SNOOP], an Informational RFC that describes the operation and records differences in vendor implementations.¶

[SNOOP], Section 2.1.1, 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.¶

[SNOOP], Section 3 describes the equivalent message in MLD and indicates that it should use the IPv6 unspecified address (::). However, several documents prohibit this:¶

• [MLDv1], Section 3 requires all MLD messages to be sent with an IPv6 link-local source address¶

• [RFC3590], Section 4 requires MLD Query messages to be sent with a valid IPv6 link-local source address¶

• [MLDv2], Section 5.1.14 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:¶

1. Updates [IGMPv3] and [MLDv2] to specify operation of a Proxy Query¶

2. Formally removes the recommendation to use the IPv6 unspecified address for Proxy Query messages in MLD¶

Unlike [SNOOP], this document can be considered authoritative because it affects [IGMPv3] and [MLDv2], both IETF protocols.¶

2. 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 [IGMPv3], Section 6.6.2. 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.¶

3. MLD Proxy Query

Instead of working against precedent established by the documents listed in Section 1, 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 [MLDv2], Section 7.6.2. 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 [SNOOP], Section 3 to formally withdraw the recommendation to use the IPv6 unspecified address for Proxy Query messages in MLD.¶

4. 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 Section 2 of this document, which is based on the recommendation in [SNOOP], Section 2.1.1, list item 4. This ensures that the appropriate router will participate in Querier election and continue to send IGMP Membership Query messages as per [IGMPv3], Section 6.6.2.¶

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 [MLDv2], Section 7.6.2.¶

5. Security Considerations

TODO¶

6. 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¶

7. References

Author's Address