RFC 4890

Recommendations for Filtering ICMPv6 Messages in Firewalls

📅 published May 2007, from ietf

Recommendations for Filtering ICMPv6 Messages in Firewalls 🎀

Network Working Group: this one lives in the IETF's Network Working Group 🌸
Category: Informational, so it's guidance, not a standard 📚
Date: May 2007 📅
Authors: E. Davies (Consultant) and J. Mohacsi (NIIF/HUNGARNET) 👑
Obsoletes / Updates: there's no Obsoletes or Updates line in the header, so this RFC doesn't claim to replace or change anything 🦋

Status of This Memo ✨

Okay, so this memo is informational 💅 It's here to share information with the Internet community, and it does not specify an Internet standard of any kind 🙈 Distribution of this memo is unlimited, so you can share it with literally anyone 💜

Copyright Notice 🌈

Abstract 🦋

Okay, so ICMPv6 is literally everywhere in IPv6 networks 😭 It does a ton of jobs and has a huge pile of message types and options 🌸 ICMPv6 is essential to IPv6 working at all, BUT there are real security risks when ICMPv6 messages get forwarded without any control over them 💀 Filtering strategies from the IPv4 world, built for ICMP, don't just transfer over 🙅‍♀️ Those strategies were designed around a helpful auxiliary protocol that may not be required for correct functioning, so they don't fit ICMPv6's much bigger role ✨

This document gives some recommendations for setting up ICMPv6 firewall filters 🛡️ The goal is to let through the ICMPv6 messages the network needs to keep running, while dropping the ones that are potential security risks 🫶 Main character energy for your firewall, fr 👑

Table of Contents 🧚

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Classifying ICMPv6 Messages  . . . . . . . . . . . . . . . . .  6
     2.1.  Error and Informational ICMPv6 Messages  . . . . . . . . .  6
     2.2.  Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . .  6
     2.3.  Network Topology and Address Scopes  . . . . . . . . . . .  7
     2.4.  Role in Establishing and Maintaining Communication . . . .  7
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
     3.1.  Denial-of-Service Attacks  . . . . . . . . . . . . . . . .  9
     3.2.  Probing . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     3.3.  Redirection Attacks . . . . . . . . . . . . . . . . . . . . 9
     3.4.  Renumbering Attacks  . . . . . . . . . . . . . . . . . . . 10
     3.5.  Problems Resulting from ICMPv6 Transparency  . . . . . . . 10
   4.  Filtering Recommendations  . . . . . . . . . . . . . . . . . . 10
     4.1.  Common Considerations  . . . . . . . . . . . . . . . . . . 11
     4.2.  Interaction of Link-Local Messages with
           Firewall/Routers and Firewall/Bridges  . . . . . . . . . . 12
     4.3.  Recommendations for ICMPv6 Transit Traffic . . . . . . . . 13
       4.3.1.  Traffic That Must Not Be Dropped . . . . . . . . . . . 14
       4.3.2.  Traffic That Normally Should Not Be Dropped  . . . . . 14
       4.3.3.  Traffic That Will Be Dropped Anyway -- No Special
               Attention Needed . . . . . . . . . . . . . . . . . . . 15
       4.3.4.  Traffic for Which a Policy Should Be Defined . . . . . 16
       4.3.5.  Traffic That Should Be Dropped Unless a Good Case
               Can Be Made  . . . . . . . . . . . . . . . . . . . . . 17
     4.4.  Recommendations for ICMPv6 Local Configuration Traffic . . 18
       4.4.1.  Traffic That Must Not Be Dropped . . . . . . . . . . . 18
       4.4.2.  Traffic That Normally Should Not Be Dropped  . . . . . 19
       4.4.3.  Traffic That Will Be Dropped Anyway -- No Special
               Attention Needed . . . . . . . . . . . . . . . . . . . 19
       4.4.4.  Traffic for Which a Policy Should Be Defined . . . . . 20
       4.4.5.  Traffic That Should Be Dropped Unless a Good Case
               Can Be Made  . . . . . . . . . . . . . . . . . . . . . 21
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Appendix A.  Notes on Individual ICMPv6 Messages . . . . . . . . . 24
     A.1.  Destination Unreachable Error Message  . . . . . . . . . . 24
     A.2.  Packet Too Big Error Message . . . . . . . . . . . . . . . 24
     A.3.  Time Exceeded Error Message  . . . . . . . . . . . . . . . 25
     A.4.  Parameter Problem Error Message  . . . . . . . . . . . . . 25
     A.5.  ICMPv6 Echo Request and Echo Response  . . . . . . . . . . 26
     A.6.  Neighbor Solicitation and Neighbor Advertisement
           Messages . . . . . . . . . . . . . . . . . . . . . . . . . 26
     A.7.  Router Solicitation and Router Advertisement Messages  . . 27
     A.8.  Redirect Messages  . . . . . . . . . . . . . . . . . . . . 27
     A.9.  SEND Certificate Path Messages . . . . . . . . . . . . . . 27
     A.10. Multicast Listener Discovery Messages  . . . . . . . . . . 27
     A.11. Multicast Router Discovery Messages  . . . . . . . . . . . 28
     A.12. Router Renumbering Messages  . . . . . . . . . . . . . . . 28
     A.13. Node Information Query and Reply . . . . . . . . . . . . . 28
     A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 28
     A.15. Unused and Experimental Messages . . . . . . . . . . . . . 29
   Appendix B.  Example Script to Configure ICMPv6 Firewall Rules . . 30

1. Introduction ✨

okay bestie, so when a network runs IPv6 [RFC2460], ICMPv6 [RFC4443] is basically the MVP 👑. It's a huge part of setting up and keeping communication going, both at the interface level and for sessions to remote nodes 🌐. That means if a firewall filters ICMPv6 too aggressively, it can wreck how IPv6 communication gets established and maintained 💀. BUT letting every single ICMPv6 message through with zero questions asked can be a major security risk 🙈. This document recommends a set of rules that tries to balance effective IPv6 communication with what site security needs 🫶.

The right rules depend a little on what the firewall is protecting. Here are the cases:

an individual host,
an end site where all ICMPv6 messages originate or terminate within the site, or
a transit site such as an Internet Service Provider's site where some ICMPv6 messages will be passing through.

The document suggests different rules for each situation where it matters 🦋. It also notes some situations where alternative rules could be adopted, depending on the nature of the work happening on the site and the security policies that come with it 💅. In general, Internet Service Providers should not filter ICMPv6 messages transiting their sites. That way, all the necessary communication elements are available to their customers, who can decide and filter according to their own policy 🎀.

Already know ICMPv6 well? No judgment, you can skip ahead to the recommended filtering rules in Section 4 and the example configuration script for Linux Netfilter in Appendix B 🧚.

ICMPv6 has a LOT of functions spread across a bunch of sub-protocols, so there's a correspondingly huge number of messages and options inside them 😭. The functions that are currently defined fall into a few categories:

Returning Error Messages 🚨

Returning error messages to the source if a packet could not be delivered. Four different error messages, each with a number of sub-types, are specified in [RFC4443].

Connection Checking 🏓

Simple monitoring of connectivity through echo requests and responses, used by the ping and traceroute utilities. The Echo Request and Echo Response messages are specified in [RFC4443].

Discovery Functions 🔍

Finding neighbors (both routers and hosts) connected to the same link and figuring out their IP and link layer addresses. These messages are also used to check the uniqueness of any addresses that an interface proposes to use (Duplicate Address Detection - DAD). Four messages -- Neighbor Solicitation (NS), Neighbor Advertisement (NA), Router Solicitation (RS) and Router Advertisement (RA) -- are specified in [RFC2461].
Making sure neighbors stay reachable using the same IP and link layer addresses after the initial discovery (Neighbor Unreachability Discovery - NUD), and notifying neighbors of changes to link layer addresses. Uses NS and NA [RFC2461].
Finding routers and figuring out how to get IP addresses to join the subnets the routers support. Uses RS and RA [RFC2461].
If stateless autoconfiguration of hosts is enabled, communicating prefixes and other configuration info (including the link Maximum Transmission Unit (MTU) and suggested hop limit default) from routers to hosts. Uses RS and RA [RFC2462].
When using SEcure Neighbor Discovery (SEND) to authenticate a router attached to a link, the Certificate Path Solicitation and Advertisement messages specified in [RFC3971] are used by hosts to retrieve, from the router, the certificates documenting the trust chain between a trust anchor and the router. 🔐
Determining the MTU along a path. The Packet Too Big error message is essential to this function [RFC1981].
Providing a means to discover the IPv6 addresses associated with the link layer address of an interface (the inverse of Neighbor Discovery, where the link layer address is discovered given an IPv6 address). Two messages, Inverse Neighbor Discovery Solicitation and Advertisement messages, are specified in [RFC3122].
Communicating which multicast groups have listeners on a link to the multicast capable routers connected to that link. Uses the messages Multicast Listener Query, Multicast Listener Report (two versions), and Multicast Listener Done (protocol version 1 only), as specified in Multicast Listener Discovery MLDv1 [RFC2710] and MLDv2 [RFC3810].
Discovering multicast routers attached to the local link. Uses the messages Multicast Router Advertisement, Multicast Router Solicitation, and Multicast Router Termination, as specified in Multicast Router Discovery [RFC4286].

Reconfiguration Functions 🔄

Redirecting packets to a more appropriate router on the local link for the destination address, or pointing out that a destination is actually on the local link even if it isn't obvious from the IP address (where a link supports multiple subnets). The Redirect message is specified in [RFC2461].
Supporting renumbering of networks by allowing the prefixes advertised by routers to be altered. Uses NS, NA, RS and RA together with the Router Renumbering message specified in [RFC2894].

Mobile IPv6 Support 🧳

Providing support for some aspects of Mobile IPv6, especially dealing with the IPv6 Mobile Home Agent functionality provided in routers and needed to support a Mobile node homed on the link. The Home Agent Address Discovery Request and Reply and the Mobile Prefix Solicitation and Advertisement messages are specified in [RFC3775].

Experimental Extensions 🧪

An experimental extension to ICMPv6 specifies the ICMP Node Information Query and Response messages, which can be used to retrieve some basic information about nodes [RFC4620].
The SEAmless IP MOBility (SEAMOBY) working group specified a pair of experimental protocols that use an ICMPv6 message specified in [RFC4065] to help locate an access router and move the attachment point of a mobile node from one access router to another.

Many of these messages should only be used in a link-local context rather than end-to-end, and filters need to care about the type of addresses in ICMPv6 packets as well as the specific source and destination addresses 👀.

Compared with ICMP in IPv4, ICMPv6 can't be treated as an auxiliary function whose packets can be dropped in most cases without damaging the network 😤. That means firewall filters for ICMPv6 have to be configured much more carefully than was the case for ICMP, where a small set of blanket rules could typically be applied 💖.

2. Classifying ICMPv6 Messages 🗂️

2.1. Error and Informational ICMPv6 Messages

ICMPv6 messages contain an eight-bit Type field, interpreted as an integer between 0 and 255. Messages with Type values less than or equal to 127 are Error messages, and the rest are Informational messages 📦. Generally speaking, Error messages with well-known (standardized) Type values would normally be expected to be allowed to be sent to or pass through firewalls, and they may be essential to establishing and maintaining communications (see Section 2.4) 🛡️. Informational messages, on the other hand, will usually be the subject of policy rules. The ones passing through end site firewalls can, in many but by no means all cases, be dropped without damaging IPv6 communications 🌸.

2.2. Addressing of ICMPv6

ICMPv6 messages are sent using various kinds of source and destination address types and scopes 🗺️. The source address is usually a unicast address, but during address autoconfiguration message exchanges, the unspecified address (::) is also used as a source address [RFC2462] ✨.

Multicast Listener Discovery (MLD) Report and Done messages are sent with a link-local address as the IPv6 source address, if a valid address is available on the interface. If a valid link-local address isn't available (e.g., one hasn't been configured), the message is sent with the unspecified address (::) as the IPv6 source address. Later on, once it has been configured, the node will generate new MLD Report messages with a proper link-local source address [RFC3590] 🔗.

The destination address can be a well-known multicast address, a generated multicast address such as the solicited-node multicast address, an anycast address, or a unicast address. While many ICMPv6 messages use multicast addresses most of the time, some also use unicast addresses 🎯. For instance, Router Advertisement messages are sent to the all-nodes multicast address when unsolicited, but they can also be sent to a unicast address in response to a specific Router Solicitation. This is rarely seen in current implementations, tho 🤷‍♀️.

2.3. Network Topology and Address Scopes

ICMPv6 messages can be classified according to whether they're meant for end-to-end communications or local communications within a link 🛤️. There are also messages we can classify as 'any-to-end', which can be sent from any point within a path back to the source. Typically, these are used to announce an error in processing the original packet 🚩. For instance, the address resolution messages are solely for local communications [RFC2461], whereas the Destination Unreachable messages are any-to-end in nature. Generally, end-to-end and any-to-end messages might be expected to pass through firewalls depending on policies, but local communications must not 🙅‍♀️.

Local communications will use link-local addresses in many cases, but they may also use global unicast addresses when configuring global addresses, for example 🌍. Also, some ICMPv6 messages used in local communications may contravene the usual rules requiring compatible scopes for source and destination addresses. Keep an eye out for that one, bestie 👀💜.

2.4. Role in Establishing and Maintaining Communication ✨

Okay so, lots of ICMPv6 messages help set up or keep up communications to and from the firewall, and those messages have to be accepted by firewalls for local delivery 💅. A firewall is usually also acting as a router, so every message that might be used to configure a router interface needs to be accepted and generated 🔥. These messages SHOULD NOT transit through a firewall that is also acting as a router, because they're normally meant for use within a link 🙈.

Now the big one 👑. Most ICMPv6 error messages traveling end-to-end or any-to-end are absolutely essential for establishing and maintaining communications 😭. These MUST be passed through firewalls, and they might also be sent to and from firewalls to help with setting up and keeping up communications 🫶. For example, the Packet Too Big error message is needed to figure out the MTU along a path, both when a session first starts and later if the path gets rerouted in the middle of a session 🦋.

The rest of the ICMPv6 messages, the ones that aren't tied to establishing or maintaining communication, will normally be legit trying to pass through a firewall from inside to out or outside to in 🌸. But in most cases, whether to let them through can be decided by local policy without messing with IPv6 communications 💖.

The filtering rules for the various message roles will generally be different 🌈.

3. Security Considerations ✨

Okay, security time, bestie 🔐. This memo recommends filtering configurations for firewalls designed to minimize the security vulnerabilities that can come up when you're using the many different sub-protocols of ICMPv6 to support IPv6 communication 💜.

A major concern is that it's generally not possible to use IPsec or other means to authenticate the sender and validate the contents of many ICMPv6 messages 😬. Part of the reason is that a site can legitimately expect to receive certain error and other messages from almost any location in the wider Internet, and these messages may show up as a result of the very first message sent to a destination 🧚. Setting up security associations with all possible sources of ICMPv6 messages is therefore impossible 💀.

Since security associations can't be set up to protect some messages that are needed for establishing and maintaining communications, alternative means have to be used to reduce the vulnerability of sites to ICMPv6-based attacks 🛡️. The most common way to do this is with strict filtering policies in site firewalls, which limit the unauthenticated ICMPv6 messages that can pass between the site and the wider Internet 🎀. This makes controlling ICMPv6 filtering a delicate balancing act: you have to protect the site by dropping some ICMPv6 traffic at the firewall, while still letting enough of it through that efficient communication can happen ✨.

SEND [RFC3971] has been specified as a way to improve the security of local ICMPv6 communications 🌟. SEND sidesteps the security association bootstrapping problems that would come up if IPsec were used 🫧. SEND only affects link-local messages and doesn't limit the filtering that firewalls can apply, so its role in security isn't discussed any further in this document 🙃.

Firewalls will normally be used to monitor ICMPv6 to control the following security concerns 👀:

3.1. Denial-of-Service Attacks

ICMPv6 can be used to cause a denial of service (DoS) in a bunch of ways 😤. That includes simply sending excessive numbers of ICMPv6 packets to destinations in the site, and sending error messages that disrupt established communications by causing sessions to get dropped 💥. Also, if spurious communication establishment or maintenance messages can be sneaked onto a link, it might be possible to invalidate legitimate addresses or disable interfaces 🥀.

3.2. Probing

A major security consideration is stopping attackers from probing the site to work out its topology and find hosts that might be vulnerable to attack 🕵️‍♀️. Carefully crafted but, often, malformed messages can be used to provoke ICMPv6 responses from hosts, which tells attackers who the potential targets are for future attacks 🎯. The very large address space of IPv6 makes probing a much less effective weapon compared with IPv4, provided that addresses are not allocated in an easily guessable fashion 🌌. This subject is explored in more depth in [SCAN-IMP] 📚.

3.3. Redirection Attacks

A redirection attack could be used by a malicious sender to perform man-in-the-middle attacks, or to divert packets either to a malicious monitor or to cause DoS by blackholing the packets 🕳️. These attacks would normally have to be carried out locally on a link, using the Redirect message 📡. Administrators need to decide if the efficiency gain from using Redirect messages is worth the risk of malicious use 🤔. Factors to consider include the physical security of the link and the complexity of addressing on the link 🔍. For example, on an open wireless link, redirection would be a serious hazard because there's no physical security 📶. On the other hand, with a wired link in a secure building with complex addressing and redundant routers, the efficiency gains might well outweigh the small risk of a rogue node being connected 🏢.

3.4. Renumbering Attacks

Spurious Renumbering messages can lead to the disruption of a site 😱. Renumbering messages are REQUIRED to be authenticated with IPsec, so it's difficult to carry out these attacks in practice 🔒, but they SHOULD NOT be allowed through a site boundary firewall 🚫. On the other hand, a site may employ multiple "layers" of firewalls 🧅. In this case, Renumbering messages might be expected to be allowed to transit interior firewalls but not pass across the outer boundary 🧱.

3.5. Problems Resulting from ICMPv6 Transparency

Because some ICMPv6 error packets need to pass through a firewall in both directions, malicious users can potentially use these messages to communicate between inside and outside, bypassing administrative inspection 🙊. For example, it might be possible to carry out a covert conversation through the payload of ICMPv6 error messages, or to tunnel inappropriate encapsulated IP packets inside ICMPv6 error messages 🕶️. This problem can be eased by filtering ICMPv6 errors with a deep packet inspection mechanism, to make sure the packet carried as a payload is associated with legitimate traffic to or from the protected network 🔎.

4. Filtering Recommendations 💅

When designing firewall filtering rules for ICMPv6, the rules can be split into two classes 🍓:

Rules for ICMPv6 traffic transiting the firewall, with some minor variations for
- firewalls protecting end sites or individual hosts, and
- firewalls protecting transit sites
Rules for ICMPv6 directed to interfaces on the firewall

Firewalls integrated with an individual host ("end host firewalls") can be treated as end site firewalls, but the special considerations discussed in Section 4.2 MAY be relevant, because the firewall is not a router 🖥️.

This section shares some common considerations to keep in mind when designing filtering rules, and then sorts the rules for each class into categories. The categories are 📋:

Messages that MUST NOT be dropped: usually because establishment or maintenance of communications will be prevented or severely impacted 🚨.
Messages that SHOULD NOT be dropped: administrators need to have a very good reason for dropping this category 🧐.
Messages that MAY be dropped in firewall/routers, but these messages may already be targeted to drop for other reasons (e.g., because they are using link-local addresses) or because the protocol specification would cause the messages to be rejected if they had passed through a router. Special considerations apply to transit traffic if the firewall is not a router, as discussed in Section 4.2 🧹.
Messages that administrators MAY or MAY NOT want to drop, depending on local policy 🎲.
Messages that administrators SHOULD consider dropping (e.g., ICMP node information name lookup queries) 🙅‍♀️.

More detailed analysis of each of the message types can be found in Appendix A 📖.

4.1. Common Considerations

Depending on the classification of the message to be filtered (see Section 2), ICMPv6 messages SHOULD be filtered based on the ICMPv6 type of the message, and on the type (unicast, multicast, etc.) and scope (link-local, global unicast, etc.) of the source and destination addresses 🎯. In some cases, it MAY be desirable to filter on the Code field of ICMPv6 error messages 🔍.

Messages that can be authenticated on delivery, probably because they contain an IPsec AH header or ESP header with authentication, MAY be subject to less strict policies than messages that cannot be authenticated 🔐. In the rest of this section, we're generally considering what should be configured for unauthenticated messages 🫠. In many cases, it's not realistic to expect more than a tiny fraction of the messages to be authenticated 🥲.

Where messages aren't essential to establishing or maintaining communications, local policy can be used to decide whether a message should be allowed or dropped 🗳️.

Depending on the capabilities of the firewall being configured, it MAY be possible for the firewall to maintain state about packets that may result in error messages being returned, or about ICMPv6 packets (e.g., Echo Requests) that are expected to receive a specific response 🧠. This state may let the firewall perform more precise checks based on that state, and apply limits on the number of ICMPv6 packets accepted, incoming or outgoing, as a result of a packet traveling in the opposite direction 🚦. The capabilities of firewalls to perform this kind of stateful packet inspection vary from model to model, and it's not assumed that firewalls are uniformly capable in this respect 🤷‍♀️.

Firewalls that are able to perform deep packet inspection MAY be able to check the header fields at the start of the errored packet carried by ICMPv6 error messages 🔬. If the embedded packet has a source address that does not match the destination of the error message, the packet SHOULD be dropped 🗑️. This gives a partial defense against some possible attacks on TCP that use spoofed ICMPv6 error messages, but the checks can also be carried out at the destination 🛡️. For further information on these attacks, see [ICMP-ATTACKS] 📎.

In general, the scopes of the source and destination addresses of ICMPv6 messages SHOULD be matched, and packets with mismatched addresses SHOULD be dropped if they attempt to transit a router 🧭. However, some of the address configuration messages carried locally on a link may legitimately have mismatched addresses 🏠. Node implementations MUST accept these messages delivered locally on a link, and administrators SHOULD be aware that they can exist 👀.

ICMPv6 messages transiting firewalls inbound to a site may be treated differently depending on whether they are addressed to a node on the site or to some other node 🚪. For end sites, packets addressed to nodes not on the site SHOULD be dropped, but would generally be forwarded by firewalls on transit sites 🌍.

4.2. Interaction of Link-Local Messages with Firewall/Routers and Firewall/Bridges ✨

Okay so firewalls can be built in two ways 🧱. They can be IP routers (firewall/routers), or they can be link layer bridges, like Ethernet bridges, that are totally transparent to IP even though they're actually peeking at the IP packets as they pass through (firewall/bridges). 👀

A lot of the messages used to set up and maintain communications on the local link get sent with a link-local address as at least one of their source or destination. 🔗 Routers that follow the IPv6 standards won't forward these packets, so you don't need extra rules to stop them crossing a firewall/router 💅. Admins may still want rules that drop them anyway, as insurance and as a way to monitor for attacks 🕵️‍♀️. Also, the specs for ICMPv6 messages that are only meant for the local link include some built-in checks, so receivers can tell if a message went through a router. These checks include:

Requiring that the hop limit in the IPv6 header is set to 255 on transmission. Receivers verify that the hop limit is still 255, to ensure that the packet has not passed through a router. 🫶
Checking that the source address is a link-local unicast address. 🌸

So it's not essential to set up firewall/router rules that drop out-of-specification packets of these types 🙌. If one of these packets has non-link-local source and destination addresses and gets through the firewall/router, it would get rejected by the checks at the destination anyway. Firewall admins may still want rules that log or drop those out-of-spec packets, though 💖.

Firewall/bridges are a bit different 🌉. The physical links on either side of the firewall/bridge are treated as a single logical link for IP purposes. That means the link-local messages used for discovery on the link must be allowed to transit the transparent bridge. Administrators should ensures that routers and hosts attached to the link containing the firewall/bridge are built to the correct specifications, so out-of-specification packets actually get dropped the way we described earlier in this section 🎀.

An end host firewall can generally be thought of as a special case of a firewall/bridge 🦋. The only link-local messages that need to be allowed through are the ones directed to the host's interface. Very focused, very iconic 👑.

4.3. Recommendations for ICMPv6 Transit Traffic 🚚

This section lays out rules that should be applied to ICMPv6 traffic trying to transit a firewall. Let's get into it 🧚.

4.3.1. Traffic That Must Not Be Dropped 🚫

Error messages that are essential to setting up and maintaining communications:

Destination Unreachable (Type 1) - All codes
Packet Too Big (Type 2)
Time Exceeded (Type 3) - Code 0 only
Parameter Problem (Type 4) - Codes 1 and 2 only

Appendix A.4 suggests some more specific checks that could be performed on Parameter Problem messages, if a firewall has the necessary packet inspection capabilities 🔍.

Connectivity checking messages:

Echo Request (Type 128)
Echo Response (Type 129)

For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be possible, the connectivity checking messages are absolutely essential to let through the firewall 💜. It's been common practice in IPv4 networks to drop Echo Request messages in firewalls to cut down the risk of scanning attacks on the protected network. As discussed in Section 3.2, the risks from port scanning in an IPv6 network are much less severe, so it's not necessary to filter IPv6 Echo Request messages 🙈.

4.3.2. Traffic That Normally Should Not Be Dropped 🌷

Error messages other than the ones listed in Section 4.3.1:

Time Exceeded (Type 3) - Code 1
Parameter Problem (Type 4) - Code 0

Mobile IPv6 messages that are needed to help with mobility:

Home Agent Address Discovery Request (Type 144)
Home Agent Address Discovery Reply (Type 145)
Mobile Prefix Solicitation (Type 146)
Mobile Prefix Advertisement (Type 147)

Admins may want more selective rules, as described in Appendix A.14, depending on whether the site is catering to mobile nodes that would normally be at home on the site, and/or foreign mobile nodes roaming onto the site 🧳.

4.3.3. Traffic That Will Be Dropped Anyway -- No Special Attention Needed 😴

The messages in this section are all about local management of nodes connected to the logical link they were first sent on. All of these messages should never be propagated beyond the link they were initially transmitted on. If the firewall is a firewall/bridge rather than a firewall/router, these messages should be allowed to transit the firewall, since they're meant for setting up communications between the two physical parts of the link that are bridged into one logical link 🌉.

During normal operations, these messages will have destination addresses that are mostly link-local, but in some cases global unicast addresses, of interfaces on the local link. No special action is needed to filter messages with link-local addresses in a firewall/router. As discussed in Section 4.1, these messages are specified so that either the receiver can check that the message hasn't passed through a router, or it will be dropped at the first router it runs into 💅.

Admins may also want to set up rules in firewall/routers to catch illegal packets sent with hop limit = 1, so that ICMPv6 Time Exceeded messages don't get generated for these packets 🙃.

Address Configuration and Router Selection messages (must be received with hop limit = 255):

Router Solicitation (Type 133)
Router Advertisement (Type 134)
Neighbor Solicitation (Type 135)
Neighbor Advertisement (Type 136)
Redirect (Type 137)
Inverse Neighbor Discovery Solicitation (Type 141)
Inverse Neighbor Discovery Advertisement (Type 142)

Link-local multicast receiver notification messages (must have link-local source address):

Listener Query (Type 130)
Listener Report (Type 131)
Listener Done (Type 132)
Listener Report v2 (Type 143)

SEND Certificate Path notification messages (must be received with hop limit = 255):

Certificate Path Solicitation (Type 148)
Certificate Path Advertisement (Type 149)

Multicast Router Discovery messages (must have link-local source address and hop limit = 1):

Multicast Router Advertisement (Type 151)
Multicast Router Solicitation (Type 152)
Multicast Router Termination (Type 153)

4.3.4. Traffic for Which a Policy Should Be Defined 🗺️

The message type that the experimental Seamoby protocols use will be expected to cross site boundaries in normal operation. Transit sites must allow these messages to transit the site. End site administrators should determine whether they need to support these experiments. Otherwise, messages of this type should be dropped:

Seamoby Experimental (Type 150)

Error messages not currently defined by IANA:

Unallocated Error messages (Types 5-99 inclusive and 102-126 inclusive)

The base ICMPv6 specification suggests that error messages not explicitly known to a node should be forwarded and passed to any higher-level protocol that might be able to interpret them. There's a small risk that such messages could be used to create a covert channel or form part of a DoS attack 😬. End site admins should be aware of this and decide whether they want to allow these messages through the firewall. Firewalls protecting transit sites must allow all types of error messages to transit the site, but they may adopt different policies for error messages addressed to nodes within the site 🌐.

All informational messages with types not explicitly assigned by IANA, currently:

Unallocated Informational messages (Types 154-199 inclusive and 202-254 inclusive).

Note that the base ICMPv6 specification requires that received informational messages with unknown types must be silently discarded. Transit sites must allow these messages to transit the site. End site administrators can either adopt a policy of allowing all these messages through the firewall, relying on end hosts to drop unrecognized messages, or drop all such messages at the firewall. Different policies could be adopted for inbound and outbound messages 🔁.

If administrators choose to implement policies that drop currently unallocated error or informational messages, it's important to review the set of messages affected, in case IANA assigns new message types later 📋.

4.3.5. Traffic That Should Be Dropped Unless a Good Case Can Be Made 🧐

Node Information enquiry messages should generally not be forwarded across site boundaries. Some of these messages use non-link-local unicast addresses, so they won't necessarily be dropped by address scope limiting rules:

Node Information Query (Type 139)
Node Information Response (Type 140)

Router Renumbering messages should not be forwarded across site boundaries. As originally specified, these messages may use a site scope multicast address or a site local unicast address. They should be caught by standard rules meant to stop any packet with a multicast site scope or site local destination from being forwarded across a site boundary, provided those rules are configured correctly. Since site local addresses have now been deprecated, it seems likely that changes may be made to allow the use of unique local addresses or global unicast addresses. Should that happen, it will be essential to explicitly filter these messages at site boundaries 🚧. If a site has internal as well as boundary firewalls, individual policies should be set up for the internal firewalls, depending on whether or not the site wants to use Router Renumbering:

Router Renumbering (Type 138)

Messages with types in the experimental allocations:

Types 100, 101, 200, and 201.

Messages using the extension type numbers until such time as ICMPv6 needs to use such extensions:

Types 127 and 255.

4.4. Recommendations for ICMPv6 Local Configuration Traffic 🛠️

This section recommends filtering rules for ICMPv6 traffic addressed to an interface on a firewall. For a small number of messages, the desired behavior may differ between interfaces on the site or private side of the firewall and those on the public Internet side of the firewall 🌈.

4.4.1. Traffic That Must Not Be Dropped

okay so these error messages are literally essential for setting up and keeping connections alive 💖 do not drop them 🙅‍♀️

Destination Unreachable (Type 1) - All codes
Packet Too Big (Type 2)
Time Exceeded (Type 3) - Code 0 only
Parameter Problem (Type 4) - Codes 1 and 2 only

Connectivity checking messages (aka the pings of the networking world 🏓):

Echo Request (Type 128)
Echo Response (Type 129)

as we covered in Section 4.3.1, dropping connectivity checking messages will stop the firewall from being the destination of a Teredo tunnel 🫣 and it's not considered necessary to turn off connectivity checking in IPv6 networks, because port scanning is less of a security risk ✨

there's a whole bunch of other message sets that help configure the node and keep unicast and multicast traffic flowing through its interfaces 🌈 these messages must not be dropped if the node is going to successfully take part in an IPv6 network. the one exception is Redirect, which needs an explicit policy decision (see Section 4.4.4) 🧚

Address Configuration and Router Selection messages:

Router Solicitation (Type 133)
Router Advertisement (Type 134)
Neighbor Solicitation (Type 135)
Neighbor Advertisement (Type 136)
Inverse Neighbor Discovery Solicitation (Type 141)
Inverse Neighbor Discovery Advertisement (Type 142)

Link-Local Multicast Receiver Notification messages:

Listener Query (Type 130)
Listener Report (Type 131)
Listener Done (Type 132)
Listener Report v2 (Type 143)

SEND Certificate Path Notification messages:

Certificate Path Solicitation (Type 148)
Certificate Path Advertisement (Type 149)

Multicast Router Discovery messages:

Multicast Router Advertisement (Type 151)
Multicast Router Solicitation (Type 152)
Multicast Router Termination (Type 153)

4.4.2. Traffic That Normally Should Not Be Dropped

these are error messages that aren't in the list above 👀 they normally shouldn't get dropped, bestie 🫶

Time Exceeded (Type 3) - Code 1
Parameter Problem (Type 4) - Code 0

4.4.3. Traffic That Will Be Dropped Anyway -- No Special Attention Needed

Router Renumbering messages must be authenticated using IPsec 🔐 so it's not essential to filter these, even if they aren't allowed at the firewall/router:

Router Renumbering (Type 138)

Mobile IPv6 messages that help with mobility:

Home Agent Address Discovery Request (Type 144)
Home Agent Address Discovery Reply (Type 145)
Mobile Prefix Solicitation (Type 146)
Mobile Prefix Advertisement (Type 147)

it may be desirable to drop these messages, especially on public interfaces, if the firewall is not also providing mobile home agent services. otherwise they'll be ignored anyway 🙈

the message used by the experimental Seamoby protocols may be dropped, but it will be ignored if the service isn't implemented 🦋

Seamoby Experimental (Type 150)

4.4.4. Traffic for Which a Policy Should Be Defined

Redirect messages are a significant security risk, so admins need to take a case-by-case approach to whether firewalls, routers in general, and other nodes should accept them 🚨

Redirect (Type 137)

conformant nodes must provide configuration controls that let nodes control how they behave with respect to Redirect messages 💅 so it should only be necessary to install specific filtering rules under special circumstances, like if Redirect messages are accepted on private interfaces but not public ones 🎀

if a node implements the experimental Node Information service, the admin needs to make an explicit decision about whether the node should respond to or accept Node Information messages on each interface 🧐

Node Information Query (Type 139)
Node Information Response (Type 140)

it may be possible to disable the service on the node if it isn't wanted. in that case these messages will be ignored and no filtering is necessary 🌸

Error messages not currently defined by IANA:

Unallocated Error messages (Types 5-99 inclusive and 102-126 inclusive)

the base ICMPv6 specification suggests that error messages not explicitly known to a node should be forwarded and passed to any higher-level protocol that might be able to interpret them 🤔 there's a small risk that such messages could be used to make a covert channel or be part of a DoS attack. admins should be aware of this and decide whether they want to let these messages reach the firewall 🛡️

4.4.5. Traffic That Should Be Dropped Unless a Good Case Can Be Made

Messages with types in the experimental allocations:

Types 100, 101, 200, and 201.

Messages using the extension type numbers until ICMPv6 needs to use such extensions:

Types 127 and 255.

All informational messages with types not explicitly assigned by IANA, currently:

Types 154-199 inclusive and 202-254 inclusive.

note that the base ICMPv6 specification requires that received informational messages with unknown types must be silently discarded 🤫

5. Acknowledgements 🌷

Pekka Savola created the original IPv6 Security Overview document, which had suggestions for ICMPv6 filter setups. that info has been folded into this document. he also gave us some important comments 💜 some analysis of the classification of ICMPv6 messages and the term 'any-to-end' was used by Jari Arkko in a document about ICMPv6 and IKE 🫶

the Netfilter configuration script in Appendix B was contributed by Suresh Krishnan 🙌

6. References 📚

6.1. Normative References

[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, June 2001.
[RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information Queries", RFC 4620, August 2006.

6.2. Informative References

[ICMP-ATTACKS] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2006.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[SCAN-IMP] Chown, T., "IPv6 Implications for Network Scanning", Work in Progress, March 2007.
[netfilter] netfilter.org, "The netfilter.org project", Firewalling, NAT and Packet Mangling for Linux, 2006, <http://www.netfilter.org/>.

Appendix A. Notes on Individual ICMPv6 Messages 🧁

A.1. Destination Unreachable Error Message

Destination Unreachable (Type 1) error messages [RFC4443] are sent any-to-end between unicast addresses 💌 the message can be generated from any node a packet passes through when that node can't forward the packet for any reason except congestion.

Destination Unreachable messages are super useful for debugging, but they also matter for speeding up cycling through possible addresses. they can skip the need to wait through timeouts, so they can be part of setting up or keeping communications going ⏩ it's a common practice in IPv4 to hold back ICMP Destination Unreachable messages to hide the networking topology and/or service structure 🕵️‍♀️ the same idea could be applied to IPv6, but this can slow down connections if a host has multiple addresses, some of which are deprecated, as they may be when using privacy addresses [RFC3041] 😬 if policy allows ICMPv6 Destination Unreachable messages to be generated, it's important that nodes give the correct reason code, one of: no route to destination, administratively prohibited, beyond scope of source address, address unreachable, port unreachable, source address failed ingress/egress policy, or reject route to destination.

A.2. Packet Too Big Error Message

Packet Too Big (Type 2) error messages [RFC4443] are sent any-to-end between unicast addresses 📦 the message can be generated from any node on the path that a packet travels through when that node can't forward the packet because it's too large for the MTU of the next link. this message is vital for Path MTU Discovery to work correctly, so it's part of establishing and maintaining communications 🫶 since routers aren't allowed to fragment packets, telling sources they need to fragment large packets matters more than it does for IPv4 ✨ if these messages aren't generated when they should be, hosts will keep sending packets that are too large or may assume the route is congested. basically, parts of the Internet become inaccessible 😭

if a network chooses to generate packets no larger than the Guaranteed Minimum MTU (1280 octets) and the site's links to the wider Internet have corresponding MTUs, Packet Too Big messages should not be expected at the firewall and could be dropped if they arrive 🌈

A.3. Time Exceeded Error Message ⏰

okay so Time Exceeded (Type 3) error messages [RFC4443] can show up in two different situations, and they're lowkey different vibes:

Code 0 messages get generated at any node on the path the packet takes, and they're sent any-to-end between unicast addresses, but only if the Hop Limit value gets decremented to zero at that node. 🧭
Code 1 messages get generated at the destination node and sent end-to-end between unicast addresses if not all the segments of a fragmented message arrive within the reassembly time limit. 🧩

Code 0 messages can be needed as part of setting up communications if the path to a particular destination takes an unusually large number of hops. 🦋

Code 1 messages will generally only come from congestion in the network, and it's less essential to pass these ones along. 💤

A.4. Parameter Problem Error Message 🚨

bestie, the great majority of Parameter Problem (Type 4) error messages get generated by the destination node when it's processing destination options and other extension headers, so they're sent end-to-end between unicast addresses. 💌 Exceptionally, these messages might come from any node on the path if there's a faulty or unrecognized hop-by-hop option, or from any routing waypoint if there are faulty or unrecognized destination options tied to a Type 0 routing header. In those cases, the message gets sent any-to-end using unicast source and destination addresses. 🌍

Code 1 (Unrecognized Next Header) and Code 2 (Unrecognized IPv6 Option) messages may show up if a node on the path (usually the destination) can't process a correctly formed extension header or option. 🙈 If these messages aren't returned to the source, communication can't be established, because the source would need to adapt its choice of options, probably because the destination doesn't implement these capabilities. So these messages need to be generated and allowed for effective IPv6 communications. 💖

Code 0 (Erroneous Header) messages indicate a malformed extension header, generally as a result of incorrectly generated packets. 🛠️ These messages are useful for debugging, but it's unlikely that a node generating such packets could establish communications without human intervention to fix the problem. 😭

Code 2 messages, only, can be generated for packets with multicast destination addresses. 🌸

It's possible that attackers might try to probe or scan a network by deliberately generating packets with unknown extension headers or options, or with faulty headers. 👀 If nodes generate Parameter Problem error messages in all cases and these outgoing messages are allowed through firewalls, the attacker may be able to identify active addresses that can be probed further or learn about the network topology. 💀 The vulnerability could be mitigated while still helping to establish communications if the firewall was able to examine such error messages in depth and was configured to only allow Parameter Problem messages for headers that had been standardized but weren't supported in the protected network. 🛡️ If the network administrator believes that all nodes in the network support all legitimate extension headers, then it would be reasonable to drop all outgoing Parameter Problem messages. 🫶 Note that this is not a major vulnerability in a well-designed IPv6 network, because of the difficulties of performing scanning attacks (see Section 3.2). 🧚

A.5. ICMPv6 Echo Request and Echo Response 🏓

Echo Request (Type 128) uses unicast addresses as source addresses, but it may be sent to any legal IPv6 address, including multicast and anycast addresses [RFC4443]. Echo Requests travel end-to-end. ✨ Similarly, Echo Responses (Type 129) travel end-to-end and would have a unicast address as destination and either a unicast or anycast address as source. 💅 They're mainly used together for monitoring and debugging connectivity. Their only role in establishing communication is that they're required when verifying connectivity through Teredo tunnels [RFC4380]: Teredo tunneling to IPv6 nodes on the site won't be possible if these messages are blocked. 🚫 It's not thought that there's a significant risk from scanning attacks on a well-designed IPv6 network (see Section 3.2), so connectivity checks should be allowed by default. 🌈

A.6. Neighbor Solicitation and Neighbor Advertisement Messages 🏠

ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and 136) messages are essential to establishing and maintaining communications on the local link. 🔗 Firewalls need to generate and accept these messages so they can establish and maintain interfaces onto their connected links. 💜

Note that the address scopes of the source and destination addresses on Neighbor Solicitations and Neighbor Advertisements may not match. 🤷‍♀️ The exact functions these messages carry out depend on the mechanism being used to configure IPv6 addresses on the link (Stateless, Stateful, or Static configuration). 🎀

A.7. Router Solicitation and Router Advertisement Messages 📡

ICMPv6 Router Solicitation and Router Advertisement (Type 133 and 134) messages are essential to establishing and maintaining communications on the local link. 🧃 Firewalls need to generate these messages (since the firewall will generally be behaving as a router) and accept them, so they can establish and maintain interfaces onto their connected links. 🍓

A.8. Redirect Messages ↪️

ICMPv6 Redirect Messages (Type 137) are used on the local link to indicate that nodes are actually link-local and communications don't need to go via a router, or to indicate a more appropriate first-hop router. 🗺️ They can make communications more efficient, but they're not essential to establishing communications, and they may be a security vulnerability, particularly if a link isn't physically secured. 🙅‍♀️

Conformant nodes are required to provide configuration controls that suppress the generation of Redirect messages and allow them to be ignored on reception. 🔐

Using Redirect messages on, for example, a wireless link without link level encryption/authentication is particularly hazardous, because the link is open to eavesdropping and packet injection. 😱

A.9. SEND Certificate Path Messages 🪪

SEND [RFC3971] uses two messages (Certificate Path Solicitation and Advertisement - Types 148 and 149) sent from nodes to supposed routers on the same local link. 🕵️‍♀️ They're used to obtain a certificate path that will let the node authenticate the router's claim to provide routing services for certain prefixes. If a link connected to a firewall/router is using SEND, the firewall must be able to exchange these messages with nodes on the link that will use its routing services. 🔑

A.10. Multicast Listener Discovery Messages 🎧

Multicast Listener Discovery (MLD) version 1 [RFC2710] (Listener Query, Listener Report, and Listener Done - Types 130, 131, and 132) and version 2 [RFC3810] (Listener Query and Listener Report version 2 - Types 130 and 143) messages are sent on the local link to communicate between multicast-capable routers and nodes that want to join or leave specific multicast groups. 🎶 Firewalls need to be able to generate Listener messages in order to establish communications, and they may generate all the messages if they also provide multicast routing services. 🧚‍♀️

A.11. Multicast Router Discovery Messages 🔎

Multicast Router Discovery [RFC4286] (Router Advertisement, Router Solicitation, and Router Termination - Types 151, 152, and 153) messages are sent by nodes on the local link to discover multicast-capable routers on the link, and by multicast-capable routers to notify other nodes of their existence or change of state. 📣 Firewalls that also act as multicast routers need to process these messages on their interfaces. 💅

A.12. Router Renumbering Messages 🔢

ICMPv6 Router Renumbering (Type 138) command messages can be received, and results messages sent, by routers to change the prefixes they advertise as part of Stateless Address Configuration [RFC2461], [RFC2462]. 🔄 These messages are sent end-to-end to either the all-routers multicast address (site or local scope) or specific unicast addresses, from a unicast address. 🗼

Router Renumbering messages are required to be protected by IPsec authentication, since they could be easily misused by attackers to disrupt or divert site communications. 🚧 Renumbering messages should generally be confined to sites for this reason. 🏰

A.13. Node Information Query and Reply 📋

ICMPv6 Node Information Query and Reply (Type 139 and 140) messages defined in [RFC4620] are sent end-to-end between unicast addresses, and they can also be sent to link-local multicast addresses. 💌 They can, in theory, be sent from any node to any other, but it would generally not be desirable for nodes outside the local site to be able to send queries to nodes within the site. 🙅‍♀️ Also, these messages aren't required to be authenticated. 🫠

A.14. Mobile IPv6 Messages 🧳

Mobile IPv6 [RFC3775] defines four ICMPv6 messages that support mobile operations: Home Agent Address Discovery Request, Home Agent Address Discovery Reply, Mobile Prefix Solicitation, and ICMP Mobile Prefix Advertisement (Type 144, 145, 146, and 147). 🌍 These messages are sent end-to-end between unicast addresses of a mobile node and its home agent. They must be expected to come from outside a site, and they must traverse site-boundary firewalls to reach the home agent in order for Mobile IPv6 to function. 🚪 The two Mobile prefix messages should be protected by the use of IPsec authentication. 🔐

If the site provides home agents for mobile nodes, the firewall must allow incoming Home Agent Address Discovery Request and Mobile Prefix Solicitation messages, and outgoing Home Agent Address Discovery Reply and ICMP Mobile Prefix Advertisement messages. It may be desirable to limit the destination addresses for the incoming messages to links that are known to support home agents. 🏡
If the site is prepared to host roaming mobile nodes, the firewall must allow outgoing Home Agent Address Discovery Request and Mobile Prefix Solicitation messages, and incoming Home Agent Address Discovery Reply and ICMP Mobile Prefix Advertisement messages. ✈️
Administrators may find it desirable to prevent static nodes that are normally resident on the site from behaving as mobile nodes, by dropping Mobile IPv6 messages from these nodes. 🧱

A.15. Unused and Experimental Messages ✨

okay so a LOT of ICMPv6 Type values are just sitting there unused 🫠 nobody has registered a specific function for them with IANA yet. this section is about what to do when a message shows up using one of these Type values in a way the network administrator (and therefore the firewall) has no clue about 👀

[RFC4443] defines a bunch of experimental Type values for ICMPv6 Error and Informational messages that could be used in site-specific ways 🧪 these messages should be dropped by transit networks and at site edges. they also should not be propagated within sites unless the network administrator is explicitly made aware of usage 🙅‍♀️

the codes reserved for future extension of the ICMPv6 Type space should currently be dropped, because that functionality is as yet undefined 💀 not vibing with undefined stuff rn.

any ICMPv6 Informational messages the firewall isn't aware of should be allowed to transit through the firewall, but should not be accepted for local delivery on any of its interfaces 🦋

unknown ICMPv6 Error messages should be allowed to pass through transit networks. at end site boundaries, incoming ICMPv6 Error messages the firewall isn't aware of may be allowed through the firewall in line with the specification in [RFC4443], which asks for delivery of unknown error messages to higher-layer protocol processes 🌸 BUT admins may wish to disallow forwarding of these incoming messages as a potential security risk 😭 (this is a flag, bestie!). unknown outgoing Error messages should be dropped, because the administrator should be aware of all messages that could be generated on the site 🔒

also!! the SEAMOBY working group got an ICMPv6 message (Type 150) allocated for experimental use in two protocols 🧚 this message is sent end-to-end and may need to pass through firewalls on sites that are supporting the experimental protocols 💜

B. Example Script to Configure ICMPv6 Firewall Rules ✨

okay bestie, this appendix is a full example script 🧚 It implements most of the rules suggested in this document using the Netfilter packet filtering system for Linux [netfilter]. For IPv6, the ip6tables command is what sets up the packet filtering rules for Netfilter. The script is aimed at a simple enterprise site that may or may not support Mobile IPv6 🫶

#!/bin/bash
# Set of prefixes on the trusted ("inner") side of the firewall
export INNER_PREFIXES="2001:DB8:85::/60"
# Set of hosts providing services so that they can be made pingable
export PINGABLE_HOSTS="2001:DB8:85::/64"
# Configuration option: Change this to 1 if errors allowed only for
# existing sessions
export STATE_ENABLED=0
# Configuration option: Change this to 1 if messages to/from link
# local addresses should be filtered.
# Do not use this if the firewall is a bridge.
# Optional for firewalls that are routers.
export FILTER_LINK_LOCAL_ADDRS=0
# Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 Home Agents - see Appendix A.14
export HOME_AGENTS_PRESENT=1
# Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 mobile nodes being present on the site -
# see Appendix A.14
export MOBILE_NODES_PRESENT=1

ip6tables -N icmpv6-filter
ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter

# Match scope of src and dest else deny
# This capability is not provided for in base ip6tables functionality
# An extension (agr) exists which may support it.
#@TODO@
# ECHO REQUESTS AND RESPONSES
# ===========================

# Allow outbound echo requests from prefixes which belong to the site
for inner_prefix in $INNER_PREFIXES
do
  ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
        --icmpv6-type echo-request -j ACCEPT
done

# Allow inbound echo requests towards only predetermined hosts
for pingable_host in $PINGABLE_HOSTS
do
  ip6tables -A icmpv6-filter -p icmpv6 -d $pingable_host \
        --icmpv6-type echo-request -j ACCEPT
done

if [ "$STATE_ENABLED" -eq "1" ]
then
  # Allow incoming and outgoing echo reply messages
  # only for existing sessions
  ip6tables -A icmpv6-filter -m state -p icmpv6 \
        --state ESTABLISHED,RELATED --icmpv6-type \
      echo-reply -j ACCEPT
else
  # Allow both incoming and outgoing echo replies
  for pingable_host in $PINGABLE_HOSTS
  do
    # Outgoing echo replies from pingable hosts
    ip6tables -A icmpv6-filter -p icmpv6 -s $pingable_host \
        --icmpv6-type echo-reply -j ACCEPT
  done
  # Incoming echo replies to prefixes which belong to the site
  for inner_prefix in $INNER_PREFIXES
  do
    ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
        --icmpv6-type echo-reply -j ACCEPT
  done
fi

# Deny icmps to/from link local addresses
# If the firewall is a router:
#    These rules should be redundant as routers should not forward
#    link local addresses but to be sure...
# DO NOT ENABLE these rules if the firewall is a bridge
if [ "$FILTER_LINK_LOCAL_ADDRS" -eq "1" ]
then
  ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP
  ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP
fi

# Drop echo replies which have a multicast address as a
# destination
ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \
        --icmpv6-type echo-reply -j DROP

# DESTINATION UNREACHABLE ERROR MESSAGES
# ======================================

if [ "$STATE_ENABLED" -eq "1" ]
then
  # Allow incoming destination unreachable messages
  # only for existing sessions
  for inner_prefix in $INNER_PREFIXES
  do
    ip6tables -A icmpv6-filter -m state -p icmpv6 \
         -d $inner_prefix \
         --state ESTABLISHED,RELATED --icmpv6-type \
         destination-unreachable -j ACCEPT
  done
else
  # Allow incoming destination unreachable messages
  for inner_prefix in $INNER_PREFIXES
  do
    ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
         --icmpv6-type destination-unreachable -j ACCEPT
  done
fi

# Allow outgoing destination unreachable messages
for inner_prefix in $INNER_PREFIXES
do
  ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
         --icmpv6-type destination-unreachable -j ACCEPT
done

# PACKET TOO BIG ERROR MESSAGES
# =============================

if [ "$STATE_ENABLED" -eq "1" ]
then
  # Allow incoming Packet Too Big messages
  # only for existing sessions
  for inner_prefix in $INNER_PREFIXES
  do
    ip6tables -A icmpv6-filter -m state -p icmpv6 \

         -d $inner_prefix \
         --state ESTABLISHED,RELATED \
         --icmpv6-type packet-too-big \
         -j ACCEPT
  done
else
  # Allow incoming Packet Too Big messages
  for inner_prefix in $INNER_PREFIXES
  do
    ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
         --icmpv6-type packet-too-big -j ACCEPT
  done
fi

# Allow outgoing Packet Too Big messages
for inner_prefix in $INNER_PREFIXES
do
  ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
         --icmpv6-type packet-too-big -j ACCEPT
done

# TIME EXCEEDED ERROR MESSAGES
# ============================

if [ "$STATE_ENABLED" -eq "1" ]
then
  # Allow incoming time exceeded code 0 messages
  # only for existing sessions
  for inner_prefix in $INNER_PREFIXES
  do
    ip6tables -A icmpv6-filter -m state -p icmpv6 \
         -d $inner_prefix \
         --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \
         -j ACCEPT
  done
else
  # Allow incoming time exceeded code 0 messages
  for inner_prefix in $INNER_PREFIXES
  do
    ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
         --icmpv6-type ttl-zero-during-transit -j ACCEPT
  done
fi

#@POLICY@
# Allow incoming time exceeded code 1 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
         --icmpv6-type ttl-zero-during-reassembly -j ACCEPT
done

# Allow outgoing time exceeded code 0 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
         --icmpv6-type ttl-zero-during-transit -j ACCEPT
done

#@POLICY@
# Allow outgoing time exceeded code 1 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
         --icmpv6-type ttl-zero-during-reassembly -j ACCEPT
done


# PARAMETER PROBLEM ERROR MESSAGES
# ================================

if [ "$STATE_ENABLED" -eq "1" ]
then
  # Allow incoming parameter problem code 1 and 2 messages
  # for an existing session
  for inner_prefix in $INNER_PREFIXES
  do
    ip6tables -A icmpv6-filter -m state -p icmpv6 \
         -d $inner_prefix \
         --state ESTABLISHED,RELATED --icmpv6-type \
         unknown-header-type \
         -j ACCEPT
    ip6tables -A icmpv6-filter -m state -p icmpv6 \
         -d $inner_prefix \
         --state ESTABLISHED,RELATED \
         --icmpv6-type unknown-option \
         -j ACCEPT
  done
fi

# Allow outgoing parameter problem code 1 and code 2 messages
for inner_prefix in $INNER_PREFIXES
do
  ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
         --icmpv6-type unknown-header-type -j ACCEPT
  ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \

         --icmpv6-type unknown-option -j ACCEPT
done

#@POLICY@
# Allow incoming and outgoing parameter
# problem code 0 messages
for inner_prefix in $INNER_PREFIXES
do
  ip6tables -A icmpv6-filter -p icmpv6 \
         --icmpv6-type bad-header \
         -j ACCEPT
done

# NEIGHBOR DISCOVERY MESSAGES
# ===========================

# Drop NS/NA messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 \
         --icmpv6-type neighbor-solicitation -j DROP
ip6tables -A icmpv6-filter -p icmpv6 \
         --icmpv6-type neighbor-advertisement -j DROP

# Drop RS/RA messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 \
         --icmpv6-type router-solicitation -j DROP
ip6tables -A icmpv6-filter -p icmpv6 \
         --icmpv6-type router-advertisement -j DROP

# Drop Redirect messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type redirect -j DROP

# MLD MESSAGES
# ============

# Drop incoming and outgoing
# Multicast Listener queries (MLDv1 and MLDv2)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 130 -j DROP

# Drop incoming and outgoing Multicast Listener reports (MLDv1)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP

# Drop incoming and outgoing Multicast Listener Done messages (MLDv1)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP

# Drop incoming and outgoing Multicast Listener reports (MLDv2)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP

# ROUTER RENUMBERING MESSAGES
# ===========================

# Drop router renumbering messages
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP

# NODE INFORMATION QUERIES
# ========================

# Drop node information queries (139) and replies (140)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 139 -j DROP
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 140 -j DROP


# MOBILE IPv6 MESSAGES
# ====================

# If there are mobile ipv6 home agents present on the
# trusted side allow
if [ "$HOME_AGENTS_PRESENT" -eq "1" ]
then
  for inner_prefix in $INNER_PREFIXES
  do
    #incoming Home Agent address discovery request
    ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
         --icmpv6-type 144 -j ACCEPT
    #outgoing Home Agent address discovery reply
    ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
         --icmpv6-type 145 -j ACCEPT
    #incoming Mobile prefix solicitation
    ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
         --icmpv6-type 146 -j ACCEPT
    #outgoing Mobile prefix advertisement
    ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
         --icmpv6-type 147 -j ACCEPT
  done
fi

# If there are roaming mobile nodes present on the
# trusted side allow
if [ "$MOBILE_NODES_PRESENT" -eq "1" ]
then
  for inner_prefix in $INNER_PREFIXES
  do
    #outgoing Home Agent address discovery request
    ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
         --icmpv6-type 144 -j ACCEPT
    #incoming Home Agent address discovery reply
    ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \

         --icmpv6-type 145 -j ACCEPT
    #outgoing Mobile prefix solicitation
    ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
         --icmpv6-type 146 -j ACCEPT
    #incoming Mobile prefix advertisement
    ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
         --icmpv6-type 147 -j ACCEPT
  done
fi

# DROP EVERYTHING ELSE
# ====================

ip6tables -A icmpv6-filter -p icmpv6 -j DROP

Example Netfilter Configuration Script for ICMPv6 Filtering

Authors' Addresses

Elwyn B. Davies
Consultant
Soham, Cambs
UK

Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com


Janos Mohacsi
NIIF/HUNGARNET
Victor Hugo u. 18-22
Budapest,   H-1132
Hungary

Phone: +36 1 4503070
EMail: mohacsi@niif.hu

Full Copyright Statement ✨

Okay bestie, time for the legal bit 💅 Copyright is held by The IETF Trust (2007) 🎀. This document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 💜.

This document and everything in it are provided "AS IS" 🙈. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE all say no to ALL WARRANTIES, express or implied 💀. That includes, but isn't limited to, any promise that using the info won't infringe anyone's rights, and any implied warranty of merchantability or fitness for a particular purpose 😭.

Intellectual Property 🦋

The IETF doesn't take a side on whether any Intellectual Property Rights (or other rights someone might claim) are valid, how far they reach, or whether a license for them is even available 🌸. It also doesn't claim it has tried to dig up those rights on its own ✨. If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79 🧚.

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that might be offered, and the results of any attempt to get a general license or permission for implementers or users of this specification can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 💖.

The IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to tell them 🫶. Send that info to the IETF at ietf-ipr@ietf.org 🔥.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society 👑. Thank you, Internet Society, for keeping the lights on ⭐.

📦 where this page comes from

ietf: rfc4890 2007-05
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms