During LACNIC 43, held in São Paulo’s Anhembi District from May 5 to 9, Henri Alves de Godoy and Ernesto Sanchez presented the research paper “Considerations for filtering the ICMPv6 protocol” at the Technical Forum. This article provides a summary of the work, jointly prepared for the LACNIC Blog.
The Internet Control Message Protocol (ICMP) was defined in RFC 792 (1981) as an essential mechanism for network devices to report errors, announce connectivity issues, and allow network diagnostics. It was created together with IPv4 to provide support during the transmission of packets over the network, which travel without a guarantee that they will be delivered by the network layer. It is used, for example, to notify when a host on the network is inaccessible, to inform about expired TTL, and to identify fragmentation issues.
Some of the most popular tools that are also easy to use even for the most inexperienced users are the ping (Echo Request/Reply) and traceroute (Time Exceeded) commands, which use the ICMP protocol directly. We frequently use these tools in our daily lives, and they provide a quick and straightforward connectivity test.
With the expansion of the Internet and the possibility of browsing the Web which was once limited to universities and research centers, the introduction of small regional Internet Service Providers (ISPs) in the mid-1990s allowed each user to receive a public IPv4 address for their home. Residential users were not yet familiar with NAT and maintained a direct end-to-end connection, without any address translation and without sharing the same IP among multiple subscribers, as is the case today.
During this same period, denial of service attacks began to surface, exploiting devices connected to different networks. These attacks included smurf attacks, where ICMP Echo Request packets were sent to broadcast addresses. This became known as an amplification attack and its goal is to incapacitate a local network.
Another major incident with lasting historical implications was the Ping of Death, which exploited vulnerabilities in the implementation of the IP protocol across various operating systems, particularly Windows 95, where the attacker created an ICMP Echo Request packet exceeding the size permitted by the IP standard (65,535 bytes).
Over time, the idea that “to ping is dangerous” spread. In this context, many began to adopt blanket ICMP blocking, and for many years this was considered “good security practice.”
However, this decision was driven more by panic and fear than by technical analysis. Consequently, distinguishing between a connectivity failure and the filtering of ICMP traffic has become increasingly challenging, creating invisible networks to make it difficult to map the internal network and thus making diagnosis inefficient.
Many firewall scripts (iptables, ipchains) and tutorials encouraged fully blocking the ICMP protocol, often without explaining the technical implications. This practice became so deeply ingrained that, even after 30 years, we still see many people completely blocking ICMP on their networks, fostering a false sense of security.
ICMPv6: More than Simply a Replacement for IPv4’s ICMP
In IPv4, local network neighbor discovery relied on ARP (Address Resolution Protocol), defined in RFC 826. This protocol operates with broadcast messages, i.e., messages transmitted to all devices within the network.
Contrary to popular belief, IPv6 is not merely a bigger version of IPv4. Rather, it redefines many of the principles of network communication, such as ICMPv6, which now includes new functions, is more robust, and is no longer merely a substitute for its predecessor, ICMP. ICMPv6 now includes:
- Neighbor and router discovery: through NDP (RFC 4861).
- Address autoconfiguration: through SLAAC (RFC 4862).
- MTU discovery: an essential feature, as IPv6 does not allow intermediate fragmentation.
With the introduction of IPv6, broadcast communication was completely eliminated in favor of a much more efficient and controlled model based on multicast.
The Neighbor Discovery Protocol (NDP), defined in RFC 4861, replaces the functions of ARP and extends them by enabling neighbor and router discovery, as well as duplicate address detection (DAD).
NDP messages are transported in ICMPv6 and use specific multicast addresses (FF02::/16 prefix), optimizing discovery traffic in the network. This avoids broadcast issues as it ensures that discovery messages are only received by relevant devices.
The new approach drastically reduces network load and allows for more scalable and secure deployments, benefitting devices with limited resources (for example, IoT sensors) and environments such as data centers and enterprise networks.
Impacts of Blocking ICMPv6
While blocking ICMP traffic in IPv4 was never ideal, it often had limited impact. In contrast, blocking ICMPv6 can cause a series of disruptions and issues in the network, including:
- SLAAC failure: Hosts do not automatically receive network prefixes.
- NDP failure: Without it, MAC address resolution becomes impossible.
- MTU discovery issues.
- Duplicate Address Detection (DAD) failure.
In dual-stack corporate or academic environments, improperly blocking ICMPv6 can be the sole cause of intermittent and difficult-to-diagnose failures.
Testing Secure ICMPv6 Filtering with Containerlab
To analyze attacks based on ICMPv6 messages, a network topology was created based on Containerlab and considering the following RFCs:
RFC 3756, “IPv6 Neighbor Discovery (ND) Trust Models and Threats,” which specifies three different trust models.
RFC 4890, which provides a solid foundation for secure and functional ICMPv6 filtering. Rather than blocking all traffic, it recommends an approach based on understanding the different message types and their codes. For example:
- Type 133: Router Solicitation
- Type 134: Router Advertisement
- Type 135/136: Neighbor Solicitation/Advertisement
- Type 2: Packet Too Big
- Type 1: Destination Unreachable
The proposed test lab replicates a corporate network environment, integrating the THC IPv6 tools from the IPv6 Toolkit to simulate attack scenarios and network devices running Nokia SRL Linux and Aruba-CX OS, which allowed configuring the protection mechanisms listed below.
Use of specialized protection mechanisms:
- RA Guard: Blocks rogue RA messages on unauthorized ports.
- ND Snooping: Inspects Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages to prevent spoofing.
- DHCPv6 Guard: Detects and blocks spoofed DHCPv6 servers.
- ACLs based on VLAN type/code/port.
- Intelligent Rate Limiting: Mitigates flooding attacks without blocking essential functionality.
The tests allowed us to analyze various attack vectors and identify an effective combination of the mechanisms above for the proper filtering of ICMPv6 messages.
To watch the presentation at the LACNIC 43 Forum on YouTube, click on the following link: https://youtu.be/jRLBx-2Layw
Final Considerations
The practice of blocking ICMPv4 emerged as a reaction for providing temporary security during the early days of residential Internet access. Over time and with established habits, continuing to adhere to the same logic with ICMPv6 is a technical and operational error. Now more than ever, our security must be grounded in knowledge of best practices and technical understanding, not in fear.
The results of our testing confirm that Containerlab is a versatile and fully functional tool for creating controlled lab environments that can be used to simulate attacks without compromising production environments. Additionally, capturing and analyzing network traffic is a fundamental part of inspecting header fields and subsequently defining secure filtering rules without disrupting the normal operation of ICMPv6.
This article summarizes the presentation at the LACNIC 43 Technical Forum. ICMPv6 is essential and is currently present in computer networks. Security is no longer about blanket blocking, but about smart control and filtering.
References
- [RFC 792] – Internet Control Message Protocol.
- [RFC 4443] – ICMPv6.
- [RFC 4861] – Neighbor Discovery for IPv6.
- [RFC 4890] – Filtering Recommendations.
- RFC 3756 – IPv6 Neighbor Discovery (ND) Trust Models and Threats
- [RFC 8200] – IPv6 Specification
- [RFC 4862] – IPv6 Stateless Address Autoconfiguration
- IETF v6ops WG documents and BCOPs.
- ContainerLab – https://containerlab.dev/
- Tutorial and Labs – https://github.com/ernestosanchezv/icmpv6filter
