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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 01 August 2018 01:50 UTC

Return-Path: <brian.e.carpenter@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 97DBB130ED3 for <int-area@ietfa.amsl.com>; Tue, 31 Jul 2018 18:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level:
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: 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 6eRWKekjWJnw for <int-area@ietfa.amsl.com>; Tue, 31 Jul 2018 18:50:11 -0700 (PDT)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0: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 82637130E19 for <int-area@ietf.org>; Tue, 31 Jul 2018 18:50:11 -0700 (PDT)
Received: by mail-pg1-x534.google.com with SMTP id r5-v6so9981423pgv.0 for <int-area@ietf.org>; Tue, 31 Jul 2018 18:50:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 [192.168.178.30] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id z90-v6sm30587173pfk.85.2018.07.31.18.50.08 for <int-area@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 18:50:09 -0700 (PDT)
To: int-area@ietf.org
References: <F227637E-B12D-45AA-AD69-74C947409012@ericsson.com> <8640DCF6-A525-4CF7-A89D-2DEDBF0FADC8@strayalpha.com> <FFF1C23B-7A24-46BC-929E-DD56C77D69A2@employees.org> <A248CA44-B568-4CB9-B450-067B1845AF9B@strayalpha.com> <CALx6S36w=5J0-=JQqrX0_PR7254V0HrhJct7oomPKdxSOSU43w@mail.gmail.com> <2872BF43-20AA-4179-9269-9C4FE6F5986B@strayalpha.com> <CALx6S35VidDr1uTGCHeb3Dcc0qF3O8Lz0vvV-XKPfbY057n6XA@mail.gmail.com> <cd34a1e8da6ff4bbf5b20875827d2a09@strayalpha.com> <CALx6S348jLsnHG3gp-mh9d4KJ1bROT3OcVz=XjwVgpv1aSsi_w@mail.gmail.com> <c271e9501b381c9be6ac1f3a0095a1d9@strayalpha.com> <CALx6S35DRCEjS5qaVkj2_FJzNumrkSfCZmoSJLueqqZs+pm9gw@mail.gmail.com> <240E40E2-81F9-4FAB-A271-825BD7AC6073@strayalpha.com> <96EB5285-E0F6-43BB-A6CE-B087A4F8DF62@employees.org> <CALx6S36Ef3t7Axmx9hg994DHpVM=NdW-7ygf89E==gL4XKrkQg@mail.gmail.com> <5E21B3C1-0420-404C-9824-9B7E5A850BC5@employees.org> <CALx6S34qmKngi3hK_PVrJA1DMa5kfaLww3jfqRKN=up5v0Y0Ww@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <553ebde6-08b3-21b2-efdc-c2ddf4912870@gmail.com>
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: <CALx6S34qmKngi3hK_PVrJA1DMa5kfaLww3jfqRKN=up5v0Y0Ww@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/Ngp1QlkewQ8oWTguxIpJhMaXUM0>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.27
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: 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 <otroan@employees.org> 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
https://tools.ietf.org/html/draft-naderi-ipv6-probing .)

    Brian