GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4890

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, <http://www.netfilter.org/>.

Davies & Mohacsi Informational [Page 23] RFC 4890 ICMPv6 Filtering Recommendations May 2007

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 that a packet traverses when the node is unable to
 forward the packet for any reason except congestion.
 Destination Unreachable messages are useful for debugging, but are
 also important to speed up cycling through possible addresses, as
 they can avoid the need to wait through timeouts and hence can be
 part of the process of establishing or maintaining communications.
 It is a common practice in IPv4 to refrain from generating ICMP
 Destination Unreachable messages in an attempt to hide the networking
 topology and/or service structure.  The same idea could be applied to
 IPv6, but this can slow down connection if a host has multiple
 addresses, some of which are deprecated, as they may be when using
 privacy addresses [RFC3041].  If policy allows the generation of
 ICMPv6 Destination Unreachable messages, it is important that nodes
 provide 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 that a packet traverses on the path when the node is unable to
 forward the packet because the packet is too large for the MTU of the
 next link.  This message is vital to the correct functioning of Path
 MTU Discovery and hence is part of the establishment and maintenance
 of communications.  Since routers are not allowed to fragment
 packets, informing sources of the need to fragment large packets is
 more important than for IPv4.  If these messages are not generated
 when appropriate, hosts will continue to send packets that are too
 large or may assume that the route is congested.  Effectively, parts
 of the Internet will become inaccessible.
 If a network chooses to generate packets that are 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.

Davies & Mohacsi Informational [Page 24] RFC 4890 ICMPv6 Filtering Recommendations May 2007

A.3. Time Exceeded Error Message

 Time Exceeded (Type 3) error messages [RFC4443] can occur in two
 contexts:
 o  Code 0 are generated at any node on the path being taken by the
    packet and sent, any-to-end between unicast addresses, if the Hop
    Limit value is decremented to zero at that node.
 o  Code 1 messages are generated at the destination node and sent
    end-to-end between unicast addresses if all the segments of a
    fragmented message are not received within the reassembly time
    limit.
 Code 0 messages can be needed as part of the establishment of
 communications if the path to a particular destination requires an
 unusually large number of hops.
 Code 1 messages will generally only result from congestion in the
 network, and it is less essential to propagate these messages.

A.4. Parameter Problem Error Message

 The great majority of Parameter Problem (Type 4) error messages will
 be generated by the destination node when processing destination
 options and other extension headers, and hence are sent end-to-end
 between unicast addresses.  Exceptionally, these messages might be
 generated by any node on the path if a faulty or unrecognized hop-by-
 hop option is included or from any routing waypoint if there are
 faulty or unrecognized destination options associated with a Type 0
 routing header.  In these cases, the message will be sent any-to-end
 using unicast source and destination addresses.
 Parameter Problem Code 1 (Unrecognized Next Header) and Code 2
 (Unrecognized IPv6 Option) messages may result if a node on the path
 (usually the destination) is unable to process a correctly formed
 extension header or option.  If these messages are not returned to
 the source, communication cannot be established, as the source would
 need to adapt its choice of options probably because the destination
 does not implement these capabilities.  Hence, 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.
 Hence, these messages are useful for debugging purposes, but it is
 unlikely that a node generating such packets could establish
 communications without human intervention to correct the problem.

Davies & Mohacsi Informational [Page 25] RFC 4890 ICMPv6 Filtering Recommendations May 2007

 Code 2 messages, only, can be generated for packets with multicast
 destination addresses.
 It is possible that attackers may seek 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 whilst 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 were not
 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 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 are mainly used in combination for
 monitoring and debugging connectivity.  Their only role in
 establishing communication is that they are required when verifying
 connectivity through Teredo tunnels [RFC4380]: Teredo tunneling to
 IPv6 nodes on the site will not be possible if these messages are
 blocked.  It is not thought that there is a significant risk from
 scanning attacks on a well-designed IPv6 network (see Section 3.2),
 and 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 the establishment and maintenance of
 communications on the local link.  Firewalls need to generate and
 accept these messages to allow them to establish and maintain
 interfaces onto their connected links.

Davies & Mohacsi Informational [Page 26] RFC 4890 ICMPv6 Filtering Recommendations May 2007

 Note that the address scopes of the source and destination addresses
 on Neighbor Solicitations and Neighbor Advertisements may not match.
 The exact functions that these messages will be carrying out depends
 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 the establishment and maintenance of
 communications on the local link.  Firewalls need to generate (since
 the firewall will generally be behaving as a router) and accept these
 messages to allow them to 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 need
 not go via a router, or to indicate a more appropriate first-hop
 router.  Although they can be used to make communications more
 efficient, they are not essential to the establishment of
 communications and may be a security vulnerability, particularly if a
 link is not 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 to obtain a certificate path that will
 allow the node to 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 wish to
 join or leave specific multicast groups.  Firewalls need to be able

Davies & Mohacsi Informational [Page 27] RFC 4890 ICMPv6 Filtering Recommendations May 2007

 to generate Listener messages in order to establish communications
 and 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 that 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 readily 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
 are not required to be authenticated.

A.14. Mobile IPv6 Messages

 Mobile IPv6 [RFC3775] defines four ICMPv6 messages that are used to
 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) messages.
 These messages are sent end-to-end between unicast addresses of a
 mobile node and its home agent.  They must be expected to be sent
 from outside a site and must traverse site-boundary firewalls to
 reach the home agent in order for Mobile IPv6 to function.  The two

Davies & Mohacsi Informational [Page 28] RFC 4890 ICMPv6 Filtering Recommendations May 2007

 Mobile prefix messages should be protected by the use of IPsec
 authentication.
 o  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.
 o  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.
 o  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

 A large number of ICMPv6 Type values are currently unused.  These
 values have not had a specific function registered with IANA.  This
 section describes how to treat messages that attempt to use these
 Type values in a way of which the network administrator (and hence
 the firewall) is not aware.
 [RFC4443] defines a number of experimental Type values for ICMPv6
 Error and Informational messages, which could be used in site-
 specific ways.  These messages should be dropped by transit networks
 and at site edges.  They should also 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 as this functionality is as yet
 undefined.
 Any ICMPv6 Informational messages of which the firewall is not aware
 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 any incoming ICMPv6 Error
 messages of which the firewall is not aware may be allowed through
 the firewall in line with the specification in [RFC4443], which
 requests delivery of unknown error messages to higher-layer protocol

Davies & Mohacsi Informational [Page 29] RFC 4890 ICMPv6 Filtering Recommendations May 2007

 processes.  However, administrators may wish to disallow forwarding
 of these incoming messages as a potential security risk.  Unknown
 outgoing Error messages should be dropped as the administrator should
 be aware of all messages that could be generated on the site.
 Also, the SEAMOBY working group has had 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.

Appendix B. Example Script to Configure ICMPv6 Firewall Rules

 This appendix contains an example script to implement most of the
 rules suggested in this document when using the Netfilter packet
 filtering system for Linux [netfilter].  When used with IPv6, the
 'ip6tables' command is used to configure packet filtering rules for
 the Netfilter system.  The script is targeted 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@

Davies & Mohacsi Informational [Page 30] RFC 4890 ICMPv6 Filtering Recommendations May 2007

 # 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

Davies & Mohacsi Informational [Page 31] RFC 4890 ICMPv6 Filtering Recommendations May 2007

   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 \

Davies & Mohacsi Informational [Page 32] RFC 4890 ICMPv6 Filtering Recommendations May 2007

  1. d $inner_prefix \
  2. -state ESTABLISHED,RELATED \
  3. -icmpv6-type packet-too-big \
  4. 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

Davies & Mohacsi Informational [Page 33] RFC 4890 ICMPv6 Filtering Recommendations May 2007

 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 \

Davies & Mohacsi Informational [Page 34] RFC 4890 ICMPv6 Filtering Recommendations May 2007

  1. -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

Davies & Mohacsi Informational [Page 35] RFC 4890 ICMPv6 Filtering Recommendations May 2007

 # ===========================
 # 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 \

Davies & Mohacsi Informational [Page 36] RFC 4890 ICMPv6 Filtering Recommendations May 2007

  1. -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

Davies & Mohacsi Informational [Page 37] RFC 4890 ICMPv6 Filtering Recommendations May 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and 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 DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Davies & Mohacsi Informational [Page 38]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4890.txt · Last modified: 2007/05/09 21:00 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki