On Thu, Sep 5, 2019 at 11:33 PM Ole Troan <[email protected]> wrote: > > Bob, et al, > > I have two issues with this text. > > 1) It introduces something new and undescribed in paragraph 2. > "unless they also include mechanisms to detect that IP fragmentation isn't > working > reliably." > That seems like hand-waving to me. Suggest deleting. > > 2) Paragraph 4: > "The risks of IP fragmentation can also be mitigated > through the use of encapsulation, e.g., by transmitting IP fragments > as payloads." > > This seems like proposing new unspecified solutions with it's own set > of considerations. IP fragmentation is a general solution to all hosts, > encapsulation is certainly not in every host, and has different > properties with regards to NAT traversal etc. Also if encapsulation > was the answer, other segmentation / reassembly that were tunnel > specific could be developed. Regardless this also amounts of hand-waving > and doesn't seem to offer any advice that can be heeded now. > And of course encapsulation can also exacerbate the problem > by increasing packet size. > Suggest deletion. > Ole,
This also makes the implicit and seemingly unproven assumption that encapsulation is less fragile than IP fragmentation on the Internet. Without the data that shows otherwise, I don't believe there is any basis to say that encapsulation is generally a viable alternative. Also, I would note that there was similar text in early versions of RFC8200 that encapsulation could be used as a method of allowing extension header insertion. That text was taken out because encapsulation is not sufficiently standardized or ubiquitous to be considered a direct replacement for an IP network layer protocol function. The same is true here, encapsulation is not a drop-in replacement for IP fragmentation. Tom > New text: > > 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. > > 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). > > UDP applications SHOULD abide by the recommendations stated in > Section 3.2 of [RFC8085]. > > > Cheers, > Ole > > > On 6 Sep 2019, at 06:05, Bob Hinden <[email protected]> wrote: > > > > 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 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
