Of course if you don't mind absolutely terrible overhead and chewing lots more CPU, you could do something crazy like replace the IPIP tunnel with an EOIP tunnel inside of which you operate an MPLS VPLS tunnel, since Mikrotik's VPLS WILL do fragment reassembly for you.
1500 <-- Starting MTU
- 20 <-- Subtract 20 bytes for the IP headers (EoIP)
- 8 <-- Subtract GRE protocol header (EoIP)
- 14 <-- Subtract the encapsulated Ethernet header (sans checksum)
1458 <-- New MTU of EoIP tunnel
- 12 <-- Subtract VPLS overhead (two 4-byte MPLS tags, 1 4-byte VPLS header)
- 14 <-- Subtract the VPLS-encapsulated Ethernet header (sans checksum) - NOT sure of this one
1432 <-- Payload bytes before VPLS will have to fragment and reassemble IF you set a VPLS MTU bigger than this
The fun thing is, you can set the VPLS interface MTU bigger than the 1432 bytes and any packet over 1432 will be fragmented and reassembled by VPLS. I'm not sure if VPLS uses IP fragmentation (thereby doubling the 20-byte IP header overhead for each IP packet over the 1432 byte threshold) or some custom fragmentation/reassembly method. (Anyone know?)
You could set the VPLS interface advertised MTU to 9000 and then the interface MTU to 9000, then send VERY large packets over it. But each fragment that won't fit gets that awful 68-byte overhead in addition to whatever fragmentation/reassembly overhead there is.
How's that for fun with RouterOS?
I'm not 100% sure of that VPLS ethernet header (14-bytes). The Mikrotik vpls interface does seem to operate in ethernet mode, supporting ARP, ethernet bridging, etc. which is why I assume it just encapsulates an ethernet header. But it could instead use MPLS Forwarding Equiv. Class to map ethernet to MPLS and avoid that, and use some signaling (LDP?) to map ethernet MACs to IPs, etc. -- I'd love to know more. The Wiki doesn't show ethernet overhead for VPLS when passing IP frames. I'd love to know more about the fragmentation/reassembly method used too.