Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

["Templin (US), Fred L" <[e-mail]>]

This new text from Bob and Joe's discussion looks good to me.

> -----Original Message-----
> From: Int-area [mailto:[e-mail]] On Behalf Of Bob Hinden
> Sent: Thursday, September 05, 2019 9:05 PM
> To: [e-mail]
> Cc: Ron Bonica <rbonica=[e-mail]>; IESG <[e-mail]>; Joel Halpern <[e-mail]>; draft-ietf-
> [e-mail]; Suresh Krishnan <[e-mail]>; [e-mail]
> 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 <[e-mail]> 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 <[e-mail]>
> >> Sent: Thursday, September 5, 2019 2:29 PM
> >> To: [e-mail]
> >> Cc: Bob Hinden <[e-mail]>; Alissa Cooper <[e-mail]>; IESG <[e-mail]>; Joel Halpern
> <[e-mail]>; [e-mail]; [e-mail]; Suresh Krishnan
> <[e-mail]>
> >> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/int-area