Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt

Fred Baker <fredbaker.ietf@gmail.com> Fri, 01 November 2019 16:44 UTC

Return-Path: <fredbaker.ietf@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 99273120019 for <int-area@ietfa.amsl.com>; Fri, 1 Nov 2019 09:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 mkWo3mhg3va3 for <int-area@ietfa.amsl.com>; Fri, 1 Nov 2019 09:44:24 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 2BB4B120096 for <int-area@ietf.org>; Fri, 1 Nov 2019 09:44:24 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id w8so4615926plq.5 for <int-area@ietf.org>; Fri, 01 Nov 2019 09:44:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ajLLymaJVd1O1X5zeRII6/txyesNuxY0LPMlXch8qSk=; b=Iq5Pp57Ce3VG1i1AJO3liKMPVd6n5CnsnxVkyUkeXudXU6z4JGaK/w1VFua9Wt4dKl cxUMww7BV5pqqDu/lqAjAlXK9vkguP5h9EFbkd88oWAbPlH/cGxj4vj6ZnIWNAi1Nec2 CsciGEYPAZ6fHWOWnKKe8ssHj6XMah2et2edyC4WOP5K3/yCKhPUAF+yFdnGiqgkrrQj s/e4a3gScsRq9GYZSPw/cjOwbTPcGQPWAx4Hf25r5UalThVYzxeOGn5Mrt7CVyvYIlPu IaoRkZbaCNP4pPzjat4144yZuxfHN0Ay7bixF6ticjNENrAM64jxEW1mva5aN+xYxysa +2lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ajLLymaJVd1O1X5zeRII6/txyesNuxY0LPMlXch8qSk=; b=OpLwyTwKJ/O7O0T5Q0P3oa7QtdPtUt9nmNid/ii7hXobgePIirmGuMzLAFeJpQLFVH X91RG+ngAOLn0yyNUrYiQJWsjTDpIMKxH2HX9K8e8BCEFto4pDk7uJBjWOLKfJ1hdT35 wNdl7En5pI7l17SIRREz3ytNM9gnzwYazeeaFceH/p9fRaiPsSb+cujDv4rsGK0bfgO9 cuZ1XqRuWqbmn833h187dcN4NZwdRXDawQcMmE1SsxtQJaM7P9HgM0XlvyqcmFoxd8qf Sml8ZVaAg+wJxyxr0NKMRlQtls55Z2M3aQA8UD8+oy11FmnapyLyarZOqC/JazyrxWUn RCVQ==
X-Gm-Message-State: APjAAAXR3hpGoiU/baN+i8KMlD28OlWn4LkcZ6SX2a5BWbYII1Al4mOS nNWms/+/5afiDIuZKDm2z6I=
X-Google-Smtp-Source: APXvYqxhZvxg6HLzj8V/dF3Ghsh4FipmA1BCg3FHfFcNIumd7887sjlUW4NNQRvQ3F4HwdUUqgb22A==
X-Received: by 2002:a17:902:8506:: with SMTP id bj6mr12710795plb.165.1572626663650; Fri, 01 Nov 2019 09:44:23 -0700 (PDT)
Received: from 137.66.20.149.in-addr.arpa (137.66.20.149.in-addr.arpa. [149.20.66.137]) by smtp.gmail.com with ESMTPSA id g24sm7672662pfi.81.2019.11.01.09.44.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 09:44:23 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Fred Baker <fredbaker.ietf@gmail.com>
In-Reply-To: <A1C8A26F-09BC-497D-A919-00BAE279AB73@strayalpha.com>
Date: Fri, 01 Nov 2019 12:44:21 -0400
Cc: Erik Kline <ek.ietf@gmail.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CACCB2CE-F3F0-454C-8C56-36898062A9C7@gmail.com>
References: <157254929056.30376.9249888312089068630.idtracker@ietfa.amsl.com> <BN7PR05MB5699A257D6A46B016FBCD539AE630@BN7PR05MB5699.namprd05.prod.outlook.com> <702307FF-E65E-4800-BAC8-CEE16EAFA0BD@gmail.com> <CAMGpriUtgtr9nQ4_8_i0anzUkRpyO78QkzbXqOiFWZnZwHzsxw@mail.gmail.com> <A1C8A26F-09BC-497D-A919-00BAE279AB73@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/AQPVCtioE8yUs_cqZV1HGpLP8xI>
Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
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, 01 Nov 2019 16:44:26 -0000

On Nov 1, 2019, at 12:39 AM, Joe Touch <touch@strayalpha.com> wrote:
> On Oct 31, 2019, at 5:07 PM, Erik Kline <ek.ietf@gmail.com> wrote:
>> 
>> It may be folly to try to modify IPv4 implementations at this point.   I have no objections if you wish to try pushing this big rock up hill, but I doubt you will be successful.
>> 
>> BTW, what *actually* prevents a middlebox from doing IPv6 fragmentation? 
> 
> Expecting it to work. That middlebox has no idea what packets are going through other middleboxes from the same endpoint. There’s no way it can pick IDs to avoid collision, the way the origin can. That’s why both IPv4 and IPv6 rely on the origin creating those IDs.
> 
> The result would either be significantly increased reassembly errors, sort of like accidental poisoning of the receiver’s cache, or potentially resulting in incorrect packets (the latter could be more likely in some cases, e.g., when the fragment happens to have a zero IP checksum).

I don't especially disagree with you, BUT...

Thinking about middlebox fragmentation. OK, suppose I am a company with N middleboxen. Suppose I configured the middleboxes to generate N disjoint ranges of IDs. If I have a datagram arriving at a middle box and being fragmented into two or more, and the ID generated is within the range assigned to the middle box, I don't think the results you predict actually transpire.

Note that I'm not writing a draft about that. I'm not sure I want anyone thinking it's a great idea and needs to be implemented.