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

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Tue, 19 June 2012 00:59 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 C15CB21F86BE for <ietf@ietfa.amsl.com>; Mon, 18 Jun 2012 17:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.016
X-Spam-Level:
X-Spam-Status: No, score=0.016 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 SiI2gz2BNmJ1 for <ietf@ietfa.amsl.com>; Mon, 18 Jun 2012 17:59:09 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id E63BB21F86B8 for <ietf@ietf.org>; Mon, 18 Jun 2012 17:59:08 -0700 (PDT)
Received: (qmail 23297 invoked from network); 19 Jun 2012 01:04:23 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 19 Jun 2012 01:04:23 -0000
Message-ID: <4FDFCE8D.8090403@necom830.hpcl.titech.ac.jp>
Date: Tue, 19 Jun 2012 09:57:49 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>, ietf@ietf.org
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> <4FC96ACA.9040800@isi.edu> <4FC97E57.6070505@necom830.hpcl.titech.ac.jp> <4FCEAB53.2020504@isi.edu> <4FDB12F2.6030808@necom830.hpcl.titech.ac.jp> <4FDB6843.6090107@isi.edu> <4FDBE75A.8090100@necom830.hpcl.titech.ac.jp> <4FDBEACA.4030701@isi.edu> <4FDC1F9C.2060808@necom830.hpcl.titech.ac.jp> <79E3C9F8-3A0F-4BD7-B018-A508D439ED57@isi.edu> <4FDF219D.5020201@necom830.hpcl.titech.ac.jp> <4FDF783F.2030104@isi.edu>
In-Reply-To: <4FDF783F.2030104@isi.edu>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
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, 19 Jun 2012 00:59:09 -0000

Joe Touch wrote:

>> While your draft is rather harmful than useless, I'm fine
>> if the following point of the draft:
>>
>>      >>   Originating sources MAY set the IPv4 ID field of atomic
>>      datagrams to any value.
>>
>> is changed to:
>>
>>      >>   Originating sources MUST set the IPv4 ID field of atomic
>>      datagrams to values as unique as possible.
>>
>> which is what the current BSD implementations do.
> 
> There are implementations that set DF=1 and ID=0 (cellphones).

They are broken implementations violating RFC791.

To quote from RFC1122:

   1.2  General Considerations

      There are two important lessons that vendors of Internet host
      software have learned and which a new vendor should consider
      seriously.


      1.2.2  Robustness Principle

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability [IP:1]:

                "Be liberal in what you accept, and
                 conservative in what you send"


         The second part of the principle is almost as important:
         software on other hosts may contain deficiencies that make it
         unwise to exploit legal but obscure protocol features.  It is
         unwise to stray far from the obvious and simple, lest untoward
         effects result elsewhere.  A corollary of this is "watch out
         for misbehaving hosts"; host software should be prepared, not
         just to survive other misbehaving hosts, but also to cooperate
         to limit the amount of disruption such hosts can cause to the
         shared communication facility.

it is obvious that your draft violates the robustness principle.

> BSD does not make IDs as unique as possible; it selects them according
> to a pseudorandom algorithm that does not take into account the
> datagram's source IP, destination IP, or protocol. I.e., BSD code
> repeats the IDs more frequently than necessary when a host concurrently
> sources datagrams with different (srcIP, dstIP, proto) tuples.

You merely mean BSD code does not try to make ID unique for
the longest possible MSL and the fastest possible packet rate,
which is not my point.

As the uniqueness is broken at some MSL and rate anyway, the
current code is enough to be "as unique as possible".

						Masataka Ohta