> When sending a ping 6 to a destination not accepting fragmented
> packets, I experience loss with "big" (but < 1500) packets.
> % ping6 -s 1234 2001:7f8:54::250
> 14:03:07.959532 2001:7f8:54::145 > 2001:7f8:54::250: frag
> (0xbfb11fea:1232@0+) icmp6: echo request
> 14:03:07.959536 2001:7f8:54::145 > 2001:7f8:54::250: frag
> 14:03:07.960179 2001:7f8:54::250 > 2001:7f8:54::145: icmp6: echo reply
Sorry, just been to lunch and probably my brain is off ... but where
exactly is the loss here? You are getting a reply, right? Maybe the
receiver did receive all the fragments, figured the path MTU is large
enough and sent you back a non-fragmented echo reply?
And what do you mean by saying "destination not accepting fragmented
packets"? Do all the fragments reach the destination (and the
destination then has to figure out what to do with them)? Or does some
middlebox (I'm thinking switches / routers) touch the traffic,
discarding e.g. non-initial fragments?
Can you do tcpdump or tshark etc. on the source as well as on the
destination box to see what exactly gets through and whether your
problem is sender/destination-related or rather middlebox-related?
Oh, and what exactly caused the fragmentation in the first place? Your
local MTU seems larger than the required 1242 bytes, so path MTU
discovery must have kicked in somewhere on the way. Shouldn't you have
gotten ICMPv6 packet too big (type 2) messages on ..::145 ? Those
should be visible in tcpdump .. but you are not showing any.
I tried "ping6 2001:7f8:54::250" myself right now. Seems that my ICMP
echo request goes through unfragmented, whereas I'm getting two
fragments (first: 1232 bytes) back. So on the path from ...::145 to
me, fragmentation seems to happen, but not in the other direction.
IMHO, this means that ..::145 must have successfully performed PMTUD.
source: Linux machine with IPv6: 2a02:27d0:0:5e0d:1a03:73ff:feba:50b4
Destination machine OpenBSD 5.8 with IPv6: 2a02:27d0:0:5e0c:d6be:d9ff:fe95:a236
source# ping6 -M do -s 1232 2a02:27d0:0:5e0c:d6be:d9ff:fe95:a236
leads to answers fitting in one packet only (1280 byte) with no
source# ping6 -M do -s 1233 leads to fragmentation
I wonder why ICMPv6 answers bigger than 1232 are always fragmented.
> On 08/09/2016 07:42 AM, Laurent CARON wrote:
>> Does anybody have a clue about this issue ? Thanks
> Based on a quick look at what you sent, this is not what I would expect.
>> Am I mistaken on something, or is this behavior perfectly normal ?
>> Please note # tracepath6 from the linux box to the openbsd one reports:
>> Resume: pmtu 1500 hops 2 back 2
> This doesn't really matter. PMTU can be assymetric. So you should use
> tracepath6 from OpenBSD ot Linux, since that's the direction in which
> traffic is being fragmented.
Last time I looked at tracepath it was quite Linux-specific code and
not very portable. You can get similar information from the useful tool
$ scamper -I 'trace -M [ip_address]'
or with the OpenBSD package you can do 'scamper-trace -M [ip]'
- note that it wants a numeric v4/v6 address not a hostname.