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> Fri, 15 June 2012 16:52 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 4F14B21F8592 for <ietf@ietfa.amsl.com>; Fri, 15 Jun 2012 09:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 SPlbhkz2aIAR for <ietf@ietfa.amsl.com>; Fri, 15 Jun 2012 09:52:32 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 93A1921F856F for <ietf@ietf.org>; Fri, 15 Jun 2012 09:52:31 -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 q5FGqJuO014349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Jun 2012 09:52:19 -0700 (PDT)
Message-ID: <4FDB6843.6090107@isi.edu>
Date: Fri, 15 Jun 2012 09:52:19 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
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> <4FC96ACA.9040800@isi.edu> <4FC97E57.6070505@necom830.hpcl.titech.ac.jp> <4FCEAB53.2020504@isi.edu> <4FDB12F2.6030808@necom830.hpcl.titech.ac.jp>
In-Reply-To: <4FDB12F2.6030808@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: Fri, 15 Jun 2012 16:52:33 -0000

Masataka,

On 6/15/2012 3:48 AM, Masataka Ohta wrote:
> 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.

That is not an innocent action. It defeats PMTUD, which is a draft
standard. It also violates RFC 791 and 1121.

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

This document only restates existing requirements in this regard,
stating them in 2119-language. It does not create any new requirement.
Operates that clear the DF bit are already in violation of three
standards-track RFCs.

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

I disagree; if they wanted to do so, they already would have acted since
the requirements already exist, albeit in pre-RFC2199 language.

Joe

> 
> 					Masataka Ohta