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> Tue, 07 August 2012 17:28 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 3630421F86D1 for <ietf@ietfa.amsl.com>; Tue, 7 Aug 2012 10:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.489
X-Spam-Level:
X-Spam-Status: No, score=-105.489 tagged_above=-999 required=5 tests=[AWL=1.110, 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 fECWlZLqYT5Z for <ietf@ietfa.amsl.com>; Tue, 7 Aug 2012 10:28:52 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5558E21F86D0 for <ietf@ietf.org>; Tue, 7 Aug 2012 10:28:52 -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 q77HSIYw010963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Aug 2012 10:28:18 -0700 (PDT)
Message-ID: <50215032.7090800@isi.edu>
Date: Tue, 07 Aug 2012 10:28:18 -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>
In-Reply-To: <5020C32A.4060907@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: Tue, 07 Aug 2012 17:28:53 -0000

Hi,

On 8/7/2012 12:26 AM, Masataka Ohta wrote:
> 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?

2765.

There is no useful way to revise 791 to make the text in 2765 correct.

> 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. That is the case for
ipv4-id-update. At best it makes things a little better for some cases
of IPv6-IPv4 translation - which can be noted - but it does not correct
for the failings of 2765, which are out of scope.

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

My words were ambiguous; permit me to clarify:

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.

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.

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

Yes, but that does not affect an IPv4 source; it remains a problem, but
out of scope for this doc.

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

I have no idea why the fantasy exists that IPv6 packets MUST be
translatable into IPv4 based on the existing specs. As specified in
RFC2460, this simply isn't the case.

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.

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

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.

Correct - not regarding translation to IPv4. That's what I've been
trying to say ;-)

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

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.

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

IPv6 is fine when it talks to IPv6 only. The goal is to make IPv4 work
in a similar way.

The goal is NOT to deal with translation. IPv6-IPv4 translation has two
directions - IPv4->IPv6 (which might be in scope for this doc, but isn't
really affected by the changes - we can add a statement on that) and
IP6->IPv4 (this doc similarly doesn't break that; if anything, it makes
it easier. 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.

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

That will be fixed, yes.

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

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

That's true.

> Or, different fragments with an IPv6 ID will
> have different IPv4 IDs.

Also true.

But neither of the above requires that IPv6 IDs must be easily
translatable into valid IPv4 addresses using the existing mechanism.

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

I am lucky that you are raising these issues for two reasons:

1) it provides an opportunity to explain some of the related issues in
this doc, as noted above

2) it provides a motivation to address ID issues for IPv6-IPv4
translation in a separate document, since they're out of scope for this one.

So yes, this has been helpful.

Joe