IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Tue, 31 July 2018 21:21 UTC

Return-Path: <otroan@employees.org>
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 0B245130E07; Tue, 31 Jul 2018 14:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 VsN5zUQJd3Uj; Tue, 31 Jul 2018 14:21:45 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D01130DF7; Tue, 31 Jul 2018 14:21:45 -0700 (PDT)
Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 529312D4F9B; Tue, 31 Jul 2018 21:21:44 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 4A0242259B0; Tue, 31 Jul 2018 23:21:42 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CALx6S36Ef3t7Axmx9hg994DHpVM=NdW-7ygf89E==gL4XKrkQg@mail.gmail.com>
Date: Tue, 31 Jul 2018 23:21:42 +0200
Cc: Joe Touch <touch@strayalpha.com>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E21B3C1-0420-404C-9824-9B7E5A850BC5@employees.org>
References: <F227637E-B12D-45AA-AD69-74C947409012@ericsson.com> <0466770D-C8CA-49BB-AC10-5805CFDFB165@strayalpha.com> <6EDF0F79-C8F3-4F05-8442-FF55576ADDD0@employees.org> <alpine.DEB.2.20.1807271530280.14354@uplift.swm.pp.se> <CALx6S35LthDLRry7k-pF8KSoX4BXBA8kyArOpDUAcJMDCoLQpQ@mail.gmail.com> <alpine.DEB.2.20.1807280811540.14354@uplift.swm.pp.se> <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>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/DErlw6awHKm3GhEPiBSJAs8JOs8>
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: Tue, 31 Jul 2018 21:21:47 -0000

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?

Cheers,
Ole

v2.23.0 | Report a Bug | By Email