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> Fri, 03 August 2012 23:53 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 C46B021E8082 for <ietf@ietfa.amsl.com>; Fri, 3 Aug 2012 16:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.47
X-Spam-Level:
X-Spam-Status: No, score=-105.47 tagged_above=-999 required=5 tests=[AWL=1.129, 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 fCc2KEdtqAWI for <ietf@ietfa.amsl.com>; Fri, 3 Aug 2012 16:53:03 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E9C5621E8055 for <ietf@ietf.org>; Fri, 3 Aug 2012 16:53:02 -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 q73NqXHS017277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Aug 2012 16:52:33 -0700 (PDT)
Message-ID: <501C6441.4000302@isi.edu>
Date: Fri, 03 Aug 2012 16:52:33 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
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> <4FF20DE7.2080208@isi.edu> <500654AB.7060500@necom830.hpcl.titech.ac.jp> <8F5CBE79-4540-4519-9F51-62B36686EE8C@isi.edu> <501C5C75.9040209@necom830.hpcl.titech.ac.jp>
In-Reply-To: <501C5C75.9040209@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: Fri, 03 Aug 2012 23:53:03 -0000

On 8/3/2012 4:19 PM, Masataka Ohta wrote:
> 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.

Yes, but this is not compatible with RFC791.

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

The case above occurs only when the source gets back a "packet too big"
message with a desired MTU less than 1280. Note that this might never
happen, in which case there would never be any Fragment header.

However, even when it does happen, there is no instruction above about
how to construct the header that is compliant with RFC791.

Further, the source might already be inserting the fragmentation header
(e.g., on a 2KB packet). There's no instruction in how fragment headers
are constructed in general that complies with RFC791.

Simply using the low 16 bits is not correct. In particular, RFC2460
suggests that its 32-bit counter can wrap once a minute, and that only
one such counter might be needed for an endpoint for all connections. In
that case, the entire number space wraps twice as fast as RFC791/RFC1122
require for IPv4, and it's half the bit-width, so the low-order bits
alone wrap 120,000x faster.

> Or, are you saying RFC2460 and RFC2765 violate RFC791?

Yes.

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

This document updates RFC791, but does not fix either RFC2460 or
RFC2765. This document does not make any statements about how IPv6
generates its IDs.

>>>     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 guarantees "a suitable Identification
> value" for IPv4 ID is there in IPv6 fragmentation ID.

Not the way I interpret the text, especially because there are other
ways to generate IDs in RFC2460 that could be translated to IPv4 that
might not result from ICMP errors, or that might never have
Fragmentation headers anyway.

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

I think there are a lot of IETF documents that are not reviewed in the
correct context of existing standards. I don't think that applies to
this draft, though.

Joe