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

Joe Touch <> Sun, 12 August 2012 17:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5834D21F85D7 for <>; Sun, 12 Aug 2012 10:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.507
X-Spam-Status: No, score=-103.507 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lplWnAefzPU6 for <>; Sun, 12 Aug 2012 10:34:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 806EC21F85EF for <>; Sun, 12 Aug 2012 10:34:07 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id q7CHXawE005478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Aug 2012 10:33:40 -0700 (PDT)
Message-ID: <>
Date: Sun, 12 Aug 2012 10:33:34 -0700
From: Joe Touch <>
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 <>
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-ISI-4-43-8-MailScanner: Found to be clean
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: Sun, 12 Aug 2012 17:34:08 -0000

Again, this doc is about updating the IPv4 ID specification in RFC791 -
which has not yet been updated.

The IPv6-IPv4 translation that creates IPv4 IDs is currently
non-compliant with RFC791 and does not override RFC791. This document's
update might make that translation easier, but it doesn't make it worse
- which is why there remains no need to address that issue in this doc.

If you disagree with that conclusion, please contact the INTAREA WG
chairs directly.


On 8/12/2012 2:25 AM, Masataka Ohta wrote:
> Joe Touch wrote:
> Hi,
>>>>> 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?
>> 2765.
> Is it a consensus of IETF?
> Note that it also imply revising RFC2460, because rfc2765 specifies
> a way of ID mapping, where as rfc2460 specifies 32bit->16bit mapping
> will be performed by translators.
> Note also that there already are working implementations of
> rfc2460 and rfc2765.
>> There is no useful way to revise 791 to make the text in 2765 correct.
> Revising rfc791 not requiring a very strong uniqueness is
> useful reflecting current practice better than your draft,
> even though your draft claims "closely reflect current
> practice".
> Moreover, I can see no useful way to revise rfc2765. Do you
> have any suggestion?
>>> Without such a decision, there is no point to publish something
>>> based on RFC791 and is not compatible with RFC2765.
>> Sure there is - when IPv6 is not involved.
> But, your draft involves IPv6 and, for example, the following
> statement in your draft:
>     IPv6, even at typical MTUs, is capable of 18.7 Tbps with
>     fragmentation between two IP endpoints as an aggregate across all
>     protocols,
> is not compatible with rfc2460 and rfc2765.
>> An IPv6 source might never send packets larger than IPv4 can natively
>> handle - i.e., it could send packets 576 bytes or smaller. In that case,
>> the IPv6 source would never get an ICMP "too big" because they're not as
>> far as IPv4 is concerned. In that case, the IPv6 source would never
>> insert the Fragmentation Header.
> I'm afraid minimum MTU of IPv4 is 68, not 576 bytes.
> Anyway, IPv6 node having no idea on PMTU will send a lot of
> exactly 1280 byte long packets, because it will make TCP
> most efficient.
>> That is the fundamental flaw in these IPv6 RFCs, but it is behavior that
>> is out of scope for an IPv4 source. My doc focuses on the behavior of
>> IPv4 sources.
> While I think IPv6 RFCs have many fundamental flaws, a problem
> is that there are people in IETF insisting not to admit them
> flaws.
> Do you think you can make them admit a flaw?
>>> That is the problem. That is, if you insist on RFC791 as is, not
>>> enough is specified on how to generate IPv6 ID.
>> Yes, but that does not affect an IPv4 source; it remains a problem, but
>> out of scope for this doc.
> It is out of scope, if only rfc791 is not revised.
>>> Thus, there can be only one way (the one in RFC2765) to map IPv6
>>> ID to IPv4 ID
>> Yes, this is a nice goal, but it would have required IPv6 hosts insert
>> 16-bit IDs into *every* packet and make them just as unique as IPv4 does.
> No, not *every* packet. But, as you wrote:
>>>> Further, the source might already be inserting the fragmentation header
>>>> (e.g., on a 2KB packet).
> every such packet is required to have a unique 32bit ID which must
> also be unique as a 16bit ID after translation.
>>> Then, as fixing RFC2460 is politically impossible, we must
>>> abandone IPv6 and live with IPv4 forever.
>> I didn't say we couldn't fix - or at least try to fix - this situation.
>> But it remains out of scope for this doc.
> If only you can convince people we should fix rfc2460, not rfc791.
>>> but, "the specification of the similar field in IPv6" is, in
>>> your opinion, incomplete, let's finish it first,
>> IPv6 is fine when it talks to IPv6 only. The goal is to make IPv4 work
>> in a similar way.
> You are saying dual stack is clean and the way to go and all the
> other IPv6 deployment scenarios should be ignored.
>> it doesn't make it completely correct, though - there remain
>> problems that have nothing to do with the changes in this doc that need
>> to be addressed separately.
> The question is whether you can have a consensus that rfc2460
> is not completely correct or not.
>>> For another example,
>>>       Finally, the IPv6 ID field is
>>>       32 bits, and required unique per source/destination address pair for
>>>       IPv6,
>>> is, in your opinion, violation of RFC791.
>> No; the violation occurs only when the lower 16 bits are masked off and
>> used by themselves by on-path translators. That has nothing to do with
>> the quoted text above.
> The problem is that, if rfc2460 is not "completely correct", above
> text in your draft should be something based not on the current
> rfc2460 but on completely correctly revised rfc2460, such as
> "IPv6 ID field is required unique after translated into 16 bit
> IPv4 ID".
>> But neither of the above requires that IPv6 IDs must be easily
>> translatable into valid IPv4 addresses using the existing mechanism.
> IPv4 addresses? What do you mean?
> 						Masataka Ohta