IETF Logo Mail Archive

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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 02 November 2012 08:17 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 983F321F999F for <v6ops@ietfa.amsl.com>; Fri, 2 Nov 2012 01:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.639
X-Spam-Level:
X-Spam-Status: No, score=-101.639 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, 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 dV7CG+I9CQ2q for <v6ops@ietfa.amsl.com>; Fri, 2 Nov 2012 01:17:45 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1462821F99AB for <v6ops@ietf.org>; Fri, 2 Nov 2012 01:17:43 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so1579768wgb.13 for <v6ops@ietf.org>; Fri, 02 Nov 2012 01:17:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QhNOY6ewc0BSq6pipl0gI9yBjPWgZKsOsKzM+vgq02s=; b=iS+S1b+ahsiGU5gaazVjV1soUI/rLTBkFuI4KSyHz3UxYPlURcf8UlS6myXZv+XAu7 Y2t+TUNJe21wJrUQVEX3rX+AellsMOJF5IA9jY5VSU9XpIEWiDusW4/dzf5IO2uV1ZTu 0kwtIf41ODf9jGEg06gj9BRdmhY825olzD3mVkWInKRf3Ip8HGwZwoqlro2cGGMJBMvN LZvKbJoZxufmAULvNrU1dkDtsPy/eiHuv9zcJFnAUpdTvwUROD60hP/atxjmkYL7S85w gbCnMLFHq4XSnOysuvtnhjgP3/8mRI3OUt7n6w53zdED+spvCQeA0BOMSkvotFRdtSXS TBcQ==
Received: by 10.180.87.230 with SMTP id bb6mr1540518wib.6.1351844263195; Fri, 02 Nov 2012 01:17:43 -0700 (PDT)
Received: from [192.168.1.65] (host-2-102-219-241.as13285.net. [2.102.219.241]) by mx.google.com with ESMTPS id dm3sm1479685wib.3.2012.11.02.01.17.41 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 01:17:42 -0700 (PDT)
Message-ID: <509381B3.9040602@gmail.com>
Date: Fri, 02 Nov 2012 08:17:55 +0000
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
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> <50924264.7040300@gmail.com> <5092C0BA.4090000@isi.edu> <5092C846.5090009@gmail.com> <5092D5B1.2000201@isi.edu>
In-Reply-To: <5092D5B1.2000201@isi.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Fernando Gont <fgont@si6networks.com>, 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: Fri, 02 Nov 2012 08:17:46 -0000

On 01/11/2012 20:04, Joe Touch wrote:
> 
> 
> On 11/1/2012 12:06 PM, Brian E Carpenter wrote:
> ...
>>> In the case of C, the router needs to keep looking at subsequent options
>>> until one of three things happens:
>>>
>>>      1. a known HBH option is seen
>>>          indicating there are HBH options
>>>      2. a known E2E option is seen
>>>          indicating there are no HBH options
>>>      3. there are no more options
>>>          indicating there are no HBH options
>>>
>>> As a result, it's entirely possible that a router could need to parse
>>> the entire option chain before it can determine whether there are any
>>> HBH options.
>>
>> Yes, because of the point I just mentioned. That's a bug IMHO.
>> However, the observed problems come from middleboxes that don't
>> parse regular extension headers, not hbh option headers.
> 
> Isn't the real bug the fact that the option numbers don't indicate
> whether an option is HBH or not?

Why is that a problem? The extension header that contains the options
tells you that (0 for hbh options, 60 for destination options).

    Brian

v2.23.0 | Report a Bug | By Email