Hmm, yes, true, IPv6 does not support fragmentation at all...
It does, but it's done end-to-end, not at intermediate routers. See Section 5 of RFC 2460.
Ah, ok, yes, you're right, forgot about the fragmentation header in IPv6 :).
If BATMAN were just doing transparent link fragmentation towards its neighbours as a "fall-back" mechanism despite header compression, would it be better to also do something like "aggregation"? So for example if we were receiving a packet of 1500 bytes, which does not fit through a bat0 interface with an MTU of 1476, we could wait for a maximum of maybe 5ms for another packet and send a packet fragment of (1476 - (fragmentation information overhead)). A second packet fragment would be send with the rest of the first and the beginning of the second packet. Wouldn't that cause a lot less loss of throughput compared to splitting it in two packets of equal size as done in fragmentation in IPv4 (in fact, only the additonal fragmentation header overhead of a couple of bytes, especially in lossy environments like wifi, right?). Any concerns about such an approach?
Cheers, Linus