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

Bob Hinden <bob.hinden@gmail.com> Thu, 05 September 2019 18:29 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 C3CB5120ABB; Thu, 5 Sep 2019 11:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 ClavYgEumOLp; Thu, 5 Sep 2019 11:29:05 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 AC250120119; Thu, 5 Sep 2019 11:29:04 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id y8so3890860wrn.10; Thu, 05 Sep 2019 11:29:04 -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=jHH09fH5eesNBw48gr9m6rU2Qz92aMBD4ZO7SChkHl0=; b=mNe4jJNnOwebFcsF6JD32KC85GrKO+oz6V0kJSMBpq92uIfNrInWqMqnTSDkh98II1 F01pw4hH9UssGr8CWuXcvYEZ4Fuqh5g2Lmw5xb+F60t37UxxZFaU4G/vR++6E2olbF+C OUIpk/jlE8M4m3aSZ5zjUIVMkWEHAbGMymxdoyghG0Pa+TbW7JY42RaeiSIfBwpWVhIT ZaI1MsGx/p2bmMv2SZjma6JTnX52ZTEKNLF+uONl4bxCSUhApV7vWiFVdVTBXwDYFiEX /UvtsCh6C5ozzGD0Y+Qs+AS1CjdTtBkO3JOpPrjLq9xpQEnNmy2jhXSVUgcBvEpcYsO0 c4dw==
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=jHH09fH5eesNBw48gr9m6rU2Qz92aMBD4ZO7SChkHl0=; b=jyELUB0S+0iUSihxlmBMwo8hJB9TBM0W/QKyy3IAwfv0BtO60GwHtd08nBo09k0e8L lwogXHXxWt8t6fArO4T4RPQvHe+6G1Rja58vJ2j5QndsCLg1tMCs06Xsg2mnRFLx8zXf XauIm9ACzPtU2FUbzalMvCr6/LqfPZvBF19FhtGGwASYBY//WrJcmIcQcOlzCTEJpYyl 69P8QYls9MvOq1zAA5fYRVly6gwBoRYkaiTQMc+NjO6EP9hyL3jP+qDrzWd856UaPz3m ++T0lnKdl3luwgLJhPhkYAqxsXSpJKEcmjgWWRuu01wWhKW2e+X6Cuk40iVhnpKkgzW2 bXog==
X-Gm-Message-State: APjAAAUmA0M4oR43AIfNjTpQ2yJ/eJyfndRoFZeSV21WHXoNy6H4vAod xjYMls7uULmCDKS3uDw3tYDSdAL4
X-Google-Smtp-Source: APXvYqw2nykdM7TfHtWnkgUasIkHcOr0qjF12aHuOpEFLnP8+v0FBZznmWIQlersd72eYCEPtx9xvQ==
X-Received: by 2002:adf:e485:: with SMTP id i5mr3694549wrm.175.1567708142769; Thu, 05 Sep 2019 11:29:02 -0700 (PDT)
Received: from [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id t13sm5552114wra.70.2019.09.05.11.29.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Sep 2019 11:29:02 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <4C8FE1C4-0054-4DA1-BC6E-EBBE78695F1B@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_68BC1882-62B5-4300-B82D-F129D48AF21A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 5 Sep 2019 11:28:57 -0700
In-Reply-To: <CAHw9_iKozCAC+8TGS0fSxVZ_3pJW7rnhoKy=Y3AxLqWEXvemcA@mail.gmail.com>
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" <draft-ietf-intarea-frag-fragile@ietf.org>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>, Suresh Krishnan <suresh@kaloom.com>
To: "int-area@ietf.org" <int-area@ietf.org>
References: <efabc7c9f72c4cd9a31f56de24669640@boeing.com> <2EB90A57-9BBD-417C-AEDB-AFBFBB906956@gmail.com> <CAHw9_iKozCAC+8TGS0fSxVZ_3pJW7rnhoKy=Y3AxLqWEXvemcA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/fqcCmn5p4JmUsK02zTPWyv0Nt-s>
Subject: [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 18:29:07 -0000

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].