[ipv6hackers] Operational ICMPv6 Filtering

daniel.bartram at bt.com daniel.bartram at bt.com
Thu May 31 15:52:51 CEST 2012

Granted, but hackers don't work within what the RFC's say, or on the converse can work within exactly what they say to find vulnerabilities. If I don't know or need what type 4 does then I will block it until a time where I do need it or I find it did in fact break something. Why leave it open just because something tells you to? I'd expect an even better network engineer to make their own rules.


-----Original Message-----
From: ipv6hackers-bounces at lists.si6networks.com [mailto:ipv6hackers-bounces at lists.si6networks.com] On Behalf Of Simon Perreault
Sent: 31 May 2012 14:42
To: ipv6hackers at lists.si6networks.com
Subject: Re: [ipv6hackers] Operational ICMPv6 Filtering

On 2012-05-31 09:30, daniel.bartram at bt.com wrote:
> Thanks Simon. This particular ACL was for a WAN facing link towards an 
> ISP infrastructure where a static /127 is used. I wasn't sure, but I 
> didn't think blocking type 4 would have any affect at all?

I wouldn't ignore an RFC recommendation without being sure...

The nice thing is that there's an RFC you can point to when people question why such and such ICMP types/codes are open. Following best current practices is what I would expect of a good network engineer.

DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
Ipv6hackers mailing list
Ipv6hackers at lists.si6networks.com

More information about the Ipv6hackers mailing list