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> Sat, 16 June 2012 02:10 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 2D91811E8083 for <ietf@ietfa.amsl.com>; Fri, 15 Jun 2012 19:10:03 -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 e84FMwfxdxLb for <ietf@ietfa.amsl.com>; Fri, 15 Jun 2012 19:10:02 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 236FA11E8072 for <ietf@ietf.org>; Fri, 15 Jun 2012 19:10:02 -0700 (PDT)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5G29EOh001475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Jun 2012 19:09:14 -0700 (PDT)
Message-ID: <4FDBEACA.4030701@isi.edu>
Date: Fri, 15 Jun 2012 19:09:14 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.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> <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>
In-Reply-To: <4FDBE75A.8090100@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: Sat, 16 Jun 2012 02:10:03 -0000

Masataka,

On 6/15/2012 6:54 PM, Masataka Ohta wrote:
> Joe Touch 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 is a fair action by innocent providers.

It is a violation of standards. They may do it innocently, but it's
still a violation. This document doesn't make it more of a violation; it
just explains the existing violation.

>> It defeats PMTUD, which is a draft
>> standard.
> 
> So, the proper thing for IETF to do is to obsolete RFC1191.
>
> There is no reason for IETF to ignore operational feedback
> from the real world that RFC1191 is a bad idea.

That is not the focus of this document. Again, we don't create a new
requirement.  If you feel there is consensus to raise this change, that
would be a separate issue.

>> It also violates RFC 791 and 1121.
> 
> To stop the fair violation, obsolete RFC1191.

The steps needed to allow DF clearing need to be determined; I don't
know what they are, but that's outside the scope of this doc.

>> This document only restates existing requirements in this regard,
> 
>     >>   Originating sources MAY set the IPv4 ID field of atomic datagrams
>     to any value.
> 
> is not a restatement of existing requirements.

I will be more clear:

- regarding clearing the DF bit, this document only restates existing
requirements

Yes, there are other, new requirements that this document introduces.
But the rules about not clearing the DF bit are not new.

>> 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.
> 
> That many operators are actively violating the standard track
> RFCs means the standard track RFCs are defective.

Or that they have defective equipment, or that their logic in deciding
to run their equipment this way is defective. Just because "everyone
does it" doesn't make it correct or warrant changing the specs (see RFC
2525 for treatment of TCP implementation errors, e.g.).

>>> 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.
> 
> As your draft actively tries to change the current situation
> that:
> 
>>> Today, innocent operators often clear DF bit and
>>> end users are happy with it, because, today, probability
>>> of accidental ID match is small enough.
> 
> it is not surprising if end users think you are guilty.

Again, this document doesn't change the current situation. Operators who
clear the DF bit are not innocent - they need to override a default
setting. They are active participants. They ARE guilty of violating
existing standards.

You seem to think that this is OK because they have good reasons. That
may make their actions acceptable, but it will not make them compliant
*until* someone updates the standards that require the DF not be
cleared. This is not that document.

Joe