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

Brian E Carpenter <> Wed, 01 August 2018 01:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97DBB130ED3 for <>; Tue, 31 Jul 2018 18:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 6eRWKekjWJnw for <>; Tue, 31 Jul 2018 18:50:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82637130E19 for <>; Tue, 31 Jul 2018 18:50:11 -0700 (PDT)
Received: by with SMTP id r5-v6so9981423pgv.0 for <>; Tue, 31 Jul 2018 18:50:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=lcdE3e+wRB+JPqaET1CHpgrR2swRLWmDemAkwBGKgv0=; b=Jijy1Jt3lylZ+nsaJ+lf0g9Z1mNcWr2ydOngegaNiDwuIsg1MFaaNTVRwRj4+JrIY+ FbmAuH5yuLYS9k3xMG3a9kJE1Eju+bOX+aNsp7CbDODI+3zgEyDycn3tu1tp9xz33fVq 8ws3eDY/gzGH3TBSAqiUx8/0grskGn8NWZJZIDTxjsZwZ+mc6Jr0n4KoTn8hbrRR9XER MozkK4X+CjQH3O3S6klP+pvCW8JNtYC00j9bSASjalo80/5KxsWFmINaPylcZN6tTfPP 3EObBffxIvj3mAGh0csnMejTYDoD+cEMqux/KcgShxurkopBwPYg+nh+gCcHumZd6fKG lBmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lcdE3e+wRB+JPqaET1CHpgrR2swRLWmDemAkwBGKgv0=; b=dCEj2doT/jx64d76/nH+Sp8xtJUPozGHQMbJV5d3qkl4agS/ro+1pDWMLW/DziOk5z 8mDkqgKuw0JxTpEUOgxwnbCTrR6oHqDgzuuyYBV6QbeKBvE8uNCs3GeQIHpgNvaMNdSQ NtTSU1P/f+ud1R6OSw9tq/fWJoxVxIw/a9N2uod4SGlspRvqRdKp+flB0fzwR/He1kA/ slQg6M0M+HiUY7w480X2k/AMRHKPM9GEtI8jYY80oK37DJTVVHN24/e3eqy98i5Wcc0B GWDudKJfOzV6j7krUJSDyxPdZtpSalgfc2BBniZJVKtoZNiRoA5+XuTAzOnYYBufkG6/ jcJg==
X-Gm-Message-State: AOUpUlElSw9nHpWvTDYPXv+l8Y0pc+uFsF45IHHclVFhV6Y0uRURHE// arPDtgVXkJ44l8CNiWszRZRjcdLb
X-Google-Smtp-Source: AAOMgpfiJoC7B60uae/9VgBhDaqZbV0s500ovMjTUTcs5zg4Dp1CfbxN4NSMkk5/OWLFQnqoOTnTZw==
X-Received: by 2002:a63:a919:: with SMTP id u25-v6mr23227259pge.211.1533088210643; Tue, 31 Jul 2018 18:50:10 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id z90-v6sm30587173pfk.85.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 18:50:09 -0700 (PDT)
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Wed, 1 Aug 2018 13:50:13 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
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: Wed, 01 Aug 2018 01:50:14 -0000

On 01/08/2018 11:29, Tom Herbert wrote:
> 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?
> Ole,
> 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"
> features.

Generalised probing might be an answer, but (especially when there
are multiple address pairs to probe) it can significantly impact
start-up latency for a session. (Some dead work on that topic is at .)