Joe, > Comments below. > >> On Sep 5, 2019, at 11:33 PM, Ole Troan <otr...@employees.org> wrote: >> >> Bob, et al, >> >> I have two issues with this text. >> >> 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? I thought PLPMTUD found the largest unfragmented size of a datagram. >> 2) Paragraph 4: >> "The risks of IP fragmentation can also be mitigated >> through the use of encapsulation, e.g., by transmitting IP fragments >> as payloads." >> >> This seems like proposing new unspecified solutions with it's own set >> of considerations. > > Specific widely-deployed methods are mentioned elsewhere in the doc, > including GRE and UDP. Sorry, I couldn't find those either. Inner fragmentation, firstly is only applicable to IPv4. And only applicable to tunnels. And both those specs go to great length in avoiding fragmentation. >> IP fragmentation is a general solution to all hosts, >> encapsulation is certainly not in every host, > > Actually, it is - unless you’re claiming hosts don’t support UDP. Sorry, I don't understand what you mean. Are you saying that a new UDP applications should support the following stack: IPv6 + UDP + IPv6 + FH + UDP + Applcation data So to be able to hide IP fragments from the network? While still having to do the full PLPMTUD to function correctly? >> and has different >> properties with regards to NAT traversal etc. > > If by “different” you mean “much more likely to succeed”, agreed. I need to see numbers of that. But regardless I don't see the relevance to this document. >> vAlso if encapsulation >> was the answer, other segmentation / reassembly that were tunnel >> specific could be developed. > > It is and is widely used - IPsec tunnels over UDP, e.g. That's a encapsulated solution to start with. >> Regardless this also amounts of hand-waving >> and doesn't seem to offer any advice that can be heeded now. >> And of course encapsulation can also exacerbate the problem >> by increasing packet size. > > Yes, it makes the fragments smaller, which may be additional > effort/performance impact, but it completely hides its impact on successful > forwarding. You may be making a point. I'm afraid I don't get it. Cheers, Ole _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
