Re: Is Fragmentation at IP layer even needed ?

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 10 February 2016 10:29 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 D9C9E1A1A6C for <ietf@ietfa.amsl.com>; Wed, 10 Feb 2016 02:29:56 -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 9KrQqfMmtuRT for <ietf@ietfa.amsl.com>; Wed, 10 Feb 2016 02:29:53 -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 EE9A31A1A64 for <ietf@ietf.org>; Wed, 10 Feb 2016 02:29:52 -0800 (PST)
Received: (qmail 23973 invoked from network); 10 Feb 2016 10:10:38 -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 10:10:38 -0000
Subject: Re: Is Fragmentation at IP layer even needed ?
To: Fernando Gont <fgont@si6networks.com>, 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> <56BAD346.6090601@necom830.hpcl.titech.ac.jp> <56BAE126.5050302@si6networks.com> <56BAEBC6.3050003@necom830.hpcl.titech.ac.jp> <56BAF3F5.8030709@si6networks.com>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-ID: <56BB111C.3050903@necom830.hpcl.titech.ac.jp>
Date: Wed, 10 Feb 2016 19:29:48 +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: <56BAF3F5.8030709@si6networks.com>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/ub2prVoG9VTwV02RR5McXaXbMNU>
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 10:29:57 -0000

Fernando Gont wrote:

>> Moreover, the rfc should also limit header chain length below
>> 256B or so.
> 
> I tried that in 6man, but there was opposition to my proposal at the time.

OK, collective stupidity of IPv6 committee is same as I tried
it about 20 years ago.

>> Worse, though the rfc require an entire upper layer header
>> included in the first fragment, the requirement is too much.
> 
> Not sure what you mean.

After the last mail, I have noticed that this is a serious defect
of the rfc.

That is, if an upper layer protocol is not known to some box,
the box has no idea on how long is the header, which
means the box is now authorized to discard the packet, even if
actual header length is small and no extension header exist.

One thing we should learn from the glorious history of IPv4
is meaning of specification in rfc792 that:

  |      Internet Header + 64 bits of Original Data Datagram      |

which makes ICMP implementation independent from upper
layer header structure and requires upper layer specifications
contain port number (or something like that) information in
the first 8B of their headers.

>> According to rfc792, the first 8B should be enough. As for
>> ICMPv6, ICMPv6 should also be required to contain all the
>> header chain up to the first 8B of an upper layer header.
> 
> ... which may not be feasible if a long EH chain is employed in the
> packet that generated the error message.

That's one of a reason why long EH must be banned.

						Masataka Ohta