Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sun, 03 June 2012 19:13 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250F521F85FD for <ietf@ietfa.amsl.com>; Sun, 3 Jun 2012 12:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUWHRnkxSabR for <ietf@ietfa.amsl.com>; Sun, 3 Jun 2012 12:13:26 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 568D621F85FC for <ietf@ietf.org>; Sun, 3 Jun 2012 12:13:26 -0700 (PDT)
Received: (qmail 15355 invoked from network); 3 Jun 2012 19:14:21 -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; 3 Jun 2012 19:14:21 -0000
Message-ID: <4FCBB71E.9080209@necom830.hpcl.titech.ac.jp>
Date: Mon, 04 Jun 2012 04:12:30 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard
References: <20120531143816.30508.66250.idtracker@ietfa.amsl.com> <Pine.LNX.4.64.1205311957420.31608@shell4.bayarea.net> <4FC9585E.6010205@necom830.hpcl.titech.ac.jp> <Pine.LNX.4.64.1206022127550.17026@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.64.1206022127550.17026@shell4.bayarea.net>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sun, 03 Jun 2012 19:13:27 -0000

C. M. Heard wrote:

>> Existing routers, which was relying on ID uniqueness of atomic
>> packets, are now broken when they fragment the atomic packets.
> 
> Such routers were always broken.  An atomic packet has DF=0 and any
> router fragmenting such a packet was and is non-compliant with
> the relevant specifications (RFCs 791, 1122, 1812).

Thank you. I have overlooked that atomic implied DF=1.

But, then,

   >> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
   values within one MSL for a given source address/destination
   address/protocol triple.

makes most, if not all, IPv4 hosts non compliant if MSL=2min.

Worse, without hard value of MSL, it is a meaningless
requirement. Note that MSL=2min derived from RFC793 breaks
150Mbps TCP.

The proper solution, IMHO, to the ID uniqueness is to request
a destination host drop fragments from a source host after
it receives tens (or hundreds) of packets with different IDs
from the same source host.

A source host, then, is only required to remember the
previous ID used for each destination.

						Masataka Ohta