Ole, > Sure, but that only applies to tunnels that go end to end. And any > development of new tunnel mechanisms don't need to depend on > IP fragmentation.
All existing and future tunneling mechanisms that do not use IP fragmentation work only due to the good luck that most link sizes in the Internet are on the order of 1500. But, the only true guarantee is 1280 so the only true way to guarantee that the tunnel can support 1280 after encapsulation is to apply fragmentation before encapsulation. > This is essentially link-layer (the tunnel provides a new link layer) > fragmentation and reassembly. > It would anyway have to do that to deal with IPv4 DF=1 and IPv6. It is RFC8200-standard IPv6 fragmentation. > This document should not recommend IP in UDP in IP encapsulation to achieve > end to end IP fragmentation for new applications. "Encapsulation" does not necessarily mean IP-in-UDP-in-IP - it could be IP-in-foo-in-IP. And again, the only true way to ensure that packets will traverse a path is to limit their size to no more than 1280, and the only true way to achieve that when the original packet size cannot be reduced is through fragmentation. > If this paragraph has to be there it would be more accepting to have it in > the "Legacy protocols" parapgraph above. Not for legacy protocols - for the future of the Internet. Thanks - Fred > Legacy protocols that depend upon IP fragmentation SHOULD be updated > to break that dependency. However, in some cases, there may be no > viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP- > in-IP encapsulation). Applications and protocols cannot necessarily > know or control whether they use lower layers or network paths that > rely on such fragmentation. In these cases, the protocol will > continue to rely on IP fragmentation but should only be used in > environments where IP fragmentation is known to be supported. > The risks of IP fragmentation can also be mitigated > through the use of encapsulation, e.g., by transmitting IP fragments > as payloads. > > Cheers, > Ole > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
