Joe, > On Aug 30, 2019, at 4:36 PM, Joe Touch <[email protected]> wrote: > > Hi, all, > > I disagree with the changes indicated in this version. > > The new text is both incorrect does not IMO reflect WG consensus. > > It is simply false that "it WILL break" or "new protocols can't possibly know > whether fragmentation works" - you even cite studies where this works the > majority of the time (failing 37% for IPv6 DNS resolvers is succeeding 63%). > This is not the same as ICMP-based MTU discovery. Users absolutely can test > and know this. > > I repeat my previous suggestion with caps for emphasis- that, LIKE ALL > PROTOCOLS AND FEATURES IN THE INTERNET, IP fragmentation is not guaranteed to > work on any given path and should be confirmed before being relied upon.
The relevant text in -16 is: 6.1. For Application and Protocol Developers Developers SHOULD NOT develop new protocols or applications that rely on IP fragmentation. When a new protocol or application is deployed in an environment that does not fully support IP fragmentation, it SHOULD operate correctly, either in its default configuration or in a specified alternative configuration. While there may be controlled environments where IP fragmentation works reliably, this is a deployment issue and can not be known to someone developing a new protocol or application. It is not recommended that new protocols or applications be developed that rely on IP fragmentation. Protocols and applications that rely on IP fragmentation will fail to work on the Internet. The text in the first paragraph is unchanged in this version of the draft and has been there for awhile. The recommendation is still SHOULD NOT. This does allow other usage if there is a good reason to do so. The new second paragraph (written to resolve the DISCUSS comment) attempts to discuss the the controlled environment case. It clearly states it is a recommendation (along the lines of the SHOULD NOT) in the first paragraph and explains why. Note, personally I think, citing your case of failing 37% of the time, is consistent with “will fail to work on the Internet”. Also, isn’t this the reason why this draft exists, that is fragmentation is fragile. I hope this helps to explain the change. Thanks, Bob > > Joe > > > On 2019-08-30 14:31, [email protected] wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Internet Area Working Group WG of the IETF. >> >> Title : IP Fragmentation Considered Fragile >> Authors : Ron Bonica >> Fred Baker >> Geoff Huston >> Robert M. Hinden >> Ole Troan >> Fernando Gont >> Filename : draft-ietf-intarea-frag-fragile-16.txt >> Pages : 28 >> Date : 2019-08-30 >> >> Abstract: >> This document describes IP fragmentation and explains how it >> introduces fragility to Internet communication. >> >> This document also proposes alternatives to IP fragmentation and >> provides recommendations for developers and network operators. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-16 >> https://datatracker.ietf.org/doc/html/draft-ietf-intarea-frag-fragile-16 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-frag-fragile-16 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
