draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt   draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt 
IPv6 Operations E. Davies IPv6 Operations E. Davies
Internet-Draft Consultant Internet-Draft Consultant
Expires: April 17, 2006 J. Mohacsi Expires: September 7, 2006 J. Mohacsi
NIIF/HUNGARNET NIIF/HUNGARNET
October 14, 2005 March 6, 2006
Best Current Practice for Filtering ICMPv6 Messages in Firewalls Best Current Practice for Filtering ICMPv6 Messages in Firewalls
draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt draft-ietf-v6ops-icmpv6-filtering-bcp-01.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 April 17, 2006. This Internet-Draft will expire on September 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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. A number of security risks are associated with uncontrolled options. A number of security risks are associated with uncontrolled
forwarding of ICMPv6 messages. On the other hand, compared with IPv4 forwarding of ICMPv6 messages. On the other hand, compared with IPv4
and the corresponding protocol ICMP, ICMPv6 is essential to the and the corresponding protocol ICMP, ICMPv6 is essential to the
functioning of IPv6 rather than a useful auxiliary. functioning of IPv6 rather than a useful auxiliary.
skipping to change at page 2, line 45 skipping to change at page 2, line 45
4.3. Recommendationd for ICMPv6 Local Configuration Traffic . . 15 4.3. Recommendationd for ICMPv6 Local Configuration Traffic . . 15
4.3.1. Traffic that Must NOT be Dropped . . . . . . . . . . . 15 4.3.1. Traffic that Must NOT be Dropped . . . . . . . . . . . 15
4.3.2. Traffic that Normally Should Not be Dropped . . . . . 16 4.3.2. Traffic that Normally Should Not be Dropped . . . . . 16
4.3.3. Traffic that May be Dropped but will be Caught 4.3.3. Traffic that May be Dropped but will be Caught
Anyway . . . . . . . . . . . . . . . . . . . . . . . . 16 Anyway . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.4. Traffic for which a Dropping Policy Should be 4.3.4. Traffic for which a Dropping Policy Should be
Defined . . . . . . . . . . . . . . . . . . . . . . . 16 Defined . . . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . 17 can be Made . . . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 19 Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 20
A.1. Destination Unreachable Error Message . . . . . . . . . . 19 A.1. Destination Unreachable Error Message . . . . . . . . . . 20
A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 20 A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 20
A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 20 A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 21
A.4. Parameter Problem Error Message . . . . . . . . . . . . . 21 A.4. Parameter Problem Error Message . . . . . . . . . . . . . 21
A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 22 A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 22
A.6. Neighbor Solicitation and Neighbor Advertisement A.6. Neighbor Solicitation and Neighbor Advertisement
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 22 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 22
A.7. Router Solicitation and Router Advertisement Messages . . 22 A.7. Router Solicitation and Router Advertisement Messages . . 23
A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 22 A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 23
A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 23 A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 23
A.10. Multicast Listener Discovery Messages . . . . . . . . . . 23 A.10. Multicast Listener Discovery Messages . . . . . . . . . . 23
A.11. Multicast Router Discovery Messages . . . . . . . . . . . 23 A.11. Multicast Router Discovery Messages . . . . . . . . . . . 23
A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 23 A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 24
A.13. Node Information Query and Reply . . . . . . . . . . . . . 24 A.13. Node Information Query and Reply . . . . . . . . . . . . . 24
A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 24 A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 24
A.15. Unused and Experimental Messages . . . . . . . . . . . . . 24 A.15. Unused and Experimental Messages . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
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) [RFC2463], [I-D.ietf-ipngwg-icmp-v3] Protocol version 6 (ICMPv6) [RFC2463], [I-D.ietf-ipngwg-icmp-v3]
plays a fundamental role including being an essential component in plays a fundamental role including being an essential component in
establishing communications both at the interface level and for establishing 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 may have a detrimental effect on the
establishment of IPv6 communications. On the other hand, allowing establishment of IPv6 communications. On the other hand, allowing
skipping to change at page 5, line 32 skipping to change at page 5, line 32
[RFC3122]. [RFC3122].
o Communicating which multicast groups have listeners on a link to o Communicating which multicast groups have listeners on a link to
the multicast capable routers connected to the link. Uses the multicast capable routers connected to the link. Uses
messages Multicast Listener Query, Multicast Listener Report (two messages Multicast Listener Query, Multicast Listener Report (two
versions) and Multicast Listener Done (version 1 only) as versions) and Multicast Listener Done (version 1 only) as
specified in Multicast Listener Discovery MLDv1 [RFC2710] and specified in Multicast Listener Discovery MLDv1 [RFC2710] and
MLDv2[RFC3810]. MLDv2[RFC3810].
o Discovering multicast routers attached to the local link. Uses o Discovering multicast routers attached to the local link. Uses
messages Multicast Router Advertisement, Multicast Router messages Multicast Router Advertisement, Multicast Router
Solicitation and Multicast Router Termination as specified in Solicitation and Multicast Router Termination as specified in
Multicast Router Discovery [I-D.ietf-magma-mrdisc]. Multicast Router Discovery [RFC4286].
o Providing support for some aspects of Mobile IPv6 especially o Providing support for some aspects of Mobile IPv6 especially
dealing with the IPv6 Mobile Home Agent functionality provided in dealing with the IPv6 Mobile Home Agent functionality provided in
routers and needed to support a Mobile node homed on the link. routers and needed to support a Mobile node homed on the link.
The Home Agent Address Discovery Request and Reply; and Mobile The Home Agent Address Discovery Request and Reply; and Mobile
Prefix Solicitation and Advertisement messages are specified in Prefix Solicitation and Advertisement messages are specified in
[RFC3775] [RFC3775]
o An experimental extension to ICMPv6 specifies the ICMP Node o 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-ipngwg-icmp- retrieve some basic information about nodes [I-D.ietf-ipngwg-icmp-
name-lookups]. name-lookups].
skipping to change at page 11, line 49 skipping to change at page 11, line 49
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
defence against some possible attacks on TCP that use spoofed ICMPv6 defence 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. destination. For further information on these attacks see [I-D.gont-
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 need to legitimately have mismatched addresses. Node implementations need to
avoid over-zealous filtering of these messages delivered locally on a avoid over-zealous filtering of these messages delivered locally on a
link. link.
4.2. Recommendations for ICMPv6 Transit Traffic 4.2. Recommendations for ICMPv6 Transit Traffic
skipping to change at page 12, line 30 skipping to change at page 12, line 31
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)
o Echo Response (Type 129) o Echo Response (Type 129)
For Teredo tunneling [I-D.huitema-v6ops-teredo] to IPv6 nodes on the For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be
site to be possible, it is essential that the connectivity checking possible, it is essential that the connectivity checking messages are
messages are allowed through the firewall. It has been common allowed through the firewall. It has been common practice in IPv4
practice in IPv4 networks to drop Echo Request messages in firewalls networks to drop Echo Request messages in firewalls to minimize the
to minimize the risk of scanning attacks on the protected network. risk of scanning attacks on the protected network. As discussed in
As discussed in Section 3.2, the risks from port scanning in an IPv6 Section 3.2, the risks from port scanning in an IPv6 network are much
network are much less severe and it is not necessary to filter IPv6 less severe and it is not necessary to filter IPv6 Echo Request
Echo Request messages. messages.
4.2.2. Traffic that Normally Should Not be Dropped 4.2.2. Traffic that Normally Should Not be Dropped
Error messages other than those listed in Section 4.2.1 Error messages other than those listed in Section 4.2.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
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)
skipping to change at page 18, line 9 skipping to change at page 18, line 14
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
provided important comments. Some analysis of the classification of provided important comments. Some analysis of the classification of
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
Suresh Krishnan.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-ipngwg-icmp-name-lookups] [I-D.ietf-ipngwg-icmp-name-lookups]
Crawford, M. and B. Haberman, "IPv6 Node Information Crawford, M. and B. Haberman, "IPv6 Node Information
Queries", draft-ietf-ipngwg-icmp-name-lookups-12 (work in Queries", draft-ietf-ipngwg-icmp-name-lookups-15 (work in
progress), July 2005. progress), February 2006.
[I-D.ietf-ipngwg-icmp-v3] [I-D.ietf-ipngwg-icmp-v3]
Conta, A., "Internet Control Message Protocol (ICMPv6) for Conta, A., "Internet Control Message Protocol (ICMPv6) for
the Internet Protocol Version 6 (IPv6) Specification", the Internet Protocol Version 6 (IPv6) Specification",
draft-ietf-ipngwg-icmp-v3-07 (work in progress), draft-ietf-ipngwg-icmp-v3-07 (work in progress),
July 2005. July 2005.
[I-D.ietf-magma-mrdisc]
Haberman, B. and J. Martin, "Multicast Router Discovery",
draft-ietf-magma-mrdisc-07 (work in progress), May 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 19, line 24 skipping to change at page 19, line 27
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[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",
RFC 4286, December 2005.
7.2. Informative References 7.2. Informative References
[I-D.chown-v6ops-port-scanning-implications] [I-D.chown-v6ops-port-scanning-implications]
Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", Chown, T., "IPv6 Implications for TCP/UDP Port Scanning",
draft-chown-v6ops-port-scanning-implications-01 (work in draft-chown-v6ops-port-scanning-implications-02 (work in
progress), July 2004. progress), October 2005.
[I-D.huitema-v6ops-teredo] [I-D.gont-tcpm-icmp-attacks]
Huitema, C., "Teredo: Tunneling IPv6 over UDP through Gont, F., "ICMP attacks against TCP",
NATs", draft-huitema-v6ops-teredo-05 (work in progress), draft-gont-tcpm-icmp-attacks-05 (work in progress),
April 2005. October 2005.
[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
Network Address Translations (NATs)", RFC 4380,
February 2006.
[netfilter]
netfilter.org, "The netfilter.org project", Firewalling,
NAT and Packet Mangling for Linux , 2006,
<http://www.netfilter.org/>.
Appendix A. Notes on Individual ICMPv6 Messages Appendix A. Notes on Individual ICMPv6 Messages
A.1. Destination Unreachable Error Message A.1. Destination Unreachable Error Message
Destination Unreachable (Type 1) error messages [RFC2463] are sent Destination Unreachable (Type 1) error messages [RFC2463] 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
skipping to change at page 22, line 18 skipping to change at page 22, line 32
A.5. ICMPv6 Echo Request and Echo Response A.5. ICMPv6 Echo Request and Echo Response
Echo Request (Type 128) uses unicast addresses as source addresses, Echo Request (Type 128) uses unicast addresses as source addresses,
but may be sent to any legal IPv6 address, including multicast and but may be sent to any legal IPv6 address, including multicast and
anycast addresses [RFC2463]. Echo Requests travel end-to-end . anycast addresses [RFC2463]. Echo Requests travel end-to-end .
Similarly Echo Responses (Type 129) travel end-to-end and would have Similarly Echo Responses (Type 129) travel end-to-end and would have
a unicast address as destination and either a unicast or anycast a unicast address as destination and either a unicast or anycast
address as source. They are mainly used in combination for address as source. They are mainly used in combination for
monitoring and debugging connectivity. Their only role in monitoring and debugging connectivity. Their only role in
establishing communication is that they are required when verifying establishing communication is that they are required when verifying
connectivity through Teredo tunnels[I-D.huitema-v6ops-teredo]: Teredo connectivity through Teredo tunnels[RFC4380]: Teredo tuneling to IPv6
tuneling to IPv6 nodes on the site will not be possible if these nodes on the site will not be possible if these messages are blocked.
messages are blocked. It is not thought that there is a significant It is not thought that there is a significant risk from scanning
risk from scanning attacks on a well-designed IPv6 network (see attacks on a well-designed IPv6 network (see Section 3.2) and so
Section 3.2) and so connectivity checks should be allowed by default. 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 of communications on
the local link. Firewalls need to generate and accept these messages the local link. Firewalls need to generate and accept these messages
to allow them to establish interfaces onto their connected links. to allow them to establish 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.
skipping to change at page 23, line 36 skipping to change at page 23, line 52
and version 2 [RFC3810] (Listener Query and Listener Report Version 2 and version 2 [RFC3810] (Listener Query and Listener Report Version 2
- Types 130 and 143) messages are sent on the local link to - Types 130 and 143) messages are sent on the local link to
communicate between multicast capable routers and nodes which wish to communicate between multicast capable routers and nodes which wish to
join or leave specific multicast groups. Firewalls need to be able join or leave specific multicast groups. Firewalls need to be able
to generate Listener messages in order to establish communications to generate Listener messages in order to establish communications
and may generate all the messages if they also provide multicast and may generate all the messages if they also provide multicast
routing services. routing services.
A.11. Multicast Router Discovery Messages A.11. Multicast Router Discovery Messages
Multicast Router Discovery [I-D.ietf-magma-mrdisc] (Router Multicast Router Discovery [RFC4286] (Router Advertisement, Router
Advertisement, Router Solicitation and Router Termination - Types Solicitation and Router Termination - Types 151, 152 and 153)
151, 152 and 153) messages are sent by nodes on the local link to messages are sent by nodes on the local link to discover multicast
discover multicast capable routers on the link, and by multicast capable routers on the link, and by multicast capable routers to
capable routers to notify other nodes of their existence or change of notify other nodes of their existence or change of state. Firewalls
state. Firewalls which also act as multicast routers need to process which also act as multicast routers need to process these messages on
these messages on their interfaces. their interfaces.
A.12. Router Renumbering Messages A.12. Router Renumbering Messages
ICMPv6 Router Renumbering (Type 138) command messages can be received ICMPv6 Router Renumbering (Type 138) command messages can be received
and results messages sent by routers to change the prefixes which and results messages sent by routers to change the prefixes which
they advertise as part of Stateless Address Configuration [RFC2461], they advertise as part of Stateless Address Configuration [RFC2461],
[RFC2462]. These messages are sent end-to-end to either the all- [RFC2462]. These messages are sent end-to-end to either the all-
routers multicast address (site or local scope) or specific unicast routers multicast address (site or local scope) or specific unicast
addresses from a unicast address. addresses from a unicast address.
skipping to change at page 26, line 5 skipping to change at page 25, line 50
disallow forwarding of these incoming messages as a potential disallow forwarding of these incoming messages as a potential
security risk. Unknown outgoing Error messages should be dropped as security risk. Unknown outgoing Error messages should be dropped as
the administrator should be aware of all messages that could be the administrator should be aware of all messages that could be
generated on the site. generated on the site.
Also the Seamoby working group has had an ICMPv6 message (Type 150) Also the Seamoby working group has had an ICMPv6 message (Type 150)
allocated for experimental use in two protocols. This message is allocated for experimental use in two protocols. This message is
sent end-to-end and may need to pass through firewalls on sites that sent end-to-end and may need to pass through firewalls on sites that
are supporting the experimental protocols. are supporting the experimental protocols.
Appendix B. Example Script to Configure ICMPv6 Firewall Rules
This appendix contains an example script to implement most of the
rules suggested in this document when using the Netfilter packet
filtering system for Linux [netfilter]. When used with IPv6, the
'ip6tables' command is used to configure packet filtering rules for
the Netfilter system. The script is targeted at a simple enterprise
site that may or may not support Mobile IPv6.
#!/bin/bash
# Set of prefixes on the trusted ("inner") side of the firewall
export INNER_PREFIXES="2001:DB8:85::/60"
# Set of hosts providing services so that they can be made pingable
export PINGABLE_HOSTS="2001:DB8:85::/64"
# Configuration option: Change this to 1 if errors allowed only for
# existing sessions
export STATE_ENABLED=0
# Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 Home Agents - see Appendix B.14
export HOME_AGENTS_PRESENT=1
# Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 mobile nodes being present on the site -
# see Appendix B.14
export MOBILE_NODES_PRESENT=1
ip6tables -N icmpv6-filter
ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter
# Match scope of src and dest else deny
# This capability is not provided for in base ip6tables functionality
# An extension (agr) exists which may support it.
#@TODO@
# ECHO REQUESTS AND RESPONSES
# ===========================
# Allow outbound echo requests from prefixes which belong to the site
# for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type echo-request -j ACCEPT
done
# Allow inbound echo requests towards only predetermined hosts
# for pingable_host in $PINGABLE_HOSTS
do
ip6tables -A icmpv6-filter -p icmpv6 -d $pingable_host \
--icmpv6-type echo-request -j ACCEPT
done
if [ "$STATE_ENABLED" -eq "1" ]
then
# Allow incoming and outgoing echo reply messages
# only for existing sessions
ip6tables -A icmpv6-filter -m state -p icmpv6 \
--state ESTABLISHED,RELATED --icmpv6-type \
echo-reply -j ACCEPT
else
# Allow both incoming and outgoing echo replies
for pingable_host in $PINGABLE_HOSTS
do
# Outgoing echo replies from pingable hosts
ip6tables -A icmpv6-filter -p icmpv6 -s $pingable_host \
--icmpv6-type echo-reply -j ACCEPT
done
# Incoming echo replies to prefixes which belong to the site
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type echo-reply -j ACCEPT
done
fi
# Deny icmps to/from link local addresses
ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP
ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP
# Drop echo replies which have a multicast address as a
# destination
ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \
--icmpv6-type echo-reply -j DROP
# DESTINATION UNREACHABLE ERROR MESSAGES
# ======================================
if [ "$STATE_ENABLED" -eq "1" ]
then
# Allow incoming destination unreachable messages
# only for existing sessions
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -m state -p icmpv6 \
-d $inner_prefix \
--state ESTABLISHED,RELATED --icmpv6-type \
destination-unreachable -j ACCEPT
done
else
# Allow incoming destination unreachable messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type destination-unreachable -j ACCEPT
done
fi
# Allow outgoing destination unreachable messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type destination-unreachable -j ACCEPT
done
# PACKET TOO BIG ERROR MESSAGES
# =============================
if [ "$STATE_ENABLED" -eq "1" ]
then
# Allow incoming Packet Too Big messages
# only for existing sessions
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -m state -p icmpv6 \
-d $inner_prefix \
--state ESTABLISHED,RELATED \
--icmpv6-type packet-too-big \
-j ACCEPT
done
else
# Allow incoming Packet Too Big messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type packet-too-big -j ACCEPT
done
fi
# Allow outgoing Packet Too Big messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type packet-too-big -j ACCEPT
done
# TIME EXCEEDED ERROR MESSAGES
# ============================
if [ "$STATE_ENABLED" -eq "1" ]
then
# Allow incoming time exceeded code 0 messages
# only for existing sessions
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -m state -p icmpv6 \
-d $inner_prefix \
--state ESTABLISHED,RELATED --icmpv6-type packet-too-big \
-j ACCEPT
done
else
# Allow incoming time exceeded code 0 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type ttl-zero-during-transit -j ACCEPT
done
fi
#@POLICY@
# Allow incoming time exceeded code 1 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type ttl-zero-during-reassembly -j ACCEPT
done
# Allow outgoing time exceeded code 0 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type ttl-zero-during-transit -j ACCEPT
done
#@POLICY@
# Allow outgoing time exceeded code 1 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type ttl-zero-during-reassembly -j ACCEPT
done
# PARAMETER PROBLEM ERROR MESSAGES
# ================================
if [ "$STATE_ENABLED" -eq "1" ]
then
# Allow incoming parameter problem code 1 and 2 messages
# for an existing session
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -m state -p icmpv6 \
-d $inner_prefix \
--state ESTABLISHED,RELATED --icmpv6-type \
unknown-header-type \
-j ACCEPT
ip6tables -A icmpv6-filter -m state -p icmpv6 \
-d $inner_prefix \
--state ESTABLISHED,RELATED \
--icmpv6-type unknown-option \
-j ACCEPT
done
fi
# Allow outgoing parameter problem code 1 and code 2 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type unknown-header-type -j ACCEPT
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type unknown-option -j ACCEPT
done
#@POLICY@
# Allow incoming and outgoing parameter
# problem code 0 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type bad-header \
-j ACCEPT
done
# NEIGHBOR DISCOVERY MESSAGES
# ===========================
# Drop NS/NA messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type neighbor-solicitation -j DROP
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type neighbor-advertisement -j DROP
# Drop RS/RA messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type router-solicitation -j DROP
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type router-advertisement -j DROP
# Drop Redirect messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type redirect -j DROP
# MLD MESSAGES
# ============
# Drop incoming and outgoing
# Multicast Listener queries (MLDv1 and MLDv2)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 130 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv1)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP
# Drop incoming and outgoing Multicast Listener Done messages (MLDv1)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv2)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP
# ROUTER RENUMBERING MESSAGES
# ===========================
# Drop router renumbering messages
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP
# NODE INFORMATION QUERIES
# ========================
# Drop node information queries (139) and replies (140)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 139 -j DROP
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 140 -j DROP
# MOBILE IPv6 MESSAGES
# ====================
# If there are mobile ipv6 home agents present on the
# trusted side allow
if [ "$HOME_AGENTS_PRESENT" -eq "1" ]
then
for inner_prefix in $INNER_PREFIXES
do
#incoming Home Agent address discovery request
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 144 -j ACCEPT
#outgoing Home Agent address discovery reply
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 145 -j ACCEPT
#incoming Mobile prefix solicitation
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 146 -j ACCEPT
#outgoing Mobile prefix advertisement
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 147 -j ACCEPT
done
fi
# If there are roaming mobile nodes present on the
# trusted side allow
if [ "$MOBILE_NODES_PRESENT" -eq "1" ]
then
for inner_prefix in $INNER_PREFIXES
do
#outgoing Home Agent address discovery request
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 144 -j ACCEPT
#incoming Home Agent address discovery reply
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 145 -j ACCEPT
#outgoing Mobile prefix solicitation
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 146 -j ACCEPT
#incoming Mobile prefix advertisement
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 147 -j ACCEPT
done
fi
# DROP EVERYTHING ELSE
# ====================
ip6tables -A icmpv6-filter -p icmpv6 -j DROP
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
skipping to change at page 27, line 41 skipping to change at page 34, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 currently provided by the
Internet Society. Internet Society.
 End of changes. 25 change blocks. 
50 lines changed or deleted 387 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/