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

Bob Hinden <bob.hinden@gmail.com> Thu, 05 September 2019 22:40 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 222DC12004E; Thu, 5 Sep 2019 15:40:17 -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 UMZHIOX0iHxx; Thu, 5 Sep 2019 15:40:14 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 86C94120025; Thu, 5 Sep 2019 15:40:14 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id l16so4472150wrv.12; Thu, 05 Sep 2019 15:40:14 -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=KYXISUMPO1sNXhSKdiAqY6IQbFAWgaL09K/ghv6XQTs=; b=X1JEl+lLIpv9wq5dvm1M0CiLcIcRDx0ct4Y7InLgqWdt9cF50GbZgqk3ZasLYESwyP +DzSd4ql6QfoeEzCbJloEkoyEhyTTcLgbx882pS1vgYDKXgATNLXq+zzvOA0ivB/3/Ma BbWDiiwY+hIIudZ3MPHflILviSVc0qiFVp5L3WKFswAbQWXJBytpBw+qwREXm5Ke5pXI 0rgCki4cJvRKlh2non2+9oUDNPWuOdDFXkABD5GLu5H6YR54SDOYUHFMe6v+csoWlRyn vR1JWx/QX6Y+96TWeueCVK5JJJyVYvhtKG2BVSO+hElBxuP/m+3ZIIppJ4wNBcRoJ/0P it/A==
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=KYXISUMPO1sNXhSKdiAqY6IQbFAWgaL09K/ghv6XQTs=; b=srjSccPpzTsxyEzDnaBZQwmHRkwszcBkd/Eu4/mRuUgrw1iVaT8fw2jlMxrVl/UViv q6QpgdURzaMsSTqMjKi/R75DRRulbKFVXqZodMyEeyO7j8j1KrAy3v+iOtVPfajTZhsb zVY6//7SGWqVEbW0mJYdMe76Qz/tzI1MShK/GSpn2ji6fEiU8NgHBw0N/N80cecGR9Qq vXzEKwi4bLLTW2eBExUwU5DZWdrkTP+1Myf/8zWbSKs1t/RnFxE5fCAF0MIh+1XZPabE 04K5BlEh9JBdymJYo3n7qBwrklws1AxU9031aI7+5gmKLwkl2zjfTcV/aVQtonkoaHvM YLrQ==
X-Gm-Message-State: APjAAAX/ahXzaWjn+GEKn+rvbId2HDRzQdVb+vBsi4nW9KghfMxNQSdy n8rIx7tN85scWwINP7qWErA=
X-Google-Smtp-Source: APXvYqxjrP2HtHvpD54XQrFMchT1rbPi3FeK+5JaP+usvOeEGxfIlbb+CKb0VMdeDDzOGgivYMYPlg==
X-Received: by 2002:a5d:6648:: with SMTP id f8mr4314636wrw.167.1567723213066; Thu, 05 Sep 2019 15:40:13 -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 y13sm6874966wrg.8.2019.09.05.15.40.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Sep 2019 15:40:11 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <6E286D3A-F84E-4322-A5C8-F43617590652@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_CE6C6C4F-46A8-48A4-99A4-CBF01F351732"; 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 15:40:06 -0700
In-Reply-To: <CALx6S34e1X7y5koxmJXuOJKtJmeTHq2Q9FKX-71ZN=Q5LNBcWQ@mail.gmail.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: Tom Herbert <tom@herbertland.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> <CALx6S34e1X7y5koxmJXuOJKtJmeTHq2Q9FKX-71ZN=Q5LNBcWQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/ZN0Iw9xKpR9NBCq96_cqIg9TSko>
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 22:40:17 -0000

Tom,

> On Sep 5, 2019, at 12:53 PM, Tom Herbert <tom@herbertland.com> wrote:
> 
> On Thu, Sep 5, 2019 at 11:29 AM Bob Hinden <bob.hinden@gmail.com> wrote:
>> 
>> 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.
>> 
> Bob,
> 
> These two paragraphs seem somewhat contradicatory. For new protocols
> the recommendation is not to use fragmentation because we can't know
> whether the deployment allows that, but for legacy protocols we're
> allowed to use fragmentation if we know the deployment allows that.

I think the distinction is that it's hard to change legacy protocols and applications, but for new protocols and application, there is a choice to made and here we recommend that they not rely on fragmentation.   That seems clear to me.


> I think it's a lot simpler to just say that if you know fragmentation
> works in your environment or to some destination then you can use it,
> if not then you'll need to do something else. This applies equally to
> legacy protocols and new protocols, on the open Internet as well as
> limited domains. For that matter the rule applies pretty much to any
> protocol that might be considered "fragile" (note, this might just be
> a rewording of Joe's proposed text).

I think that an implementation can’t know fragmentation works in its environment, with out including some sort of mechanism to test it.   Legacy protocols and applications do what they do now, new protocols and application can either decide to not use fragmentation or include a mechanism in their design.

Bob


> 
> Tom
> 
> 
> 
>>   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