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, 21 June 2012 00:58 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 B213211E80A0 for <ietf@ietfa.amsl.com>; Wed, 20 Jun 2012 17:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[AWL=0.093, 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 rHkbpBvamI7w for <ietf@ietfa.amsl.com>; Wed, 20 Jun 2012 17:58:07 -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 C94CE11E8079 for <ietf@ietf.org>; Wed, 20 Jun 2012 17:58:06 -0700 (PDT)
Received: (qmail 71234 invoked from network); 21 Jun 2012 01:04:07 -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; 21 Jun 2012 01:04:07 -0000
Message-ID: <4FE2715C.2090601@necom830.hpcl.titech.ac.jp>
Date: Thu, 21 Jun 2012 09:57:00 +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: 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>
In-Reply-To: <4FC9585E.6010205@necom830.hpcl.titech.ac.jp>
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: Thu, 21 Jun 2012 00:58:07 -0000

Though the ID states:

   This
   document underscores the point that not only is reassembly (and
   possibly subsequent fragmentation) required for translation, it can
   be used to avoid issues with IPv4 ID uniqueness.

according to RFC2765, which does not need port numbers for
address mapping:

   If the IPv6 packet contains a Fragment header the header fields are
   set as above with the following exceptions:

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

         Flags:
                 The More Fragments flag is copied from the M flag in
                 the Fragment header.  The Don't Fragments flag is set
                 to zero allowing this packet to be fragmented by IPv4
                 routers.

the translated IPv4 packets are not atomic with 16bit IDs.

Note that the RFC is referred by NAT646 etc.

Then, aren't IPv6 nodes are required to rate limit packets
they generate with fragment headers assuming 16bit IDs?

Or, are 6 to 4 translators are required to rate limit and
drop rate-violating packets to make the "stateless"
translators full of states.

Or?

						Masataka Ohta

PS

As the RFC specifies ID=0 when DF is set 0, it should also
be updated to conform to the robustness principle.