[ipv6hackers] Ipv6hackers Digest, Vol 38, Issue 13

[Ray Hunter]

28 August 2014 12:00
Send Ipv6hackers mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.si6networks.com/listinfo/ipv6hackers
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ipv6hackers digest..."
1. Re: Fwd: DoS attacks (ICMPv6-based) resulting from IPv6 EH
drops (Fernando Gont)
2. Re: Fwd: DoS attacks (ICMPv6-based) resulting from IPv6 EH
drops (Mathias Morbitzer)
----------------------------------------------------------------------
Message: 1
Date: Wed, 27 Aug 2014 14:30:03 -0300
Subject: Re: [ipv6hackers] Fwd: DoS attacks (ICMPv6-based) resulting
from IPv6 EH drops
Content-Type: text/plain; charset=windows-1252
Hi, Mathias,
Just double-checking...
So when these two Linux kernel versions receive an ICMPv6 PTB<1280 not
only do not generate IPv6 atomic fragments, but also crash?
Thanks,
------------------------------------------------------------------------

When talking about storing the newly discovered PMTU in the kernel, what
do the OS/developers generally define as "the path"?

Is it the couple (<IPv6 src address>/128 , <destination address>/128)?

Or is it just (<source address = 2000/3> , <destination address>/128)?

Or something else? e.g. related to outbound interface.

I'm thinking of some potential exotic attack where you
a) spoof both <source port>/ <destination port> to attack other
protocols. e.g. a PTB generated on an HTTP session being used as a DoS
on a tunnel or vice versa.
b) attack a completely different interface on a multi-homed device
(which may be connected to a completely different network).
c) Send PTB for multicast to trigger a lower PMTU on unicast (or vice versa)

I'm beginning to think that the safe option is to limit the discovered
PMTU setting to related protocols and interfaces..... and to think of
receiving an ICMP PTB as a rather loose hint to crank down the MTU, and
only on sessions that are failing to progress nominally.

In which case you have to wonder whether ICMP PTB is pretty pointless,
and the kernel could just as well try this "fix" of reducing MTU on any
stalled sessions without waiting for the ICMP to arrive at all.

Or just implement PLPMTUD.