Re: Non-Last Small IPv6 Fragments

Erik Kline <ek@loon.co> Mon, 14 January 2019 05:19 UTC

Return-Path: <ek@google.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6055130F53 for <ipv6@ietfa.amsl.com>; Sun, 13 Jan 2019 21:19:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.499
X-Spam-Level:
X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.co
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 MJpupFIBQ3yz for <ipv6@ietfa.amsl.com>; Sun, 13 Jan 2019 21:19:18 -0800 (PST)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 DB32C130F52 for <ipv6@ietf.org>; Sun, 13 Jan 2019 21:19:17 -0800 (PST)
Received: by mail-io1-xd30.google.com with SMTP id g8so16727354iok.4 for <ipv6@ietf.org>; Sun, 13 Jan 2019 21:19:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.co; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=fo4LkmHt+IRDNK11RdqidOQWTdeS/n0s8uv53643Waw=; b=Y7mmA3XBWd00Z1WHjqhBPL/o5UGLmAsT4ssuQf/pEVlaSigiNfEAXkx1hKxqUMPbTJ BuGz38XnNRGXqDZAjt3UAdSFpnefjZl2n3u4YxgKa0ZssJ+9AMlBXQIlXy24mdNX2b0D vY+aEaLa009ytETizG6jJ8zscvhiga/LvYxfg=
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:reply-to :from:date:message-id:subject:to:cc; bh=fo4LkmHt+IRDNK11RdqidOQWTdeS/n0s8uv53643Waw=; b=OyFyAfvoaqOVxTFuCK3fGtlrVM4Sm/CoypgQSNAp4SRaHhSqcb93xMAM5pscnpl+sQ k39vcXS2j0OmQnpZckogqfprIbZSMTcDWDfLZAhGnwXmsHBMQauSWT8KZVHsp3CyPxHF fcMoNI/HL0h1XEnUQsyjZ83dm4G34fjB229aQPpDfw3lBDeE2b4Gq78iJxZEdAjs9Va6 wdfWZSdcgjNgAlAKrfMKtSVNFIwAcSr1UlTSCO/B/ceGVNnFTZdVYo2F20M5xxCxv4mP 4qS4uJ0+Y74NNBHc9ym9S3VciTkuLizOPALIeFaMws9jXYPZIQgzrfzBrpc6aK9HI27y hdyQ==
X-Gm-Message-State: AJcUukf2N+6gvPKQUsNWySSZwdQftFozQWTqSfRad0Gy0n42tw6WHxj+ f9TyfYYMPUGtq4fWmYV3miWcTCxcEYVn2hqLVd0T4A==
X-Google-Smtp-Source: ALg8bN40x2R2cjMGTVfJAZNFfwzhwToQpkMmD4ng9PmII6TlPWnYUdXS9DRpIMEgTHNjfpO7SFNedR+Gh/N0kdRkUrI=
X-Received: by 2002:a6b:1d8:: with SMTP id 207mr15747623iob.62.1547443156930; Sun, 13 Jan 2019 21:19:16 -0800 (PST)
MIME-Version: 1.0
References: <CAOSSMjV0Vazum5OKztWhAhJrjLjXc5w5YGxdzHgbzi7YVSk7rg@mail.gmail.com> <CAN-Dau1HwG5RndacpSA+si+zKuTdpSvA=QA1A11A==rMNe=4+w@mail.gmail.com> <CALx6S35KNhV2gFp9OdU+M1zy5WUuEAEvXkDXNDWWxi7uQ4e_cw@mail.gmail.com> <CAN-Dau0rTdiiF2SjByxcMG6nhPCEjUH2pYBCOeK_FSGJ_ucDQw@mail.gmail.com> <CALx6S34AyV9OpvnjQhQc56n5vfeVgU5Zd3kheP0g+XvsMbBV9g@mail.gmail.com> <1b2e318e-1a9f-bb5d-75a5-04444c42ef20@si6networks.com> <CALx6S37TJr++fC=pVoeS=mrO1fHc4gL_Wtu-XkVTswzs2XxXCA@mail.gmail.com> <CALx6S36V7vrVyoTP0G6+S5XeFNB3KWS5UaNnVi20xogRERdCfg@mail.gmail.com> <973A1649-55F6-4D97-A97F-CEF555A4D397@employees.org> <CALx6S34YbBe8xBod3VsWVO33TpZcdxh2uV1vaO8Z_NKnVXp66g@mail.gmail.com> <A3C3F9C0-0A07-41AF-9671-B9E486CB8246@employees.org> <AEA47E27-C0CB-4ABE-8ADE-51E9D599EF8F@gmail.com> <6aae7888-46a4-342d-1d76-10f8b50cebc4@gmail.com> <EC9CC5FE-5215-4105-8A34-B3F123D574B9@employees.org> <4c56f504-7cd7-6323-b14a-d34050d13f4e@foobar.org> <9E6D4A6E-8ABA-4BAB-BEC5-969078323C96@employees.org>
In-Reply-To: <9E6D4A6E-8ABA-4BAB-BEC5-969078323C96@employees.org>
Reply-To: ek@loon.co
From: Erik Kline <ek@loon.co>
Date: Sun, 13 Jan 2019 21:19:04 -0800
Message-ID: <CAAedzxpdF+yhBXfnwUcaQb-HkgdaqXRU3L+S7v8sS1F0OkwM9A@mail.gmail.com>
Subject: Re: Non-Last Small IPv6 Fragments
To: Ole Troan <otroan@employees.org>
Cc: Nick Hilliard <nick@foobar.org>, Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ae2fe1057f642fc3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/x93wO2B9PV6VMoGcfQCzFtASB_Q>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Jan 2019 05:19:20 -0000

>
>
> > Ole Troan wrote on 13/01/2019 20:03:
> >> Let’s fix path MTU discovery. There’s no fix for fragmentation.
> >
> > pmtu discovery is hard because it needs a way for an intermediate node
> to be able to signal a transmitting node to dynamically drop the MTU if
> network conditions change.  The only way to reliably work around this is to
> transmit at 1280 and claim implementation / operational breakage if this
> cannot get through.  This, however, robs the host devices of the ability to
> use higher MTUs.
>
> “Fix” as in something different than rfc8201.
>

How about a version of the fragment header that:

    (a) *always* has the L4 header (or a configurable number of bytes) in
every non-first fragment

This could be documented on a per-L4+ basis how much needs to be included,
i.e. we could have one doc for UDP and (say) a separate doc for information
QUIC would need on a per-fragment basis.

This increases the overhead in a given fragment, but also helps to ensure
that (eventually) intermediate systems can examine this field and
preemptively make a drop/no-drop decision.

    (b) state clearly that every non-last packet must contain
$CONSENSUS_MINIMUM_BYTES of actual fragment payload

No opinion on the exact value.