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> Fri, 03 August 2012 23:19 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 2F73521F8DCA for <ietf@ietfa.amsl.com>; Fri, 3 Aug 2012 16:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.04
X-Spam-Level:
X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[AWL=0.050, 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 fVDSQVFJCmX3 for <ietf@ietfa.amsl.com>; Fri, 3 Aug 2012 16:19:44 -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 E112721F8DC9 for <ietf@ietf.org>; Fri, 3 Aug 2012 16:19:43 -0700 (PDT)
Received: (qmail 12828 invoked from network); 3 Aug 2012 23:28:28 -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 Aug 2012 23:28:28 -0000
Message-ID: <501C5C75.9040209@necom830.hpcl.titech.ac.jp>
Date: Sat, 04 Aug 2012 08:19:17 +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>
In-Reply-To: <8F5CBE79-4540-4519-9F51-62B36686EE8C@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: Fri, 03 Aug 2012 23:19:45 -0000

Joe Touch wrote:

> Translators violate RFC791. They cannot merely copy the
> low-order bits of the field, since that is insufficiently
> unique, and isn't specified as being generated at the
> IPv6 source in compliance with IPv4 requirements.

RFC2765 specifies that translators can merely copy the
low-order bits of the field.

Moreover, RFC2460 specifies:

   In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments.

That is, RFC2460 guarantees that translators can obtain "a
suitable Identification value" from IPv6 "Fragment header".

Or, are you saying RFC2460 and RFC2765 violate RFC791?

I'm afraid you must say so, if you insist on "existing systems
violate the current specification" (quote from abstract of your
draft).

> It quotes IPv6 examples, but does not propose to change
> IPv6 processing. That may be needed, but that would be
> outside the scope of this doc.

It is inside the scope because RFC2765 specifies how IPv4
ID is generated from RFC2460 fragment header, which is,
according to your draft, a violation of RFC791.

>>    Finally, the IPv6 ID field is
>>    32 bits, but lower 16 bits are required unique per
>>    source/destination address pair for
>>    IPv6,
> 
> That's incorrect as per RFC2460. Other RFCs may violate that
> original spec, but that needs to be cleaned up separately.

As I stated above, RFC2460 gurantees "a suitable Identification
value" for IPv4 ID is there in IPv6 fragmentation ID.

Or, if you think RFC2460 does not mind ID uniqueness (of IPv4,
at least) so much, RFC791 should not either.

						Masataka Ohta