Bob, > -----Original Message----- > From: Bob Hinden [mailto:bob.hin...@gmail.com] > Sent: Thursday, September 05, 2019 12:33 PM > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > Cc: Bob Hinden <bob.hin...@gmail.com>; int-area@ietf.org; IESG > <i...@ietf.org>; Joel Halpern <joel.halp...@ericsson.com>; draft- > ietf-intarea-frag-frag...@ietf.org; Suresh Krishnan <sur...@kaloom.com>; > intarea-cha...@ietf.org > 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 > > <fred.l.temp...@boeing.com> 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:int-area-boun...@ietf.org] On Behalf Of Bob Hinden > >> Sent: Thursday, September 05, 2019 11:29 AM > >> To: int-area@ietf.org > >> Cc: IESG <i...@ietf.org>; Joel Halpern <joel.halp...@ericsson.com>; > >> draft-ietf-intarea-frag-frag...@ietf.org; Suresh Krishnan > >> <sur...@kaloom.com>; intarea-cha...@ietf.org > >> 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 Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
