A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices
Extracted elements (18)
IGMP Proxies and MLD Proxies are placed in separate schema branches rather than a combined branch. This allows independent optional support for IPv4 and IPv6, models minor behavioral differences more cleanly, and is consistent with other YANG models like RFC 8652 that use separate branches per address family.
The model declares two separate YANG features ('igmp-proxy' and 'mld-proxy') rather than a single combined feature, giving vendors the flexibility to implement only the address family they support while still conforming to the module.
The YANG module conforms to the Network Management Datastore Architecture (NMDA) as defined in RFC 8342, and augments the NMDA-version routing data model from RFC 8349. Implementations must support NMDA to use this module correctly.
To configure downstream interfaces for IGMP/MLD Proxies, the ability to enable IGMP or MLD on those interfaces is required, which is defined in the separate YANG module from RFC 8652 ('A YANG Data Model for IGMP and MLD'). This document only covers the proxy-specific upstream interface configuration.
The upstream interface for an IGMP Proxy MUST NOT be configured to use PIM. This is enforced via a YANG 'must' constraint: the interface name must not appear in the PIM interface list under /rt:routing/rt:control-plane-protocols/pim-base:pim.
The upstream interface for an MLD Proxy MUST NOT be configured to use PIM. This is enforced via a YANG 'must' constraint checking that the interface name does not appear in the PIM interface list.
Each source entry under a group contains source-address, up-time (uint32 seconds), and a downstream-interface list (read-only) mapping which downstream interfaces are receiving traffic for that (S,G) or (*,G) entry on the upstream interface.
The filter-mode leaf within state-group-attributes is a mandatory enumeration with values 'include' (receive only from listed sources) and 'exclude' (receive from all sources except listed). This reflects IGMPv3/MLDv2 source-specific multicast filtering.
The module augments /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol with an 'mld-proxy' container (guarded by the 'mld-proxy' feature) containing an 'interfaces' list of upstream interfaces with per-interface configuration including mld-version (uint8, range 1..2, default 2), enabled (boolean, default true), and sender-source-address (inet:ipv6-address-no-zone).
The module defines two YANG identities ('igmp-proxy' and 'mld-proxy'), both derived from rt:control-plane-protocol, enabling the proxy instances to be instantiated as control-plane protocols within the ietf-routing data model.
The read-only 'group' list under each upstream interface tracks multicast group membership state, keyed by group-address (ipv4-multicast-group-address for IGMP, ipv6-multicast-group-address for MLD). Each group entry includes up-time (uint32, seconds), filter-mode (enumeration: include or exclude), and a source list.
The sender-source-address leaf specifies the source address used in IGMP/MLD membership report and leave messages sent by the proxy. For IGMP it is inet:ipv4-address-no-zone; for MLD it is inet:ipv6-address-no-zone.
The YANG module 'ietf-igmp-mld-proxy' defines two optional features: 'igmp-proxy' for IGMP Proxy protocol support (IPv4) and 'mld-proxy' for MLD Proxy protocol support (IPv6). Either or both features may be implemented independently.
IANA registered the namespace URI 'urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy' in the IETF XML Registry (RFC 3688).
IANA registered the YANG module 'ietf-igmp-mld-proxy' with prefix 'igmp-mld-proxy' and namespace 'urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy' in the YANG Module Names registry (RFC 6020).
Read access to the igmp-proxy and mld-proxy subtrees must be controlled because the operational state data (group membership and source information) can expose which multicast groups hosts have joined, disclosing potentially sensitive group membership information.
The YANG module is designed for access via NETCONF (mandatory secure transport: SSH per RFC 6242) or RESTCONF (mandatory secure transport: TLS per RFC 8446). Deployment must use these secure transports to protect configuration and state data.
Unauthorized write access to the igmp-proxy or mld-proxy interface subtrees can cause proxy interfaces to be deleted or reconfigured, potentially leading to network malfunctions, misdelivery of multicast packets, and disruption of multicast forwarding. NACM (RFC 8341) should be used to restrict write access.