Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 06 March 2018 09:57 UTC

Return-Path: <swmike@swm.pp.se>
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 68F881270A7 for <int-area@ietfa.amsl.com>; Tue, 6 Mar 2018 01:57:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 sl_tzXOX9fBx for <int-area@ietfa.amsl.com>; Tue, 6 Mar 2018 01:57:25 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 BD97A127078 for <int-area@ietf.org>; Tue, 6 Mar 2018 01:57:24 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 55FF4AF; Tue, 6 Mar 2018 10:57:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1520330242; bh=GONYefjnRRdo40Bv67gaFdKrAGAGBrDB1/nOXNDIYOc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WaB9etiRoGkIN9KML3S6/0creBJVWgt4v7l9+AWuC4GX1KaZnV/aqDyvIfoZYvP1Q 1DYlh/rPc7Kp3ZWTe/KcMLJSrvrw7IjxOVl3r8gGtzKEZ711NRhRrso0hyfxB9ir4g lAW/jQi+W0+RViTXH7MckASAcybdkR3lEPTQOips=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 533629F; Tue, 6 Mar 2018 10:57:22 +0100 (CET)
Date: Tue, 06 Mar 2018 10:57:22 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Ron Bonica <rbonica@juniper.net>
cc: "int-area@ietf.org" <int-area@ietf.org>
In-Reply-To: <BLUPR0501MB2051C0DCCE28384FCD08F7C4AEDA0@BLUPR0501MB2051.namprd05.prod.outlook.com>
Message-ID: <alpine.DEB.2.20.1803061037320.20609@uplift.swm.pp.se>
References: <BLUPR0501MB2051C0DCCE28384FCD08F7C4AEDA0@BLUPR0501MB2051.namprd05.prod.outlook.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/p8c1DS69oLp-0EcZB9ybds1NmUI>
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
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, 06 Mar 2018 09:57:28 -0000

On Mon, 5 Mar 2018, Ron Bonica wrote:

> Folks,
>
> Please review draft-bonica-intarea-frag-fragile-01 and provide comments. 
> The URL is 
> https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile-01.

I like it.

4.6. There are cases where this "misconfiguration" is due to vendor 
default not being changed. I do not equate "misconfiguration" with "didn't 
change default configuration". Some others might. It might also be due to 
"hardware limitation". Generally, I do not like the "filtering" (I have 
opposed to this in other drafts), as for me "filtering" conveys intent. If 
there is no intent, there is no filtering, but instead there is "dropping" 
or some other word.

4.7 Can we please have 4.7 that describes cases where ICMP PTB are never 
emitted because of misconfiguration? For instance intermediate L2 switch 
that has lower MTU than the L3 nodes connected to it, or mismatched 
MTU/MRU on two nodes connected to each other.

5.1. Can we have some kind of strong recommendation that hosts enable 
PLMTUD for TCP?

6. "IP encapsulations". Shouldn't this be "some packet-in-packet 
encapsulations"? Or does "IP encapsulations" mean "anything encapsulated 
in IP"? 6.3 talks about this as well, I think it's worthwile to put in a 
sentence that whatever is said in this document, probably applies to all 
kinds of encapsulations.

6.1. Err, last paragraph, aren't we getting ahead of ourselves here? I 
guess this is because of Geoff Hustons claims? That last paragraph is in 
dispute (I'd say, from talking to other people involved in DNS).

7.2. I strongly believe we need more text here. It should be something 
along the lines of:

"As per RFC4890, network operators MUST assure proper operation of PMTUD 
by making sure that PTB packets are emitted by all equipment when it can't 
fit a packet into a smaller MTU link, and that large MTU packets are not 
silently discarded due to misconfiguration. Network operators MUST NOT 
filter ICMP PTB packets."

...

As a last comment, do we know documents that tell application developers 
how to do what this document recommends in 5.2? If someone developers 
applications that use UDP for instance, how do they know what the 
operating system PMTUD is at any given time, to avoid the host stack 
fragmenting the packet? I've been interacting with people who had this 
specific problem, and it wasn't easy to figure out exactly how to do what 
is being said in this text (which I agree should be done).

Generally, I think the IETF should strongly recommend application/protocol 
developers to not rely on IP fragmentation, generally. So the ones listed 
in 6 (and I imagine there are more of them), should change the way the 
protocol is done. This includes DNS. So all working groups should be put 
on notice to start working on this problem if they don't already have a 
solution for it.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se