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

Joe Touch <touch@isi.edu> Wed, 31 October 2012 20:00 UTC

Return-Path: <touch@isi.edu>
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 EB58821F8825 for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 13:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 N+ijHic-LtBL for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 13:00:23 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7E80821F8823 for <v6ops@ietf.org>; Wed, 31 Oct 2012 13:00:23 -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 q9VK09xQ019125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Oct 2012 13:00:09 -0700 (PDT)
Message-ID: <50918349.9020205@isi.edu>
Date: Wed, 31 Oct 2012 13:00:09 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Fernando Gont <fgont@si6networks.com>
References: <CAKD1Yr13cNspdWvTaXxHt4R_8UB-CKeA4nq8_XWrkbFGCgW7Gg@mail.gmail.com> <5090DECF.3050100@gmail.com> <CAKD1Yr1dUy-f78A2+kfA7NjpzD0WQRT8iwqGYAm5A=Erodpn-A@mail.gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <CAKD1Yr0mTTcVeq+Qf0fLv3UCBP_90QmStkK3Ha4tDdm3FxJjVA@mail.gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu> <50916F21.6030303@si6networks.com> <509174F1.8080809@isi.edu> <50918153.7070509@si6networks.com>
In-Reply-To: <50918153.7070509@si6networks.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: v6ops@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: Wed, 31 Oct 2012 20:00:24 -0000

On 10/31/2012 12:51 PM, Fernando Gont wrote:
> On 10/31/2012 04:58 PM, Joe Touch wrote:
>>> The only thing in that IPv6 would avoid is requiring routers to parse
>>> *all* options, just to find the ones that need to be processed by
>>> routers.
>>
>> Yes.
>>
>> However, since fragmentation is near the end of the set of possible
>> options, that means that ANY recommendations about how IPv6 routers
>> handle options will require deep option parsing. How does that help?
>
> mm.. not sure what you mean. Could you elaborate a bit more?

The fragment header is not required to be the first header; it's 
required to come after the HBH and before the E2E ones.

So "must drop IPv6 fragments" implies parsing ALL HBH headers that come 
before the frag header (or you'd never know the frag header was there).
>>> While the IPv6 extension header syntax is good in terms of extensibility
>>> (in principle, you can include as many options as you want, it also
>>> allows for pathological cases in which the header chain is split among
>>> multiple fragments (we're working on fixing that one), and also requires
>>> any box that wants to find the upper-layer header to parse the entire
>>> IPv6 header chain -- something that a large number of devices cannot do
>>> at wire speed.
>>
>> I thought we were talking more about fragmentation - which defeats
>> filtering on upper layer info anyway.
>
> It *currently* does in v6, but not in v4: in v4 the first fragment
> always has, at the very least, the IP addresses, upper-layer protocol,
> and transport ports. In v6 (with the current specs), that might not be
> the case.
>
>
>> The non-HBH options can be split across fragments, but not the HBH ones.
>
> And...?

I'm not sure what bug you're implying above ("we're working on fixing 
that one"), but it's not that the entire chain is split among the fragments.

Joe