Fred, >> Why is that more useful than what is in 3.5? If it’s not making a >> recommendation, why call this out in the introduction. There are lot of >> other things it doesn’t make recommendations about that aren’t in the >> Introduction either. > > Because it sets a more appropriate tone and lets the reader know from the > onset that > fragmentation and encapsulation go hand in hand. And tunnel fragmentation > avoids the > issues raised by others in this thread.
While inner fragmentation ensures the fragment will reach the tunnel tail end, a tunnel endpoint will typically not reassemble that fragment, so will generate fragments after the tunnel hop. Inner fragmentation is only available on IPv4. Outer fragmentation will look like any other fragmented packet, albeit that the tunnel tail now has to reassemble. At speeds typically much higher than a typical end host. Tunnels within a controlled domain may use fragmentation, although it still will have problems. Which is why you see most tunnel specifications for controlled domains, state that the network MTU must be "well managed". In summary, I don't think the text can say very much more than what it already does. Cheers, Ole _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
