Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

Tom Herbert <> Tue, 31 July 2018 23:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1D31130EA3 for <>; Tue, 31 Jul 2018 16:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WYWaydQddCXn for <>; Tue, 31 Jul 2018 16:29:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0DF9130DD1 for <>; Tue, 31 Jul 2018 16:29:43 -0700 (PDT)
Received: by with SMTP id t79-v6so11499346qke.4 for <>; Tue, 31 Jul 2018 16:29:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9oftiBs4dNoLcuF3C/p+MsvgW80FfDdmIAAe/HAg1N4=; b=CKJSDceG8B5mMxFIoLfHNitutj8AnLdCRf4HD7fQa0tb15H6lk1MZX+crgXqZ4OnYo a9A5JrQ62h/OoyIO5moFkc+e+matl6RKv6wu7YH/Btt7DGkZMeVQXV5BKNO85JgU9VyT A++x4gjIXb4wwpa1jSygtM1yEEYE5lBNiIwVkj51QtZFV+FdHVqLsYGaUmqDH2z5f0Ej jwf5IJVOh9DcBvV63vToERmayRg5Lh0P4iSXif1eL6u5DDfc8iTZbxlEIKty49Cy8PKk fy6aqLFpR69pBuYYjgM4xFZCVHgg6EgP/1B2QQst1izWl/FBgWml1LbmZ636tfr1kRPI L8wA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9oftiBs4dNoLcuF3C/p+MsvgW80FfDdmIAAe/HAg1N4=; b=WDpyDLmvImGRTfMa83OXY95mnaE/bA0fPtPRcff+lvSXQXTqmbKshFktXeyuug4+6s P7FN8FLa4gv5GXzqQW7RUxOGV58YeF4BdXLFqmZhGQnzizPHsbDn8VEg5E136VgtFRPw suJUvLfA4WCBZ0L+y/5hQcHEczA6sLCBh+ON3KOaYbbdn63cCGhuKdJ9BYM/FIgBiCqx F1WQWrZjivatG+GQAYsD8qy071OFxxoku3bWhyA2gxTmJS4ZB4b+VBPFPE8izOEB14TB Byp7gdLaF75QZYBuSdEbZDTNgDK1QYlP92gd2spZCZs75cecaUe4IDAuJGPg7yjAnWhh c3jg==
X-Gm-Message-State: AOUpUlGk3bCOK8+kF7E6Jd8Oe/lqsRcn0uLCN4RDqwLUTq/Sk8S6uBd6 zea0mdnBrfXT+wtB7ieENnhu9WZmQY1UFV6qusnXXg==
X-Google-Smtp-Source: AAOMgpdGXS2nkrCULYmOpr/WmLiRlRQV2llTh+N0k0685RDEdMjYdjCKo+kUuA+2RlkpzvezmWSuzCeHn3GQlzDHCJQ=
X-Received: by 2002:a37:1fdf:: with SMTP id n92-v6mr22893633qkh.333.1533079782766; Tue, 31 Jul 2018 16:29:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Tue, 31 Jul 2018 16:29:41 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Tue, 31 Jul 2018 16:29:41 -0700
Message-ID: <>
To: Ole Troan <>
Cc: Joe Touch <>, int-area <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Jul 2018 23:29:46 -0000

On Tue, Jul 31, 2018 at 2:21 PM, Ole Troan <> wrote:
> Tom,
>> How is this story going to be different for IPv6? How do we ensure that non-conformant implementation for IPv4 isn't just carried over so that fragmentation, alternative protocols, and extension headers are viable on the IPv6 Internet?
> I don’t think the IPv4 implementations are non-conformant.
> (With regards to the implications of A+P on the IPv4 architecture).
> For IPv6 one would fear that the same pressures that has led to IPv4 ossification applies.
> Well, what can we do? Apart from crypto, ensure that popular applications use the features, so they cannot be shut down?

That's the "use it or lose it" model of protocol features. TCP options
are firmly established as a required part of TCP protocol so there is
no way they could be obsoleted by external implemenation; IP options
on the other were never really required for IP operation so they are
considered expendable. The problem is that protocol features are often
defined before the application that would use them is built, so the
motivation to support all the features from the start isn't there.
This seems to be the case with extension headers, since only now does
there seem to be some serious proposals to use that functionality long
after the mechanism was first defined and IPv6 was deployed. In
reality, support of protocol features in the Internet is hardly ever
binary. Plain TCP/IPv4 packets are probably the only combination of
protocols that is guaranteed to work with probability approaching
100%, however pretty much anything else works with some varying of
probability greater than 0% but less than 100% (like EH success rates
in RFC7872). To that end, I am wondering if the idea of Happy Eyeballs
could somehow be generalized to work with these other "non-standard"


> Cheers,
> Ole