Yes, the 1516 MTU figure seems weird to me.

Let me explain how I arrived at it.

I checked my MTU from a Raspberry Pi running the latest Raspberry Pi OS (because Windows does so many things in it's own strange undocumented ways) connected directly to the router.

All ports on the router are explicitly set to MTU 1500 except the PPPoE connection, which was initially set to MTU 1508 (as almost everybody says it should be).

I tested whether pings carrying a certain amount of data could get out by doing pings like this:
ping -Mdo -c4 -s1472 51.148.72.21
or this:
ping -Mdo -c4 -s1452 2a02:8010::100
The figure after the -s is the size of the data in the ping.
The addresses are addresses within the Zen infrastructure that I'm confidant are properly connected with MTU 1500 and which will respond normally to pings. They're actually addresses that appear near the top when I do traceroute to anywhere.

The result of these ping commands is either 4 correct responses from the given address or 4 error messages saying "message too long".

Initially I found the longest IPv4 ping that gave no error was -s1472 and the longest IPv6 was 1444.

Googling seemed to suggest 1472 was correct in most cases for IPv4 and an MTU of 1500.

But it seemed like 1444 for IPv6 was an odd result, so on a hunch I tried increasing the MTU on the PPPoE port one byte at a time and, amazingly, I found the maximum IPv6 ping size increased too.

I was able to increase the maximum IPv6 ping size up to 1452 by setting the PPPoE MTU to 1516 but that was the biggest it would go.

1452 is 20 bytes less than 1472 which does make some kind of sense, though I'm no expert on MTUs, IP and PPPoE.

But I'm rather puzzled by the fact that, as far as I can see, virtually nobody else anywhere on the internet is talking about using an MTU of 1516 to carry dual stack PPPoE.

And why would be overhead due to PPPoE encapsulation change depending on whether the packet inside is IPv4 or IPv6?

Edited by bdg2 (Mon 08-Nov-21 21:49:11)

Those values are the maximum.

The ping utility (in linux anyway..) has the size specified for the payload. An 8 byte ICMP header is attached to that data. So you are sending for IPv4 1472 bytes + 8 bytes ICMP header + 20 bytes IPv4 Header = 1500 bytes..

Similar IPv6 has 1452 bytes + 8 bytes ICMP + 40 bytes IPv6 Header = 1500 bytes.

Setting 1516 bytes on your port seems weird, but its working so I wouldn't look too much further.

In reply to a post by bdg2:

But I'm rather puzzled by the fact that, as far as I can see, virtually nobody else anywhere on the internet is talking about using an MTU of 1516 to carry dual stack PPPoE.

And why would be overhead due to PPPoE encapsulation change depending on whether the packet inside is IPv4 or IPv6?

You are correct to wonder as the 8-byte header is for establishing a layer 2 connection so by definition doesn't have fields for IP addresses (or even care about them).
The baby jumbo ethernet frames only need to exist on the wire if the client (e.g. router or single PC doing PPPoE) and server (e.g. modem bridging PPPoE to PPPoA) are separate boxes, rather than a router with built-in DSL modem.

As others have said the MTU for the actual IP traffic can be 1500 for both IPv4 and IPv6 on standard ethernet and the larger header of IPv6 means it is the MSS (e.g. for TCP) that will be lower.

The reason a router may need to set an MTU of 1508 on a PPPoE interface is more as a means to push the parent ethernet interface's maximum frame size (from L2 default 1518) up by the same amount rather than the router wanting to send IP packets to the modem.

Edited by prlzx (Wed 10-Nov-21 18:42:38)