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> Fri, 15 June 2012 10:49 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 4B56321F854D for <ietf@ietfa.amsl.com>; Fri, 15 Jun 2012 03:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.399
X-Spam-Level: *
X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 KfWrtDSj4IuD for <ietf@ietfa.amsl.com>; Fri, 15 Jun 2012 03:49:31 -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 F224221F853D for <ietf@ietf.org>; Fri, 15 Jun 2012 03:49:30 -0700 (PDT)
Received: (qmail 80776 invoked from network); 15 Jun 2012 10:53:50 -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; 15 Jun 2012 10:53:50 -0000
Message-ID: <4FDB12F2.6030808@necom830.hpcl.titech.ac.jp>
Date: Fri, 15 Jun 2012 19:48:18 +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>
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>
In-Reply-To: <4FCEAB53.2020504@isi.edu>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
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: Fri, 15 Jun 2012 10:49:32 -0000

After thinking more about the draft, I think it is
purposelessly hostile against innocent operators and
end users who are suffering between people filtering
ICMP and people insisting on PMTUD.

Today, innocent operators often clear DF bit and
end users are happy with it, because, today, probability
of accidental ID match is small enough.

However, as the ID specifies:

   >> Originating sources MAY set the IPv4 ID field of atomic datagrams
   to any value.

   >> IPv4 datagram transit devices MUST NOT clear the DF bit.

people insisting on PMTUD are now authorized to set ID always
zero, trying to discourage ICMP filtering and DF bit clearing.

But, as people filtering ICMP won't stop doing so and if
operators can do nothing other than clearing DF, it is
end users who suffers.

Then, end users may actively act against PMTUD and/or IETF.

					Masataka Ohta