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> Wed, 18 July 2012 18:29 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 6861411E813B for <ietf@ietfa.amsl.com>; Wed, 18 Jul 2012 11:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.477
X-Spam-Level:
X-Spam-Status: No, score=-105.477 tagged_above=-999 required=5 tests=[AWL=1.122, 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 IYlSjwKhvZUE for <ietf@ietfa.amsl.com>; Wed, 18 Jul 2012 11:29:15 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E366011E8132 for <ietf@ietf.org>; Wed, 18 Jul 2012 11:29:14 -0700 (PDT)
Received: from c1-vpn9.isi.edu (c1-vpn9.isi.edu [128.9.176.39]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q6IITlou005551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Jul 2012 11:29:47 -0700 (PDT)
Subject: Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=iso-2022-jp
From: Joe Touch <touch@isi.edu>
In-Reply-To: <500654AB.7060500@necom830.hpcl.titech.ac.jp>
Date: Wed, 18 Jul 2012 11:29:55 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F5CBE79-4540-4519-9F51-62B36686EE8C@isi.edu>
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>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
X-Mailer: Apple Mail (2.1278)
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: Wed, 18 Jul 2012 18:29:15 -0000

On Jul 17, 2012, at 11:16 PM, Masataka Ohta wrote:

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

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.

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

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.

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

That's incorrect as per RFC2460. Other RFCs may violate that original spec, but that needs to be cleaned up separately.

Joe