Joe, edited to focus on the two added "recommendation sentences".
>>>> 1) It introduces something new and undescribed in paragraph 2. >>>> "unless they also include mechanisms to detect that IP fragmentation isn't >>>> working >>>> reliably." >>>> That seems like hand-waving to me. Suggest deleting. >>> >>> Fragmentation success or failure is directly testable. Any feedback >>> mechanism will work and specific ones are mentioned elsewhere (PLPMTUD). >>> >>> This differs from ICMP black-holing in path MTU detection. >> >> Can you please point me to where in the PLPMTUD document testing for IP >> fragmentation is described? > > Any feedback mechanism will detect when fragmentation - or anything else - > prevents delivery. Any pointer to such a mechanism in any IETF protocol? Would be interesting to get transport/application perspective on this. But unless there is a reference I would claim this is hand-waving. [...] > If you fragment and put the result inside GRE or UDP, the impact of the > fragment (interfering with flow-based multi path routing, nat traversal, etc) > is overcome. 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. 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. This document should not recommend IP in UDP in IP encapsulation to achieve end to end IP fragmentation for new applications. If this paragraph has to be there it would be more accepting to have it in the "Legacy protocols" parapgraph above. 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 Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
