[ipv6hackers] Operational ICMPv6 Filtering

Simon Perreault simon.perreault at viagenie.ca
Thu May 31 16:44:21 CEST 2012

On 2012-05-31 10:33, daniel.bartram at bt.com wrote:
> So this prompted me to do a bit of research into ICMPv6 Type 4, which
> I probably should have done earlier.
> RFC4443: If an IPv6 node processing a packet finds a problem with a
> field in the IPv6 header or extension headers such that it cannot
> complete processing the packet, it MUST discard the packet and SHOULD
> originate an ICMPv6 Parameter Problem message to the packet's source,
> indicating the type and location of the problem.
> Now interesting points here. The router must discard a problematic
> packet after realising it can't process it, fair enough. But it
> SHOULD originate an ICMPv6 type 4 message - it doesn't necessarily
> have to. So by RFC4890 stating it MUST not be dropped, is not
> entirely correct. In fact, I'd prefer it not to generate a message.

The reason it's a SHOULD is to account for ICMP error generation rate 
limiting. Not personal preference.

> Say a rouge user is sending randomly constructed ICMPv6 packets into
> a network, and they finally send one that a node returns a type 4
> packet. Now the rouge user knows they've found a packet structure the
> node cannot process so not only can they now flood this router with
> this type of packet (that it has to process to figure out it's not
> valid), it now also creates additional network bandwidth by
> constantly sending these type 4's back - almost like a self-inflicted
> DoS.

They don't need ICMP to find a header that the node doesn't know how to 
process. They can just go to IANA and pick one that doesn't exist.

> So must I still allow ICMPv6 type 4's through?

Yes, unless you can find better justification.

Sometimes I wish the situation for network engineers was the same as for 
doctors: follow the BCPs or be sued for malpractice...

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

More information about the Ipv6hackers mailing list