draft-ietf-v6ops-icmpv6-filtering-recs-02.txt   draft-ietf-v6ops-icmpv6-filtering-recs-03.txt 
IPv6 Operations E. Davies IPv6 Operations E. Davies
Internet-Draft Consultant Internet-Draft Consultant
Expires: January 10, 2007 J. Mohacsi Intended status: Informational J. Mohacsi
NIIF/HUNGARNET Expires: August 17, 2007 NIIF/HUNGARNET
July 9, 2006 February 13, 2007
Recommendations for Filtering ICMPv6 Messages in Firewalls Recommendations for Filtering ICMPv6 Messages in Firewalls
draft-ietf-v6ops-icmpv6-filtering-recs-02.txt draft-ietf-v6ops-icmpv6-filtering-recs-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2007. This Internet-Draft will expire on August 17, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
In networks supporting IPv6 the Internet Control Message Protocol In networks supporting IPv6 the Internet Control Message Protocol
version 6 (ICMPv6) plays a fundamental role with a large number of version 6 (ICMPv6) plays a fundamental role with a large number of
functions, and a correspondingly large number of message types and functions, and a correspondingly large number of message types and
options. ICMPv6 is essential to the functioning of IPv6 but there options. ICMPv6 is essential to the functioning of IPv6 but there
are a number of security risks associated with uncontrolled are a number of security risks associated with uncontrolled
forwarding of ICMPv6 messages. Filtering strategies designed for the forwarding of ICMPv6 messages. Filtering strategies designed for the
corresponding protocol, ICMP, in IPv4 networks are not directly corresponding protocol, ICMP, in IPv4 networks are not directly
skipping to change at page 2, line 18 skipping to change at page 2, line 18
This document provides some recommendations for ICMPv6 firewall This document provides some recommendations for ICMPv6 firewall
filter configuration that will allow propagation of ICMPv6 messages filter configuration that will allow propagation of ICMPv6 messages
that are needed to maintain the functioning of the network but drop that are needed to maintain the functioning of the network but drop
messages which are potential security risks. messages which are potential security risks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Classifying ICMPv6 Messages . . . . . . . . . . . . . . . . . 6 2. Classifying ICMPv6 Messages . . . . . . . . . . . . . . . . . 6
2.1. Error and Informational ICMPv6 Messages . . . . . . . . . 6 2.1. Error and Informational ICMPv6 Messages . . . . . . . . . 6
2.2. Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . . 6 2.2. Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . . 7
2.3. Network Topology and Address Scopes . . . . . . . . . . . 7 2.3. Network Topology and Address Scopes . . . . . . . . . . . 7
2.4. Role in Establishing Communication . . . . . . . . . . . . 7 2.4. Role in Establishing and Maintaining Communication . . . . 8
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
3.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 9 3.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 9
3.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Redirection Attacks . . . . . . . . . . . . . . . . . . . 9 3.3. Redirection Attacks . . . . . . . . . . . . . . . . . . . 10
3.4. Renumbering Attacks . . . . . . . . . . . . . . . . . . . 9 3.4. Renumbering Attacks . . . . . . . . . . . . . . . . . . . 10
3.5. Problems Resulting from ICMPv6 Transparency . . . . . . . 10 3.5. Problems Resulting from ICMPv6 Transparency . . . . . . . 10
4. Filtering Recommendations . . . . . . . . . . . . . . . . . . 10 4. Filtering Recommendations . . . . . . . . . . . . . . . . . . 10
4.1. Common Considerations . . . . . . . . . . . . . . . . . . 11 4.1. Common Considerations . . . . . . . . . . . . . . . . . . 11
4.2. Interaction of Link Local Messages with 4.2. Interaction of Link Local Messages with
Firewall/Routers and Firewall/Bridges . . . . . . . . . . 12 Firewall/Routers and Firewall/Bridges . . . . . . . . . . 12
4.3. Recommendations for ICMPv6 Transit Traffic . . . . . . . . 12 4.3. Recommendations for ICMPv6 Transit Traffic . . . . . . . . 13
4.3.1. Traffic that Must Not be Dropped . . . . . . . . . . . 13 4.3.1. Traffic that Must Not be Dropped . . . . . . . . . . . 13
4.3.2. Traffic that Normally Should Not be Dropped . . . . . 13 4.3.2. Traffic that Normally Should Not be Dropped . . . . . 14
4.3.3. Traffic that will be Dropped Anyway - No Special 4.3.3. Traffic that will be Dropped Anyway - No Special
Attention Needed . . . . . . . . . . . . . . . . . . . 13 Attention Needed . . . . . . . . . . . . . . . . . . . 14
4.3.4. Traffic for which a Dropping Policy Should be 4.3.4. Traffic for which a Policy Should be Defined . . . . . 15
Defined . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.5. Traffic which Should be Dropped Unless a Good Case 4.3.5. Traffic which Should be Dropped Unless a Good Case
can be Made . . . . . . . . . . . . . . . . . . . . . 15 can be Made . . . . . . . . . . . . . . . . . . . . . 16
4.4. Recommendations for ICMPv6 Local Configuration Traffic . . 16 4.4. Recommendations for ICMPv6 Local Configuration Traffic . . 17
4.4.1. Traffic that Must Not be Dropped . . . . . . . . . . . 16 4.4.1. Traffic that Must Not be Dropped . . . . . . . . . . . 17
4.4.2. Traffic that Normally Should Not be Dropped . . . . . 17 4.4.2. Traffic that Normally Should Not be Dropped . . . . . 18
4.4.3. Traffic that will be Dropped Anyway - No Special 4.4.3. Traffic that will be Dropped Anyway - No Special
Attention Needed . . . . . . . . . . . . . . . . . . . 17 Attention Needed . . . . . . . . . . . . . . . . . . . 18
4.4.4. Traffic for which a Dropping Policy Should be 4.4.4. Traffic for which a Policy Should be Defined . . . . . 19
Defined . . . . . . . . . . . . . . . . . . . . . . . 17
4.4.5. Traffic which Should be Dropped Unless a Good Case 4.4.5. Traffic which Should be Dropped Unless a Good Case
can be Made . . . . . . . . . . . . . . . . . . . . . 18 can be Made . . . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 21 Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 22
A.1. Destination Unreachable Error Message . . . . . . . . . . 21 A.1. Destination Unreachable Error Message . . . . . . . . . . 22
A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 21 A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 22
A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 22 A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 23
A.4. Parameter Problem Error Message . . . . . . . . . . . . . 22 A.4. Parameter Problem Error Message . . . . . . . . . . . . . 23
A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 23 A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 24
A.6. Neighbor Solicitation and Neighbor Advertisement A.6. Neighbor Solicitation and Neighbor Advertisement
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 23 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.7. Router Solicitation and Router Advertisement Messages . . 24 A.7. Router Solicitation and Router Advertisement Messages . . 25
A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 24 A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 25
A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 24 A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 25
A.10. Multicast Listener Discovery Messages . . . . . . . . . . 24 A.10. Multicast Listener Discovery Messages . . . . . . . . . . 25
A.11. Multicast Router Discovery Messages . . . . . . . . . . . 25 A.11. Multicast Router Discovery Messages . . . . . . . . . . . 26
A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 25 A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 26
A.13. Node Information Query and Reply . . . . . . . . . . . . . 25 A.13. Node Information Query and Reply . . . . . . . . . . . . . 26
A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 25 A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 26
A.15. Unused and Experimental Messages . . . . . . . . . . . . . 26 A.15. Unused and Experimental Messages . . . . . . . . . . . . . 27
Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 27 Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 36
1. Introduction 1. Introduction
When a network supports IPv6 [RFC2460], the Internet Control Message When a network supports IPv6 [RFC2460], the Internet Control Message
Protocol version 6 (ICMPv6) [RFC4443], [I-D.ietf-ipngwg-icmp-v3] Protocol version 6 (ICMPv6) [RFC4443] plays a fundamental role
plays a fundamental role including being an essential component in including being an essential component in establishing and
establishing communications both at the interface level and for maintaining communications both at the interface level and for
sessions to remote nodes. This means that overly aggressive sessions to remote nodes. This means that overly aggressive
filtering of ICMPv6 may have a detrimental effect on the filtering of ICMPv6 by firewalls may have a detrimental effect on the
establishment of IPv6 communications. On the other hand, allowing establishment and maintenance of IPv6 communications. On the other
indiscriminate passage of all ICMPv6 messages can be a major security hand, allowing indiscriminate passage of all ICMPv6 messages can be a
risk. This document recommends a set of rules which seek to balance major security risk. This document recommends a set of rules which
effective IPv6 communication against the needs of site security. 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 Readers familiar with ICMPv6 can skip to the recommended filtering
rules in Section 4 and an example configuration script for Linux rules in Section 4 and an example configuration script for Linux
netfilter in Appendix B. netfilter in Appendix B.
ICMPv6 has a large number of functions defined in a number of sub- ICMPv6 has a large number of functions defined in a number of sub-
protocols, and there are a correspondingly large number of messages protocols, and there are a correspondingly large number of messages
and options within these messages. The functions currently defined and options within these messages. The functions currently defined
fall into a number of categories: fall into a number of categories:
Returning Error Messages Returning Error Messages
skipping to change at page 4, line 35 skipping to change at page 5, line 4
fall into a number of categories: fall into a number of categories:
Returning Error Messages Returning Error Messages
* Returning error messages to the source if a packet could not * Returning error messages to the source if a packet could not
be delivered. Four different error messages, each with a be delivered. Four different error messages, each with a
number of sub-types are specified in [RFC4443]. number of sub-types are specified in [RFC4443].
Connection Checking Connection Checking
* Simple monitoring of connectivity through echo requests and * Simple monitoring of connectivity through echo requests and
responses used by the ping and traceroute utilities. The responses used by the ping and traceroute utilities. The
Echo Request and Echo Response messages are specified in Echo Request and Echo Response messages are specified in
[RFC4443]. [RFC4443].
Discovery Functions Discovery Functions
* Finding neighbors (both routers and hosts) connected to the * Finding neighbors (both routers and hosts) connected to the
same link and determining their IP and link layer addresses. same link and determining their IP and link layer addresses.
These messages are also used to check the uniqueness of any These messages are also used to check the uniqueness of any
addresses that an interface proposes to use (Duplicate addresses that an interface proposes to use (Duplicate
Address Detection - DAD)). Four messages - Neighbor Address Detection - DAD). Four messages - Neighbor
Solicitation (NS), Neighbor Advertisement (NA), Router Solicitation (NS), Neighbor Advertisement (NA), Router
Solicitation (RS) and Router Advertisement (RA) - are Solicitation (RS) and Router Advertisement (RA) - are
specified in [RFC2461]. specified in [RFC2461].
* Ensuring that neighbors remain reachable using the same IP * Ensuring that neighbors remain reachable using the same IP
and link layer addresses after initial discovery (Neighbor and link layer addresses after initial discovery (Neighbor
Unreachability Discovery - NUD) and notifying neighbors of Unreachability Discovery - NUD) and notifying neighbors of
changes to link layer addresses. Uses NS and NA [RFC2461]. changes to link layer addresses. Uses NS and NA [RFC2461].
* Finding routers and determining how to obtain IP addresses * Finding routers and determining how to obtain IP addresses
to join the subnets supported by the routers. Uses RS and to join the subnets supported by the routers. Uses RS and
RA [RFC2461].[[anchor2: [RFC Editor: Please update RA [RFC2461].
references to RFC2461 when the new version of RFC2461 is
published.] --Authors]]
* If stateless auto-configuration of hosts is enabled, * If stateless auto-configuration of hosts is enabled,
communicating prefixes and other configuration information communicating prefixes and other configuration information
(including the link MTU and suggested hop limit default) (including the link Maximum Transfer Unit (MTU) and
from routers to hosts. Uses RS and RA [RFC2462]. [[anchor3: suggested hop limit default) from routers to hosts. Uses RS
[RFC Editor: Please update references to RFC2462 when the and RA [RFC2462].
new version of RFC2462 is published.] --Authors]]
* Using SEcure Neighbor Discovery (SEND) to authenticate a * Using SEcure Neighbor Discovery (SEND) to authenticate a
router attached to a link, the Certificate Path Solicitation router attached to a link, the Certificate Path Solicitation
and Advertisement messages specified in [RFC3971] are used and Advertisement messages specified in [RFC3971] are used
by hosts to retrieve the trust chain between a trust anchor by hosts to retrieve the trust chain between a trust anchor
and the router certificate from the router. and the router certificate from the router.
* Determining the Maximum Transmission Unit (MTU) along a * Determining the Maximum Transmission Unit (MTU) along a
path. The Packet Too Big error message is essential to this path. The Packet Too Big error message is essential to this
function [RFC1981]. function [RFC1981].
* Providing a means to discover the IPv6 addresses associated * Providing a means to discover the IPv6 addresses associated
with the link layer address of an interface (the inverse of with the link layer address of an interface (the inverse of
skipping to change at page 6, line 7 skipping to change at page 6, line 26
Mobile IPv6 Support Mobile IPv6 Support
* Providing support for some aspects of Mobile IPv6 especially * Providing support for some aspects of Mobile IPv6 especially
dealing with the IPv6 Mobile Home Agent functionality dealing with the IPv6 Mobile Home Agent functionality
provided in routers and needed to support a Mobile node provided in routers and needed to support a Mobile node
homed on the link. The Home Agent Address Discovery Request homed on the link. The Home Agent Address Discovery Request
and Reply; and Mobile Prefix Solicitation and Advertisement and Reply; and Mobile Prefix Solicitation and Advertisement
messages are specified in [RFC3775] messages are specified in [RFC3775]
Experimental Extensions Experimental Extensions
* An experimental extension to ICMPv6 specifies the ICMP Node * An experimental extension to ICMPv6 specifies the ICMP Node
Information Query and Response messages which can be used to Information Query and Response messages which can be used to
retrieve some basic information about nodes [I-D.ietf- retrieve some basic information about nodes [RFC4620].
ipngwg-icmp-name-lookups].
* The SEAmless IP MOBility (seamoby) working group specified a * The SEAmless IP MOBility (seamoby) working group specified a
pair of experimental protocols which use an ICMPv6 message pair of experimental protocols which use an ICMPv6 message
specified in [RFC4065] to help in locating an access router specified in [RFC4065] to help in locating an access router
and moving the attachment point of a mobile node from one and moving the attachment point of a mobile node from one
access router to another. access router to another.
Many of these messages should only be used in a link-local context 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 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 type of addresses in ICMPv6 packets as well as the specific source
and destination addresses. and destination addresses.
skipping to change at page 6, line 37 skipping to change at page 7, line 7
2. Classifying ICMPv6 Messages 2. Classifying ICMPv6 Messages
2.1. Error and Informational ICMPv6 Messages 2.1. Error and Informational ICMPv6 Messages
ICMPv6 messages contain an eight bit Type field interpreted as an ICMPv6 messages contain an eight bit Type field interpreted as an
integer between 0 and 255. Messages with Type values less than or integer between 0 and 255. Messages with Type values less than or
equal to 127 are Error Messages. The remainder are Informational equal to 127 are Error Messages. The remainder are Informational
Messages. In general terms, Error Messages with well-known Messages. In general terms, Error Messages with well-known
(standardized) Type values would normally be expected to be allowed (standardized) Type values would normally be expected to be allowed
to be sent to or pass through firewalls, and may be essential to the to be sent to or pass through firewalls, and may be essential to the
establishment of communications (see Section 2.4) whereas establishment and maintenance of communications (see Section 2.4)
Informational Messages will generally be the subject of policy rules, whereas Informational Messages will generally be the subject of
and those passing through firewalls can, in many but by no means all policy rules, and those passing through end site firewalls can, in
cases, be dropped without damaging IPv6 communications. many but by no means all cases, be dropped without damaging IPv6
communications.
2.2. Addressing of ICMPv6 2.2. Addressing of ICMPv6
ICMPv6 messages are sent using various kinds of source and ICMPv6 messages are sent using various kinds of source and
destination address types. The source address is usually a unicast destination address types. The source address is usually a unicast
address, but during address autoconfiguration message exchanges, the address, but during address autoconfiguration message exchanges, the
unspecified address :: is also used as a source address [RFC2462]. unspecified address :: is also used as a source address [RFC2462].
Multicast Listener Discovery (MLD) Report and Done messages are sent Multicast Listener Discovery (MLD) Report and Done messages are sent
with a link-local address as the IPv6 source address, if a valid with a link-local address as the IPv6 source address, if a valid
skipping to change at page 7, line 18 skipping to change at page 7, line 36
proper link-local source address once it has been configured proper link-local source address once it has been configured
[RFC3590]. [RFC3590].
The destination address can be either a well-known multicast address, The destination address can be either a well-known multicast address,
a generated multicast address such as the solicited-node multicast a generated multicast address such as the solicited-node multicast
address, an anycast address or a unicast address. While many ICMPv6 address, an anycast address or a unicast address. While many ICMPv6
messages use multicast addresses most of the time, some also use messages use multicast addresses most of the time, some also use
unicast addresses. For instance, the Router Advertisement messages unicast addresses. For instance, the Router Advertisement messages
are sent to the all-nodes multicast address when unsolicited, but can 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 also be sent to a unicast address in response to a specific Router
Solicitation. Solicitation, although this is rarely seen in current
implementations.
2.3. Network Topology and Address Scopes 2.3. Network Topology and Address Scopes
ICMPv6 messages can be classified according to whether they are meant ICMPv6 messages can be classified according to whether they are meant
for end-to-end communications or communications within a link. There for end-to-end communications or communications within a link. There
are also messages that we can classify as 'any-to-end', which can be 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 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 are used to announce an error in processing the original packet. For
instance, the address resolution messages are solely for local instance, the address resolution messages are solely for local
communications [RFC2461], whereas the Destination Unreachable communications [RFC2461], whereas the Destination Unreachable
messages are any-to-end in nature. Generally end-to-end and any-to- 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 end messages might be expected to pass through firewalls depending on
policies but local communications must not. policies but local communications must not.
Local communications will use link-local addresses in many cases but Local communications will use link-local addresses in many cases but
may also use global unicast addresses when configuring global may also use global unicast addresses when configuring global
addresses, for example. Also some ICMPv6 messages used in local addresses, for example. Also some ICMPv6 messages used in local
communications may contravene the usual rules requiring compatible communications may contravene the usual rules requiring compatible
scopes for source and destination addresses. scopes for source and destination addresses.
2.4. Role in Establishing Communication 2.4. Role in Establishing and Maintaining Communication
Many ICMPv6 messages have a role in establishing communications to Many ICMPv6 messages have a role in establishing or maintaining
and from the firewall and such messages have to be accepted by communications to and from the firewall and such messages have to be
firewalls for local delivery. Generally a firewall will also be accepted by firewalls for local delivery. Generally a firewall will
acting as a router so that all the messages that might be used in also be acting as a router so that all the messages that might be
configuring a router interface need to be accepted and generated. used in configuring a router interface need to be accepted and
This type of communication establishment messages should not be generated. These messages should not transit through a firewall that
passed through a firewall as they are normally intended for use is also acting as a router as they are normally intended for use
within a link. within a link.
On the other hand, most ICMPv6 error messages traveling end-to-end or On the other hand, most ICMPv6 error messages traveling end-to-end or
any-to-end are essential to the establishment of communications. any-to-end are essential to the establishment and maintenance of
communications. These messages must be passed through firewalls and
These messages must be passed through firewalls and might also be might also be sent to and from firewalls to assist with establishment
sent to and from firewalls to assist with establishment of and maintenance of communications. For example the Packet Too Big
communications. For example the Packet Too Big error message is error message is needed to determine the MTU along a path both when a
needed to establish the MTU along a path. communication session is established initially and later if the path
is rerouted during the session.
The remaining ICMPv6 messages which are not associated with The remaining ICMPv6 messages which are not associated with
communication establishment will normally be legitimately attempting communication establishment or maintenance will normally be
to pass through a firewall from inside to out or vice versa, but in legitimately attempting to pass through a firewall from inside to out
most cases decisions as to whether to allow them to pass or not can or vice versa, but in most cases decisions as to whether to allow
be made on the basis of local policy without interfering with the them to pass or not can be made on the basis of local policy without
establishment of IPv6 communications. interfering with IPv6 communications.
The filtering rules for the various message roles will generally be The filtering rules for the various message roles will generally be
different. different.
3. Security Considerations 3. Security Considerations
This memo recommends filtering configurations for firewalls designed This memo recommends filtering configurations for firewalls designed
to minimize the security vulnerabilities that can arise in using the to minimize the security vulnerabilities that can arise in using the
many different sub-protocols of ICMPv6 in support of IPv6 many different sub-protocols of ICMPv6 in support of IPv6
communication. communication.
skipping to change at page 8, line 37 skipping to change at page 9, line 10
A major concern is that it is generally not possible to use IPsec or 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 other means to authenticate the sender and validate the contents of
many ICMPv6 messages. To a large extent this is because a site can many ICMPv6 messages. To a large extent this is because a site can
legitimately expect to receive certain error and other messages from legitimately expect to receive certain error and other messages from
almost any location in the wider Internet, and these messages may almost any location in the wider Internet, and these messages may
occur as a result of the first message sent to a destination. occur as a result of the first message sent to a destination.
Establishing security associations with all possible sources of Establishing security associations with all possible sources of
ICMPv6 messages is therefore impossible. ICMPv6 messages is therefore impossible.
The inability to establish security associations to protect some The inability to establish security associations to protect some
messages that are needed to establish communications means that messages that are needed to establish and maintain communications
alternative means have to used to reduce the vulnerability of sites means that alternative means have to used to reduce the vulnerability
to ICMPv6 based attacks. The most common way of doing this is to of sites to ICMPv6 based attacks. The most common way of doing this
establish strict filtering policies in site firewalls to limit the is to establish strict filtering policies in site firewalls to limit
unauthenticated ICMPv6 messages that can pass between the site and the unauthenticated ICMPv6 messages that can pass between the site
the wider Internet. This makes control of ICMPv6 filtering a and the wider Internet. This makes control of ICMPv6 filtering a
delicate balance between protecting the site by dropping some of the delicate balance between protecting the site by dropping some of the
ICMPv6 traffic passing through the firewall and allowing enough of ICMPv6 traffic passing through the firewall and allowing enough of
the traffic through to make sure that efficient communication can be the traffic through to make sure that efficient communication can be
established. established.
SEND [RFC3971] has been specified as a means to improve the security SEND [RFC3971] has been specified as a means to improve the security
of local ICMPv6 communications. SEND sidesteps security association of local ICMPv6 communications. SEND sidesteps security association
bootstrapping problems that would result if IPsec was used. SEND bootstrapping problems that would result if IPsec was used. SEND
affects only link local messages and does not limit the filtering affects only link local messages and does not limit the filtering
which firewalls can apply and its role in security is therefore not which firewalls can apply and its role in security is therefore not
skipping to change at page 9, line 16 skipping to change at page 9, line 37
Firewalls will normally be used to monitor ICMPv6 to control the Firewalls will normally be used to monitor ICMPv6 to control the
following security concerns: following security concerns:
3.1. Denial of Service Attacks 3.1. Denial of Service Attacks
ICMPv6 can be used to cause a Denial of Service(DoS) in a number of 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 ways, including simply sending excessive numbers of ICMPv6 packets to
destinations in the site and sending error messages which disrupt destinations in the site and sending error messages which disrupt
established communications by causing sessions to be dropped. Also established communications by causing sessions to be dropped. Also
if spurious communication establishment messages can be infiltrated if spurious communication establishment or maintenance messages can
on to a link it might be possible to invalidate legitimate addresses be infiltrated on to a link it might be possible to invalidate
or disable interfaces. legitimate addresses or disable interfaces.
3.2. Probing 3.2. Probing
A major security consideration is preventing attackers probing the A major security consideration is preventing attackers probing the
site to determine the topology and identify hosts that might be site to determine the topology and identify hosts that might be
vulnerable to attack. Carefully crafted but, often, malformed vulnerable to attack. Carefully crafted but, often, malformed
messages can be used to provoke ICMPv6 responses from hosts thereby messages can be used to provoke ICMPv6 responses from hosts thereby
informing attackers of potential targets for future attacks. However informing attackers of potential targets for future attacks. However
the very large address space of IPv6 makes probing a less effective the very large address space of IPv6 makes probing a less effective
weapon as compared with IPv4 provided that addresses are not weapon as compared with IPv4 provided that addresses are not
skipping to change at page 9, line 42 skipping to change at page 10, line 15
3.3. Redirection Attacks 3.3. Redirection Attacks
A redirection attack could be used by a malicious sender to perform A redirection attack could be used by a malicious sender to perform
man-in-the-middle attacks or divert packets either to a malicious man-in-the-middle attacks or divert packets either to a malicious
monitor or to cause DoS by blackholing the packets. These attacks monitor or to cause DoS by blackholing the packets. These attacks
would normally have to be carried out locally on a link using the would normally have to be carried out locally on a link using the
Redirect message. Administrators need to decide if the improvement Redirect message. Administrators need to decide if the improvement
in efficiency from using Redirect messages is worth the risk of in efficiency from using Redirect messages is worth the risk of
malicious use. Factors to consider include the physical security of malicious use. Factors to consider include the physical security of
the link and the complexity of addressing on the link. For example, the link and the complexity of addressing on the link. For example,
on a wireless link, redirection would be a serious hazard due to the on an open wireless link, redirection would be a serious hazard due
lack of physical security. On the other hand, with a wired link in a to the lack of physical security. On the other hand, with a wired
secure building with complex addressing and redundant routers, the link in a secure building with complex addressing and redundant
efficiency gains might well outweigh the small risk of a rogue node routers, the efficiency gains might well outweigh the small risk of a
being connected. rogue node being connected.
3.4. Renumbering Attacks 3.4. Renumbering Attacks
Spurious Renumbering messages can lead to the disruption of a site. Spurious Renumbering messages can lead to the disruption of a site.
Although Renumbering messages are required to be authenticated with Although Renumbering messages are required to be authenticated with
IPsec, so that it is difficult to carry out such attacks in practice, IPsec, so that it is difficult to carry out such attacks in practice,
they should not be allowed through a firewall. they should not be allowed through a site boundary firewall. On the
other hand a site may employ multiple "layers" of firewall. 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 3.5. Problems Resulting from ICMPv6 Transparency
Because some ICMPv6 error packets need to be passed through a Because some ICMPv6 error packets need to be passed through a
firewall in both directions, malicious users can potentially use firewall in both directions, malicious users can potentially use
these messages to communicate between inside and outside, bypassing these messages to communicate between inside and outside, bypassing
administrative inspection. For example it might be possible to carry administrative inspection. For example it might be possible to carry
out a covert conversation through the payload of ICMPv6 error out a covert conversation through the payload of ICMPv6 error
messages or tunnel inappropriate encapsulated IP packets in ICMPv6 messages or tunnel inappropriate encapsulated IP packets in ICMPv6
error messages. This problem can be alleviated by filtering ICMPv6 error messages. This problem can be alleviated by filtering ICMPv6
errors using a deep packet inspection mechanism to ensure that the errors using a deep packet inspection mechanism to ensure that the
packet carried as a payload is associated with legitimate traffic to packet carried as a payload is associated with legitimate traffic to
or from the protected network. or from the protected network.
4. Filtering Recommendations 4. Filtering Recommendations
When designing firewall filtering rules for ICMPv6, the rules can be When designing firewall filtering rules for ICMPv6, the rules can be
divided into two classes: divided into two classes:
o Rules for ICMPv6 traffic transiting the firewall 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 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.
This section suggests some common considerations which should be This section suggests some common considerations which should be
borne in mind when designing filtering rules and then categorizes the borne in mind when designing filtering rules and then categorizes the
rules for each class. The categories are: rules for each class. The categories are:
o Messages that must not be dropped: usually because establishment o Messages that must not be dropped: usually because establishment
of communications will be prevented or severely impacted. or maintenance of communications will be prevented or severely
impacted.
o Messages that should not be dropped: administrators need to have a o Messages that should not be dropped: administrators need to have a
very good reason for dropping this category very good reason for dropping this category
o Messages that may be dropped in firewall/routers but it is not o Messages that may be dropped in firewall/routers, but these
essential because they would normally be dropped for other reasons messages may already be targeted to drop for other reasons, (e.g.,
(e.g., because they would be using link-local addresses) or the because they are using link-local addresses), or because the
protocol specification would cause them to be rejected if they had protocol specification would cause the messages to be rejected if
passed through a router. Special considerations apply to transit they had passed through a router. Special considerations apply to
traffic if the firewall is not a router as discussed in transit traffic if the firewall is not a router as discussed in
Section 4.2. Section 4.2.
o Messages that administrators may or may not want to drop depending o Messages that administrators may or may not want to drop depending
on local policy. on local policy.
o Messages that administrators should consider dropping (e.g., ICMP o Messages that administrators should consider dropping (e.g., ICMP
node information name lookup queries) node information name lookup queries)
More detailed analysis of each of the message types can be found in More detailed analysis of each of the message types can be found in
Appendix A. Appendix A.
4.1. Common Considerations 4.1. Common Considerations
Depending on the classification of the message to be filtered (see Depending on the classification of the message to be filtered (see
Section 2), ICMPv6 messages should be filtered based on the ICMPv6 Section 2), ICMPv6 messages should be filtered based on the ICMPv6
type of the message and the type (unicast, multicast, etc.) and scope type of the message and the type (unicast, multicast, etc.) and scope
(link-local, global unicast, etc) of source and destination (link-local, global unicast, etc) of source and destination
addresses. In some cases it may be desirable to filter on the Code addresses. In some cases it may be desirable to filter on the Code
field of ICMPv6 error messages. field of ICMPv6 error messages.
Messages that are authenticated by means of an IPsec AH or ESP header Messages that can be authenticated on delivery, probably because they
may be subject to less strict policies than unauthenticated messages. contain an IPsec AH header or ESP header with authentication, may be
In the remainder of this section, we are generally considering what subject to less strict policies than messages that cannot be
should be configured for unauthenticated messages. In many cases it authenticated. In the remainder of this section, we are generally
is not realistic to expect more than a tiny fraction of the messages considering what should be configured for unauthenticated messages.
to be authenticated. 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 of Where messages are not essential to the establishment or maintenance
communications, local policy can be used to determine whether a of communications, local policy can be used to determine whether a
message should be allowed or dropped. message should be allowed or dropped.
Depending on the capabilities of the firewall being configured, it Depending on the capabilities of the firewall being configured, it
may be possible for the firewall to maintain state about packets that may be possible for the firewall to maintain state about packets that
may result in error messages being returned or about ICMPv6 packets may result in error messages being returned or about ICMPv6 packets
(e.g., Echo Requests) that are expected to receive a specific (e.g., Echo Requests) that are expected to receive a specific
response. This state may allow the firewall to perform more precise response. This state may allow the firewall to perform more precise
checks based on this state, and to apply limits on the number of 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 ICMPv6 packets accepted incoming or outgoing as a result of a packet
traveling in the opposite direction. The capabilities of firewalls traveling in the opposite direction. The capabilities of firewalls
skipping to change at page 11, line 44 skipping to change at page 12, line 28
and it is not assumed that firewalls are uniformly capable in this and it is not assumed that firewalls are uniformly capable in this
respect. respect.
Firewalls which are able to perform deep packet inspection may be Firewalls which are able to perform deep packet inspection may be
able to check the header fields in the start of the errored packet able to check the header fields in the start of the errored packet
which is carried by ICMPv6 error messages. If the embedded packet which is carried by ICMPv6 error messages. If the embedded packet
has a source address which does not match the destination of the has a source address which does not match the destination of the
error message the packet can be dropped. This provides a partial error message the packet can be dropped. This provides a partial
defense against some possible attacks on TCP that use spoofed ICMPv6 defense against some possible attacks on TCP that use spoofed ICMPv6
error messages, but the checks can also be carried out at the error messages, but the checks can also be carried out at the
destination. For further information on these attacks see [I-D.gont- destination. For further information on these attacks see
tcpm-icmp-attacks]. [I-D.ietf-tcpm-icmp-attacks].
In general, the scopes of source and destination addresses of ICMPv6 In general, the scopes of source and destination addresses of ICMPv6
messages should be matched, and packets with mismatched addresses messages should be matched, and packets with mismatched addresses
should be dropped if they attempt to transit a router. However some should be dropped if they attempt to transit a router. However some
of the address configuration messages carried locally on a link may of the address configuration messages carried locally on a link may
legitimately have mismatched addresses. Node implementations must legitimately have mismatched addresses. Node implementations must
accept these messages delivered locally on a link and administrators accept these messages delivered locally on a link and administrators
should be aware that they can exist. should be aware that they can exist.
ICMPv6 messages transiting firewalls inbound to a site may be treated
differently depending on whether they 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 4.2. Interaction of Link Local Messages with Firewall/Routers and
Firewall/Bridges Firewall/Bridges
Firewalls can be implemented both as IP routers (firewall/routers) Firewalls can be implemented both as IP routers (firewall/routers)
and as link layer bridges (e.g., Ethernet bridges) that are and as link layer bridges (e.g., Ethernet bridges) that are
transparent to the IP layer although they will actually be inspecting transparent to the IP layer although they will actually be inspecting
the IP packets as they pass through (firewall/bridges). the IP packets as they pass through (firewall/bridges).
Many of the messages used for establishment of communications on the Many of the messages used for establishment and maintenance of
local link will be sent with link-local addresses for at least one of communications on the local link will be sent with link-local
their source and destination. Routers conforming to the IPv6 addresses for at least one of their source and destination. Routers
standards will not forward these packets; there is no need to conforming to the IPv6 standards will not forward these packets;
configure additional rules to prevent these packets traversing a there is no need to configure additional rules to prevent these
firewall/router, although administrators may wish to configure rules packets traversing a firewall/router, although administrators may
that would drop these packets for insurance and as a means of wish to configure rules that would drop these packets for insurance
monitoring for attacks. Also the specifications of ICMPv6 messages and as a means of monitoring for attacks. Also the specifications of
intended for use only on the local link specify various measures ICMPv6 messages intended for use only on the local link specify
which would allow receivers to detect if the message had passed various measures which would allow receivers to detect if the message
through a router, including: had passed through a router, including:
o Requiring that the hop limit in the IPv6 header is set to 255 on 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, transmission. Receivers verify that the hop limit is still 255,
to ensure that the packet has not passed through a router. to ensure that the packet has not passed through a router.
o Checking that the source address is a link-local unicast address. o Checking that the source address is a link-local unicast address.
Accordingly it is not essential to configure firewall/router rules to Accordingly it is not essential to configure firewall/router rules to
drop out-of-specification packets of these types. If they have non- drop out-of-specification packets of these types. If they have non-
link-local source and destination addresses, allowing them to link-local source and destination addresses, allowing them to
traverse the firewall/router, they would be rejected because of the traverse the firewall/router, they would be rejected because of the
checks performed at the destination. Again, firewall administrators checks performed at the destination. Again, firewall administrators
may still wish to configure rules to log or drop such out-of- may still wish to configure rules to log or drop such out-of-
skipping to change at page 12, line 47 skipping to change at page 13, line 38
For firewall/bridges, slightly different considerations apply. The For firewall/bridges, slightly different considerations apply. The
physical links on either side of the firewall/bridge are treated as a 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 single logical link for the purposes of IP. Hence the link local
messages used for discovery functions on the link must be allowed to messages used for discovery functions on the link must be allowed to
transit the transparent bridge. Administrators should assure for transit the transparent bridge. Administrators should assure for
themselves that routers and hosts attached to the link containing the themselves that routers and hosts attached to the link containing the
firewall/bridge are built to the correct specifications so that out- firewall/bridge are built to the correct specifications so that out-
of-specification packets are actually dropped as described in the of-specification packets are actually dropped as described in the
earlier part of this section. 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 4.3. Recommendations for ICMPv6 Transit Traffic
This section recommends rules that should be applied to ICMPv6 This section recommends rules that should be applied to ICMPv6
traffic attempting to transit a firewall. traffic attempting to transit a firewall.
4.3.1. Traffic that Must Not be Dropped 4.3.1. Traffic that Must Not be Dropped
Error messages that are essential to the establishment of Error messages that are essential to the establishment and
communications: maintenance of communications:
o Destination Unreachable (Type 1) - All codes o Destination Unreachable (Type 1) - All codes
o Packet Too Big (Type 2) o Packet Too Big (Type 2)
o Time Exceeded (Type 3) - Code 0 only o Time Exceeded (Type 3) - Code 0 only
o Parameter Problem (Type 4) - Codes 1 and 2 only o Parameter Problem (Type 4) - Codes 1 and 2 only
Appendix A.4 suggests some more specific checks that could be Appendix A.4 suggests some more specific checks that could be
performed on Parameter Problem messages if a firewall has the performed on Parameter Problem messages if a firewall has the
necessary packet inspection capabilities. necessary packet inspection capabilities.
Connectivity checking messages: Connectivity checking messages:
o Echo Request (Type 128) o Echo Request (Type 128)
skipping to change at page 14, line 49 skipping to change at page 15, line 46
hop limit = 255): hop limit = 255):
o Certificate Path Solicitation (Type 148) o Certificate Path Solicitation (Type 148)
o Certificate Path Advertisement (type 149) o Certificate Path Advertisement (type 149)
Multicast Router Discovery messages (must have link-local source Multicast Router Discovery messages (must have link-local source
address and hop limit = 1): address and hop limit = 1):
o Multicast Router Advertisement (Type 151) o Multicast Router Advertisement (Type 151)
o Multicast Router Solicitation (Type 152) o Multicast Router Solicitation (Type 152)
o Multicast Router Termination (Type 153) o Multicast Router Termination (Type 153)
4.3.4. Traffic for which a Dropping Policy Should be Defined 4.3.4. Traffic for which a Policy Should be Defined
The message type that the experimental Seamoby protocols are using The message type that the experimental Seamoby protocols are using
will be expected to have to cross site boundaries in normal will be expected to have to cross site boundaries in normal
operation. Administrators should determine if they need to support operation. Transit sites must allow these messages to transit the
these experiments and otherwise messages of this type should be site. End site administrators should determine if they need to
dropped: support these experiments and otherwise messages of this type should
be dropped:
o Seamoby Experimental (Type 150) o Seamoby Experimental (Type 150)
Error messages not currently defined by IANA: Error messages not currently defined by IANA:
o Unallocated Error messages (Types 5-99 and 102-126, inclusive) o Unallocated Error messages (Types 5-99 and 102-126, inclusive)
The base ICMPv6 specification suggests that error messages which are The base ICMPv6 specification suggests that error messages which are
not explicitly known to a node should be forwarded and passed to any 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 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 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 channel or form part of a DoS attack. Administrators of end sites
of this and determine whether they wish to allow these messages should be aware of this and determine whether they wish to allow
through the firewall. 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
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 which Should be Dropped Unless a Good Case can be Made 4.3.5. Traffic which Should be Dropped Unless a Good Case can be Made
Node Information enquiry messages should generally not be forwarded Node Information enquiry messages should generally not be forwarded
across site boundaries. Some of these messages will be using non- across site boundaries. Some of these messages will be using non-
link-local unicast addresses so that they will not necessarily be link-local unicast addresses so that they will not necessarily be
dropped by address scope limiting rules: dropped by address scope limiting rules:
o Node Information Query (Type 139) o Node Information Query (Type 139)
o Node Information Response (Type 140) o Node Information Response (Type 140)
Router Renumbering messages should not be forwarded across site Router Renumbering messages should not be forwarded across site
boundaries. As originally specified, these messages may use a site boundaries. As originally specified, these messages may use a site
scope multicast address or a site local unicast address. They should scope multicast address or a site local unicast address. They should
be caught by standard rules that are intended to stop any packet with be caught by standard rules that are intended to stop any packet with
a multicast site scope or site local destination being forwarded a multicast site scope or site local destination being forwarded
across a site boundary provided these are correctly configured. across a site boundary provided these are correctly configured.
Since site local addresses have now been deprecated it seems likely Since site local addresses have now been deprecated it seems likely
that changes may be made to allow the use of unique local addresses that changes may be made to allow the use of unique local addresses
or global unicast addresses. Should this happen, it will be or global unicast addresses. Should this happen, it will be
essential to explicitly filter these messages: essential to explicitly filter these messages at site boundaries. If
o Router Renumbering (Type 139) a site has internal as well as boundary firewalls, individual
policies should be established for the internal firewalls depending
on whether the site wishes to use Router Renumbering or not:
o Router Renumbering (Type 138)
Messages with types in the experimental allocations: Messages with types in the experimental allocations:
o Types 100, 101, 200 and 201. o Types 100, 101, 200 and 201.
Messages using the extension type numbers until such time as ICMPv6 Messages using the extension type numbers until such time as ICMPv6
needs to use such extensions: needs to use such extensions:
o Types 127 and 255. 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 informational
messages with unknown types must be silently discarded.
4.4. Recommendations for ICMPv6 Local Configuration Traffic 4.4. Recommendations for ICMPv6 Local Configuration Traffic
This section recommends filtering rules for ICMPv6 traffic addressed This section recommends filtering rules for ICMPv6 traffic addressed
to an interface on a firewall. For a small number of messages, the to an interface on a firewall. For a small number of messages, the
desired behavior may differ between interfaces on the site or private 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 side of the firewall and the those on the public Internet side of the
firewall. firewall.
4.4.1. Traffic that Must Not be Dropped 4.4.1. Traffic that Must Not be Dropped
Error messages that are essential to the establishment of Error messages that are essential to the establishment and
communications: maintenance of communications:
o Destination Unreachable (Type 1) - All codes o Destination Unreachable (Type 1) - All codes
o Packet Too Big (Type 2) o Packet Too Big (Type 2)
o Time Exceeded (Type 3) - Code 0 only o Time Exceeded (Type 3) - Code 0 only
o Parameter Problem (Type 4) - Codes 1 and 2 only o Parameter Problem (Type 4) - Codes 1 and 2 only
Connectivity checking messages: Connectivity checking messages:
o Echo Request (Type 128) o Echo Request (Type 128)
o Echo Response (Type 129) o Echo Response (Type 129)
As discussed in Section 4.3.1, dropping connectivity checking As discussed in Section 4.3.1, dropping connectivity checking
messages will prevent the firewall being the destination of a Teredo messages will prevent the firewall being the destination of a Teredo
skipping to change at page 17, line 31 skipping to change at page 18, line 43
Error messages other than those listed in Section 4.4.1: Error messages other than those listed in Section 4.4.1:
o Time Exceeded (Type 3) - Code 1 o Time Exceeded (Type 3) - Code 1
o Parameter Problem (Type 4) - Code 0 o Parameter Problem (Type 4) - Code 0
4.4.3. Traffic that will be Dropped Anyway - No Special Attention 4.4.3. Traffic that will be Dropped Anyway - No Special Attention
Needed Needed
Router Renumbering messages must be authenticated using IPsec, so it Router Renumbering messages must be authenticated using IPsec, so it
is not essential to filter these messages even if they are not is not essential to filter these messages even if they are not
allowed at the firewall/router: allowed at the firewall/router:
o Router Renumbering (Type 139) o Router Renumbering (Type 138)
Mobile IPv6 messages that are needed to assist mobility: Mobile IPv6 messages that are needed to assist mobility:
o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Request (Type 144)
o Home Agent Address Discovery Reply (Type 145) o Home Agent Address Discovery Reply (Type 145)
o Mobile Prefix Solicitation (Type 146) o Mobile Prefix Solicitation (Type 146)
o Mobile Prefix Advertisement(Type 147) o Mobile Prefix Advertisement(Type 147)
It may be desirable to drop these messages, especially on public It may be desirable to drop these messages, especially on public
interfaces, if the firewall is not also providing mobile Home Agent interfaces, if the firewall is not also providing mobile Home Agent
services, but they will be ignored otherwise. services, but they will be ignored otherwise.
The message used by the experimental Seamoby protocols may be dropped The message used by the experimental Seamoby protocols may be dropped
but will be ignored if the service is not implemented: but will be ignored if the service is not implemented:
o Seamoby Experimental (Type 150) o Seamoby Experimental (Type 150)
4.4.4. Traffic for which a Dropping Policy Should be Defined 4.4.4. Traffic for which a Policy Should be Defined
Redirect messages provide a significant security risk and Redirect messages provide a significant security risk and
administrators should take a case-by-case view of whether firewalls, administrators should take a case-by-case view of whether firewalls,
routers in general and other nodes should accept these messages: routers in general and other nodes should accept these messages:
o Redirect (Type 137) o Redirect (Type 137)
Conformant nodes must provide configuration controls which allow Conformant nodes must provide configuration controls which allow
nodes to control their behavior with respect to Redirect messages so nodes to control their behavior with respect to Redirect messages so
that it should only be necessary to install specific filtering rules that it should only be necessary to install specific filtering rules
under special circumstances, such as if Redirect messages are under special circumstances, such as if Redirect messages are
accepted on private interfaces but not public ones. accepted on private interfaces but not public ones.
If a node implements the experimental Node Information service, the If a node implements the experimental Node Information service, the
administrator needs to make an explicit decision as to whether the administrator needs to make an explicit decision as to whether the
node should respond to or accept Node Information messages on each node should respond to or accept Node Information messages on each
skipping to change at page 18, line 19 skipping to change at page 19, line 29
under special circumstances, such as if Redirect messages are under special circumstances, such as if Redirect messages are
accepted on private interfaces but not public ones. accepted on private interfaces but not public ones.
If a node implements the experimental Node Information service, the If a node implements the experimental Node Information service, the
administrator needs to make an explicit decision as to whether the administrator needs to make an explicit decision as to whether the
node should respond to or accept Node Information messages on each node should respond to or accept Node Information messages on each
interface: interface:
o Node Information Query (Type 139) o Node Information Query (Type 139)
o Node Information Response (Type 140) o Node Information Response (Type 140)
It may be possible to disable the service on the node if it is not It may be possible to disable the service on the node if it is not
wanted in which case these messages will ignored and no filtering is wanted in which case these messages will be ignored and no filtering
necessary. is necessary.
Error messages not currently defined by IANA: Error messages not currently defined by IANA:
o Unallocated Error messages (Types 5-99 and 102-126, inclusive) o Unallocated Error messages (Types 5-99 and 102-126, inclusive)
The base ICMPv6 specification suggests that error messages which are The base ICMPv6 specification suggests that error messages which are
not explicitly known to a node should be forwarded and passed to any 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 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 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 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 of this and determine whether they wish to allow these messages to be
skipping to change at page 18, line 40 skipping to change at page 20, line 4
of this and determine whether they wish to allow these messages to be of this and determine whether they wish to allow these messages to be
sent to the firewall. sent to the firewall.
4.4.5. Traffic which Should be Dropped Unless a Good Case can be Made 4.4.5. Traffic which Should be Dropped Unless a Good Case can be Made
Messages with types in the experimental allocations: Messages with types in the experimental allocations:
o Types 100, 101, 200 and 201. o Types 100, 101, 200 and 201.
Messages using the extension type numbers until such time as ICMPv6 Messages using the extension type numbers until such time as ICMPv6
needs to use such extensions: needs to use such extensions:
o Types 127 and 255. o Types 127 and 255.
All informational messages with types not explicitly assigned by All informational messages with types not explicitly assigned by
IANA, currently: IANA, currently:
o Types 154 - 199 inclusive and 202 - 254 inclusive. o Types 154 - 199 inclusive and 202 - 254 inclusive.
Note that the base ICMPv6 specification requires that informational Note that the base ICMPv6 specification requires that received
messages with unknown types must be silently discarded. informational messages with unknown types must be silently discarded.
5. IANA Considerations 5. IANA Considerations
There are no IANA considerations defined in this document. There are no IANA considerations defined in this document.
6. Acknowledgements 6. Acknowledgements
Pekka Savola created the original IPv6 Security Overview document Pekka Savola created the original IPv6 Security Overview document
which contained suggestions for ICMPv6 filter setups. This which contained suggestions for ICMPv6 filter setups. This
information has been incorporated into this document. He has also information has been incorporated into this document. He has also
skipping to change at page 19, line 21 skipping to change at page 20, line 34
ICMPv6 messages and the term 'any-to-end' were used by Jari Arkko in ICMPv6 messages and the term 'any-to-end' were used by Jari Arkko in
a draft relating to ICMPv6 and IKE. a draft relating to ICMPv6 and IKE.
The Netfilter configuration script in Appendix C was contributed by The Netfilter configuration script in Appendix C was contributed by
Suresh Krishnan. Suresh Krishnan.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-ipngwg-icmp-name-lookups]
Crawford, M. and B. Haberman, "IPv6 Node Information
Queries", draft-ietf-ipngwg-icmp-name-lookups-15 (work in
progress), February 2006.
[I-D.ietf-ipngwg-icmp-v3]
Conta, A., "Internet Control Message Protocol (ICMPv6) for
the Internet Protocol Version 6 (IPv6) Specification",
draft-ietf-ipngwg-icmp-v3-07 (work in progress),
July 2005.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, August 1996.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
skipping to change at page 20, line 31 skipping to change at page 21, line 34
[RFC4065] Kempf, J., "Instructions for Seamoby and Experimental [RFC4065] Kempf, J., "Instructions for Seamoby and Experimental
Mobility Protocol IANA Allocations", RFC 4065, July 2005. Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, December 2005. RFC 4286, December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information
Queries", RFC 4620, August 2006.
7.2. Informative References 7.2. Informative References
[I-D.gont-tcpm-icmp-attacks] [I-D.ietf-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP", Gont, F., "ICMP attacks against TCP",
draft-gont-tcpm-icmp-attacks-05 (work in progress), draft-ietf-tcpm-icmp-attacks-01 (work in progress),
October 2005. October 2006.
[I-D.ietf-v6ops-scanning-implications] [I-D.ietf-v6ops-scanning-implications]
Chown, T., "IPv6 Implications for Network Scanning", Chown, T., "IPv6 Implications for Network Scanning",
draft-ietf-v6ops-scanning-implications-00 (work in draft-ietf-v6ops-scanning-implications-01 (work in
progress), June 2006. progress), October 2006.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001. January 2001.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
February 2006. February 2006.
[netfilter] [netfilter]
skipping to change at page 21, line 19 skipping to change at page 22, line 26
A.1. Destination Unreachable Error Message A.1. Destination Unreachable Error Message
Destination Unreachable (Type 1) error messages [RFC4443] are sent Destination Unreachable (Type 1) error messages [RFC4443] are sent
any-to-end between unicast addresses. The message can be generated any-to-end between unicast addresses. The message can be generated
from any node which a packet traverses when the node is unable to from any node which a packet traverses when the node is unable to
forward the packet for any reason except congestion. forward the packet for any reason except congestion.
Destination Unreachable messages are useful for debugging but are Destination Unreachable messages are useful for debugging but are
also important to speed up cycling through possible addresses, as also important to speed up cycling through possible addresses, as
they can avoid the need to wait through timeouts and hence can be they can avoid the need to wait through timeouts and hence can be
part of the process of establishing communications. It is a common part of the process of establishing or maintaining communications.
practice in IPv4 to refrain from generating ICMP Destination It is a common practice in IPv4 to refrain from generating ICMP
Unreachable messages in an attempt to hide the networking topology Destination Unreachable messages in an attempt to hide the networking
and/or service structure. The same idea could be applied to IPv6 but topology and/or service structure. The same idea could be applied to
this can slow down connection if a host has multiple addresses, some IPv6 but this can slow down connection if a host has multiple
of which are deprecated, as they may be when using privacy addresses addresses, some of which are deprecated, as they may be when using
[RFC3041]. If policy allows the generation of ICMPv6 Destination privacy addresses [RFC3041]. If policy allows the generation of
Unreachable messages, it is important that nodes provide the correct ICMPv6 Destination Unreachable messages, it is important that nodes
reason code, one of: no route to destination, administratively provide the correct reason code, one of: no route to destination,
prohibited, beyond scope of source address, address unreachable, port administratively prohibited, beyond scope of source address, address
unreachable, source address failed ingress/egress policy, reject unreachable, port unreachable, source address failed ingress/egress
route to destination. policy, reject route to destination.
A.2. Packet Too Big Error Message A.2. Packet Too Big Error Message
Packet Too Big (Type 2) error messages [RFC4443] are sent any-to-end Packet Too Big (Type 2) error messages [RFC4443] are sent any-to-end
between unicast addresses. The message can be generated from any between unicast addresses. The message can be generated from any
node which a packet traverses on the path when the node is unable to node which 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 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 next link. This message is vital to the correct functioning of Path
MTU Discovery and hence is part of the establishment of MTU Discovery and hence is part of the establishment and maintenance
communications. Since routers are not allowed to fragment packets, of communications. Since routers are not allowed to fragment
informing sources of the need to fragment large packets is more packets, informing sources of the need to fragment large packets is
important than for IPv4. If these messages are not generated when more important than for IPv4. If these messages are not generated
appropriate, hosts will continue to send packets which are too large when appropriate, hosts will continue to send packets which are too
or may assume that the route is congested. Effectively parts of the large or may assume that the route is congested. Effectively parts
Internet will become inaccessible. of the Internet will become inaccessible.
If a network chooses to generate packets that are no larger than the 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 Guaranteed Minimum MTU (1280 octets) and the site's links to the
wider internet have corresponding MTUs, Packet Too Big messages wider internet have corresponding MTUs, Packet Too Big messages
should not be expected at the firewall and could be dropped if they should not be expected at the firewall and could be dropped if they
arrive. arrive.
A.3. Time Exceeded Error Message A.3. Time Exceeded Error Message
Time Exceeded (Type 3) error messages [RFC4443] can occur in two Time Exceeded (Type 3) error messages [RFC4443] can occur in two
skipping to change at page 23, line 44 skipping to change at page 24, line 50
establishing communication is that they are required when verifying establishing communication is that they are required when verifying
connectivity through Teredo tunnels[RFC4380]: Teredo tunneling to connectivity through Teredo tunnels[RFC4380]: Teredo tunneling to
IPv6 nodes on the site will not be possible if these messages are 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 blocked. It is not thought that there is a significant risk from
scanning attacks on a well-designed IPv6 network (see Section 3.2) scanning attacks on a well-designed IPv6 network (see Section 3.2)
and so connectivity checks should be allowed by default. and so connectivity checks should be allowed by default.
A.6. Neighbor Solicitation and Neighbor Advertisement Messages A.6. Neighbor Solicitation and Neighbor Advertisement Messages
ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and
136) messages are essential to the establishment of communications on 136) messages are essential to the establishment and maintenance of
the local link. Firewalls need to generate and accept these messages communications on the local link. Firewalls need to generate and
to allow them to establish interfaces onto their connected links. accept these messages to allow them to establish and maintain
interfaces onto their connected links.
Note that the address scopes of the source and destination addresses Note that the address scopes of the source and destination addresses
on Neighbor Solicitations and Neighbor Advertisements may not match. on Neighbor Solicitations and Neighbor Advertisements may not match.
The exact functions which these messages will be carrying out depends The exact functions which these messages will be carrying out depends
on the mechanism being used to configure IPv6 addresses on the link on the mechanism being used to configure IPv6 addresses on the link
(Stateless, Stateful or Static configuration). (Stateless, Stateful or Static configuration).
A.7. Router Solicitation and Router Advertisement Messages A.7. Router Solicitation and Router Advertisement Messages
ICMPv6 Router Solicitation and Router Advertisement(Type 133 and 134) ICMPv6 Router Solicitation and Router Advertisement(Type 133 and 134)
messages are essential to the establishment of communications on the messages are essential to the establishment and maintenance of
local link. Firewalls need to generate (since the firewall will communications on the local link. Firewalls need to generate (since
generally be behaving as a router) and accept these messages to allow the firewall will generally be behaving as a router) and accept these
them to establish interfaces onto their connected links. messages to allow them to establish and maintain interfaces onto
their connected links.
A.8. Redirect Messages A.8. Redirect Messages
ICMPv6 Redirect Messages(Type 137) are used on the local link to ICMPv6 Redirect Messages(Type 137) are used on the local link to
indicate that nodes are actually link-local and communications need indicate that nodes are actually link-local and communications need
not go via a router, or to indicate a more appropriate first hop not go via a router, or to indicate a more appropriate first hop
router. Although they can be used to make communications more router. Although they can be used to make communications more
efficient, they are not essential to the establishment of efficient, they are not essential to the establishment of
communications and may be a security vulnerability, particularly if a communications and may be a security vulnerability, particularly if a
link is not physically secured. Conformant nodes are required to link is not physically secured. Conformant nodes are required to
provide configuration controls which suppress the generation of provide configuration controls which suppress the generation of
Redirect messages and allow them to be ignored on reception. Using Redirect messages and allow them to be ignored on reception. Using
Redirect messages on, for example, a wireless link without link level Redirect messages on, for example, a wireless link without link level
encryption/authentication is particularly hazardous because the link encryption/authentication is particularly hazardous because the link
is open to eavesdroppring and packet injection. is open to eavesdropping and packet injection.
A.9. SEND Certificate Path Messages A.9. SEND Certificate Path Messages
SEND [RFC3971] uses two messages (Certificate Path Solicitation and SEND [RFC3971] uses two messages (Certificate Path Solicitation and
Advertisement - Types 148 and 149) sent from nodes to supposed Advertisement - Types 148 and 149) sent from nodes to supposed
routers on the same local link to obtain a certificate path which routers on the same local link to obtain a certificate path which
will allow the node to authenticate the router's claim to provide will allow the node to authenticate the router's claim to provide
routing services for certain prefixes. If a link connected to a routing services for certain prefixes. If a link connected to a
firewall/router is using SEND, the firewall must be able to exchange firewall/router is using SEND, the firewall must be able to exchange
these messages with nodes on the link that will use its routing these messages with nodes on the link that will use its routing
skipping to change at page 25, line 32 skipping to change at page 26, line 38
addresses from a unicast address. addresses from a unicast address.
Router Renumbering messages are required to be protected by IPsec Router Renumbering messages are required to be protected by IPsec
authentication since they could be readily misused by attackers to authentication since they could be readily misused by attackers to
disrupt or divert site communications. Renumbering messages should disrupt or divert site communications. Renumbering messages should
generally be confined to sites for this reason. generally be confined to sites for this reason.
A.13. Node Information Query and Reply A.13. Node Information Query and Reply
ICMPv6 Node Information Query and Reply (Type 139 and 140) messages ICMPv6 Node Information Query and Reply (Type 139 and 140) messages
are sent end-to-end between unicast addresses, and can also be sent defined in [RFC4620] are sent end-to-end between unicast addresses,
to link-local multicast addresses. They can, in theory, be sent from and can also be sent to link-local multicast addresses. They can, in
any node to any other but it would generally not be desirable for theory, be sent from any node to any other but it would generally not
nodes outside the local site to be able to send queries to nodes be desirable for nodes outside the local site to be able to send
within the site. Also these messages are not required to be queries to nodes within the site. Also these messages are not
authenticated. required to be authenticated.
A.14. Mobile IPv6 Messages A.14. Mobile IPv6 Messages
Mobile IPv6 [RFC3775] defines four ICMPv6 messages which are used to Mobile IPv6 [RFC3775] defines four ICMPv6 messages which are used to
support mobile operations: Home Agent Address Discovery Request, Home support mobile operations: Home Agent Address Discovery Request, Home
Agent Address Discovery Reply, Mobile Prefix Solicitation and ICMP Agent Address Discovery Reply, Mobile Prefix Solicitation and ICMP
Mobile Prefix Advertisement(Type 144, 145, 146 and 147) messages. Mobile Prefix Advertisement(Type 144, 145, 146 and 147) messages.
These messages are sent end-to-end between unicast addresses of a 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 mobile node and its home agent. They must be expected to be sent
from outside a site and must traverse site-boundary firewalls toreach from outside a site and must traverse site-boundary firewalls to
the home agent in order for Mobile IPv6 to function. The two Mobile reach the home agent in order for Mobile IPv6 to function. The two
prefix messages should be protected by the use of IPsec Mobile prefix messages should be protected by the use of IPsec
authentication. authentication.
o If the site provides home agents for mobile nodes, the firewall o If the site provides home agents for mobile nodes, the firewall
must allow incoming Home Agent Address Discovery Request and must allow incoming Home Agent Address Discovery Request and
Mobile Prefix Solicitation messages, and outgoing Home Agent Mobile Prefix Solicitation messages, and outgoing Home Agent
Address Discovery Reply and ICMP Mobile Prefix Advertisement Address Discovery Reply and ICMP Mobile Prefix Advertisement
messages. It may be desirable to limit the destination addresses messages. It may be desirable to limit the destination addresses
for the incoming messages to links that are known to support home for the incoming messages to links that are known to support home
agents. agents.
o If the site is prepared to host roaming mobile nodes, the firewall o If the site is prepared to host roaming mobile nodes, the firewall
must allow outgoing Home Agent Address Discovery Request and must allow outgoing Home Agent Address Discovery Request and
Mobile Prefix Solicitation messages, and incoming Home Agent Mobile Prefix Solicitation messages, and incoming Home Agent
skipping to change at page 26, line 29 skipping to change at page 27, line 33
dropping Mobile IPv6 messages from these nodes. dropping Mobile IPv6 messages from these nodes.
A.15. Unused and Experimental Messages A.15. Unused and Experimental Messages
A large number of ICMPv6 Type values are currently unused. These A large number of ICMPv6 Type values are currently unused. These
values have not had a specific function registered with IANA. This values have not had a specific function registered with IANA. This
section describes how to treat messages which attempt to use these section describes how to treat messages which attempt to use these
Type values in a way of which the network administrator (and hence Type values in a way of which the network administrator (and hence
the firewall) is not aware. the firewall) is not aware.
[I-D.ietf-ipngwg-icmp-v3] defines a number of experimental Type [RFC4443] defines a number of experimental Type values for ICMPv6
values for ICMPv6 Error and Informational messages, which could be Error and Informational messages, which could be used in site
used in site specific ways. These values should be treated in the specific ways. These values should be treated in the same way as
same way as values which are not registered by IANA unless the values which are not registered by IANA unless the network
network administrator is explicitly made aware of usage. administrator is explicitly made aware of usage.
The codes reserved for future extension of the ICMPv6 Type space The codes reserved for future extension of the ICMPv6 Type space
should currently be dropped as this functionality is as yet should currently be dropped as this functionality is as yet
undefined. undefined.
Any ICMPv6 Informational messages of which the firewall is not aware Any ICMPv6 Informational messages of which the firewall is not aware
should not be allowed to pass through the firewall or be accepted for should not be allowed to pass through the firewall or be accepted for
local delivery on any of its interfaces. local delivery on any of its interfaces.
Any incoming ICMPv6 Error messages of which the firewall is not aware Any incoming ICMPv6 Error messages of which the firewall is not aware
skipping to change at page 35, line 5 skipping to change at page 35, line 19
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 147 -j ACCEPT --icmpv6-type 147 -j ACCEPT
done done
fi fi
# DROP EVERYTHING ELSE # DROP EVERYTHING ELSE
# ==================== # ====================
ip6tables -A icmpv6-filter -p icmpv6 -j DROP ip6tables -A icmpv6-filter -p icmpv6 -j DROP
Example Netfilter Configuration Script for ICMPv6 Filtering
Authors' Addresses Authors' Addresses
Elwyn B. Davies Elwyn B. Davies
Consultant Consultant
Soham, Cambs Soham, Cambs
UK UK
Phone: +44 7889 488 335 Phone: +44 7889 488 335
Email: elwynd@dial.pipex.com Email: elwynd@dial.pipex.com
Janos Mohacsi Janos Mohacsi
NIIF/HUNGARNET NIIF/HUNGARNET
Victor Hugo u. 18-22 Victor Hugo u. 18-22
Budapest, H-1132 Budapest, H-1132
Hungary Hungary
Phone: +36 1 4503070 Phone: +36 1 4503070
Email: mohacsi@niif.hu Email: mohacsi@niif.hu
Intellectual Property Statement 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 36, line 29 skipping to change at page 36, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 72 change blocks. 
234 lines changed or deleted 285 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/