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
- [Int-area] draft-bonica-intarea-frag-fragile-01 Ron Bonica
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Joe Touch
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Ron Bonica
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Joe Touch
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Bob Hinden
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Mikael Abrahamsson
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Joe Touch
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Tom Herbert
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Joe Touch
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Ole Troan
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Templin, Fred L
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Tom Herbert
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Joe Touch
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Templin, Fred L
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Ron Bonica
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Tom Herbert
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Joe Touch
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Joe Touch
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Templin, Fred L
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Joe Touch
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Ron Bonica
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Ron Bonica
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Joe Touch
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Mikael Abrahamsson
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Tom Herbert
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Joe Touch
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Ron Bonica
- Re: [Int-area] draft-bonica-intarea-frag-fragile-… Joe Touch