Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard

Joe Touch <touch@isi.edu> Mon, 02 July 2012 21:09 UTC

Return-Path: <touch@isi.edu>
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 76C9A21F861E for <ietf@ietfa.amsl.com>; Mon, 2 Jul 2012 14:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.702
X-Spam-Level:
X-Spam-Status: No, score=-105.702 tagged_above=-999 required=5 tests=[AWL=0.897, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 K59ggr6GUQNV for <ietf@ietfa.amsl.com>; Mon, 2 Jul 2012 14:09:42 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id BBFE421F8608 for <ietf@ietf.org>; Mon, 2 Jul 2012 14:09:38 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q62L8ura024895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jul 2012 14:08:56 -0700 (PDT)
Message-ID: <4FF20DE7.2080208@isi.edu>
Date: Mon, 02 Jul 2012 14:08:55 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
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>
In-Reply-To: <4FE2715C.2090601@necom830.hpcl.titech.ac.jp>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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: Mon, 02 Jul 2012 21:09:42 -0000

Hi,

On 6/20/2012 5:57 PM, Masataka Ohta wrote:
> 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.

I would expect that the translator would be responsible for this, though
there is the problem that multiple translators interfere with each other.

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

> 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.

That is an error in this RFC, which also is outside the scope of the
ipv4-id-update doc.

Joe