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> Wed, 18 July 2012 06:15 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 0A67711E813B for <ietf@ietfa.amsl.com>; Tue, 17 Jul 2012 23:15:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.007
X-Spam-Level:
X-Spam-Status: No, score=-0.007 tagged_above=-999 required=5 tests=[AWL=0.083, 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 7s79MLOEqlOa for <ietf@ietfa.amsl.com>; Tue, 17 Jul 2012 23:15:56 -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 287A711E812F for <ietf@ietf.org>; Tue, 17 Jul 2012 23:15:55 -0700 (PDT)
Received: (qmail 89470 invoked from network); 18 Jul 2012 06:20:30 -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; 18 Jul 2012 06:20:30 -0000
Message-ID: <500654AB.7060500@necom830.hpcl.titech.ac.jp>
Date: Wed, 18 Jul 2012 15:16:11 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.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> <4FE2715C.2090601@necom830.hpcl.titech.ac.jp> <4FF20DE7.2080208@isi.edu>
In-Reply-To: <4FF20DE7.2080208@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: Wed, 18 Jul 2012 06:15:57 -0000

Joe Touch wrote:

>> Or, are 6 to 4 translators are required to rate limit and
>> drop rate-violating packets to make the "stateless"
>> translators full of states.
>
> I would expect that the translator would be responsible
> for this, though

Do you mean translators must rate limit, or translators
violate RFC2765:

>>            Identification:
>>                    Copied from the low-order 16-bits in the
>>                    Identification field in the Fragment header.

and use some other number as an ID?

> there is the problem that multiple translators interfere
> with each other.

Yes, even rate limiting translators may interfere each other,
which means rate limiting must be done at the IPv6 source
node.

> Regardless, this is outside the scope of the ipv4-id-update doc.

In the ID, there are a lot of references to IPv6.

For example, the following statement of the ID:

   Finally, the IPv6 ID field is
   32 bits, and required unique per source/destination address pair for
   IPv6, whereas for IPv4 it is only 16 bits and required unique per
   source/destination/protocol triple.

must be modified as:

   Finally, the IPv6 ID field is
   32 bits, but lower 16 bits are required unique per
   source/destination address pair for
   IPv6, whereas for IPv4 it is only 16 bits and required unique per
   source/destination/protocol triple.

						Masataka Ohta