Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

Philipp Kern <phil@philkern.de> Thu, 01 November 2012 09:10 UTC

Return-Path: <pkern@spike.0x539.de>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B82F21F8549 for <v6ops@ietfa.amsl.com>; Thu, 1 Nov 2012 02:10:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svzXLvMWN5O2 for <v6ops@ietfa.amsl.com>; Thu, 1 Nov 2012 02:10:01 -0700 (PDT)
Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id EDEBA21F8543 for <v6ops@ietf.org>; Thu, 1 Nov 2012 02:10:00 -0700 (PDT)
Received: from [2001:470:720c:0:5d87:dcc4:f187:37f2] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <pkern@spike.0x539.de>) id 1TTqmh-0007zy-Rp; Thu, 01 Nov 2012 10:09:56 +0100
Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from <pkern@spike.0x539.de>) id 1TTqmg-0006IT-M4; Thu, 01 Nov 2012 10:09:54 +0100
Date: Thu, 01 Nov 2012 10:09:54 +0100
From: Philipp Kern <phil@philkern.de>
To: Lorenzo Colitti <lorenzo@google.com>
Message-ID: <20121101090954.GA23956@spike.0x539.de>
References: <BB219517-B488-4777-AE9C-35C57BE91263@kumari.net> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF778@XCH-NW-01V.nw.nos.boeing.com> <507F265E.6030000@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5BFAE@XCH-NW-01V.nw.nos.boeing.com> <507F32DA.30600@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5BFC3@XCH-NW-01V.nw.nos.boeing.com> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5C234@XCH-NW-01V.nw.nos.boeing.com> <8C48B86A895913448548E6D15DA7553B18E941@xmb-rcd-x09.cisco.com> <5091907E.3090206@isi.edu> <CAKD1Yr2nzYmH07b=FXC4wQmYjC85vc6Sp2SzCsLVc8p7o_ayrg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA"
Content-Disposition: inline
In-Reply-To: <CAKD1Yr2nzYmH07b=FXC4wQmYjC85vc6Sp2SzCsLVc8p7o_ayrg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "draft-taylor-v6ops-fragdrop@tools.ietf.org" <draft-taylor-v6ops-fragdrop@tools.ietf.org>
Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Nov 2012 09:10:01 -0000

On Thu, Nov 01, 2012 at 09:35:07AM +0900, Lorenzo Colitti wrote:
> Operators who want to have their routers do things like:
[…]
> - Stateless ACL processing for security purposes
[…]
> configure their routers to look at upper-layer headers. If the routers
> cannot parse the extension header chain but only look at the next header
> value in the IPv6 header, then the operators have a choice:
> 
> 1. Give up the above functionality.
> 2. Drop all packets with extension headers.
> 
> It's not just the fragment header, it's all extension headers. The fragment
> header is just the most important one.

Isn't the point that another packet will arrive later that doesn't bear
the information anymore that's needed to do the filtering decision?
Hence the fragmentation being the only concept that pushes information
away from a per-packet point of view to one where you'd require state?

(Also: To say that it wasn't forseen what would be possible in hardware
today a decade ago and then argue based on the current state of
technology to remove a feature does sound a tad wrong to me. Hardware
does evolve.)

Kind regards
Philipp Kern