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

Ole Troan <otroan@employees.org> Fri, 06 September 2019 06:33 UTC

Return-Path: <otroan@employees.org>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350AD120130; Thu, 5 Sep 2019 23:33:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xv2YOoSyI2n4; Thu, 5 Sep 2019 23:33:35 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D3C12002E; Thu, 5 Sep 2019 23:33:35 -0700 (PDT)
Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 6C96D4E11B38; Fri, 6 Sep 2019 06:33:34 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id F0C401BA8186; Fri, 6 Sep 2019 08:33:31 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <E770BEF0-D901-4CD0-96E6-C626B560DCD6@gmail.com>
Date: Fri, 06 Sep 2019 08:33:31 +0200
Cc: "int-area@ietf.org" <int-area@ietf.org>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, IESG <iesg@ietf.org>, Joel Halpern <joel.halpern@ericsson.com>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, Suresh Krishnan <suresh@kaloom.com>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>, Joe Touch <touch@strayalpha.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <163CD364-2975-467A-8925-F114FFD9C422@employees.org>
References: <efabc7c9f72c4cd9a31f56de24669640@boeing.com> <2EB90A57-9BBD-417C-AEDB-AFBFBB906956@gmail.com> <CAHw9_iKozCAC+8TGS0fSxVZ_3pJW7rnhoKy=Y3AxLqWEXvemcA@mail.gmail.com> <4C8FE1C4-0054-4DA1-BC6E-EBBE78695F1B@gmail.com> <BYAPR05MB5463F112A3FFA8CE6378F3D3AEBB0@BYAPR05MB5463.namprd05.prod.outlook.com> <ab0d5600-d71c-9f0b-2955-64074e040bc6@strayalpha.com> <E770BEF0-D901-4CD0-96E6-C626B560DCD6@gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/Zvo34f0xUpc4tthEd9UkBd75Ngk>
Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2019 06:33:39 -0000

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.

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 <bob.hinden@gmail.com> 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 <touch@strayalpha.com> 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 <bob.hinden@gmail.com>
>>> Sent: Thursday, September 5, 2019 2:29 PM
>>> To: int-area@ietf.org
>>> Cc: Bob Hinden <bob.hinden@gmail.com>; Alissa Cooper <alissa@cooperw.in>; IESG <iesg@ietf.org>; Joel Halpern <joel.halpern@ericsson.com>; draft-ietf-intarea-frag-fragile@ietf.org; intarea-chairs@ietf.org; Suresh Krishnan <suresh@kaloom.com>
>>> 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
>>> Int-area@ietf.org
>>> https://www.ietf.org/mailman/listinfo/int-area
>