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

Fred Baker <fredbaker.ietf@gmail.com> Fri, 13 September 2019 19:20 UTC

Return-Path: <fredbaker.ietf@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 2D84F120105; Fri, 13 Sep 2019 12:20:00 -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 5WUrsUbiLNMR; Fri, 13 Sep 2019 12:19:58 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 2253A1200FA; Fri, 13 Sep 2019 12:19:58 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id o18so1917529wrv.13; Fri, 13 Sep 2019 12:19:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JtJKSzmGAkfhI/hU/GAj89EbmBWXWdFT0CnhYK+iT84=; b=OzixOFlXaBShg3/369B/txB0dln87vb1duyBt9eSg3yYRLL0r3iAPXzP1olV17f7qp ea4b8Wvd0jKT40OOudWtBE7NizwuBrJeRa8fzAQLc4dGYz4dKj9xzKx6tgvdiUBBBRfJ eDE4fK/3sgFZ6rMT19D6D4x/ZnBhUgF9YbIZbil0Xj+mEeT7d7Uf1UaCGH8Bh3O4qmpb PvpL/ZmQtDw0Eq+senJLs1qeDq+u2X7QKL8jr2W+fbC20EuRzO8aFjyrcl1YjtRhz2fl nlI1bT6cetSrHjEv6ALnHaH9HvxvjHwvMNJPM3lqta2V0PU5YSpiFhYxGOIj1B8bRini XxOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JtJKSzmGAkfhI/hU/GAj89EbmBWXWdFT0CnhYK+iT84=; b=R21yLKxLBmjBKOhkludpQVo9PgpjsodjqJliU8rVhQtAbY0+8feSq2QidS1iEaJRo6 zQzyExEj3fscojtztf3PBURelixG2P+iDY5p01tOWdKNPjnLL06jlpqePmGVLXrRy9Lv tu7dgyG93vKwyRpOdc+QwKG/aqdLAMXG/B6aF8GuZhcLjTYMc5IftEyVjvU9zDk0p54q E1ZpbWa2QlqXw3QTAB1nruHsr/qykQWlUtWLy0aSnaussEoutXlMcHBnIN7Lwf11/YIX rAu/aPnfx7PHjYPSxHhbx1CeHYhi4bfuZMLaowMuQHQXPKuVDU1TNeEHUks6BqxUViGz 95yA==
X-Gm-Message-State: APjAAAW5f8bdMxkILBfiLWJYYRfs9AgHhecRAMdqOgc6HqcsJ8pHS7Qc D4LQZYn0w5pte4abwLHma3g=
X-Google-Smtp-Source: APXvYqyN6ACSnZSBx++ih0bS4zq+g+bIpWh/TbU+a2g9e29KNm4ZYxWyTA4AMzbP3cskU5LEiUE7Dg==
X-Received: by 2002:adf:dd4d:: with SMTP id u13mr8900560wrm.112.1568402396628; Fri, 13 Sep 2019 12:19:56 -0700 (PDT)
Received: from [192.168.1.31] ([176.232.184.174]) by smtp.gmail.com with ESMTPSA id e6sm3173204wrp.91.2019.09.13.12.19.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Sep 2019 12:19:55 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.2\))
From: Fred Baker <fredbaker.ietf@gmail.com>
In-Reply-To: <614FEA1D-B044-4282-9F45-50ED4FD3695F@strayalpha.com>
Date: Fri, 13 Sep 2019 22:19:52 +0300
Cc: Geoff Huston <gih@apnic.net>, Fred Templin <Fred.L.Templin@boeing.com>, Fernando Gont <fgont@si6networks.com>, Bob Hinden <bob.hinden@gmail.com>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, IESG <iesg@ietf.org>, Suresh Krishnan <suresh@kaloom.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A0AD4E6C-DC30-46E1-8905-32C2799DA076@gmail.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> <BYAPR05MB5463F112A3FFA8CE6378F3D3AEBB0@BYAPR05MB5463.namprd05.prod.outlook.com> <ab0d5600-d71c-9f0b-2955-64074e040bc6@strayalpha.com> <E770BEF0-D901-4CD0-96E6-C626B560DCD6@gmail.com> <163CD364-2975-467A-8925-F114FFD9C422@employees.org> <E00B6159-2771-42D8-B5E8-7750E0B828DE@strayalpha.com> <3764D860-BC6F-441A-86EF-59E1742D7654@employees.org> <939AFA6F-4C75-4532-82DE-77D14ABC41ED@strayalpha.com> <5C51DCDC-4031-47D9-A28E-812D0E66EE35@employees.org> <5DAA16CC-791E-4042-95F6-65DA58D23EB8@gmail.com> <EA3B45A1-FFD2-49A5-B577-602065632F41@strayalpha.com> <5d22dd34-3972-060e-ddc1-b7f27a110a69@si6networks.com> <14f06217149d40ba8a41865ebb08ee08@boeing.com> <91894E0E-09D3-42E4-B6C4-88AE4493D796@apnic.net> <614FEA1D-B044-4282-9F45-50ED4FD3695F@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3594.4.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/k00xn6VGMoyIwcsChYBdQ2aB92Q>
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, 13 Sep 2019 19:20:00 -0000


> On Sep 11, 2019, at 7:50 AM, Joe Touch <touch@strayalpha.com> wrote:
> 
> Second, the problem with the logic that “bigger avoids fragmentation” is that the very specification of ANY minimum MTU, coupled with IP-in-IP tunnels (for their own sake, or as part of IPsec tunnel mode), ends up then requiring fragmentation. There’s no way around that - once there’s a required minimum and once it’s recursive, the game is over.

Indeed.

My perception is that the larger the difference between the packet size sent and the smallest link MTU the packet will encounter, the lower the probability that the packet will get fragmented in flight - in IPv4 - or will result in an ICMP PTB message. The only size that completely prevents those outcomes is to not send the packet.