When using ping command for path MTU discovery be aware of OS variations. Some treat the size variable as the data component only and others as the entire packet (data + header).
When we are talking 1500 MTU this value is including the header.
IPv6 has a fixed header size of 40 bytes so a 1500 MTU would yield a max payload (data) of 1460 bytes. If you are using ping deduct another 8 bytes for ICMPv6 so 1452 bytes.
The Linux command allows it but its probably extraneous for ICMPv6.
(redacted this after testing)
I don't know the finer details of how the command interacts with the IP system in the kernel so I had been setting it to be sure. But if there is no "do not fragment" option in some other OS (Windows?) then I wouldn't over think it.
WFH Linux Systems and Networks Engineer in the Internet industry | Specialising in Mikrotik | APNIC member | Open to job offers | ZL2NET
After the post by @MadEngineer I thought I had better test this:
"Will the kernel enforce the ICMPv6 packet size if no-frag option is omitted" and it is clear the answer is no.
For example:
ping -6 -s 1453 -M do [IPv6 capable host]
Response "ping: local error: message too long, mtu: 1500" (This is the expected result)
However....
ping -6 -s 1453 [Same IPv6 capable host]
Response "1461 bytes from redacted (redacted): icmp_seq=1 ttl=61 time=26.2 ms"
So at least under Linux (Ubuntu with 6.14.0 kernel) it needs the no-frag set else the kernel will do what it does and treat ping like any other application and fragment the traffic.
WFH Linux Systems and Networks Engineer in the Internet industry | Specialising in Mikrotik | APNIC member | Open to job offers | ZL2NET
Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly
to your computer or smartphone by using a feed reader.
Trusted
Net Trust Ltd
