draft-ietf-v6ops-icmpv6-filtering-recs-00.txt   draft-ietf-v6ops-icmpv6-filtering-recs-01.txt 
IPv6 Operations E. Davies IPv6 Operations E. Davies
Internet-Draft Consultant Internet-Draft Consultant
Expires: October 14, 2006 J. Mohacsi Expires: December 15, 2006 J. Mohacsi
NIIF/HUNGARNET NIIF/HUNGARNET
April 12, 2006 June 13, 2006
Recommendations for Filtering ICMPv6 Messages in Firewalls Recommendations for Filtering ICMPv6 Messages in Firewalls
draft-ietf-v6ops-icmpv6-filtering-recs-00.txt draft-ietf-v6ops-icmpv6-filtering-recs-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 October 14, 2006. This Internet-Draft will expire on December 15, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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
skipping to change at page 2, line 41 skipping to change at page 2, line 41
4.2.4. Traffic for which a Dropping Policy Should be 4.2.4. Traffic for which a Dropping Policy Should be
Defined . . . . . . . . . . . . . . . . . . . . . . . 14 Defined . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.5. Traffic which Should be Dropped Unless a Good Case 4.2.5. Traffic which Should be Dropped Unless a Good Case
can be Made . . . . . . . . . . . . . . . . . . . . . 14 can be Made . . . . . . . . . . . . . . . . . . . . . 14
4.3. Recommendations for ICMPv6 Local Configuration Traffic . . 15 4.3. Recommendations 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 . . . . . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . 20 Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 20
A.1. Destination Unreachable Error Message . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . . . 23
A.7. Router Solicitation and Router Advertisement Messages . . 23 A.7. Router Solicitation and Router Advertisement Messages . . 23
A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . 24
A.11. Multicast Router Discovery Messages . . . . . . . . . . . 23 A.11. Multicast Router Discovery Messages . . . . . . . . . . . 24
A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . 25
A.15. Unused and Experimental Messages . . . . . . . . . . . . . 25 A.15. Unused and Experimental Messages . . . . . . . . . . . . . 25
Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 25 Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . . . 35
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], [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
indiscriminate passage of all ICMPv6 messages can be a major security indiscriminate passage of all ICMPv6 messages can be a major security
risk. This document recommends a set of rules which seek to balance risk. This document recommends a set of rules which seek to balance
effective IPv6 communication against the needs of site security. effective IPv6 communication against the needs of site security.
Readers familiar with ICMPv6 can skip to the recommended filtering
rules in Section 4 and an example configuration script for Linux
netfilter in Appendix B.
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
are: are:
o Returning error messages to the source if a packet could not be o Returning error messages to the source if a packet could not be
delivered. Four different error messages, each with a number of delivered. Four different error messages, each with a number of
sub-types are specified in [RFC4443]. sub-types are specified in [RFC4443].
o Simple monitoring of connectivity through echo requests and o Simple monitoring of connectivity through echo requests and
responses used by the ping and traceroute utilities. The Echo responses used by the ping and traceroute utilities. The Echo
Request and Echo Response messages are specified in [RFC4443]. Request and Echo Response messages are specified in [RFC4443].
o Finding neighbors (both routers and hosts) connected to the same o Finding neighbors (both routers and hosts) connected to the same
link and determining their IP and link layer addresses. These link and determining their IP and link layer addresses. These
messages are also used to check the uniqueness of any addresses messages are also used to check the uniqueness of any addresses
that an interface proposes to use (Duplicate Address Detection - that an interface proposes to use (Duplicate Address Detection -
DAD)). Four messages - Neighbor Solicitation (NS), Neighbor DAD)). Four messages - Neighbor Solicitation (NS), Neighbor
Advertisement (NA), Router Solicitation (RS) and Router Advertisement (NA), Router Solicitation (RS) and Router
Advertisement (RA) - are specified in [RFC4311]. Advertisement (RA) - are specified in [RFC2461].
o Ensuring that neighbors remain reachable using the same IP and o Ensuring that neighbors remain reachable using the same IP and
link layer addresses after initial discovery (Neighbor link layer addresses after initial discovery (Neighbor
Unreachability Discovery - NUD) and notifying neighbors of changes Unreachability Discovery - NUD) and notifying neighbors of changes
to link layer addresses. Uses NS and NA [RFC4311]. to link layer addresses. Uses NS and NA [RFC2461].
o Finding routers and determining how to obtain IP addresses to join o Finding routers and determining how to obtain IP addresses to join
the subnets supported by the routers. Uses RS and RA [RFC4311]. the subnets supported by the routers. Uses RS and RA
[RFC2461].[[anchor2: [RFC Editor: Please update references to
RFC2461 when the new version of RFC2461 is published.] --Authors]]
o If stateless auto-configuration of hosts is enabled, communicating o If stateless auto-configuration of hosts is enabled, communicating
prefixes and other configuration information (including the link prefixes and other configuration information (including the link
MTU and suggested hop count default) from routers to hosts. Uses MTU and suggested hop limit default) from routers to hosts. Uses
RS and RA [RFC2462]. [[anchor2: [RFC Editor: Please update RS and RA [RFC2462]. [[anchor3: [RFC Editor: Please update
references to RFC2462 when the new version of RFC2462 is references to RFC2462 when the new version of RFC2462 is
published.] --Authors]] published.] --Authors]]
o Using SEcure Neighbor Discovery (SEND) to authenticate a router o Using SEcure Neighbor Discovery (SEND) to authenticate a router
attached to a link, the Certificate Path Solicitation and attached to a link, the Certificate Path Solicitation and
Advertisement messages specified in [RFC3971] are used by hosts to Advertisement messages specified in [RFC3971] are used by hosts to
retrieve the trust chain between a trust anchor and the router retrieve the trust chain between a trust anchor and the router
certificate from the router. certificate from the router.
o Redirecting packets to a more appropriate router on the local link o Redirecting packets to a more appropriate router on the local link
for the destination address or pointing out that a destination is for the destination address or pointing out that a destination is
actually on the local link even if it is not obvious from the IP actually on the local link even if it is not obvious from the IP
address (where a link supports multiple subnets). The Redirect address (where a link supports multiple subnets). The Redirect
message is specified in [RFC4311]. message is specified in [RFC2461].
o Supporting renumbering of networks by allowing the prefixes o Supporting renumbering of networks by allowing the prefixes
advertised by routers to be altered. Uses NS, NA, RS and RA advertised by routers to be altered. Uses NS, NA, RS and RA
together with the Router Renumbering message specified in together with the Router Renumbering message specified in
[RFC2894]. [RFC2894].
o Determining the Maximum Transmission Unit (MTU) along a path. The o Determining the Maximum Transmission Unit (MTU) along a path. The
Packet Too Big error message is essential to this function Packet Too Big error message is essential to this function
[RFC1981]. [RFC1981].
o Providing a means to discover the IPv6 addresses associated with o Providing a means to discover the IPv6 addresses associated with
the link layer address of an interface (the inverse of Neighbor the link layer address of an interface (the inverse of Neighbor
Discovery, where the link layer address is discovered given an Discovery, where the link layer address is discovered given an
skipping to change at page 7, line 13 skipping to change at page 7, line 17
Solicitation. Solicitation.
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 [RFC4311], 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 for example when configuring may also use global unicast addresses for example when configuring
global addresses. Also some ICMPv6 messages in local communications global addresses. Also some ICMPv6 messages in local communications
may contravene the usual rules requiring compatible scopes for source may contravene the usual rules requiring compatible scopes for source
and destination addresses. and destination addresses.
skipping to change at page 11, line 18 skipping to change at page 11, line 21
Many of the messages used for establishment of communications on the Many of the messages used for establishment of communications on the
local link will be sent with link-local addresses for at least one of local link will be sent with link-local addresses for at least one of
their source and destination. Routers (and firewalls) conforming to their source and destination. Routers (and firewalls) conforming to
the IPv6 standards will not forward these packets; there is no need the IPv6 standards will not forward these packets; there is no need
to configure additional rules to prevent these packets traversing the to configure additional rules to prevent these packets traversing the
firewall/router. Also the specifications of ICMPv6 messages intended firewall/router. Also the specifications of ICMPv6 messages intended
for use only on the local link specify various measures which would for use only on the local link specify various measures which would
allow receivers to detect if the message had passed through a allow receivers to detect if the message had passed through a
firewall/router, including: firewall/router, including:
o Requiring that the hop count 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. On reception the hop count is required to be still transmission. On reception the hop limit is required to be still
255 which would not be the case if the packet had passed through a 255 which would not be the case if the packet had passed through a
firewall/router. firewall/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 rules to drop Accordingly it is not essential to configure firewall rules to drop
illegal packets of these types. If they have non-link-local source illegal packets of these types. If they have non-link-local source
and destination addresses, allowing them to traverse the firewall, and destination addresses, allowing them to traverse the firewall,
they would be rejected because of the checks performed at the they would be rejected because of the checks performed at the
destination. However, firewall administrators may still wish to log destination. However, firewall administrators may still wish to log
or drop such illegal packets. or drop such illegal packets.
skipping to change at page 13, line 24 skipping to change at page 13, line 28
initially transmitted. All these messages should never be propagated initially transmitted. All these messages should never be propagated
beyond the link on which they were initially transmitted. During beyond the link on which they were initially transmitted. During
normal operations these messages will have destination addresses, normal operations these messages will have destination addresses,
mostly link local but in some cases global unicast addresses, of mostly link local but in some cases global unicast addresses, of
interfaces on the local link. No special action is needed to filter interfaces on the local link. No special action is needed to filter
messages with link-local addresses. As discussed in Section 4.1 messages with link-local addresses. As discussed in Section 4.1
these messages are specified so that either the receiver is able to these messages are specified so that either the receiver is able to
check that the message has not passed through a firewall/router or it check that the message has not passed through a firewall/router or it
will be dropped at the first router it encounters. Administrators will be dropped at the first router it encounters. Administrators
may wish to consider providing rules to catch illegal packets sent may wish to consider providing rules to catch illegal packets sent
with Hop Count = 1 to avoid ICMPv6 Time Exceeded messages being with hop limit = 1 to avoid ICMPv6 Time Exceeded messages being
generated for these packets. generated for these packets.
Address Configuration and Router Selection messages (must be received Address Configuration and Router Selection messages (must be received
with Hop Count = 255): with hop limit = 255):
o Router Solicitation (Type 133) o Router Solicitation (Type 133)
o Router Advertisement (Type 134) o Router Advertisement (Type 134)
o Neighbor Solicitation (Type 135) o Neighbor Solicitation (Type 135)
o Neighbor Advertisement (Type 136) o Neighbor Advertisement (Type 136)
o Redirect (Type 137) o Redirect (Type 137)
o Inverse Neighbor Discovery Solicitation (Type 141) o Inverse Neighbor Discovery Solicitation (Type 141)
o Inverse Neighbor Discovery Advertisement (Type 142) o Inverse Neighbor Discovery Advertisement (Type 142)
Link-local multicast receiver notification messages (must have link- Link-local multicast receiver notification messages (must have link-
local source address): local source address):
o Listener Query (Type 130) o Listener Query (Type 130)
o Listener Report (Type 131) o Listener Report (Type 131)
o Listener Done (Type 132) o Listener Done (Type 132)
o Listener Report v2 (Type 143) o Listener Report v2 (Type 143)
SEND Certificate Path notification messages (must be received with SEND Certificate Path notification messages (must be received with
Hop Count = 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 Count = 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.2.4. Traffic for which a Dropping Policy Should be Defined 4.2.4. Traffic for which a Dropping Policy Should be Defined
The message which the experimental Seamoby protocols are using will The message which the experimental Seamoby protocols are using will
be expected to have to cross site boundaries. Administrators should be expected to have to cross site boundaries. Administrators should
determine if they need to support these experiments and otherwise determine if they need to support these experiments and otherwise
messages of this type should be dropped: messages of this type should be dropped:
skipping to change at page 15, line 11 skipping to change at page 15, line 18
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
messages with unknown types must be silently discarded.
4.3. Recommendations for ICMPv6 Local Configuration Traffic 4.3. 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.3.1. Traffic that Must NOT be Dropped 4.3.1. Traffic that Must NOT be Dropped
skipping to change at page 17, line 44 skipping to change at page 18, line 4
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
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
provided important comments. Some analysis of the classification of provided important comments. Some analysis of the classification of
skipping to change at page 18, line 38 skipping to change at page 18, line 47
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.
[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
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999. October 1999.
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, [RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894,
August 2000. August 2000.
skipping to change at page 19, line 22 skipping to change at page 19, line 37
[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", [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, December 2005. RFC 4286, December 2005.
[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
Sharing", RFC 4311, November 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.
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-02 (work in draft-chown-v6ops-port-scanning-implications-02 (work in
progress), October 2005. progress), October 2005.
skipping to change at page 24, line 15 skipping to change at page 24, line 31
messages are sent by nodes on the local link to discover multicast messages are sent by nodes on the local link to discover multicast
capable routers on the link, and by multicast capable routers to capable routers on the link, and by multicast capable routers to
notify other nodes of their existence or change of state. Firewalls notify other nodes of their existence or change of state. Firewalls
which also act as multicast routers need to process these messages on which also act as multicast routers need to process 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 [RFC4311], 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.
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
skipping to change at page 27, line 28 skipping to change at page 27, line 45
done done
# Incoming echo replies to prefixes which belong to the site # Incoming echo replies to prefixes which belong to the site
for inner_prefix in $INNER_PREFIXES for inner_prefix in $INNER_PREFIXES
do do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type echo-reply -j ACCEPT --icmpv6-type echo-reply -j ACCEPT
done done
fi fi
# Deny icmps to/from link local addresses # Deny icmps to/from link local addresses
# These rules should be redundant as routers should not forward
# link local addresses but to be sure...
ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP
ip6tables -A icmpv6-filter -p icmpv6 -s 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 # Drop echo replies which have a multicast address as a
# destination # destination
ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \ ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \
--icmpv6-type echo-reply -j DROP --icmpv6-type echo-reply -j DROP
# DESTINATION UNREACHABLE ERROR MESSAGES # DESTINATION UNREACHABLE ERROR MESSAGES
# ====================================== # ======================================
 End of changes. 30 change blocks. 
32 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/