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

Bob Hinden <bob.hinden@gmail.com> Thu, 05 September 2019 19:33 UTC

Return-Path: <bob.hinden@gmail.com>
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 460CD120B2B; Thu, 5 Sep 2019 12:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dDVOz3AnrMvo; Thu, 5 Sep 2019 12:33:14 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A684D120B1F; Thu, 5 Sep 2019 12:33:13 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id k1so4088349wmi.1; Thu, 05 Sep 2019 12:33:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=br6nblE22KKw0/A2r2OrZj0cIwozwvAG4ygOqcm6xQM=; b=J23T0IU9TBwXUTmXp9SlCK7l+bJVBCgwxthmpAMzZpl1CxzOkbVqSRCQE/zahwCdEj /fKZY/blkyfAngBiGv+uBGP5UXWSLxURPlYknxnFyvSGTG2Y5em9PQu1Gz4/Fq0457Nm jENrnC36tfkLEcaoipNAJ8JVYhgtLhn4rdrqOGSRBv518Kxbt7O6KHBkcBQkODRELGIl mJ5FFiZk+GlCWh7AMxkIYVHLarQ3H2hZaWlgijOmhheOmIR2V2CWn7baD+sARc+Xg/Rc Xb53o9zJ+oVZG1v17zesFJ9D4XJNHdHFCWIff4H6/Cay7KFVke0dWSCen43Q1+ZHNr3B P59w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=br6nblE22KKw0/A2r2OrZj0cIwozwvAG4ygOqcm6xQM=; b=MCywt8lS8iVg0kmSXURFRfyoGe30SD/i4ZDHq8tvxHVpN23urMMSVVxyoUZa/LHL9b HiSbBCoHVkJKFR7rZUYHhlrswBid3epM8LBDy9ukT3xOjlR5DOYyXnNGT6aSllke/nBZ yEIYMolxJJTmAzDW/bxUOYp1MoJbGTdw4zOz2rD4b0LakVNByRh72JlpYOZr1z8D5mRk mgUECZdgMxvlM+rP0ef+oxEyBgkVH99EHM/yCsO0FUANXuIc5/bdbOLjYne+/wXepoMW n+4KLjd8jtFON8QoC2InfI/y8ijJLTNS5z614yir9g6Lw3O9PZRdTKGyXs2jo2GestFj Th+w==
X-Gm-Message-State: APjAAAVEJalSp6slJWxRWyPij6id2quQeff6v1akZWSc2AnnRJLKacL5 sdNeOxBBO58P+vTjeOL/d0Y=
X-Google-Smtp-Source: APXvYqyHv/3trh/CN9sbiWvh1sY+gLIEdtD6473B3+MlA0nRhRTAnB6I0F0tp6fM173yCTvFTVnbCg==
X-Received: by 2002:a1c:7407:: with SMTP id p7mr4529918wmc.31.1567711992058; Thu, 05 Sep 2019 12:33:12 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:f954:34b0:ff7a:6463? ([2601:647:5a00:ef0b:f954:34b0:ff7a:6463]) by smtp.gmail.com with ESMTPSA id 12sm3204909wmi.34.2019.09.05.12.33.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Sep 2019 12:33:11 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <8E1A6788-AE6D-41D5-B124-9653CD0FCE8D@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_ADABF9F4-1CE3-4FBC-8600-BE7B545FBE3C"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 05 Sep 2019 12:33:06 -0700
In-Reply-To: <b756262692d54930896218abc8316926@boeing.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, "int-area@ietf.org" <int-area@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>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
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> <b756262692d54930896218abc8316926@boeing.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/a_mos-Z9rKtBPaqiOvu7AnKRhgw>
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: Thu, 05 Sep 2019 19:33:17 -0000

Fred,

> On Sep 5, 2019, at 11:57 AM, Templin (US), Fred L <Fred.L.Templin@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.

Bob


> 
> Thanks - Fred
> 
>> -----Original Message-----
>> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Bob Hinden
>> Sent: Thursday, September 05, 2019 11:29 AM
>> To: int-area@ietf.org
>> Cc: IESG <iesg@ietf.org>; Joel Halpern <joel.halpern@ericsson.com>; draft-ietf-intarea-frag-fragile@ietf.org; Suresh Krishnan
>> <suresh@kaloom.com>; intarea-chairs@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].
>