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> Thu, 16 August 2012 00:45 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 2F4A421F846E for <ietf@ietfa.amsl.com>; Wed, 15 Aug 2012 17:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.051
X-Spam-Level:
X-Spam-Status: No, score=-0.051 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh6b4kx9Fi+C for <ietf@ietfa.amsl.com>; Wed, 15 Aug 2012 17:45:22 -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 6AA3921F846C for <ietf@ietf.org>; Wed, 15 Aug 2012 17:45:22 -0700 (PDT)
Received: (qmail 34253 invoked from network); 16 Aug 2012 00:44:09 -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; 16 Aug 2012 00:44:09 -0000
Message-ID: <502C427F.7090505@necom830.hpcl.titech.ac.jp>
Date: Thu, 16 Aug 2012 09:44:47 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
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> <4FE2715C.2090601@necom830.hpcl.titech.ac.jp> <4FF20DE7.2080208@isi.edu> <500654AB.7060500@necom830.hpcl.titech.ac.jp> <8F5CBE79-4540-4519-9F51-62B36686EE8C@isi.edu> <501C5C75.9040209@necom830.hpcl.titech.ac.jp> <501C6441.4000302@isi.edu> <5020C32A.4060907@necom830.hpcl.titech.ac.jp> <50215032.7090800@isi.edu> <5027767A.60601@necom830.hpcl.titech.ac.jp> <5027E8EE.8010109@isi.edu> <5028CCB9.5050503@necom830.hpcl.titech.ac.jp> <5028CFC2.1060200@isi.edu>
In-Reply-To: <5028CFC2.1060200@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: Thu, 16 Aug 2012 00:45:23 -0000

Joe Touch wrote:

>>> Again, this doc is about updating the IPv4 ID specification in RFC791 -
>>> which has not yet been updated.
>>
>> But, the way you update rfc791 requires updating rfc2460,
>> rfc2765 and their implementations, for which there is no
>> consensus.
> 
> It certainly does not.

The following requirement in your draft:

   >> Sources of non-atomic IPv4 datagrams MUST rate-limit their output
   to comply with the ID uniqueness requirements.

requires updating rfc2460 and/or rfc2765 to rate-limit IPv6
datagrams with fragment headers below 6.4 Mbps (assuming
unfragmented packet is 1500B long).

>> That is, though your draft claims to "more closely reflect
>> current practice" and "more closely match IPv6", the way you
>> update rfc791 does not "reflect current practice" nor "match
>> IPv6".
> 
> It does -

The current practice, with both IPv4 and IPv6, is to have
loose uniqueness of IDs.

Or, do you mean the current practice the practice not of
the real world network operation but of the way of
discussion in intarea WG?

> it doesn't reflect the errors in IPv6-IPv4 translation, which
> is not "IPv6".

Most, if not all, implementers do not think them errors.

						Masataka Ohta