IETF Logo Mail Archive

Re: [IETF] 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> Wed, 06 June 2012 00:51 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 4AC8921F8803 for <ietf@ietfa.amsl.com>; Tue, 5 Jun 2012 17:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.693
X-Spam-Level:
X-Spam-Status: No, score=-102.693 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, 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 tPL7nyrgnlTY for <ietf@ietfa.amsl.com>; Tue, 5 Jun 2012 17:51:15 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A961521F87FF for <ietf@ietf.org>; Tue, 5 Jun 2012 17:51:15 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q560ofGO029056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jun 2012 17:50:41 -0700 (PDT)
Message-ID: <4FCEA961.6040508@isi.edu>
Date: Tue, 05 Jun 2012 17:50:41 -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: Warren Kumari <warren@kumari.net>
Subject: Re: [IETF] 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> <Pine.LNX.4.64.1206022127550.17026@shell4.bayarea.net> <35224171-BE58-4875-BE3A-7EAE7BB8B18D@kumari.net>
In-Reply-To: <35224171-BE58-4875-BE3A-7EAE7BB8B18D@kumari.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "C. M. Heard" <heard@pobox.com>, IETF <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: Wed, 06 Jun 2012 00:51:16 -0000

Kuari wrote:
> On Jun 3, 2012, at 12:34 AM, C. M. Heard wrote:
>> On Sat, 2 Jun 2012, Masataka Ohta wrote:
>>> Existing routers, which was relying on ID uniqueness of atomic
>>> packets, are now broken when they fragment the atomic packets.
 >>
>> Such routers were always broken.  An atomic packet has DF=0 and any
>> router fragmenting such a packet was and is non-compliant with
>> the relevant specifications (RFCs 791, 1122, 1812).
 >
> Sorry, but no….
>
> Not following the RFC != broken. Not following the RFC == non-compliant.
>
> There are numerous places where implementations do not follow the
> specs for various reasons, ranging from simply not bothering, through
> philosophical differences to customers paying for non-compliant feature X.

Vendors that "choose to ignore" (IMO, that's "violates") the specs 
rarely make clear their rationale or the consequences to users.

Regardless, as has been noted, the routers were already non-compliant 
when they ignored the flags of an atomic datagram.

Joe

v2.23.0 | Report a Bug | By Email