IETF Logo Mail Archive

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-00.txt

Ole Troan <otroan@employees.org> Thu, 16 August 2018 17:02 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 00784130DC4 for <int-area@ietfa.amsl.com>; Thu, 16 Aug 2018 10:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 X5vHtL00rfzQ for <int-area@ietfa.amsl.com>; Thu, 16 Aug 2018 10:02:46 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6BE1277BB for <int-area@ietf.org>; Thu, 16 Aug 2018 10:02:46 -0700 (PDT)
Received: from [192.168.10.187] (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 667732D4FAB; Thu, 16 Aug 2018 17:02:42 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-9AD40C2A-89E5-447A-B5FB-DE9CF1D39A8C"
Mime-Version: 1.0 (1.0)
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <F15BBC81-F3BF-4762-B27E-61A418EA8356@strayalpha.com>
Date: Thu, 16 Aug 2018 19:02:37 +0200
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, int-area@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <D6F35FA4-6305-464B-A1A6-667E0CE30985@employees.org>
References: <153434872145.14477.17942361917248825531@ietfa.amsl.com> <2c82b61e-8017-742e-764b-559f2ec4bd37@gmail.com> <alpine.DEB.2.20.1808160735400.19688@uplift.swm.pp.se> <AE241D6E-2379-4EFB-802C-BFBC840273E7@employees.org> <2BB8A510-DEA7-4543-9FF4-6D82D5ADBA53@strayalpha.com> <66DE41F9-32D7-45F2-AADB-37DD19A5F5A5@employees.org> <F15BBC81-F3BF-4762-B27E-61A418EA8356@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/uQ63LN2_MK8rvZxWocGGXx6c6rU>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-00.txt
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: Thu, 16 Aug 2018 17:02:49 -0000

Joe,

> On 16 Aug 2018, at 15:58, Joe Touch <touch@strayalpha.com> wrote:
> 
> 
> 
>> On Aug 16, 2018, at 5:47 AM, Ole Troan <otroan@employees.org> wrote:
>> 
>> Joe,
>> 
>>>> IPv4 fragments do have a higher drop probability than other packets. Just from the fact that multiple end-users are sharing a 16 bit identifier space.
>>> 
>>> It’s really the fact that NATs that process fragments don’t reassemble before translating and/or don’t rate limit fragments they generate as already required by 791 (as explained in 6884).
>> 
>> That’s incorrect.
>> See https://tools.ietf.org/html/rfc7597#section-8.3.3
> 
> You should re-read that RFC. It correctly points out that this is a flaw in current devices. 
> 
> There is a solution - reassemble before NATing, and when issuing the new packets, issue then with IDs generated at the NAT.

These are not NATs. They are specifically designed to be stateless. Sure you can argue that the A+P solutions break the Internet, our answer to that oh well, move to IPv6. 

> The correct behavior is already indicated in RFC 6864, Sec 5.3.1

>>> A NAT that is broken isn’t helping users share addresses. It’s just broken.
>> 
>> I wish it was that simple.
> 
> It’s not simple, but saying that “fragmentation is broken” does not make it more simple either.

True. 
Regardless, I fear we aren’t going to agree on this, but at least I think we have understood each other’s points. 

Cheers 
Ole

v2.23.0 | Report a Bug | By Email