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

Masataka Ohta <> Tue, 07 August 2012 07:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5732321F85F3 for <>; Tue, 7 Aug 2012 00:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.043
X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C-Ll3l1nakzl for <>; Tue, 7 Aug 2012 00:27:23 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 396D821F85D8 for <>; Tue, 7 Aug 2012 00:27:20 -0700 (PDT)
Received: (qmail 72827 invoked from network); 7 Aug 2012 07:36:52 -0000
Received: from (HELO ? ( by with SMTP; 7 Aug 2012 07:36:52 -0000
Message-ID: <>
Date: Tue, 07 Aug 2012 16:26:34 +0900
From: Masataka Ohta <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Joe Touch <>
Subject: Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Aug 2012 07:27:24 -0000

Joe Touch wrote:

>> RFC2765 specifies that translators can merely copy the
>> low-order bits of the field.
> Yes, but this is not compatible with RFC791.

Then, which should we revice? RFC791, RFC2765 or both?

Without such a decision, there is no point to publish something
based on RFC791 and is not compatible with RFC2765.

> The case above occurs only when the source gets back a "packet too big"
> message with a desired MTU less than 1280.

which means RFC2460 expects it.

> Note that this might never
> happen, in which case there would never be any Fragment header.

If you can assume so, let's better assume that accidental ID
match never happen and we all can be very happy.

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

That is the problem. That is, if you insist on RFC791 as is, not
enough is specified on how to generate IPv6 ID.

> Further, the source might already be inserting the fragmentation header
> (e.g., on a 2KB packet).

Thus, there can be only one way (the one in RFC2765) to map IPv6
ID to IPv4 ID

Or, if multiple IPv6 fragments with same ID use different IPv4
translators with different mapping algorithm, each IPv6
fragments will have different IPv4 IDs.

> There's no instruction in how fragment headers
> are constructed in general that complies with RFC791.

Is it a problem of RFC791 or RFC2460/2765?

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

Never mind.

IPv6 specification is not self consistent at all.

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

Then, as fixing RFC2460 is politically impossible, we must
abandone IPv6 and live with IPv4 forever.

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

You draft says:

   This document updates the specification of the IPv4 ID field to more
   closely reflect current practice, and to include considerations taken
   into account during the specification of the similar field in IPv6.

but, "the specification of the similar field in IPv6" is, in
your opinion, incomplete, let's finish it first, only after
which you can revise your draft "to include considerations
taken into account during the specification of the similar
field in IPv6."

More specifically, for example, the following statement in your draft:

   The latter case is relevant only for
   IPv6 datagrams sent to IPv4 destinations to support subsequent
   fragmentation after translation to IPv4.

is incorrect because NAT646 refer RFC2765.

For another example,

   Finally, the IPv6 ID field is
   32 bits, and required unique per source/destination address pair for

is, in your opinion, violation of RFC791.

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

As I stated above, there can be only one way common to all the
6->4 translators. Or, different fragments with an IPv6 ID will
have different IPv4 IDs.

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

So, you are lucky that I have noticed the problem at the last call.

						Masataka Ohta