Network Working Group E. Davies
Request for Comments: 4890 Consultant
Category: Informational J. Mohacsi
NIIF/HUNGARNET
May 2007
Recommendations for Filtering ICMPv6 Messages in Firewalls
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
In networks supporting IPv6, the Internet Control Message Protocol
version 6 (ICMPv6) plays a fundamental role with a large number of
functions, and a correspondingly large number of message types and
options. ICMPv6 is essential to the functioning of IPv6, but there
are a number of security risks associated with uncontrolled
forwarding of ICMPv6 messages. Filtering strategies designed for the
corresponding protocol, ICMP, in IPv4 networks are not directly
applicable, because these strategies are intended to accommodate a
useful auxiliary protocol that may not be required for correct
functioning.
This document provides some recommendations for ICMPv6 firewall
filter configuration that will allow propagation of ICMPv6 messages
that are needed to maintain the functioning of the network but drop
messages that are potential security risks.
Davies & Mohacsi Informational [Page 1]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
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
Davies & Mohacsi Informational [Page 2]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
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
When a network supports IPv6 [RFC2460], the Internet Control Message
Protocol version 6 (ICMPv6) [RFC4443] plays a fundamental role
including being an essential component in establishing and
maintaining communications both at the interface level and for
sessions to remote nodes. This means that overly aggressive
filtering of ICMPv6 by firewalls may have a detrimental effect on the
establishment and maintenance of IPv6 communications. On the other
hand, allowing indiscriminate passage of all ICMPv6 messages can be a
major security risk. This document recommends a set of rules that
seek to balance effective IPv6 communication against the needs of
site security.
In a few cases, the appropriate rules will depend on whether the
firewall is protecting
o an individual host,
o an end site where all ICMPv6 messages originate or terminate
within the site, or
o a transit site such as an Internet Service Provider's site where
some ICMPv6 messages will be passing through.
The document suggests alternative rules appropriate to each situation
where it is relevant. It also notes some situations where
alternative rules could be adopted according to the nature of the
work being carried out on the site and consequent security policies.
In general, Internet Service Providers should not filter ICMPv6
messages transiting their sites so that all the necessary
communication elements are available to their customers to decide and
filter according to their policy.
Readers familiar with ICMPv6 can skip to the recommended filtering
rules in Section 4 and an example configuration script for Linux
Netfilter in Appendix B.
Davies & Mohacsi Informational [Page 3]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
ICMPv6 has a large number of functions defined in a number of sub-
protocols, and there are a correspondingly large number of messages
and options within these messages. The functions currently defined
fall into a number of 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 determining 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].
* Ensuring that neighbors remain reachable using the same IP
and link layer addresses after initial discovery (Neighbor
Unreachability Discovery - NUD) and notifying neighbors of
changes to link layer addresses. Uses NS and NA [RFC2461].
* Finding routers and determining how to obtain IP addresses
to join the subnets supported by the routers. Uses RS and
RA [RFC2461].
* If stateless autoconfiguration of hosts is enabled,
communicating prefixes and other configuration information
(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 the certificates
Davies & Mohacsi Informational [Page 4]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
documenting the trust chain between a trust anchor and the
router from 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 the link.
Uses 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 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 is
not 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].
Davies & Mohacsi Informational [Page 5]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
Experimental Extensions
* An experimental extension to ICMPv6 specifies the ICMP Node
Information Query and Response messages that 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 in locating an access router
and moving 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 be concerned with the
type of addresses in ICMPv6 packets as well as the specific source
and destination addresses.
Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be
treated as an auxiliary function with packets that can be dropped in
most cases without damaging the functionality of the network. This
means that firewall filters for ICMPv6 have to be more carefully
configured than was the case for ICMP, where typically a small set of
blanket rules could 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. The remainder are Informational
messages. In general terms, Error messages with well-known
(standardized) Type values would normally be expected to be allowed
to be sent to or pass through firewalls, and may be essential to the
establishment and maintenance of communications (see Section 2.4)
whereas Informational messages will generally be the subject of
policy rules, and those 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].
Davies & Mohacsi Informational [Page 6]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
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
is not available (e.g., one has not been configured), the message is
sent with the unspecified address (::) as the IPv6 source address.
Subsequently, the node will generate new MLD Report messages with
proper link-local source address once it has been configured
[RFC3590].
The destination address can be either 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, the Router Advertisement messages
are sent to the all-nodes multicast address when unsolicited, but can
also be sent to a unicast address in response to a specific Router
Solicitation, although this is rarely seen in current
implementations.
2.3. Network Topology and Address Scopes
ICMPv6 messages can be classified according to whether they are meant
for end-to-end communications or local communications within a link.
There are also messages that 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
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.
2.4. Role in Establishing and Maintaining Communication
Many ICMPv6 messages have a role in establishing or maintaining
communications to and from the firewall and such messages have to be
accepted by firewalls for local delivery. Generally, a firewall will
also be acting as a router so that all the messages that might be
used in configuring a router interface need to be accepted and
generated. These messages should not transit through a firewall that
is also acting as a router as they are normally intended for use
within a link.
Davies & Mohacsi Informational [Page 7]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
On the other hand, most ICMPv6 error messages traveling end-to-end or
any-to-end are essential to the establishment and maintenance of
communications. These messages must be passed through firewalls and
might also be sent to and from firewalls to assist with establishment
and maintenance of communications. For example, the Packet Too Big
error message is needed to determine the MTU along a path both when a
communication session is established initially and later if the path
is rerouted during the session.
The remaining ICMPv6 messages that are not associated with
communication establishment or maintenance will normally be
legitimately attempting to pass through a firewall from inside to out
or vice versa, but in most cases decisions as to whether or not to
allow them to pass can be made on the basis of local policy without
interfering with IPv6 communications.
The filtering rules for the various message roles will generally be
different.
3. Security Considerations
This memo recommends filtering configurations for firewalls designed
to minimize the security vulnerabilities that can arise in using the
many different sub-protocols of ICMPv6 in support of IPv6
communication.
A major concern is that it is generally not possible to use IPsec or
other means to authenticate the sender and validate the contents of
many ICMPv6 messages. To a large extent, this is because a site can
legitimately expect to receive certain error and other messages from
almost any location in the wider Internet, and these messages may
occur as a result of the first message sent to a destination.
Establishing security associations with all possible sources of
ICMPv6 messages is therefore impossible.
The inability to establish security associations to protect some
messages that are needed to establish and maintain communications
means that alternative means have to be used to reduce the
vulnerability of sites to ICMPv6-based attacks. The most common way
of doing this is to establish strict filtering policies in site
firewalls to limit the unauthenticated ICMPv6 messages that can pass
between the site and the wider Internet. This makes control of
ICMPv6 filtering a delicate balance between protecting the site by
dropping some of the ICMPv6 traffic passing through the firewall and
allowing enough of the traffic through to make sure that efficient
communication can be established.
Davies & Mohacsi Informational [Page 8]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
SEND [RFC3971] has been specified as a means to improve the security
of local ICMPv6 communications. SEND sidesteps security association
bootstrapping problems that would result if IPsec was used. SEND
affects only link-local messages and does not limit the filtering
that firewalls can apply, and its role in security is therefore not
discussed 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 number of
ways, including simply sending excessive numbers of ICMPv6 packets to
destinations in the site and sending error messages that disrupt
established communications by causing sessions to be dropped. Also,
if spurious communication establishment or maintenance messages can
be infiltrated onto a link, it might be possible to invalidate
legitimate addresses or disable interfaces.
3.2. Probing
A major security consideration is preventing attackers from probing
the site to determine the topology and identify hosts that might be
vulnerable to attack. Carefully crafted but, often, malformed
messages can be used to provoke ICMPv6 responses from hosts thereby
informing attackers of potential targets for future attacks.
However, the very large address space of IPv6 makes probing a less
effective weapon as 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 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 improvement
in efficiency 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 due
to the lack of 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.
Davies & Mohacsi Informational [Page 9]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
3.4. Renumbering Attacks
Spurious Renumbering messages can lead to the disruption of a site.
Although Renumbering messages are required to be authenticated with
IPsec, so that it is difficult to carry out such attacks in practice,
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 be passed 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 tunnel inappropriate encapsulated IP packets in ICMPv6
error messages. This problem can be alleviated by filtering ICMPv6
errors using a deep packet inspection mechanism to ensure that 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
divided into two classes:
o Rules for ICMPv6 traffic transiting the firewall, with some minor
variations for
* firewalls protecting end sites or individual hosts, and
* firewalls protecting transit sites
o 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.
Davies & Mohacsi Informational [Page 10]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
This section suggests some common considerations that should be borne
in mind when designing filtering rules and then categorizes the rules
for each class. The categories are:
o Messages that must not be dropped: usually because establishment
or maintenance of communications will be prevented or severely
impacted.
o Messages that should not be dropped: administrators need to have a
very good reason for dropping this category.
o 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.
o Messages that administrators may or may not want to drop depending
on local policy.
o 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 the type (unicast, multicast, etc.) and scope
(link-local, global unicast, etc.) of 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 remainder of this section, we are generally
considering what should be configured for unauthenticated messages.
In many cases, it is not realistic to expect more than a tiny
fraction of the messages to be authenticated.
Where messages are not essential to the establishment or maintenance
of communications, local policy can be used to determine whether a
message should be allowed or dropped.
Davies & Mohacsi Informational [Page 11]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
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 allow the firewall to perform more precise
checks based on this state, and to 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 such stateful packet inspection vary from model to model,
and it is 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 in the start of the errored packet that is
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 can be dropped. This provides 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 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
Firewalls can be implemented both as IP routers (firewall/routers)
and as link layer bridges (e.g., Ethernet bridges) that are
transparent to the IP layer although they will actually be inspecting
the IP packets as they pass through (firewall/bridges).
Many of the messages used for establishment and maintenance of
communications on the local link will be sent with link-local
addresses for at least one of their source and destination. Routers
conforming to the IPv6 standards will not forward these packets;
there is no need to configure additional rules to prevent these
Davies & Mohacsi Informational [Page 12]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
packets traversing a firewall/router, although administrators may
wish to configure rules that would drop these packets for insurance
and as a means of monitoring for attacks. Also, the specifications
of ICMPv6 messages intended for use only on the local link specify
various measures that would allow receivers to detect if the message
had passed through a router, including:
o 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.
o Checking that the source address is a link-local unicast address.
Accordingly, it is not essential to configure firewall/router rules
to drop out-of-specification packets of these types. If they have
non-link-local source and destination addresses, allowing them to
traverse the firewall/router, they would be rejected because of the
checks performed at the destination. Again, firewall administrators
may still wish to configure rules to log or drop such out-of-
specification packets.
For firewall/bridges, slightly different considerations apply. The
physical links on either side of the firewall/bridge are treated as a
single logical link for the purposes of IP. Hence, the link local
messages used for discovery functions 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 that out-of-specification
packets are actually dropped as described in the earlier part of this
section.
An end host firewall can generally be thought of as a special case of
a firewall/bridge, but the only link-local messages that need to be
allowed through are those directed to the host's interface.
4.3. Recommendations for ICMPv6 Transit Traffic
This section recommends rules that should be applied to ICMPv6
traffic attempting to transit a firewall.
Davies & Mohacsi Informational [Page 13]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
4.3.1. Traffic That Must Not Be Dropped
Error messages that are essential to the establishment and
maintenance of communications:
o Destination Unreachable (Type 1) - All codes
o Packet Too Big (Type 2)
o Time Exceeded (Type 3) - Code 0 only
o 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:
o Echo Request (Type 128)
o Echo Response (Type 129)
For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be
possible, it is essential that the connectivity checking messages are
allowed through the firewall. It has been common practice in IPv4
networks to drop Echo Request messages in firewalls to minimize 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, and it is not necessary to filter IPv6 Echo Request
messages.
4.3.2. Traffic That Normally Should Not Be Dropped
Error messages other than those listed in Section 4.3.1:
o Time Exceeded (Type 3) - Code 1
o Parameter Problem (Type 4) - Code 0
Mobile IPv6 messages that are needed to assist mobility:
o Home Agent Address Discovery Request (Type 144)
o Home Agent Address Discovery Reply (Type 145)
o Mobile Prefix Solicitation (Type 146)
o Mobile Prefix Advertisement (Type 147)
Administrators may wish to apply more selective rules as described in
Appendix A.14 depending on whether the site is catering for mobile
nodes that would normally be at home on the site and/or foreign
mobile nodes roaming onto the site.
Davies & Mohacsi Informational [Page 14]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
4.3.3. Traffic That Will Be Dropped Anyway -- No Special Attention
Needed
The messages listed in this section are all involved with local
management of nodes connected to the logical link on which they were
initially transmitted. All these messages should never be propagated
beyond the link on which they were initially transmitted. If the
firewall is a firewall/bridge rather than a firewall/router, these
messages should be allowed to transit the firewall as they would be
intended for establishing communications between the two physical
parts of the link that are bridged into a single logical link.
During normal operations, these messages will have destination
addresses, 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 is able to check that the message has not
passed through a router or it will be dropped at the first router it
encounters.
Administrators may also wish to consider providing rules in firewall/
routers to catch illegal packets sent with hop limit = 1 to avoid
ICMPv6 Time Exceeded messages being generated for these packets.
Address Configuration and Router Selection messages (must be received
with hop limit = 255):
o Router Solicitation (Type 133)
o Router Advertisement (Type 134)
o Neighbor Solicitation (Type 135)
o Neighbor Advertisement (Type 136)
o Redirect (Type 137)
o Inverse Neighbor Discovery Solicitation (Type 141)
o Inverse Neighbor Discovery Advertisement (Type 142)
Link-local multicast receiver notification messages (must have link-
local source address):
o Listener Query (Type 130)
o Listener Report (Type 131)
o Listener Done (Type 132)
o Listener Report v2 (Type 143)
Davies & Mohacsi Informational [Page 15]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
SEND Certificate Path notification messages (must be received with
hop limit = 255):
o Certificate Path Solicitation (Type 148)
o Certificate Path Advertisement (Type 149)
Multicast Router Discovery messages (must have link-local source
address and hop limit = 1):
o Multicast Router Advertisement (Type 151)
o Multicast Router Solicitation (Type 152)
o Multicast Router Termination (Type 153)
4.3.4. Traffic for Which a Policy Should Be Defined
The message type that the experimental Seamoby protocols are using
will be expected to have to cross site boundaries in normal
operation. Transit sites must allow these messages to transit the
site. End site administrators should determine if they need to
support these experiments and otherwise messages of this type should
be dropped:
o Seamoby Experimental (Type 150)
Error messages not currently defined by IANA:
o Unallocated Error messages (Types 5-99 inclusive and 102-126
inclusive)
The base ICMPv6 specification suggests that error messages that are
not explicitly known to a node should be forwarded and passed to any
higher-level protocol that might be able to interpret them. There is
a small risk that such messages could be used to provide a covert
channel or form part of a DoS attack. Administrators of end sites
should be aware of this and determine whether they wish to allow
these messages through the firewall. Firewalls protecting transit
sites must allow all types of error messages to transit the site but
may adopt different policies for error messages addressed to nodes
within the site.
All informational messages with types not explicitly assigned by
IANA, currently:
o 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
Davies & Mohacsi Informational [Page 16]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
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 is important to
review the set of messages affected in case new message types are
assigned by IANA.
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 will be using non-
link-local unicast addresses so that they will not necessarily be
dropped by address scope limiting rules:
o Node Information Query (Type 139)
o 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 that are intended to stop any packet with
a multicast site scope or site local destination being forwarded
across a site boundary provided these are correctly configured.
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 this 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 established for the internal firewalls depending
on whether or not the site wishes to use Router Renumbering:
o Router Renumbering (Type 138)
Messages with types in the experimental allocations:
o Types 100, 101, 200, and 201.
Messages using the extension type numbers until such time as ICMPv6
needs to use such extensions:
o Types 127 and 255.
Davies & Mohacsi Informational [Page 17]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
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 the those on the public Internet side of the
firewall.
4.4.1. Traffic That Must Not Be Dropped
Error messages that are essential to the establishment and
maintenance of communications:
o Destination Unreachable (Type 1) - All codes
o Packet Too Big (Type 2)
o Time Exceeded (Type 3) - Code 0 only
o Parameter Problem (Type 4) - Codes 1 and 2 only
Connectivity checking messages:
o Echo Request (Type 128)
o Echo Response (Type 129)
As discussed in Section 4.3.1, dropping connectivity checking
messages will prevent the firewall being the destination of a Teredo
tunnel and it is not considered necessary to disable connectivity
checking in IPv6 networks because port scanning is less of a security
risk.
There are a number of other sets of messages that play a role in
configuring the node and maintaining unicast and multicast
communications through the interfaces of a node. These messages must
not be dropped if the node is to successfully participate in an IPv6
network. The exception to this is the Redirect message for which an
explicit policy decision should be taken (see Section 4.4.4).
Address Configuration and Router Selection messages:
o Router Solicitation (Type 133)
o Router Advertisement (Type 134)
o Neighbor Solicitation (Type 135)
o Neighbor Advertisement (Type 136)
o Inverse Neighbor Discovery Solicitation (Type 141)
o Inverse Neighbor Discovery Advertisement (Type 142)
Davies & Mohacsi Informational [Page 18]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
Link-Local Multicast Receiver Notification messages:
o Listener Query (Type 130)
o Listener Report (Type 131)
o Listener Done (Type 132)
o Listener Report v2 (Type 143)
SEND Certificate Path Notification messages:
o Certificate Path Solicitation (Type 148)
o Certificate Path Advertisement (Type 149)
Multicast Router Discovery messages:
o Multicast Router Advertisement (Type 151)
o Multicast Router Solicitation (Type 152)
o Multicast Router Termination (Type 153)
4.4.2. Traffic That Normally Should Not Be Dropped
Error messages other than those listed in Section 4.4.1:
o Time Exceeded (Type 3) - Code 1
o 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
is not essential to filter these messages even if they are not
allowed at the firewall/router:
o Router Renumbering (Type 138)
Mobile IPv6 messages that are needed to assist mobility:
o Home Agent Address Discovery Request (Type 144)
o Home Agent Address Discovery Reply (Type 145)
o Mobile Prefix Solicitation (Type 146)
o 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, but they will be ignored otherwise.
Davies & Mohacsi Informational [Page 19]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
The message used by the experimental Seamoby protocols may be dropped
but will be ignored if the service is not implemented:
o Seamoby Experimental (Type 150)
4.4.4. Traffic for Which a Policy Should Be Defined
Redirect messages provide a significant security risk, and
administrators should take a case-by-case approach to whether
firewalls, routers in general, and other nodes should accept these
messages:
o Redirect (Type 137)
Conformant nodes must provide configuration controls that allow nodes
to control their behavior with respect to Redirect messages so that
it should only be necessary to install specific filtering rules under
special circumstances, such as if Redirect messages are accepted on
private interfaces but not public ones.
If a node implements the experimental Node Information service, the
administrator needs to make an explicit decision as to whether the
node should respond to or accept Node Information messages on each
interface:
o Node Information Query (Type 139)
o Node Information Response (Type 140)
It may be possible to disable the service on the node if it is not
wanted, in which case these messages will be ignored and no filtering
is necessary.
Error messages not currently defined by IANA:
o Unallocated Error messages (Types 5-99 inclusive and 102-126
inclusive)
The base ICMPv6 specification suggests that error messages that are
not explicitly known to a node should be forwarded and passed to any
higher-level protocol that might be able to interpret them. There is
a small risk that such messages could be used to provide a covert
channel or form part of a DoS attack. Administrators should be aware
of this and determine whether they wish to allow these messages to be
sent to the firewall.
Davies & Mohacsi Informational [Page 20]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
4.4.5. Traffic That Should Be Dropped Unless a Good Case Can Be Made
Messages with types in the experimental allocations:
o Types 100, 101, 200, and 201.
Messages using the extension type numbers until such time as ICMPv6
needs to use such extensions:
o Types 127 and 255.
All informational messages with types not explicitly assigned by
IANA, currently:
o 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 contained suggestions for ICMPv6 filter setups. This
information has been incorporated into this document. He has also
provided important comments. Some analysis of the classification of
ICMPv6 messages and the term 'any-to-end' were used by Jari Arkko in
a document relating to 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.
Davies & Mohacsi Informational [Page 21]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
[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.
Davies & Mohacsi Informational [Page 22]
RFC 4890 ICMPv6 Filtering Recommendations May 2007
[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,
RFC, FYI, BCP