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> Sun, 12 August 2012 17:34 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 5834D21F85D7 for <ietf@ietfa.amsl.com>; Sun, 12 Aug 2012 10:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.507
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lplWnAefzPU6 for <ietf@ietfa.amsl.com>; Sun, 12 Aug 2012 10:34:07 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 806EC21F85EF for <ietf@ietf.org>; Sun, 12 Aug 2012 10:34:07 -0700 (PDT)
Received: from [128.9.176.29] (c1-vpn3.isi.edu [128.9.176.29]) (authenticated bits=0) by vapor.isi.edu (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: <5027E8EE.8010109@isi.edu>
Date: Sun, 12 Aug 2012 10:33:34 -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> <501C6441.4000302@isi.edu> <5020C32A.4060907@necom830.hpcl.titech.ac.jp> <50215032.7090800@isi.edu> <5027767A.60601@necom830.hpcl.titech.ac.jp>
In-Reply-To: <5027767A.60601@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: 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.

Joe

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
>