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

Ole Troan <otroan@employees.org> Fri, 03 August 2018 09:54 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 D2374130ECD; Fri, 3 Aug 2018 02:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qj2ELvlGdYH9; Fri, 3 Aug 2018 02:54:08 -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 2188D130EC4; Fri, 3 Aug 2018 02:54:08 -0700 (PDT)
Received: from [10.194.66.106] (77.16.210.106.tmi.telenormobil.no [77.16.210.106]) (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 BF1E42D4F91; Fri, 3 Aug 2018 09:54:05 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <B70622BD-A01F-4B9E-AABE-BB1CEB2F8A6E@strayalpha.com>
Date: Fri, 3 Aug 2018 11:54:02 +0200
Cc: Tom Herbert <tom@herbertland.com>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FB96C1B8-3E8F-4C03-B8A5-CB7A4621CCE0@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> <96 EB5285-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> <8D23C8B1-C2DA-4A8B-A2BE-8CCF6233B3A5@strayalpha.com> <D1D5EDCE-7C43-4CD8-947C-AA43CDB18892@employees.org> <1B04E207-08FA-400F-BBED-67379FEFD64E@strayalpha.com> <62804AFB-A3A9-45E5-8EEB-EF46CB37AB0D@employees.org> <ea11591585f8efb373ec6c273e9f750e@strayalpha.com> <5A8E1A6D-F9BD-4F11-B02E-0B23FA046DF7@employees.org> <0a3864b522d890e0d1f16b45d9de3c70@strayalpha.com> <0967B124-4DE2-4E58-BDFE-39785EC27832@employees.org> <B70622BD-A01F-4B9E-AABE-BB1CEB2F8A6E@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/7HY0RpUTVafgXPd2FukefcnErs4>
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: Fri, 03 Aug 2018 09:54:10 -0000

Joe,

>>> It also looks like (at first glance at least) these devices work only when there isn't multipath between the back and front side.
>> 
>> The A+P routers are stateless and do support multipath. Including traffic does not need to be symmetric.
>> That’s the main selling point for A+P, that you don’t need per flow state in the core of the network.
> 
> The +P part doesn’t seem like it’s compatible with fragmentation, though - yet it doesn’t update RFC791 to deprecate it throughout the Internet.

It’s not incompatible with fragmentation. Just that there are some pitfalls. As explained in rfc7597. 
Fragmented packets do have a higher drop probability, and a higher probability of mis-reassembly on the end system with A+P.
Quite similar in behavior to a CGN. 

> 
> The only conclusion is that A+P should never be deployed in the presence of fragmentation - not that it should drop fragments, nor that we should consider deprecating fragmentation to address that flaw.

The problem A+P solves is to allow IPv4 to continue to grow outside it’s boundaries. The solution keeps session state close to the edge, so much more architecturally clean than CGN. 

If you can solve this problem in a better way please go ahead. 

Cheers 
Ole