RE: Is Fragmentation at IP layer even needed ?

Ronald Bonica <rbonica@juniper.net> Mon, 08 February 2016 21:54 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD111B33C5 for <ietf@ietfa.amsl.com>; Mon, 8 Feb 2016 13:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level:
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 pvwFkgHZ8Inp for <ietf@ietfa.amsl.com>; Mon, 8 Feb 2016 13:54:47 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4581B33C7 for <ietf@ietf.org>; Mon, 8 Feb 2016 13:54:46 -0800 (PST)
Received: from BLUPR05MB1985.namprd05.prod.outlook.com (10.162.224.27) by BLUPR05MB1988.namprd05.prod.outlook.com (10.162.224.30) with Microsoft SMTP Server (TLS) id 15.1.403.16; Mon, 8 Feb 2016 21:54:29 +0000
Received: from BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) by BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) with mapi id 15.01.0403.017; Mon, 8 Feb 2016 21:54:29 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: Mark Andrews <marka@isc.org>
Subject: RE: Is Fragmentation at IP layer even needed ?
Thread-Topic: Is Fragmentation at IP layer even needed ?
Thread-Index: AQHRYaXAunwSsaAfb02BXXvzNQGQm58iVVOAgABAuLSAABZuQA==
Date: Mon, 08 Feb 2016 21:54:28 +0000
Message-ID: <BLUPR05MB19857B918B236880CE8FE871AED50@BLUPR05MB1985.namprd05.prod.outlook.com>
References: <CAOJ6w=EvzE3dM4Y2mFFR=9YyPBdmFu_jkF4-42LjkdbRd3yz_w@mail.gmail.com> <BLUPR05MB1985F5F2BB3118362C67B921AED50@BLUPR05MB1985.namprd05.prod.outlook.com> <20160208200943.A615941B5B96@rock.dv.isc.org>
In-Reply-To: <20160208200943.A615941B5B96@rock.dv.isc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: isc.org; dkim=none (message not signed) header.d=none;isc.org; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.12]
x-microsoft-exchange-diagnostics: 1; BLUPR05MB1988; 5:9+NB1pDJZm8pWX4hszx1beAZGx+nQryKuSio7FHiKTM5ra/o9lJ6DGEB5bS9SzAsxEK4TOAtPxZYuQu3aXjbOJFzh7OoVkpP6NqaVuiseh4u6Z6RxQ+UhFJta3BOb4yovf25cO5t+9ouRxR8Z0sinQ==; 24:+tylQR8k5DFiM1Vn92l1jqADQGDg3Bi+MjRnXv3dpZOpZ/CsTjdEq4Mz2XcqtCAV8m/hKh7NDUYkvMfKqqLMl9fkShGhzRlqzCuAnb9oubA=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1988;
x-ms-office365-filtering-correlation-id: 171f1a5d-e4ff-4c63-3b8a-08d330d26b51
x-microsoft-antispam-prvs: <BLUPR05MB19884A18F6A96B6F71ECE0A5AED50@BLUPR05MB1988.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR05MB1988; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1988;
x-forefront-prvs: 084674B2CF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(10400500002)(76576001)(99286002)(2950100001)(1220700001)(110136002)(3280700002)(3660700001)(1096002)(11100500001)(4326007)(92566002)(5001960100002)(15975445007)(586003)(3846002)(189998001)(19580395003)(77096005)(5003600100002)(6116002)(102836003)(2906002)(74316001)(76176999)(50986999)(5008740100001)(122556002)(54356999)(2900100001)(33656002)(106116001)(5004730100002)(66066001)(40100003)(87936001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1988; H:BLUPR05MB1985.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2016 21:54:28.9560 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1988
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/OmVorvIz7gCLKb2NuegLODHOGyc>
Cc: ietf <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2016 21:54:49 -0000

Hi Mark,

> 
> Actually fragmentation works well unless you have a firewall that drops
> fragments.  When they are not being deliberately blocked the packets get
> through and are reassembled.  It is also not many operators.  It is some
> operators.
> 

The words "many" and "some" don't do justice to the conversation.  https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world-02 provides more concrete numbers from real-world observation.

Beyond that, I agree that IPv6 fragmentation works perfectly unless firewalls are configured to make it stop working. Sadly, the number of network in which firewalls are so configured is too large to ignore. See the draft mentioned above.

> Additionally there is zero reasons why firewalls can't open <src, dst, frag
> offset != 0> when they open <src, dst, proto, src port, dst port> for reply
> traffic for those that are paranoid about just letting all non-zero fragment
> offset through.  I just let the non-zero offset fragments through.
> 
> You might get a few extra packet through.
> 

So, you are voicing support for Option 2a (i.e., Convince operators not to drop fragmented packets). This will clearly take time. Do you think that we should do anything else in the interim? Maybe 1b) Write an RFC informing developers of UDP applications of the problem and advising them not to rely on protocol MTU > 1280.

                                                                                                                                                                     Ron