On Tue, Sep 3, 2019 at 5:20 PM Bob Hinden <[email protected]> wrote: > > Tom, > > > On Sep 3, 2019, at 2:20 PM, Tom Herbert <[email protected]> wrote: > >> > >> 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. > > > > Bob, I don't understand this change. The old text had a normative > > requirement (a MAY), but the new paragraph doesn't include any > > normative requirements. Why? It seems like the WG had come to > > consensus on the previous text, but the new text is substantially > > different beyond just being an edit. > > The change was made to resolve an IESG Discuss. > > The first paragraph is still normative and covers the second paragraph. > SHOULD NOT and MAY are related. The second paragraph describes the > controlled environment case in more detail. > > The text in -15 > > Developers MAY develop new protocols or applications that rely on IP > fragmentation if the protocol or application is to be run only in > environments where IP fragmentation is known to be supported. > > This isn't workable. How can a developer possibly know what environment the > code is going to be running in? For example, when code is checked into a > Linux distribution, how would the developer know where it is going to be > running and IP fragmentation is works reliably?
Bob, Linux kernel has supported fragmentation for more than twenty years. If a packet length not marked with DF exceeds MTU it will be fragmented. That's the default behavior and it is in deployment for a long time. I don't see any bug here, nor any reason to change the host implementation. The bug related to fragmentation seems to be that some non-conformant middleboxes don't properly handle fragments. IMO, the draft misses an opportunity to influence the change needed to fix this. In regards to the changes in the latest version of the draft, Joe had previoulsy suggested the following alternate text: “The Internet is a best-effort system and lacks a formal validation or conformance mechanism. Like any other protocol feature, IP fragmentation is useful only when it actually works - both by successfully traversing routers and other in-network devices and when it is correctly supported by endpoints. As a consequence, like any other protocol feature, IP fragmentation MAY be used by new protocols that validate its successful traversal and provide an alternate as a backup.” It seemed like this proposed text was positively received on this list and there wasn't any pushback to it. Is inclusion of this text still under consideration? Thanks, Tom > > Bob > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
