Bob, > -----Original Message----- > From: Bob Hinden [mailto:[email protected]] > Sent: Thursday, September 05, 2019 12:33 PM > To: Templin (US), Fred L <[email protected]> > Cc: Bob Hinden <[email protected]>; [email protected]; IESG > <[email protected]>; Joel Halpern <[email protected]>; draft- > [email protected]; Suresh Krishnan <[email protected]>; > [email protected] > Subject: Re: [Int-area] Discussion about Section 6.1 in > draft-ietf-intarea-frag-fragile > > Fred, > > > On Sep 5, 2019, at 11:57 AM, Templin (US), Fred L > > <[email protected]> wrote: > > > > Bob, > > > > Your effort is appreciated, but IMHO does not quite go far enough. Here is > > a proposed edit: > > Thanks! > > > > > OLD: > > Protocols and applications that rely on IP > > fragmentation will work less reliably on the Internet unless they > > also include mechanisms to detect that IP fragmentation isn't working > > reliably. > > > > NEW: > > Protocols and applications that rely on IP > > fragmentation will work less reliably on the Internet unless they > > also include mechanisms to detect that IP fragmentation isn't working > > reliably, or encapsulate their fragments in protocol headers that can > > traverse fragment-dropping middleboxes. > > I am not sure we want or should add specific mechanisms here. Encapsulation > is one approach, but there are others.
s/encapsulate/disguise ? Fred > > Bob > > > > > > Thanks - Fred > > > >> -----Original Message----- > >> From: Int-area [mailto:[email protected]] On Behalf Of Bob Hinden > >> Sent: Thursday, September 05, 2019 11:29 AM > >> To: [email protected] > >> Cc: IESG <[email protected]>; Joel Halpern <[email protected]>; > >> [email protected]; Suresh Krishnan > >> <[email protected]>; [email protected] > >> Subject: [Int-area] Discussion about Section 6.1 in > >> draft-ietf-intarea-frag-fragile > >> > >> Hi, > >> > >> Based on the discussion, I would like to propose to see if this will > >> resolve the issues raised. It attempts to cover the issues raised. > >> > >> The full section 6.1 is included below, but only the last sentence in the > >> second paragraph changed. > >> > >> Please review and comment. > >> > >> Thanks, > >> Bob > >> > >> > >> > >> 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 work less reliably on the Internet unless they > >> also include mechanisms to detect that IP fragmentation isn't working > >> reliably. > >> > >> 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). 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. > >> > >> Protocols may be able to avoid IP fragmentation by using a > >> sufficiently small MTU (e.g. The protocol minimum link MTU), > >> disabling IP fragmentation, and ensuring that the transport protocol > >> in use adapts its segment size to the MTU. Other protocols may > >> deploy a sufficiently reliable PMTU discovery mechanism > >> (e.g.,PLMPTUD). > >> > >> UDP applications SHOULD abide by the recommendations stated in > >> Section 3.2 of [RFC8085]. > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
