IPv6 ICMP - denied packets
Hi, I recently installed a probe at home, and now my router spits out loads of 'denied icmpv6'-messages. After going through the logs for the last two days, I have ~1900 entries of denies towards the probe -- all of them more or less like this (with different source); ### Jun 22 2014 22:30:22.863 CEST: %IPV6_ACL-6-ACCESSLOGDP: list ipv6-inbound/2100 denied icmpv6 2A01:4F8:130:24A4::13:76 (Po1.102) -> {PROBE-IPV6-ADDRESS} (1/4), 8 packets ### I've got an ACL applied ingress on the link to my ISP, and the relevant part is shown below; ### ipv6 access-list ipv6-inbound sequence 2000 permit icmp any any echo-reply sequence 2005 permit icmp any any echo-request sequence 2010 permit icmp any any packet-too-big sequence 2015 permit icmp any any time-exceeded sequence 2020 permit icmp any any destination-unreachable sequence 2025 permit icmp any any parameter-problem sequence 2100 deny icmp any any log-input ### This ACL conforms to RFC4890[1] (except the Mobile IPv6 part). Of the 1900 entries, all of them are ICMPv6 type 1. ~300 of them have the code bit[2] set to 1, and ~1600 of them are set to 4. These are the top sources; ### 367 2001:500:2::C 313 2001:500:2D::D 289 2A01:4F8:130:24A4::13:76 289 2001:500:3::42 196 2A01:4F8:121:30A4::78:15 161 2001:DC3::35 100 2001:7FE::53 67 2001:7FD::1 60 2001:500:2F::F ### All of these are DNS root servers (except those starting with 2A01:4F8, which are some Atlas-thingies). It seems to me that the Atlas-probe sends quite some amount of ICMPv6-packets to the root DNS-servers (and even Atlas' own boxes), that are being returned with errors. Why does the probe do this, and does it actually rely on these replies? [1] <http://www.ietf.org/rfc/rfc4890.txt> [2] <http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml#icmpv6-parameters-codes-2> -- Joachim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014/06/23 23:01 , Joachim Tingvold wrote:
Hi,
I recently installed a probe at home, and now my router spits out loads of 'denied icmpv6'-messages.
After going through the logs for the last two days, I have ~1900 entries of denies towards the probe -- all of them more or less like this (with different source);
### Jun 22 2014 22:30:22.863 CEST: %IPV6_ACL-6-ACCESSLOGDP: list ipv6-inbound/2100 denied icmpv6 2A01:4F8:130:24A4::13:76 (Po1.102) -> {PROBE-IPV6-ADDRESS} (1/4), 8 packets ###
I've got an ACL applied ingress on the link to my ISP, and the relevant part is shown below;
### ipv6 access-list ipv6-inbound sequence 2000 permit icmp any any echo-reply sequence 2005 permit icmp any any echo-request sequence 2010 permit icmp any any packet-too-big sequence 2015 permit icmp any any time-exceeded sequence 2020 permit icmp any any destination-unreachable sequence 2025 permit icmp any any parameter-problem sequence 2100 deny icmp any any log-input ###
This ACL conforms to RFC4890[1] (except the Mobile IPv6 part).
Of the 1900 entries, all of them are ICMPv6 type 1. ~300 of them have the code bit[2] set to 1, and ~1600 of them are set to 4.
Type 1, code 4 is port unreachable. That is triggered by UDP traceroute. It would be better not to filter those packets. Type 1, code 1 means administratively prohibited. It is best to allow that one as well. Or in general, any destination unreachable ICMP. Though I don't understand why 'sequence 2020 permit icmp any any destination-unreachable' does accept those packets. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOomfkACgkQ23LKRM64egJu+QCfVdUc8qMYufSw+IvThUYfzPyn nwYAoIK0MmsAYptBL8DUgqCB4bb1brC0 =5Cqj -----END PGP SIGNATURE-----
On 23 Jun 2014, at 23:19, Philip Homburg wrote:
Type 1, code 4 is port unreachable. That is triggered by UDP traceroute. It would be better not to filter those packets.
Type 1, code 1 means administratively prohibited. It is best to allow that one as well. Or in general, any destination unreachable ICMP.
Though I don't understand why 'sequence 2020 permit icmp any any destination-unreachable' does accept those packets.
Does or doesn't? (-: In any case; i figured out that 'destination-unreachable' actually only means type 1, code 3, which would explain a lot. A bit confusing name I guess (even though it makes sense, kinda). So, I'll just change 'destination-unreachable' (type 1, code 3) to 'unreachable' (type 1, all codes), and it should be good. -- Joachim
On 2014.06.23. 23:01, Joachim Tingvold wrote:
It seems to me that the Atlas-probe sends quite some amount of ICMPv6-packets to the root DNS-servers (and even Atlas' own boxes), that are being returned with errors. Why does the probe do this, and does it actually rely on these replies?
Besides the technicalities of firewall rules: all probes are automatically involved in measurements towards root DNS servers (ping/trace/DNS) and pieces of the infrastructure (ping/trace). We use this data to establish baselines about the probe's capabilities and to power the maps available on the site. Many probes report problems in one way or another; we are far beyond the point where we can rely on all (or a set of carefully selected) probes to supply useful data. Regards, Robert
participants (3)
-
Joachim Tingvold -
Philip Homburg -
Robert Kisteleki