IP Multicast Explained: IGMP, MLD, PIM and How to Secure It

IP multicast lets one sender transmit a single stream that the network copies only where receivers have asked for it, instead of sending one copy per receiver (unicast) or one copy to everybody on the segment (broadcast). Hosts ask for a group with IGMP on IPv4 or MLD on IPv6, switches use snooping to keep the stream off ports that did not ask, and routers use PIM to build distribution trees between subnets. Securing it means controlling who can send, who can join, which routers may act as querier or rendezvous point, and keeping link local discovery protocols such as mDNS and SSDP inside the link.

Multicast is the quiet protocol family under a lot of everyday networking. Your laptop joins a handful of groups the moment it gets an address. Printers and speakers announce themselves with it. Routing protocols such as OSPF use it to find neighbours. Trading floors and IPTV networks depend on it for volume. Because it is mostly invisible, it is also mostly unaudited, and the defaults are tuned for convenience on a trusted segment.

This post continues our one protocol per post series. For neighbouring layers, see IPv6 address autoconfiguration, OSPF and link state routing, how Ethernet switching works and LLDP and what it reveals. Here we stay on multicast itself: addresses, group membership, snooping, PIM trees, where it shows up, what can go wrong, and how to see and limit it on a Linux host or a lab network.

Key takeaways

• IPv4 multicast uses 224.0.0.0/4 (224.0.0.0 to 239.255.255.255). IPv6 multicast uses ff00::/8, and the fourth hexadecimal digit of the address carries its scope, so ff02:: is link local and ff05:: is site local.
• Hosts tell routers which groups they want with IGMP (IPv4) or MLD (IPv6). The current specifications are RFC 9776 for IGMPv3 and RFC 9777 for MLDv2, both published in March 2025 as Internet Standards STD 100 and STD 101. They obsolete RFC 3376 and RFC 3810, which most documentation still cites.
• On each subnet one router is elected querier: the one with the lowest IP address. That rule is simple and unauthenticated, so a forged query from a lower address can take the role.
• A plain Ethernet switch treats multicast like broadcast and floods it to every port in the VLAN. IGMP and MLD snooping (described in RFC 4541) lets the switch forward a group only to ports that joined it, plus router ports.
• PIM sparse mode (RFC 7761) builds shared trees through a rendezvous point (RP) and then switches to shortest path trees. Source specific multicast (SSM, RFC 4607) skips the RP entirely: receivers ask for a specific source and group pair, using 232.0.0.0/8 on IPv4 and ff3x::/32 on IPv6.
• None of the core group management messages are encrypted, and authentication is optional (the specifications describe IPsec, which is rarely deployed for it). The practical defences are boundaries, filters and pinned roles: scope groups, filter joins, pin the querier and RP, block unsolicited sources, and keep mDNS and SSDP from ever answering off the link.
• CISA lists SSDP with a bandwidth amplification factor of 30.8 and mDNS with 2 to 10 when they respond to the internet. Neither should ever be reachable from outside the local link.

What IP multicast is and how it differs from unicast and broadcast

There are three ways to deliver an IP packet to more than one place.

Unicast sends a packet to one address. If 500 viewers want the same video, the source sends 500 copies, and every link between the source and the viewers carries every copy that passes over it.

Broadcast sends a packet to every host on a subnet (on IPv4, the subnet broadcast address or 255.255.255.255). Routers do not forward it, so it cannot cross subnets, and every host on the segment has to receive and discard the packet even if it does not care. IPv6 has no broadcast at all; it uses multicast for everything broadcast used to do.

Multicast sends one packet to a group address. The network replicates the packet only at the points where the paths to interested receivers split. A receiver opts in, the network remembers that, and a link with no interested receivers carries nothing. The source does not need to know who is listening or how many receivers there are.

The model goes back to Steve Deering's host extensions, published as RFC 1112 in August 1989. It defined the idea of a host group, the class D address space, IGMP version 1 and the mapping from IP group addresses to Ethernet multicast MAC addresses. Almost everything that came later refines that model rather than replacing it.

A few properties follow from the design and matter for security later:

• Multicast rides on UDP (or raw IP), not TCP. There is no handshake with receivers, so there is no connection state that proves who is on the other end.
• Anyone on a link can join anything. Joining a group is an unprivileged operation on most operating systems. The IGMPv3 specification says so directly in its security section: forging a local report is pointless because a local user can simply join.
• Anyone can send to a group. In the classic "any source" model, a router forwards traffic for group G from whatever source appears. This is the main reason the IETF now recommends source specific multicast between networks.
• TTL and hop limit control reach. RFC 5771 reserves the 224.0.0.0/24 local network control block for protocol control traffic that is not forwarded off link, and its protocols send with TTL 1. Application streams use larger values, and scope boundaries are enforced by router configuration, not by the packet.

IPv4 multicast addresses: 224.0.0.0/4

IPv4 multicast occupies the old class D space, 224.0.0.0 to 239.255.255.255. The IANA IPv4 multicast address space registry (last updated 20 August 2026 when we checked) and RFC 5771 (March 2010) divide it into blocks. The ones you meet in practice:

Some well known individual groups from the IANA registry:

SSDP's IPv4 group, 239.255.255.250, sits inside the administratively scoped block and is defined by the UPnP device architecture rather than by an individual IANA entry.

IPv6 multicast addresses: ff00::/8

On IPv6 every address that begins with ff is multicast. RFC 4291 (February 2006) defines the format: after the ff come four flag bits and a four bit scope field, then a 112 bit group ID. The scope is the useful part for operators because it is visible in the address itself:

The flags mark whether an address is permanently assigned (flag clear, the "well known" addresses) or transient, and whether it is derived from a unicast prefix. An address starting ff3x:: is a unicast prefix based transient address, and RFC 4607 reserves ff3x::/32 for source specific multicast.

Well known IPv6 groups from the IANA IPv6 multicast registry (last updated 7 April 2026 when we checked):

IPv6 also uses solicited node multicast addresses (ff02::1:ffXX:XXXX) for Neighbor Discovery, so even a host that never runs a multicast application is a member of several groups. This is why switches that break MLD can break basic IPv6 reachability.

From group address to Ethernet MAC address

Multicast frames on Ethernet need a destination MAC address. RFC 1112 maps an IPv4 group by placing the low order 23 bits of the IP address into the Ethernet multicast address 01-00-5E-00-00-00. Because a group address has 28 significant bits and only 23 make it into the MAC, 32 different IPv4 groups share each multicast MAC address. 224.1.1.1 and 239.129.1.1 both become 01:00:5e:01:01:01, so a host or a non snooping switch filtering on MAC alone will receive both.

IPv6 is simpler. RFC 2464 maps a group to a MAC whose first two octets are 33:33 followed by the low 32 bits of the IPv6 address. ff02::fb becomes 33:33:00:00:00:fb.

That mapping overlap is one reason operators avoid choosing groups like x.0.0.y and x.128.0.y, which collide with the link local control block at the MAC layer and may be flooded by switches that flood 224.0.0.x addresses.

How hosts join groups: IGMPv2, IGMPv3 and MLDv2

Routers need to know whether anyone on an attached subnet wants a group. They learn it from IGMP on IPv4 and MLD on IPv6. MLD is not a separate IP protocol: it is a set of ICMPv6 message types (130, 131 and 132 for MLDv1, plus type 143 for MLDv2 reports). IGMP is IP protocol 2.

All of these messages are link local. IGMPv3 messages are sent with TTL 1 and carry the IP Router Alert option. MLD messages must use a link local IPv6 source, a hop limit of 1 and an IPv6 Router Alert in a hop by hop header. Routers do not forward them.

The RFC numbers, confirmed

The topic brief for this post listed RFC 3376 and RFC 3810. Those are the documents most guides still point to, but they are no longer current:

RFC 9776 describes itself as a revised version of RFC 3376 with clarifications and errata fixes, backward compatible with it. RFC 9777 does the same for MLDv2. Both moved the protocols to full Internet Standard status. Anything you configured against the older RFCs still interoperates.

IGMPv2: join, report, leave

IGMPv2 has three message types that matter: Membership Query, Version 2 Membership Report and Leave Group.

1. Join. When an application on a host joins a group, the host immediately sends an unsolicited Membership Report to the group address itself.
2. Query. The elected querier periodically sends a General Query to 224.0.0.1, the all systems address. Each host that belongs to a group sets a random delay timer and, if no other host reports first, sends a report for that group. Hosts suppress their own report when they hear someone else's, because the router only needs to know that at least one member exists.
3. Leave. When the last application leaves a group, the host sends a Leave Group message to 224.0.0.2 (all routers). The querier then sends a Group Specific Query to check whether anyone else still wants it, and if no report comes back within the last member query time, it stops forwarding.

The weakness of IGMPv2 is that it only knows about groups. A receiver asks for "group G" and gets traffic from every source that sends to G.

IGMPv3 and MLDv2: source filtering

IGMPv3 adds source filtering. A host reports, for each group, a filter mode and a source list:

• INCLUDE mode with a list of sources means "send me group G, but only from these sources".
• EXCLUDE mode with a list means "send me group G from everyone except these sources". EXCLUDE with an empty list is the old IGMPv2 style "any source" join.

Reports are no longer sent to the group address. IGMPv3 hosts send reports to 224.0.0.22, the address all IGMPv3 capable routers listen on. MLDv2 hosts send reports to ff02::16. Report suppression is gone: every host reports for itself, which lets routers and snooping switches track individual members and leave quickly.

Hosts send two kinds of report. Current State Reports answer queries. State Change Reports are sent unsolicited when the host's filter for a group changes, and are retransmitted Robustness Variable times so a single lost packet does not break the change.

Routers keep, per group, a filter mode, a group timer and a timer per source. This state is what lets a router forward (S, G) traffic only from requested sources and is the foundation for source specific multicast.

MLDv2 is functionally the same protocol for IPv6. RFC 9777 notes that it is interoperable with MLDv1, as IGMPv3 is with IGMPv2.

What queriers do, with numbers

One router per subnet is elected querier. For IGMP the rule is the lowest IPv4 address; for MLD it is the lowest IPv6 address. Every router starts by assuming it is the querier and sends a burst of startup queries. When it hears a General Query from a lower address, it falls silent and starts an Other Querier Present timer. If that timer expires without hearing the winner again, it resumes querying.

The default timers in RFC 9776 section 8:

Two derived values decide how quickly the network reacts:

Worked example 1: Group Membership Interval. This is how long a router waits without hearing a report before deciding a group has no members. RFC 9776 defines it as Robustness Variable times Query Interval, plus two Query Response Intervals: 2 × 125 + 2 × 10 = 270 seconds. RFC 3376 defined it with one Query Response Interval, which gives 2 × 125 + 10 = 260 seconds. The 10 second change is small, but if you are reading older vendor documentation that says 260, this is where the difference comes from.

Worked example 2: Other Querier Present Interval. This is how long the non querier routers wait before taking over. It is Robustness Variable times Query Interval plus half a Query Response Interval: 2 × 125 + 0.5 × 10 = 255 seconds. So if an attacker takes over the querier role with a forged query and then goes silent, the legitimate router stays quiet for more than four minutes. During that time, if the forger ignores leaves, streams can keep flowing to groups with no members for up to the 270 second group membership interval. The RFC 9776 security section describes exactly this outcome.

Worked example 3: leave latency. With defaults, after the last member sends a leave, the querier sends Last Member Query Count (equal to Robustness Variable, so 2) group specific queries one Last Member Query Interval apart. The stream stops roughly 2 seconds after the leave if nobody answers. For an IPTV channel change that is noticeable, which is why many access switches offer an immediate leave or fast leave option on ports with a single receiver.

Version compatibility

If a router hears an older version query on a subnet, the IGMPv3 specification says it must fall back to the oldest version present. Hosts do the same when they hear an older querier. This keeps old devices working, but it also means one IGMPv1 or IGMPv2 speaker, real or forged, can drag a whole segment down to the older behaviour. The security section of RFC 9776 points out that a forged v1 report puts a router into "v1 members present" state, in which it ignores leaves.

IGMP and MLD snooping on switches

A standard Ethernet switch learns unicast MAC addresses from source addresses and forwards frames to the port where each MAC lives. Multicast MACs never appear as source addresses, so the switch never learns where they live. The default is to treat multicast exactly like broadcast: copy the frame out of every port in the VLAN.

On a small home network that barely matters. On a network carrying a 10 Mbit/s video stream, every port in the VLAN gets 10 Mbit/s of video whether it asked or not. Wireless networks can feel it more, because a multicast frame has to be receivable by every associated client and gets no per client acknowledgement, so a few streams can take a large share of airtime.

IGMP snooping fixes this by letting the switch listen to IGMP (and MLD snooping to MLD) and build a forwarding table of which ports want which groups. RFC 4541 (May 2006) is the informational document that records how snooping switches should behave. Its forwarding rules are worth knowing because they explain most "multicast works sometimes" puzzles:

1. Traffic for groups outside 224.0.0.x is forwarded according to the membership table, and always to router ports.
2. Traffic for 224.0.0.x is forwarded on all ports, because many systems use those addresses without joining, and routing protocols depend on them.
3. An unregistered group (traffic for a group nobody has reported) must be sent to ports with a multicast router attached and may be flooded everywhere. RFC 4541 warns both ways: not flooding can starve IGMPv3 hosts behind switches that do not understand IGMPv3, and flooding can overwhelm hosts so badly that they miss queries.
4. Non IPv4 multicast should keep being flooded unless the switch understands it, which is why MLD snooping needs its own support.

Why flooding still happens with snooping turned on

Several situations put you back into flooding even on a snooping switch:

• No querier. Snooping tables are fed by reports, and hosts only send reports on joins and in response to queries. If there is no multicast router on a VLAN, entries time out and many switches fall back to flooding. The common fix is a snooping querier: a switch configured to send queries on a VLAN that has no router. RFC 4541 also describes switches that proxy queries with a 0.0.0.0 source address, precisely so they are not mistaken for a newly elected querier, and warns that a switch must never inject an IGMPv2 query into an IGMPv3 network.
• Unknown or unregistered groups. A source that starts sending to a group no one has joined is flooded or sent to router ports depending on the switch's unregistered flood setting.
• Link local groups. Anything in 224.0.0.0/24 is flooded by design, and on IPv6 the switch must not block ff02::1 or Neighbor Discovery.
• MAC overlap. Switches that snoop on MAC addresses rather than IP addresses treat all 32 IPv4 groups that share a MAC as one.
• Version mismatch. A switch that snoops IGMPv2 but sees IGMPv3 reports to 224.0.0.22 may not build entries at all.

Router ports and the mrouter problem

A snooping switch also has to know which ports lead to multicast routers, because all traffic and all reports must reach them. Switches learn router ports from queries, PIM hellos, or static configuration, and RFC 4286 (December 2005) defines Multicast Router Discovery for the same purpose. A host that sends a forged query or PIM hello on an access port can get its port marked as a router port and start receiving every group in the VLAN. Pinning router ports and disabling router port learning on access ports closes that gap.

How routers build trees: PIM sparse mode, rendezvous points and SSM

IGMP and MLD end at the first router. Between routers, multicast needs a routing protocol that builds a distribution tree from sources to every subnet with receivers. The dominant one is Protocol Independent Multicast. "Protocol independent" means PIM does not carry its own topology; it uses whatever unicast routing table the router already has (OSPF, IS-IS, BGP or static routes) to work out which interface points back towards a source or an RP.

PIM control messages use IP protocol 103. Link local PIM messages go to the all PIM routers group, 224.0.0.13 on IPv4 and ff02::d on IPv6, with TTL 1.

Reverse path forwarding

Every PIM decision rests on the reverse path forwarding (RPF) check. A router accepts a multicast packet from source S only on the interface it would itself use to send unicast traffic back to S. Packets that arrive on any other interface are dropped. The RPF check prevents loops, and it is also a weak form of source validation: a forged source address must at least arrive from the direction the real source would.

PIM sparse mode

PIM sparse mode (PIM-SM), now specified in RFC 7761 (March 2016, obsoleting RFC 4601 of August 2006), assumes receivers are sparse and nobody gets traffic unless they ask. It works in phases:

1. Designated router election. On each subnet the PIM routers exchange Hello messages (default every 30 seconds, with a default holdtime of 3.5 times that, 105 seconds) and elect a designated router (DR). The DR is the router that acts for hosts on that subnet.
2. Shared tree towards the RP. When the receiver side DR learns from IGMP or MLD that a host wants group G, it sends a (*, G) Join hop by hop towards the rendezvous point for G. Each router along the way adds state, building a shared tree rooted at the RP. Joins are refreshed periodically (t_periodic, default 60 seconds).
3. Registering the source. When a source starts sending to G, its DR encapsulates the packets in unicast PIM Register messages and sends them to the RP. The RP decapsulates them and forwards them down the shared tree. It can also join towards the source, after which it sends a Register-Stop so the source DR stops encapsulating.
4. Switching to the shortest path tree. Once traffic is flowing, the receiver side DR can join directly towards the source with an (S, G) Join, building a shortest path tree, and prune that source off the shared tree. RFC 7761 leaves the switchover policy to the implementation and describes two extremes: switch on the first packet, or an infinite threshold that never leaves the shared tree. A keepalive timer (default 210 seconds) removes (S, G) state when the source goes quiet.

Rendezvous points and how routers find them

Every router must agree which RP serves each group range. The options:

The RP is a critical role. Anyone who can make the network believe they are the RP for a group range receives registers for every source in that range and decides where the shared tree goes.

Source specific multicast

SSM, defined in RFC 4607 (August 2006), removes the RP. The receiver names the source as well as the group, and the pair (S, G) is called a channel. The receiver side DR joins directly towards S, so there is no shared tree, no Register messages and no source discovery problem. RFC 4604 (August 2006) explains how hosts use IGMPv3 and MLDv2 INCLUDE mode reports to request channels.

SSM addresses are 232.0.0.0/8 on IPv4 and ff3x::/32 on IPv6. In SSM a router builds forwarding state only for (S, G) channels that receivers have explicitly requested, so traffic to 232.x.x.x from a source nobody named has no tree to travel down.

From a security point of view this is a large improvement. In any source multicast a stranger can start sending to your group and every receiver gets it. In SSM a receiver only gets the sources it named.

In August 2020 the IETF published RFC 8815 as a Best Current Practice deprecating any source multicast for interdomain multicast and recommending SSM between networks. Any source multicast remains reasonable inside one administrative domain.

Other modes

PIM dense mode (RFC 3973, January 2005, experimental) floods traffic everywhere and prunes it back where no receiver exists. It is simple but wasteful and is rarely used now. Bidirectional PIM (RFC 5015, October 2007) builds one shared tree for many to many applications. The common deployment pattern today is PIM-SM for any source groups inside an organisation and SSM wherever sources are known in advance.

Comparison: IGMPv2, IGMPv3, MLDv1, MLDv2, PIM-SM and SSM

And a decision table for choosing a model:

Where multicast is used every day

Multicast is not just for video networks. A typical laptop on a home network is a member of several groups within seconds of connecting.

Routing and gateway redundancy. OSPF uses 224.0.0.5 and 224.0.0.6 (ff02::5 and ff02::6 for OSPFv3) to find neighbours and flood link state updates. RIPv2 uses 224.0.0.9. VRRP uses 224.0.0.18 for gateway failover. PIM itself uses 224.0.0.13. All of these are link local and rely on the fact that nobody outside the link can reach them.

IPv6 itself. Router advertisements go to ff02::1, router solicitations to ff02::2, and neighbour solicitations to solicited node groups. If multicast breaks on an IPv6 segment, addressing breaks. The SLAAC and DHCPv6 post covers those flows.

mDNS and DNS service discovery. Multicast DNS, RFC 6762 (February 2013), lets devices resolve names ending in .local without a DNS server by sending DNS queries to 224.0.0.251 or ff02::fb on UDP port 5353. Combined with DNS based service discovery (RFC 6763), it is how printers, speakers, screen casting targets and file shares announce themselves. Answers often contain host names, device models and service names.

SSDP and UPnP. Simple Service Discovery Protocol, part of UPnP, uses 239.255.255.250 and ff02::c on UDP port 1900. Devices announce themselves with NOTIFY messages and answer M-SEARCH discovery requests with a pointer to an XML device description. Smart TVs, media servers and many home routers speak it.

LLMNR. Link local multicast name resolution uses 224.0.0.252 and is still enabled on some desktop operating systems as a fallback when DNS fails.

IPTV and video distribution. Many providers carry live television as multicast channels, often SSM, so that a set top box joins one channel at a time. Broadcast studios use multicast for uncompressed video over IP.

Financial market data. Trading venues commonly publish price feeds as multicast, often as two redundant streams on separate groups, because one packet reaching hundreds of subscribers at the same time is fairer and faster than unicast fan out.

Time synchronisation. The Precision Time Protocol (IEEE 1588) uses 224.0.1.129 and ff0x::181 for its primary messages in multicast mode. Power grid, broadcast and telecom networks depend on it for sub microsecond timing.

Software and image distribution. Some operating system deployment tools push one disk image to a lab of machines at once with multicast, which is far faster than one unicast copy per machine.

The security risks of multicast

Multicast protocols were designed for cooperative networks. The core group management and discovery messages carry no encryption and, in practice, no authentication. The IGMPv3 specification is plain about it: any device on a link can passively receive any IGMP message, which can reveal sensitive group memberships or help map the devices on a link. The risks below describe mechanisms and fixes, not attack procedures.

Unauthorised sources

In any source multicast, a router forwards traffic for a group from any source that passes the RPF check. A compromised host, a misconfigured encoder or a test application can start sending to a production group and every receiver will process it. For market data or industrial control that means corrupted input; for video it means a hijacked channel.

Fixes: use SSM wherever sources are known, so receivers only accept named sources. Where any source groups are needed, filter which sources may register with the RP (most implementations support a register policy), apply access lists on source facing interfaces, and keep applications validating the content they receive. Multicast payloads are unauthenticated unless the application authenticates them.

Group flooding and state exhaustion

Each joined group creates state in hosts, switches and routers. A host that joins thousands of groups fills snooping tables and router state, and a source that sends to many unregistered groups may be flooded across a VLAN. The RFC 9776 security section also describes a denial of service against hosts using forged group and source specific queries with very large source lists, which forces the host to store and process sources until it replies, and suggests limiting how much a host stack will record.

Fixes: per port and per VLAN limits on the number of groups and channels, IGMP and MLD join filters that restrict which groups an access port may join, rate limits on control traffic, and host stack limits. On Linux the kernel already caps the number of groups a socket can join and the number of sources per filter.

Rogue queriers

Querier election picks the lowest address and does not check who sent the query. A forged query from a lower address takes the querier role on the subnet. If the forger then stops querying, the legitimate router waits the Other Querier Present Interval (255 seconds with defaults) before resuming, and memberships can go stale. A forged query also tells snooping switches that the port is a router port.

Fixes: pin the querier where your equipment supports it, set access ports so that queries arriving on them are dropped (many switches call this an IGMP or MLD guard or filter), and avoid running snooping queriers on more than the switch you intend. The RFC 9776 security considerations say hosts should ignore version 2 and 3 queries without the Router Alert option and general queries not sent to 224.0.0.1, and that routers should not forward queries.

Rogue PIM routers and rogue rendezvous points

A device that speaks PIM on a link can become a neighbour, win DR election, send joins and asserts, or claim to be a candidate RP if BSR is in use. RFC 7761 section 6 describes forged Hellos, Joins, Asserts, Registers and Register-Stops. A forged Register can make the RP forward bogus data, and a forged Register-Stop can stop a legitimate source from being heard. It notes that Register attacks do not apply to SSM only deployments.

Fixes: enable PIM only on interfaces that face other routers, never on access ports; filter PIM neighbours by address; configure the RP statically or filter BSR candidate RP and bootstrap messages at domain boundaries; filter which groups each RP will serve; and authenticate link local PIM messages with IPsec where your platform supports it. RFC 5796 (March 2010) makes ESP mandatory and AH optional for this, and specifies manual keying as mandatory to implement, because automatic key negotiation for a group of routers on a shared link is harder than for a pair of hosts.

mDNS and SSDP information leakage

mDNS and SSDP were built to tell everyone on a link what you are. That is the feature. It is also a reconnaissance gift on shared networks: hotel and conference Wi-Fi, university halls, flat office networks and guest VLANs. A passive listener can learn device names (often including a person's name), operating system and model, services offered, and which internal services exist. SSDP device descriptions frequently include manufacturer, model, serial number and firmware version.

Fixes: keep discovery traffic on the segments that need it. Disable or restrict mDNS responders on servers, set device names that do not contain personal information, use client isolation on guest wireless, and if discovery must cross VLANs, use a controlled gateway that forwards only specific service types rather than a blanket reflector.

Amplification and reflection

Discovery protocols reply to small requests with large answers, and UDP has no handshake that proves the request came from the address it claims. When a device answers discovery requests from the internet, an attacker can spoof a victim's address and use the device as a reflector. CISA alert TA14-017A on UDP based amplification attacks lists SSDP, with a bandwidth amplification factor of 30.8, and mDNS, with a factor of 2 to 10 via unicast queries. CISA added mDNS to the alert on 19 August 2015, citing CERT Coordination Center vulnerability note VU#550620, published on 31 March 2015, which describes mDNS implementations that respond to unicast queries from outside the local link and warns that the replies can disclose information about devices and be used for amplification.

RFC 6762 already says that a responder receiving a query by direct unicast should check that the source address belongs to the local subnet (or, on IPv6, has an on link prefix) and silently ignore it if not. The problem is implementations and devices that do not enforce that, and home routers that expose UPnP and SSDP on the WAN side.

Fixes: block UDP 1900 and 5353 inbound at every internet edge, confirm that consumer routers do not answer SSDP on the WAN, and follow the CISA guidance of source address validation and ingress filtering.

Scope boundary leaks

Administratively scoped groups (239.0.0.0/8 and the IPv6 scopes below global) only stay inside a boundary if routers at the edge are configured to enforce it. If they are not, organisation local streams can leak to partner links or a provider. Fixes: configure multicast boundaries on edge interfaces that block 239.0.0.0/8 and the matching IPv6 scopes, and test them.

Risk and control summary

Step by step: watch and limit multicast on Linux and a lab network

The following steps run on a Linux host with iproute2, tcpdump and nftables. Replace eth0 with your interface name (ip -br link lists them). None of these commands change routing; the filtering steps change only what this host accepts or forwards.

Step 1: list the groups your host has joined

# All interfaces, IPv4 and IPv6 multicast memberships
ip maddr show

# One interface, IPv6 only
ip -6 maddr show dev eth0

Typical output on a desktop shows 224.0.0.1 (all systems), 224.0.0.251 (mDNS, if a responder is running), ff02::1, ff02::fb and one or more ff02::1:ff solicited node groups. The link lines show the matching 01:00:5e and 33:33 MAC addresses, so you can see the RFC 1112 and RFC 2464 mappings on your own machine.

The kernel's view per interface, including which IGMP version it is using and its timers, lives in procfs:

cat /proc/net/igmp      # IPv4 groups per interface, with version and reporters
cat /proc/net/igmp6     # IPv6 groups per interface
cat /proc/net/mcfilter  # IPv4 source filters (IGMPv3 INCLUDE and EXCLUDE lists)

Step 2: see which processes are listening on discovery ports

sudo ss -ulpn | grep -E ':(5353|1900|5355)\b'

This shows which programs hold sockets on mDNS (5353), SSDP (1900) and LLMNR (5355). On many desktops that is avahi-daemon, systemd-resolved, a browser or a media application.

Step 3: watch IGMP and MLD on the wire

# IGMP: queries, reports and leaves
sudo tcpdump -ni eth0 -vv igmp

# MLD: ICMPv6 inside a hop by hop header with Router Alert
sudo tcpdump -ni eth0 -vv 'ip6[6] == 0'

The IGMP capture shows which device is the querier (its source address on the "igmp query" lines) and which groups each host reports. If the querier's address is not a router you know, find out what it is. The MLD filter matches IPv6 packets whose first extension header is hop by hop, which is how MLD messages are sent; tcpdump decodes the MLD reports inside them.

To force a report so you can see it, join a group with a tool that opens a multicast socket, or simply restart the mDNS responder and watch it join 224.0.0.251.

Step 4: watch discovery traffic and see what it reveals

# mDNS and SSDP announcements and queries on the local link
sudo tcpdump -ni eth0 -A 'udp port 5353 or udp port 1900'

Leave this running for a few minutes on a home network. You will usually see device names, model strings and service types. That is exactly what a stranger on the same Wi-Fi sees. To list mDNS services in a structured way:

avahi-browse -art | head -50

Step 5: check the kernel limits

sysctl net.ipv4.igmp_max_memberships net.ipv4.igmp_max_msf
sysctl net.ipv4.conf.all.force_igmp_version net.ipv6.conf.all.force_mld_version

According to the kernel's ip-sysctl documentation, igmp_max_memberships is the maximum number of multicast groups that can be subscribed (default 20) and igmp_max_msf is the maximum number of addresses in a group's source filter list (default 10). These limits are what stop a single misbehaving program from asking the kernel to track an unbounded number of groups or sources. force_igmp_version and force_mld_version default to 0, which means no version is enforced: the host falls back to IGMPv1 or v2 (or MLDv1) when it hears an older querier, and returns to the newest version when the older querier present timer expires. Setting them to 3 or 2 pins the host to IGMPv3 or MLDv2, which stops a forged old version query from downgrading it, at the cost of not interoperating with genuinely old queriers.

Step 6: stop the host answering discovery where it does not need to

Do this on servers and on laptops that roam onto untrusted networks. Check what depends on mDNS first: printing and some file sharing use it.

For systemd-resolved, in /etc/systemd/resolved.conf:

[Resolve]
MulticastDNS=no
LLMNR=no

Then sudo systemctl restart systemd-resolved and confirm with resolvectl status.

For Avahi, restrict it to trusted interfaces and stop it publishing host details in /etc/avahi/avahi-daemon.conf:

[server]
allow-interfaces=eth0
deny-interfaces=wlan0

[publish]
publish-hinfo=no
publish-workstation=no

Restart with sudo systemctl restart avahi-daemon, or stop and disable it on servers that never need it.

Step 7: filter multicast at the host or lab gateway with nftables

This ruleset is for a Linux box acting as a lab or home gateway with a WAN interface (wan0) and a LAN interface (lan0). It drops discovery traffic arriving from the internet, keeps link local discovery off the routed path, and lets IGMP and MLD work on the LAN. Load it into a test namespace or a lab box first; a firewall mistake on a remote machine can lock you out.

table inet mcast_guard {
  chain input {
    type filter hook input priority 0; policy accept;

    # Never answer mDNS, SSDP or LLMNR from the internet side
    iifname "wan0" udp dport { 1900, 5353, 5355 } drop

    # Ignore IGMP and MLD queries from the WAN; queriers belong on the LAN
    iifname "wan0" ip protocol igmp drop
    iifname "wan0" icmpv6 type { mld-listener-query, mld-listener-report, mld2-listener-report, mld-listener-done } drop
  }

  chain forward {
    type filter hook forward priority 0; policy accept;

    # Do not route organisation local or link local groups to or from the WAN
    oifname "wan0" ip daddr { 224.0.0.0/24, 239.0.0.0/8 } drop
    iifname "wan0" ip daddr 224.0.0.0/4 drop
    oifname "wan0" ip6 daddr { ff02::/16, ff05::/16, ff08::/16 } drop
    iifname "wan0" ip6 daddr ff00::/8 drop
  }
}

Save it as /etc/nftables.d/mcast-guard.nft, check it with sudo nft -c -f /etc/nftables.d/mcast-guard.nft, then load it with sudo nft -f. If your gateway forwards IPTV from a provider, the WAN multicast drop in the forward chain will block it; replace it with a rule that accepts only the provider's SSM range and source.

Step 8: turn on snooping and a querier on a Linux bridge

A Linux bridge (used by many lab hosts, virtualisation hosts and software routers) supports IGMP and MLD snooping. If no router on the bridge sends queries, enable the bridge's own querier so that snooping entries stay fresh instead of falling back to flooding:

# Check current settings
ip -d link show br0 | grep -o 'mcast_[a-z_]* [0-9a-z]*'

# Enable snooping and the bridge querier for IPv4 and IPv6
sudo ip link set dev br0 type bridge mcast_snooping 1 mcast_querier 1

# See the multicast database the bridge has learned
bridge mdb show

To stop flooding unknown multicast to a port that should only get what it asks for, such as a port facing a guest VM:

sudo bridge link set dev vnet3 mcast_flood off

To stop a guest or user port being treated as a router port if something on it sends queries or PIM hellos, set its router mode to 0 (disabled). The default, 1, lets the bridge detect routers automatically, which is exactly what a forged query exploits. And to cap how many groups one port can register, which limits state exhaustion from a single noisy guest, set a per port maximum:

sudo bridge link set dev vnet3 mcast_router 0
sudo bridge link set dev vnet3 mcast_max_groups 64

The bridge querier is off by default, and mcast_flood is on by default, so a fresh Linux bridge floods unknown multicast to every port until you change it.

The same concepts apply on managed switches under different names: enable snooping per VLAN, enable a snooping querier only on one switch per VLAN where no router exists, set a static router port towards the real router, disable router port learning and drop queries on access ports, and limit the number of groups per port.

Step 9: check what is reachable from outside

From a machine outside your network, or with your provider's help, confirm that nothing answers on UDP 1900 or 5353 on your public addresses. For home routers, also turn off UPnP on the WAN side if the router exposes a setting for it, and check the router's own documentation for what UPnP features it enables by default.

Securing multicast in an enterprise or provider network

The host steps above help at the edge. On a routed multicast network, the controls are configuration patterns you apply to every router and switch:

1. Inventory your groups. Write down which groups and channels you use, which sources send them, and where receivers live. You cannot filter what you have not listed.
2. Prefer SSM. Move known sources to 232.0.0.0/8 or ff3x::/32 channels and configure receivers for IGMPv3 and MLDv2. This removes RP and Register exposure for those streams.
3. Scope the rest. Use 239.0.0.0/8 or non global IPv6 scopes for any source groups and configure boundaries at domain edges.
4. Pin the RP. Use static RP or anycast RP. If you use BSR, filter bootstrap and candidate RP messages at edges, and limit which group ranges each candidate RP may claim.
5. Limit PIM to router links. Disable PIM on access and server VLANs unless a router there needs it. Filter PIM neighbours by address. Use IPsec authentication (RFC 5796) where supported.
6. Harden access ports. Snooping on, query and PIM guard on, join filters for the groups each port class needs, a maximum group count, and storm control for multicast.
7. Watch control plane load. Rate limit IGMP, MLD and PIM to the router CPU, and alert on rapid changes in group count or on new queriers and DRs.
8. Authenticate the data. Where the content matters (market data, telemetry, control systems), authenticate messages at the application layer. Network controls narrow who can send; they do not prove what was sent.

Timeline: multicast standards and security milestones

Common mistakes

• Citing the obsolete RFCs. RFC 3376 and RFC 3810 were replaced by RFC 9776 and RFC 9777 in March 2025. The protocols are compatible, but timer formulas such as the Group Membership Interval changed slightly.
• Turning on snooping without a querier. Snooping entries come from reports, and hosts only report when queried. A VLAN without a router and without a snooping querier loses its entries and floods, often a few minutes after everything looked fine.
• Running two snooping queriers. Two switches on the same VLAN both configured as querier fight the election and confuse router port detection. Pick one.
• Filtering MLD as if it were optional. Blocking all ICMPv6 or all IPv6 multicast on a switch breaks Neighbor Discovery. Filter by role, not wholesale.
• Enabling PIM on every interface. PIM on an access VLAN lets any device that speaks PIM become a neighbour and possibly the DR.
• Leaving BSR unfiltered at a boundary. A candidate RP announcement from outside can redirect your shared trees.
• Choosing groups that collide at the MAC layer. Groups such as 239.0.0.x and 239.128.0.x map to the same MAC addresses as 224.0.0.x and can be flooded as link local traffic.
• Using an mDNS reflector to fix discovery across VLANs. A blanket reflector copies every announcement, including the ones you did not mean to share, into every VLAN. Forward specific services instead.
• Assuming UPnP on the router is internal only. Check that the WAN side does not answer SSDP.
• Treating multicast payloads as trusted. Network controls limit sources; they do not authenticate data.

FAQ

What is IP multicast in simple terms?

It is a way for one sender to deliver the same packets to many receivers at once. The sender transmits one copy to a group address, and the network copies it only where paths to receivers that asked for the group split.

What is the IPv4 multicast address range?

224.0.0.0/4, which is 224.0.0.0 to 239.255.255.255. 224.0.0.0/24 is link local control traffic, 232.0.0.0/8 is source specific multicast and 239.0.0.0/8 is administratively scoped for private use inside an organisation.

What is the IPv6 multicast address range?

ff00::/8. Every address beginning with ff is multicast, and the fourth hex digit gives the scope: ff02:: is link local, ff05:: site local and ff0e:: global.

What is the difference between IGMP and PIM?

IGMP runs between hosts and their first router and says which groups hosts on a subnet want. PIM runs between routers and builds the trees that carry multicast from sources to those subnets. MLD is the IPv6 equivalent of IGMP; PIM works for both IPv4 and IPv6.

What is the difference between IGMPv2 and IGMPv3?

IGMPv2 lets a host join or leave a group. IGMPv3 adds source filtering, so a host can ask for a group only from specific sources (INCLUDE) or from all but specific sources (EXCLUDE). IGMPv3 is needed for source specific multicast. Its current specification is RFC 9776.

What does IGMP snooping do?

It lets a switch listen to IGMP messages and forward each multicast group only to the ports that joined it, plus ports that lead to routers. Without snooping, a switch floods multicast to every port in the VLAN like broadcast.

Why is multicast flooding my network even with IGMP snooping on?

Usually because there is no querier on the VLAN, so snooping entries expire; because traffic is for an unregistered group or for 224.0.0.x, which is flooded by design; or because the switch does not understand the IGMP version the hosts are using.

What is a rendezvous point in PIM?

A router chosen as the meeting point for a group range in PIM sparse mode. Receivers' routers join towards the RP, sources register with it, and once traffic flows, routers can switch to a direct path to the source. Source specific multicast does not use an RP.

Is multicast a security risk?

It can be. Group management and discovery messages are unauthenticated, any source can send to an any source group, mDNS and SSDP reveal device details, and SSDP and mDNS can be abused for amplification if exposed to the internet. Scoping, SSM, filtering and pinning the querier and RP address most of this.

How do I see which multicast groups my Linux machine has joined?

Run ip maddr show. For the kernel's per interface view including IGMP versions use cat /proc/net/igmp and cat /proc/net/igmp6, and watch the protocol with sudo tcpdump -ni eth0 igmp.

Where Safeguard fits

Safeguard does not monitor multicast traffic, configure switches or routers, or analyse network devices. Its fit here is indirect and sits with the software around the network: the open source libraries inside your mDNS and SSDP responders, network operating system builds, telemetry collectors, market data handlers and the automation code that pushes multicast configuration. Safeguard scans those repositories, container images and SBOM files for known vulnerable components, shows which projects contain a given component and version, ranks findings with reachability analysis, and applies policies and gates before a build ships.

That matters because discovery and multicast handling code is exactly the kind of small, widely embedded component that ends up in many products and is rarely updated after it ships. Knowing where each version lives is the first step to replacing it.

The network controls above narrow who can send and join. The software that speaks these protocols, from mDNS and UPnP libraries to the collectors and automation you build around multicast, still ships open source components that need patching, and fork and patch for those components is in early access.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not multicast monitoring or network security. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the container image for a market data handler, a streaming relay or a discovery gateway your team builds, the same scan lists the packages and versions inside it, including any mDNS, UPnP or multicast library, and their known vulnerabilities.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a vulnerable dependency in a Python or Go tool that joins multicast groups or parses SSDP device descriptions.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given version of a discovery or networking library and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• IETF RFC 1112: Host Extensions for IP Multicasting
• IETF RFC 2236: Internet Group Management Protocol, Version 2
• IETF RFC 9776: Internet Group Management Protocol, Version 3
• IETF RFC 3376: Internet Group Management Protocol, Version 3 (obsoleted)
• IETF RFC 2710: Multicast Listener Discovery for IPv6
• IETF RFC 9777: Multicast Listener Discovery Version 2 (MLDv2) for IPv6
• IETF RFC 3810: MLDv2 for IPv6 (obsoleted)
• IETF RFC 4541: Considerations for IGMP and MLD Snooping Switches
• IETF RFC 7761: Protocol Independent Multicast, Sparse Mode
• IETF RFC 4607: Source-Specific Multicast for IP
• IETF RFC 4604: Using IGMPv3 and MLDv2 for Source-Specific Multicast
• IETF RFC 8815: Deprecating Any-Source Multicast for Interdomain Multicast
• IETF RFC 2365: Administratively Scoped IP Multicast
• IETF RFC 5771: IANA Guidelines for IPv4 Multicast Address Assignments
• IETF RFC 4291: IP Version 6 Addressing Architecture
• IETF RFC 2464: Transmission of IPv6 Packets over Ethernet Networks
• IETF RFC 5059: Bootstrap Router (BSR) Mechanism for PIM
• IETF RFC 4610: Anycast-RP Using PIM
• IETF RFC 3618: Multicast Source Discovery Protocol
• IETF RFC 4286: Multicast Router Discovery
• IETF RFC 5796: Authentication and Confidentiality in PIM Link-Local Messages
• IETF RFC 6762: Multicast DNS
• IANA: IPv4 Multicast Address Space Registry
• IANA: IPv6 Multicast Address Space Registry
• CISA: UDP-Based Amplification Attacks (TA14-017A)
• CERT/CC: VU#550620, mDNS implementations may respond to unicast queries originating outside the local link
• Open Connectivity Foundation: UPnP Device Architecture 2.0 (PDF)
• IETF RFC 3973: PIM Dense Mode
• IETF RFC 5015: Bidirectional PIM
• Linux kernel documentation: IP sysctl
• ip-maddress(8) manual page
• ip-link(8) manual page (bridge mcast options)
• bridge(8) manual page (mdb, mcast_router, mcast_flood, mcast_max_groups)
• systemd resolved.conf manual (MulticastDNS=, LLMNR=)
• avahi-daemon.conf(5) manual page
• nftables manual page

Last reviewed: 24 October 2026. Multicast specifications and network operating system defaults change; check the current RFCs and your platform documentation before changing production configuration.