When you send an ICMPv4 echo request to 224.0.0.1 (all-hosts multicast group) with destination MAC 01:00:5e:00:00:01, Linux silently drops these packets by default. This behavior is controlled by the kernel parameter:

net.ipv4.icmp_echo_ignore_broadcasts = 1

Despite the parameter name mentioning "broadcasts", it actually affects both broadcast AND multicast ICMPv4 traffic. This often surprises network engineers expecting multicast ping responses.

There are several historical reasons for this design:

• Smurf Attack Protection: In the 1990s, attackers would spoof victim IPs and send ICMP echoes to broadcast/multicast addresses, creating massive traffic amplification
• Network Resource Conservation: Responding to every multicast ping could overwhelm systems on large networks
• RFC 1122 Compliance: Section 3.2.2.6 states hosts MAY silently discard ICMP echo requests to broadcast/multicast addresses

Interestingly, ICMPv6 behaves differently with ff02::1 (all-nodes multicast):

# This typically works by default on Linux:
ping6 -I eth0 ff02::1%eth0

The key differences are:

1. IPv6 was designed with multicast security in mind from the beginning
2. IPv6 multicast scoping (link-local vs global) provides better control
3. Neighbor Discovery Protocol (NDP) relies on multicast responses

To enable responses while understanding the risks:

# Temporary change (until reboot):
sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0

# Permanent change:
echo "net.ipv4.icmp_echo_ignore_broadcasts = 0" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Security considerations when changing this:

• Monitor for ICMP flood attacks
• Consider rate limiting ICMP responses
• Use firewall rules to restrict who can send these requests

For safer multicast ping handling, you could implement selective response rules using iptables:

# Allow multicast pings only from trusted networks
sudo iptables -A INPUT -d 224.0.0.1 -p icmp --icmp-type echo-request \
    -s 192.168.1.0/24 -j ACCEPT

# Rate limit other multicast pings
sudo iptables -A INPUT -d 224.0.0.1 -p icmp --icmp-type echo-request \
    -m limit --limit 5/minute --limit-burst 10 -j ACCEPT

While unlikely to change soon, future Linux kernels might:

• Add separate controls for IPv4 broadcast vs multicast
• Implement similar rate limiting for ICMPv6
• Provide more granular response controls

The current asymmetry between IPv4 and IPv6 behavior is likely to remain due to their different security models and architectural approaches to multicast.

---

When troubleshooting network connectivity on Linux systems, you might encounter an odd behavior where ICMPv4 echo requests to multicast address 224.0.0.1 get silently dropped. This occurs despite proper MAC address resolution (01:00:5e:00:00:01) and appears to violate IPv4 multicast fundamentals.

The Linux kernel parameter net.ipv4.icmp_echo_ignore_broadcasts (default value: 1) controls this behavior. While its name suggests broadcast handling, it actually governs responses to both:

• Traditional broadcasts (e.g., 255.255.255.255)
• All-hosts multicast (224.0.0.1)

Historical ICMPv4 vulnerabilities motivated this design:

# Potential amplification attack example
hping3 --icmp --spoof victim_ip --destip 224.0.0.1 --flood

Key risks mitigated:

• Smurf attacks (network bandwidth amplification)
• ICMP flood DDoS using multicast reflection
• Resource exhaustion from processing multicast replies

IPv6 handles this differently with ff02::1 (all-nodes multicast):

ping6 -I eth0 ff02::1

Reasons for the divergence:

• IPv6's built-in security features (e.g., mandatory IPSec support)
• Different multicast architecture with scope controls
• Modern kernel implementations learning from IPv4 issues

To temporarily allow responses (not recommended for production):

sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0

Persistent configuration (Ubuntu/Debian):

# /etc/sysctl.d/10-icmp.conf
net.ipv4.icmp_echo_ignore_broadcasts = 0

Instead of disabling protection, consider:

# Rate limiting ICMP responses
sudo iptables -A INPUT -p icmp --icmp-type echo-request \
    -m limit --limit 1/second -j ACCEPT

For debugging purposes, use targeted unicast pings or implement proper multicast listeners rather than relying on ICMP responses.