RE: Is Fragmentation at IP layer even needed ?

Ronald Bonica <rbonica@juniper.net> Mon, 08 February 2016 17:21 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 363B31B2F98 for <ietf@ietfa.amsl.com>; Mon, 8 Feb 2016 09:21:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.901
X-Spam-Level:
X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KSlIh2-4Zx-L for <ietf@ietfa.amsl.com>; Mon, 8 Feb 2016 09:21:33 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0131.outbound.protection.outlook.com [65.55.169.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C14D1B2F94 for <ietf@ietf.org>; Mon, 8 Feb 2016 09:21:33 -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 17:21:31 +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 17:21:31 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: Alexey Eromenko <al4321@gmail.com>, ietf <ietf@ietf.org>
Subject: RE: Is Fragmentation at IP layer even needed ?
Thread-Topic: Is Fragmentation at IP layer even needed ?
Thread-Index: AQHRYaXAunwSsaAfb02BXXvzNQGQm58iVVOA
Date: Mon, 08 Feb 2016 17:21:30 +0000
Message-ID: <BLUPR05MB1985F5F2BB3118362C67B921AED50@BLUPR05MB1985.namprd05.prod.outlook.com>
References: <CAOJ6w=EvzE3dM4Y2mFFR=9YyPBdmFu_jkF4-42LjkdbRd3yz_w@mail.gmail.com>
In-Reply-To: <CAOJ6w=EvzE3dM4Y2mFFR=9YyPBdmFu_jkF4-42LjkdbRd3yz_w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.12]
x-microsoft-exchange-diagnostics: 1; BLUPR05MB1988; 5:TNFMDUe7s37bzbZy5JxdyTwXNgQ9ehVUoj0qPxBD2n3R044+jPRCh/AWtMBIecJGoSOpWbnjTqhrrPLxBNGqZxyHZVPUFMfeL+TWJRjy+YHDuewqxr/A3KUT0kDC2tYQFLZuBUJKJwXCGqjfH3c3mA==; 24:S89hPWt7NpZgxkSwwh38B/qI2g0ZCC7Fv06qLkAV7k+5qnhC2hG6zAvJ/gvxbzlZYn5XDiYprO3tJR5YHjlGV9WgTgmFKJwaCAFm4DQEmdg=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1988;
x-ms-office365-filtering-correlation-id: 3f1d65a0-1c14-4b65-ede3-08d330ac495e
x-microsoft-antispam-prvs: <BLUPR05MB19886A7C84A63DC2B6CA8288AED50@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)(377454003)(76104003)(53754006)(2900100001)(106116001)(33656002)(122556002)(76176999)(19625215002)(74316001)(54356999)(50986999)(5008740100001)(40100003)(87936001)(86362001)(66066001)(5004730100002)(76576001)(99286002)(19580405001)(5001770100001)(10400500002)(189998001)(3846002)(19580395003)(2906002)(586003)(790700001)(15975445007)(5001960100002)(5002640100001)(6116002)(102836003)(77096005)(5003600100002)(16236675004)(1220700001)(3660700001)(3280700002)(107886002)(2950100001)(92566002)(11100500001)(1096002)(19300405004); 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: multipart/alternative; boundary="_000_BLUPR05MB1985F5F2BB3118362C67B921AED50BLUPR05MB1985namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2016 17:21:30.8444 (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/DS8kmOrkIH5xrsFDsIavS1zVlqI>
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 17:21:36 -0000

Hi Alexey,

This question comes up every few years. The short answer is:


-          The vast majority of Internet traffic rides over TCP or UDP

-          Generally speaking, traffic that rides over TCP does not rely on IP fragmentation

-          However, traffic the rides over UDP absolutely relies on IP fragmentation

So, as things stand, IP fragmentation is required to support UDP. However, the conversation doesn’t end at that.

Operational experience has taught us that IPv6 fragmentation does not work so well. Unlike IPv4, IPv6 encodes fragmentation information in an IPv6 extension header. Sadly, many operators discard packets containing that extension header. So, as specified, IPv6 provides fragmentation services, but as deployed, it does not.

Many end-stations work around this problem by sending packets no longer that the IPv6 minimum MTU (1280 bytes). This ensures that IPv6 fragmentation services will never be required. However, it also prevents applications and networks from realizing the benefits of larger packets.

So, the internet community has the following options:


1)      Live with the status quo / Send only packets < 1280 bytes

a.       Say nothing in the standards about the issue, beyond what has already been said

b.      Write an RFC informing developers of UDP applications of the problem and advising them not to rely on protocol MTU > 1280

c.       Deprecate IPv6 fragmentation

2)      Fix the problem / Allow end-stations to send larger packets

a.       Convince operators not to drop fragmented packets

b.      Design a UDP replacement that provides fragmentation service and migrate UPD applications to the replacement protocol

Options 2a and 2b may not achievable, because they require action on the part of many, many parties. So, we seem to be stuck with Options 1a, 1b and 1c.

In light of this, your original question is not only appropriate, it is telling.

                                                                                                        Ron



From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Alexey Eromenko
Sent: Sunday, February 07, 2016 7:47 AM
To: ietf <ietf@ietf.org>
Subject: Is Fragmentation at IP layer even needed ?

Hi All,

I'm re-evaluating TCP/IP stack again with my ongoing IP-FF research.

My question: Is packet fragmentation at IP layer even needed ?

Basically here are few possibilities:

1. Fragmentation-and-reassembly at every hop. (I don't know if anybody implements it)
2. IPv4 style-fragmentation -- fragmentation per every hop, reassembly at destination end.
3. IPv6-style-fragmentation -- fragmentation only at source end, reassembly at destination end.
4. No fragmentation at all (the advantage here: faster Router processing vs #1 or #2 and less implementation bugs); Assuming standard packet size is defined at 1280 bytes, like in IPv6
5. MTU path discovery via ICMP -- RFC-1981
6. MTU path discovery via TCP (or other Transport) -- RFC-4821 (or other way)

I'm leaning towards 4 + 6 solution in my own protocol, IP-FF.
What do you think ?
Should IP layer provide fragmentation ?

--
-Alexey Eromenko "Technologov"