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

Christian Huitema <huitema@huitema.net> Sun, 26 August 2018 17:32 UTC

Return-Path: <huitema@huitema.net>
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 C56A0130DCB for <int-area@ietfa.amsl.com>; Sun, 26 Aug 2018 10:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 U3JzE5F_OtWI for <int-area@ietfa.amsl.com>; Sun, 26 Aug 2018 10:32:08 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49182128CE4 for <int-area@ietf.org>; Sun, 26 Aug 2018 10:32:08 -0700 (PDT)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx12.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1ftytR-0006bv-5d for int-area@ietf.org; Sun, 26 Aug 2018 19:32:06 +0200
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1ftytJ-00025N-Sz for int-area@ietf.org; Sun, 26 Aug 2018 13:32:01 -0400
Received: (qmail 9334 invoked from network); 26 Aug 2018 17:31:54 -0000
Received: from unknown (HELO [172.20.1.108]) (Authenticated-user:_huitema@huitema.net@[63.64.30.195]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tte@cs.fau.de>; 26 Aug 2018 17:31:54 -0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <CALx6S35-n_ROEZv0NReVEWTUhnyc25SNJb5DaeqtnxPAPk6QjQ@mail.gmail.com>
Date: Sun, 26 Aug 2018 10:31:53 -0700
Cc: Toerless Eckert <tte@cs.fau.de>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CAF493D3-37A2-4A89-BA88-81567E5B88F1@huitema.net>
References: <CALx6S36Ef3t7Axmx9hg994DHpVM=NdW-7ygf89E==gL4XKrkQg@mail.gmail.com> <5E21B3C1-0420-404C-9824-9B7E5A850BC5@employees.org> <CALx6S34qmKngi3hK_PVrJA1DMa5kfaLww3jfqRKN=up5v0Y0Ww@mail.gmail.com> <8D23C8B1-C2DA-4A8B-A2BE-8CCF6233B3A5@strayalpha.com> <D1D5EDCE-7C43-4CD8-947C-AA43CDB18892@employees.org> <1B04E207-08FA-400F-BBED-67379FEFD64E@strayalpha.com> <137751A3-7C52-4CCF-AE9C-B99C4A85EFC1@strayalpha.com> <alpine.DEB.2.20.1808021749020.19688@uplift.swm.pp.se> <CALx6S35kw2dodgG2L3LE3A5y8RYEXy6izQWgrQTwg7-yPqpzOg@mail.gmail.com> <alpine.DEB.2.20.1808030857370.19688@uplift.swm.pp.se> <20180825032457.ol5rlrr7h2kqi6px@faui48f.informatik.uni-erlangen.de> <CALx6S35-n_ROEZv0NReVEWTUhnyc25SNJb5DaeqtnxPAPk6QjQ@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Originating-IP: 168.144.250.232
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: ham
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.09)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5uTEJ/TAs+3ph3BImmYdloV602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO3NBQ8jcSCSHwUCPl9o/grPBFCAKYcLuPfWMLWK7DDnqcDRR/2U4LeRey2p6dKZNpSTg 127TqHZDxA/kZB41Rh901iU5yAsBk1OyzGhUzELBnXoevxvfYUBXZFVAfNJz2TSkkFlQZz6yFr2K mBj9WjbWc+PIB7z0NFJh8FN10Ic641c/SimthgfOQipLVZUf64m3kXFxT3PHKpC8L4Stjnk9BNSM IeL844hdb5YC9oOas7rU/0aIzyPhsTjj9F2Uj6usY79cyEbvO/ynfpPGXABEQWDHVvR21jQr4ydt 9ILFP/xTyMZZlIincyRwJ1jG2ZD3bkPnLatXTmXUrNRl9fBdKRQ31g4VUpqJQ0lQU8P8KPwbT+Q3 o5mCCjJmkc0aeldTYuFU08ZfNHjA+GkLixh7cooL9qbRJJ2e8gSQUqIJqGD7UDqBLMovKf8FhYpt 8fvg7iEFLP+SSY+Av5+AiC4LT+YMU6qWdVGzdmZoM9uNWmUZh13Bdo8xj26Cdb82fNt1mIipy0/+ 4v3DeKLxbk+RquskHfnrHOMs1efGdCmSvphIBNEpvU3XYoNG/OMT5kvwVgxcMUN0RhygSDflq1IR FZ4oobg8BBg3Jq+ntzj0U+eJFUNA/4CAqoxclEdILu55gpE6rQrAuqadMAWEUm1ojR3lEG4dwgYo aVWMRMmQzPx2tRInHghlXopjXZUD9E9i5fItKCuMu+YhUG8g2Cyu7ALr9GwxDinRa92sptNCd2ax XUPd24nlSlq9nqu7l64l2AmoxV6Yskm9am4MNPusTLyQUkuqrhsucqa5i4vWpDlLGcickW+v6n18 gZqGBWUVrBsPGnNiJ83AD/4JscAWFbmwdx3QWSMCSWQ/zrMKfFoPKz4hR1t8dRAWSM6nEelNC4wc 2LkM7XQE4YLVklPsdKV/0Fj4doeplIgBJ9cx
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/THLQHskCM1LqkXboiThMAypS-Gw>
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: Sun, 26 Aug 2018 17:32:11 -0000

It seems that the biggest obstacle to fragmentation are NAT and Firewall. They need the port numbers in order to find and enforce context. NAT might be going away with IPv6, maybe, but firewalls are not.

Have considered strategies that move the port number inside the IP header? For example, have an UDP replacement for IPv6 that does not have any port number in the new UDP header, and relies instead on unique IPv6 addresses per context?

-- Christian Huitema 

> On Aug 26, 2018, at 10:08 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
>> On Fri, Aug 24, 2018 at 8:24 PM, Toerless Eckert <tte@cs.fau.de> wrote:
>>> On Fri, Aug 03, 2018 at 09:48:25AM +0200, Mikael Abrahamsson wrote:
>>> I've kept saying "Networks must support ip fragmentation properly.
>> 
>> Why ? Wheren't you also saying that you've got (like probably many
>> else on this thread) all the experience that only TCP MSS gets you
>> working connectivity in many case (like hotels) ?
>> 
>> IMHO, we (network layer) should accept defeat on network layer
>> fragmentation and agree that we should make it easier for the
>> transport layer to resolve the problem.
>> 
>> Aka: I would lvoe to see a new ICMPv4/ICMPv6 reply and/or PTB reply option
>> indicating "Fragmented Packets Not Permitted". Any network device which
>> for whatever reason does not like Fragemnts would simply drop
>> fragmented packets and send this as a reply. Allows then the
>> transport layer to automatically use packetization  (such as TCP MSS)
>> to get packets through.
>> 
>> Of course. Will take a decade to get ubiquitously deployed, but
>> neither IPv4 nor IPv6 will go away, only the problems with fragmentation
>> will become worse and work if we do not have an exit strategy like this.
>> 
> Toeless,
> 
> I'm curious why you think the problems with fragmentation will become
> worse. The draft and much of this thread has already highlighted the
> problems with fragmentation that happen because of non-conformant
> implementation. While there's a lot of legacy implementation that
> might hard to fix completely, I don't think we've seen a good argument
> that these problems are infeasible to fix in new deployments and
> products. I think this draft is an opportunity not only highlight the
> problems, but to suggest some practical fixes to improve the situation
> as a way forward.
> 
> Tom
> 
>> If we don't try an exit strategy like this, we will just get what
>> Joe said, the complete segmentation of the Internet with more and
>> more L4 or even higher layer proxies.
>> 
>> Btw: +1 for adopting the doc as a WG item, but primarily because everything
>> before section 7 is on a way to become a good read of reality. Section
>> 7 recommendations is only a faith based exercise (praying) as long as it tries to
>> get the job done primarily by appealing to application developers.
>> 
>> Cheers
>>    Toerless
>> 
>> 
>> 
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area