network
Click on the red underlined text to get to the source
... RFC2461].
* Supporting renumbering of networks by allowing the prefixes
advertised by routers ...
... ICMPv6 cannot be
treated as an auxiliary function with packets that can be dropped in
most cases without damaging the functionality of the network. This
means that firewall filters ...
... Network Topology and Address Scopes ...
... possible, it is essential that the connectivity checking messages are
allowed through the firewall. It has been common practice in IPv4
networks to drop Echo Request messages in firewalls to minimize the
...
... firewalls to minimize the
risk of scanning attacks on the protected network. As discussed in
Section 3.2, the risks from port scanning in an IPv6 network ...
... network. As discussed in
Section 3.2, the risks from port scanning in an IPv6 network are much
less severe, and it is not necessary to filter IPv6 ...
... tunnel and it is not considered necessary to disable connectivity
checking in IPv6 networks because port scanning is less of a security
risk.
...
... node. These messages must
not be dropped if the node is to successfully participate in an IPv6
network. The exception to this is the Redirect message for which an
explicit policy decision should be taken (see Section 4.4.4).
...
... Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380prop, February 2006. ...
... Internet will become inaccessible.
If a network chooses to generate packets that are no larger than the
Guaranteed Minimum MTU (1280 octets ...
... Code 1 messages will generally only result from congestion in the
network, and it is less essential to propagate these messages.
...
... It is possible that attackers may seek to probe or scan a network by
deliberately generating packets with unknown extension headers or
...
... active
addresses that can be probed further or learn about the network
topology. The vulnerability could be mitigated whilst helping to
establish communications if the firewall ...
... Problem messages for headers that had been standardized but were not
supported in the protected network. If the network administrator
believes that all nodes ...
... headers that had been standardized but were not
supported in the protected network. If the network administrator
believes that all nodes in the network ...
... network administrator
believes that all nodes in the network support all legitimate
extension headers, then it would be reasonable to drop all outgoing
...
... Parameter Problem messages. Note that this is not a major
vulnerability in a well-designed IPv6 network because of the
difficulties of performing scanning attacks (see Section 3.2).
...
... blocked. It is not thought that there is a significant risk from
scanning attacks on a well-designed IPv6 network (see Section 3.2),
and so connectivity checks should be allowed by default.
...
... section describes how to treat messages that attempt to use these
Type values in a way of which the network administrator (and hence
the firewall) is not aware.
...
... Type values for ICMPv6
Error and Informational messages, which could be used in site-
specific ways. These messages should be dropped by transit networks
and at site edges. They should also not be propagated within sites
...
... and at site edges. They should also not be propagated within sites
unless the network administrator is explicitly made aware of usage.
The codes reserved for future extension of the ICMPv6 Type ...
... Unknown ICMPv6 Error messages should be allowed to pass through
transit networks. At end site boundaries any incoming ICMPv6 Error
messages of which the firewall is not aware may be allowed through
...