Hello,
Maybe I have missed/misunderstood something but I was wondering whether there is an underlying reason as to why the default MTU for IPv6 implementations (1280 B) is more than twice the default MTU for IPv4 (576 B)? Is there a reason behind such a difference?
As a follow up to this question, I wonder whether having a much higher default MTU for IPv6 may be an issue whenever we encapsulate IPv6 packets into IPv4 using, for instance, 6rd or 6 to 6 over 4? Since we encapsulate packets that are meant for applications with higher MTUs but send them over IPv4, it would seem to me that fragmentation is more likely to occur in such context.
Thank you very much for the clarification, I hope I am not mixing up too many concepts.
Simon
Fragmentation is a problem and sources should try to avoid it. With IPv4, we have to live with the existing equipment and there are some (rare) systems that do not support an MTU larger than e.g. 576B. The consequence is that apps have to estimate path MTU, which costs complexity and causes some occasional undesired fragmentations or losses. For example, a TCP app has the choice: do the simple thing and use the default MSS value that corresponds to an MTU of 576B (this is inefficient if you have large data to transfer) or estimate the path MTU. Because IPv4 is legacy, we live with it.
In contrast, the IETF decided that for IPv6 we should avoid the problem at the source by mandating that every IPv6 link should support at least 1280B. This makes sense because IPv6 is (perceived as) new. For example, if you design a new IoT device that uses IPv6 over a low power wireless technology that supports only small packet sizes, it is up to your data link layer to fragment your big IPv6 packet into several small link layer packets. If a fragment is lost, it is the wireless mac layer that must take care of fixing the problem. Then if you design a TCP app for IPv6 you can always use the default of 1280B; you can use path MTU estimation if you want to go beyond but the gain will not be large.
The value of 1280B was chosen to be safe even when there are multiples layers of encapsulation when the Ethernet packet offers an MTU of 1500B.
In contrast, the IETF decided that for IPv6 we should avoid the problem at the source by mandating that every IPv6 link should support at least 1280B. This makes sense because IPv6 is (perceived as) new. For example, if you design a new IoT device that uses IPv6 over a low power wireless technology that supports only small packet sizes, it is up to your data link layer to fragment your big IPv6 packet into several small link layer packets. If a fragment is lost, it is the wireless mac layer that must take care of fixing the problem. Then if you design a TCP app for IPv6 you can always use the default of 1280B; you can use path MTU estimation if you want to go beyond but the gain will not be large.
The value of 1280B was chosen to be safe even when there are multiples layers of encapsulation when the Ethernet packet offers an MTU of 1500B.
Great, thank you for the explanation!
