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

Tom Herbert <tom@herbertland.com> Thu, 05 September 2019 19:53 UTC

Return-Path: <tom@herbertland.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 7407C120B34 for <int-area@ietfa.amsl.com>; Thu, 5 Sep 2019 12:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 6CvnDTLoOEBj for <int-area@ietfa.amsl.com>; Thu, 5 Sep 2019 12:53:14 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 E86EE120B74 for <int-area@ietf.org>; Thu, 5 Sep 2019 12:53:13 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id a23so1740447edv.5 for <int-area@ietf.org>; Thu, 05 Sep 2019 12:53:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RvSWF6vTG7bbxHuQHJQh6Y/OVlWlIjmARDYCe6RRJnE=; b=ZEQ0pN4hTL3QbWdzPszoIjZxTs3ebj57WHZSHNsfZ5gyDr0xVtr6sY09cZ2/fTsthN cekz1zc5hfxO2UcdqdlgJp/p6UA+uKvab0DgX/YxYCToA0yXm1UUt71O04L7RsFppqco ++3TBrDZoy/2n3If29j5QkHt9pLo8sqQpxbfDCEZO9LC9FcH+mrbmo4LbZl31I2+2IU7 VudlZ42ybNoBJSmIZsol/OrFNQrZWueFcfEsbeiXjG6LZwUVMghYppQYrr+8VlOTn9HF C0T/2aQvphZ/jDqs8PW8HCkNRtN03MC0hyZ6o/PT8sCMwD6VDFBuqMDzrHDDbS7449eX lP7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RvSWF6vTG7bbxHuQHJQh6Y/OVlWlIjmARDYCe6RRJnE=; b=fo/XqXbKblDCpTd2piEdmo9xNKEvod75PkgUay5ryuLGNOh/7JQnY7LUCJ9KktBBjW zVUV2kjy+kju3GgT8XjZuXA6rFfSZi2XYj0K7NtNJuWMFpVPBj2QNxYM4fL+r8CYzNkb 6Df9zjLk3NTQ5ups7QIcAvonikMRnW6/9Xu3vezNSbZGdQnxnMZsg3VnYBIizue+IABA 7pb1PgPgnnWK5M6bK5NQQyVplymw0Zm56MD+bMhIS7G6YS8oKzxbgXJgJDNgWE7NV8BA hyLG6AzzWEfV6SnTHiQCzxEqF7rO3LiMw8PJYR/Mn2oJrXavPdriJWUtJNf7wXLV0ZZm ozmA==
X-Gm-Message-State: APjAAAVO+f1Z7ZZ4W3+KtL62xheO/OIkFhGxMUxIz0Ke69BZ2o+M5Zcn fkK+VqxknyrkAvvkMbzg7YuNZ48qG6gA5PvXZrmbKw==
X-Google-Smtp-Source: APXvYqyb/S7AvExFzVPI7PWfApGx7MKqr575RZLIFljpY9KXxDY+uJ7AxBvBkkheTCxfhVrmhh/yNqb+RkL76mOotkQ=
X-Received: by 2002:a05:6402:1511:: with SMTP id f17mr5687550edw.226.1567713192396; Thu, 05 Sep 2019 12:53:12 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <4C8FE1C4-0054-4DA1-BC6E-EBBE78695F1B@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 05 Sep 2019 12:53:01 -0700
Message-ID: <CALx6S34e1X7y5koxmJXuOJKtJmeTHq2Q9FKX-71ZN=Q5LNBcWQ@mail.gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>
Cc: "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>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/ozCTtwnSVMNucP5WF0kWlwUO3Os>
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:53:25 -0000

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

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