Re: Is Fragmentation at IP layer even needed ?

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 10 February 2016 06:06 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 88C3C1B377A for <ietf@ietfa.amsl.com>; Tue, 9 Feb 2016 22:06:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.608
X-Spam-Level:
X-Spam-Status: No, score=0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.001] autolearn=no
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 KAx9Yfdgeec3 for <ietf@ietfa.amsl.com>; Tue, 9 Feb 2016 22:06:03 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 135FC1B3775 for <ietf@ietf.org>; Tue, 9 Feb 2016 22:06:02 -0800 (PST)
Received: (qmail 20870 invoked from network); 10 Feb 2016 05:46:48 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 10 Feb 2016 05:46:48 -0000
Subject: Re: Is Fragmentation at IP layer even needed ?
To: ietf@ietf.org
References: <CAOJ6w=EvzE3dM4Y2mFFR=9YyPBdmFu_jkF4-42LjkdbRd3yz_w@mail.gmail.com> <BLUPR05MB1985F5F2BB3118362C67B921AED50@BLUPR05MB1985.namprd05.prod.outlook.com> <20160208200943.A615941B5B96@rock.dv.isc.org> <CAMm+LwgLoYpQ1TNOTOuJzh+cu+GyRBf9=y_K7K35boQ9WcZKjA@mail.gmail.com> <56B92A96.9050200@si6networks.com> <CAMm+LwifTXvVd1mPZOfcOOR03Fnj-82H9aDVS01=wGezePtnXw@mail.gmail.com> <56BA4BC7.1010002@isi.edu> <CAMm+Lwi-n=be4AWGibs+Zq9egYw5pSDmPGb-4P0LDEcX1E6osA@mail.gmail.com> <56BA68CE.7090304@isi.edu>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-ID: <56BAD346.6090601@necom830.hpcl.titech.ac.jp>
Date: Wed, 10 Feb 2016 15:05:58 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56BA68CE.7090304@isi.edu>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/O4z_W_JoKxMrfZHdU0O78p0nr3Y>
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: Wed, 10 Feb 2016 06:06:04 -0000

Joe Touch wrote:

> Reason #1: IP reassembly is already deployed.

The reality is that wise operators denied deployment of
stupid idea of extension headers including that for IP
reassembly.

> 	- now you want that info even further obscured by another
> 	layer of encapsulation

Wrong. The worst kind of obscurity is a transport header at
the end of a chain of 1000 or more IPv6 extension headers.

Note that the transport header may not be placed in the
first fragment.

As following a long chain means vulnerability to DOS, there
should be some upper bound on the chain length and the most
reasonable value for the upper bound is 0, because all the
extension headers are useless.

						Masataka Ohta