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> Sat, 02 June 2012 02:47 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 D3EC511E8110 for <ietf@ietfa.amsl.com>; Fri, 1 Jun 2012 19:47:03 -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 AhEB-b21faDa for <ietf@ietfa.amsl.com>; Fri, 1 Jun 2012 19:47:03 -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 ED11711E808C for <ietf@ietf.org>; Fri, 1 Jun 2012 19:47:02 -0700 (PDT)
Received: (qmail 98108 invoked from network); 2 Jun 2012 02:47: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; 2 Jun 2012 02:47:21 -0000
Message-ID: <4FC97E57.6070505@necom830.hpcl.titech.ac.jp>
Date: Sat, 02 Jun 2012 11:45:43 +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: Joe Touch <touch@isi.edu>
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> <4FC96ACA.9040800@isi.edu>
In-Reply-To: <4FC96ACA.9040800@isi.edu>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
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: Sat, 02 Jun 2012 02:47:04 -0000

Joe Touch wrote:

>> Existing routers, which was relying on ID uniqueness of atomic
>> packets, are now broken when they fragment the atomic packets.

> The recommendation in this doc - that such sources MUST rate-limit - is
> to comply with the ID uniqueness requirements already in RFC791 that
> this doc does not deprecate - e.g., its use to support fragmentation.

It means that the uniqueness requirements must be loosened.

Another example is that, when route changes, routers
fragmenting atomic packets may change, which means rate
limiting does not guarantee ID uniqueness.

> We all recognize that there are plenty of non-compliant NAT boxes

Rest of my examples are plain routers, which has been fully
compliant.

>>    Is there some document provided to obsolete the following:
>>
>>      The IPv6 fragment header is present
>>
>>      when the source has received
>>      a "packet too big" ICMPv6 error message when the path cannot support
>>      the required minimum 1280-byte IPv6 MTU and is thus subject to
>>      translation
>>
>>    which is meaningless from the beginning, because length of
>>    IPv6 ID is 32 bit, from which it is impossible to generate
>>    unique IPv4 ID.
> 
> None of which I am aware.

There should be. May I volunteer?

						Masataka Ohta