This new text from Bob and Joe's discussion looks good to me. > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of Bob Hinden > Sent: Thursday, September 05, 2019 9:05 PM > To: [email protected] > Cc: Ron Bonica <[email protected]>; IESG <[email protected]>; > Joel Halpern <[email protected]>; draft-ietf- > [email protected]; Suresh Krishnan <[email protected]>; > [email protected] > Subject: Re: [Int-area] Discussion about Section 6.1 in > draft-ietf-intarea-frag-fragile > > Hi, > > Joe and I talked off list. The result is below. Changes were to add a > sentence in the forth and fifth paragraphs. > > Please review. > > 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). Applications and protocols cannot necessarily > know or control whether they use lower layers or network paths that > rely on such fragmentation. 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). The risks of IP fragmentation can also be mitigated > through the use of encapsulation, e.g., by transmitting IP fragments > as payloads. > > UDP applications SHOULD abide by the recommendations stated in > Section 3.2 of [RFC8085]. > > ————— > > > > > On Sep 5, 2019, at 6:18 PM, Joe Touch <[email protected]> wrote: > > > > Although this is close, it misses the mark a little on the issue that > > the app may not actually have any control here - or know how or when to > > reduce its MTU. That might be a minor point to add, but is worth adding. > > This isn't just an app layer issue. > > > > Joe > > > > On 9/5/2019 4:45 PM, Ron Bonica wrote: > >> Bob, > >> > >> I think that this is a close to consensus as we are going to get. > >> > >> Ron > >> > >> > >> Juniper Business Use Only > >> > >> -----Original Message----- > >> From: Bob Hinden <[email protected]> > >> Sent: Thursday, September 5, 2019 2:29 PM > >> To: [email protected] > >> Cc: Bob Hinden <[email protected]>; Alissa Cooper <[email protected]>; > >> IESG <[email protected]>; Joel Halpern > <[email protected]>; [email protected]; > [email protected]; Suresh Krishnan > <[email protected]> > >> Subject: 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
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
