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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 01 November 2012 19:06 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 0898121F9424 for <v6ops@ietfa.amsl.com>; Thu, 1 Nov 2012 12:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.636
X-Spam-Level:
X-Spam-Status: No, score=-101.636 tagged_above=-999 required=5 tests=[AWL=0.055, 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 qJwG+HvTkZV5 for <v6ops@ietfa.amsl.com>; Thu, 1 Nov 2012 12:06:43 -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 ADBB621F9221 for <v6ops@ietf.org>; Thu, 1 Nov 2012 12:06:36 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so1349095wgb.13 for <v6ops@ietf.org>; Thu, 01 Nov 2012 12:06:35 -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=t8DUw+f0uJQTiDSRxrocrjfuR0Y42fsGDzTpeHPZIlE=; b=BJcpcv28wHb4vS9j1Hv4+ZmLMw4yxOoWN2zI9T9Dsr97o5YFuuJ4GkTB2aesqcxx+D WIGv7/zSn+TBzWzPznL9DIhdVwv7IhVmRdJ4GPqtQxSN9Mj2ZFBXZ4F0LWfrRVSclSva MSMqGKlmIQDfe+wyxbrln48WvQFPJ7EH2gGWlfMeD3jNR6azYy6TG1B3ekdMEsTHRBdH UmJKdnvvi7yU/JHHJZr7AJIak91fLOelzR3p7h+wgCLyc+Bg8WcVdKphYgh5Dho9O7LJ Tl5KN5Mt0lD0gtKAnUfh5UJAZkwZmx7et4QdJhkAW/7G12xcuDinprNS0HJ3qoblPfSF G9Ww==
Received: by 10.180.84.102 with SMTP id x6mr2864785wiy.12.1351796795815; Thu, 01 Nov 2012 12:06:35 -0700 (PDT)
Received: from [192.168.1.65] (host-2-102-216-140.as13285.net. [2.102.216.140]) by mx.google.com with ESMTPS id ay10sm171263wib.2.2012.11.01.12.06.33 (version=SSLv3 cipher=OTHER); Thu, 01 Nov 2012 12:06:34 -0700 (PDT)
Message-ID: <5092C846.5090009@gmail.com>
Date: Thu, 01 Nov 2012 19:06:46 +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>
In-Reply-To: <5092C0BA.4090000@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: Thu, 01 Nov 2012 19:06:44 -0000

Joe,

On 01/11/2012 18:34, Joe Touch wrote:
> 
> 
> On 11/1/2012 2:35 AM, Brian E Carpenter wrote:
>> On 31/10/2012 18:58, Joe Touch wrote:
>>>
>>>
>>> On 10/31/2012 11:34 AM, Fernando Gont wrote:
>>>> On 10/31/2012 04:11 PM, Joe Touch wrote:
>>>>> Yes, but the whole point of the IPv6 option architecture was to avoid
>>>>> the issues seen with IPv4 options.
>>>>
>>>> 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.
>>
>> No. The only extension header that *needs* to be parsed by intermediate
>> routers is the hop-by-hop options header, and that is the first one (if
>> present).
> 
> The first one could be:
> 
>     A. a known HBH option
>         indicating there are HBH options
>     B. a known E2E option
>         indicating there are no HBH options
>     C. an unknown option or a pad option
>         indicating NOTHING

Actually there is another unfortunate aspect of RFC 2460 here. It would
be better if it said that the hbh options extension header MUST be
first, instead of just recommending it. I think I will add that to my draft.

> 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.

     Brian

>> (You can legitimately argue that the hbh header and the routing header
>> are effectively useless, but that doesn't break fundamental
>> connectivity.)
>>
>> IPv6 routers should have nothing to do with fragmentation.
> 
> +1
> 
>> The problem is due to middleboxes that break the IPv6 spec by inspecting
>> any part of the packet beyond the hop-by-hop header and discarding what
>> they don't understand.
> 
> +1
> 
> Joe
>