doc: Add RFC documents

1 files changed, 2131 insertions, 0 deletions

diff --git a/doc/rfc/rfc4890.txt b/doc/rfc/rfc4890.txt
new file mode 100644
index 0000000..192ec48
--- /dev/null
+++ b/doc/rfc/rfc4890.txt
@@ -0,0 +1,2131 @@
+
+
+
+
+
+
+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
+
+
+            -d $inner_prefix \
+            --state ESTABLISHED,RELATED \
+            --icmpv6-type packet-too-big \
+            -j ACCEPT
+     done
+   else
+     # Allow incoming Packet Too Big messages
+     for inner_prefix in $INNER_PREFIXES
+     do
+       ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
+            --icmpv6-type packet-too-big -j ACCEPT
+     done
+   fi
+
+   # Allow outgoing Packet Too Big messages
+   for inner_prefix in $INNER_PREFIXES
+   do
+     ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
+            --icmpv6-type packet-too-big -j ACCEPT
+   done
+
+   # TIME EXCEEDED ERROR MESSAGES
+   # ============================
+
+   if [ "$STATE_ENABLED" -eq "1" ]
+   then
+     # Allow incoming time exceeded code 0 messages
+     # only for existing sessions
+     for inner_prefix in $INNER_PREFIXES
+     do
+       ip6tables -A icmpv6-filter -m state -p icmpv6 \
+            -d $inner_prefix \
+            --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \
+            -j ACCEPT
+     done
+   else
+     # Allow incoming time exceeded code 0 messages
+     for inner_prefix in $INNER_PREFIXES
+     do
+       ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
+            --icmpv6-type ttl-zero-during-transit -j ACCEPT
+     done
+   fi
+
+   #@POLICY@
+   # Allow incoming time exceeded code 1 messages
+   for inner_prefix in $INNER_PREFIXES
+   do
+
+
+
+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
+
+
+            --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
+
+
+            --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]
+