pim N. Karstens Internet-Draft Garmin Updates: [4541, 9776, 9777] (if approved) 2 November 2026 Intended status: Standards Track Expires: 6 May 2027 Proxy Query Messages draft-karstens-pim-proxy-query-messages-00 Abstract TODO: provide abstract 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. Karstens Expires 6 May 2027 [Page 1] Internet-Draft Proxy Query Messages November 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. IGMP Proxy Query . . . . . . . . . . . . . . . . . . . . . . 3 3. MLD Proxy Query . . . . . . . . . . . . . . . . . . . . . . . 4 4. Operational Considerations . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 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 Karstens Expires 6 May 2027 [Page 2] Internet-Draft Proxy Query Messages November 2026 * [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. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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. Karstens Expires 6 May 2027 [Page 3] Internet-Draft Proxy Query Messages November 2026 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 Karstens Expires 6 May 2027 [Page 4] Internet-Draft Proxy Query Messages November 2026 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 7.1. Normative References [BRIDGE] IEEE, "IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Bridges", IEEE Std 802.1D-2004, 2004. [IGMPv3] Haberman, B., Ed., "Internet Group Management Protocol, Version 3", STD 100, RFC 9776, DOI 10.17487/RFC9776, March 2025, . [MLDv2] Haberman, B., Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", STD 101, RFC 9777, DOI 10.17487/RFC9777, March 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SNOOP] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, . 7.2. Informative References Karstens Expires 6 May 2027 [Page 5] Internet-Draft Proxy Query Messages November 2026 [MLDv1] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, . [RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, DOI 10.17487/RFC3590, September 2003, . Author's Address Nate Karstens Garmin International Email: nate.karstens@garmin.com Karstens Expires 6 May 2027 [Page 6]