IETF Logo Mail Archive

Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 29 March 2016 00:12 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 82F0C12D136 for <v6ops@ietfa.amsl.com>; Mon, 28 Mar 2016 17:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQJe88m5CKfV for <v6ops@ietfa.amsl.com>; Mon, 28 Mar 2016 17:12:08 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBF712D0DF for <v6ops@ietf.org>; Mon, 28 Mar 2016 17:12:08 -0700 (PDT)
Received: by mail-pa0-x22d.google.com with SMTP id fe3so23221pab.1 for <v6ops@ietf.org>; Mon, 28 Mar 2016 17:12:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Ex+peYvimmnRL+AYXJ9aTXGUjUXjPZ1iMobxJX6IMLg=; b=Dams3JjlVYUzzNg0aEye2t4oDju5FvmYrj20JhTYYiks2vJ8fzXzDPtUtRTSM4ciyy tJKLh/f4o2dzG//2xXHR+mDF/0K/rPeho5DSnl75/oksY+4hnkCnH78HEChEu9zdQLI6 HSpF4vwYH49Zg1cu+52jxjKo937zZFNnHyuVE/21Ic9HNSkxf8fw/sL3NWoLg3ALS5S9 le0iH5lJW2Ua4YtIIrmiTXdjBrhWvIANE6Ij17pTgptrj2JSDo5jPyRm7Jns+59yu86d 9e4qjBmNs+tzEgjA4giOB/n5pk9BuAqzFhGv0YVrRs7CcgHbGOpaeML20vUDPQgIRXJY 2QTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Ex+peYvimmnRL+AYXJ9aTXGUjUXjPZ1iMobxJX6IMLg=; b=cqGYVw888uhY6ccoZWEL2YKosuiw1XNPeAYFe0QhGq+fWgiWEej/Gdc6QQ7k3UK7lu bgt8BYLLMafJyyFNlNK861U0m7hi6kr7XkVkDILashdVTwMZ2j91Z+AK1NWuoyrBCGOW UAtLvAu1ipveCLZJGyHUUUupXIdPXcG3Wzv4y9qmLBgEbGcIaSUzql/EvDncrcZ0hzgm rW5YLWxMktz/xMiH1qtpBPpHkF2zoQzJHNoQsOPVOd6VJWX/7pd4m9XN8LIhwxhkRxhB fRvH2oDWWdI7dvkNlqc6Ejucm1Lt6AqOm8ypKLn2Avg3HzGIdia2bAgYv5QIhx43ySJw NC0w==
X-Gm-Message-State: AD7BkJJ57n/2SSmWtl2Kc7eJsJYXFl49CxROOVQokJhfty42udg6UGmQ+igHodqexFU6Vw==
X-Received: by 10.66.66.234 with SMTP id i10mr26402870pat.114.1459210328322; Mon, 28 Mar 2016 17:12:08 -0700 (PDT)
Received: from ?IPv6:2406:e007:71e7:1:28cc:dc4c:9703:6781? ([2406:e007:71e7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ql1sm38308144pac.24.2016.03.28.17.12.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 17:12:06 -0700 (PDT)
To: "Fred Baker (fred)" <fred@cisco.com>, Joe Touch <touch@isi.edu>
References: <CAHw9_iLbqEvsw0x4dDcA3Zy3SXKUROcQuy5nSynsL9Xi+xrZLg@mail.gmail.com> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <CALx6S37zP4UvCtBJsvnPN6OmDB0OQDMfRrJNy1XF0t4COStUjQ@mail.gmail.com> <56E98086.5040209@foobar.org> <EE17974D-EDA4-4732-B29E-B2B3BC36DB86@employees.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <56F9C856.2030403@gmail.com>
Date: Tue, 29 Mar 2016 13:12:06 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/G8EBUfqxobl4cQX-K1jp6rgYAWE>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 29 Mar 2016 00:12:10 -0000

On 29/03/2016 12:44, Fred Baker (fred) wrote:
> 
>> On Mar 28, 2016, at 4:30 PM, Joe Touch <touch@isi.edu> wrote:
>>
>>
>>
>> On 3/28/2016 3:21 PM, Brian E Carpenter wrote:
>>> On 29/03/2016 10:36, Fred Baker (fred) wrote:
>>>>
>>>> On Mar 28, 2016, at 2:29 PM, touch@isi.edu wrote:
>>>>> Note, however, that the idea of an offset to "jump" to the transport
>>>>> header makes no sense. There's no rule that HBH header lengths never
>>>>> change in transit, which means you just end up with another field that
>>>>> might be inconsistent with the actual header.
>>>>
>>>> Don't tell the 6man chairs. They think that changing the length of a HBH header (or any header) in transit would be a problem, and I can confirm that in the event that there is an AH header in the packet. We had that discussion in 6man at IETF 94.
>>>
>>> In any case, that issue is foreseen in
>>> https://tools.ietf.org/html/draft-zhang-6man-offset-option-01#section-6
>>
>> Simple counterexample - quickstart (RFC4782).
>>
>> Intermediate routers are allowed to indicate they do not support the
>> option by *deleting* it.

I find it disturbing that we published an RFC suggesting that, which
is IMNSHO inconsistent with the intent, if not the words, in RFC2460. My
distress is increased by the fact that I ballotted No Objection to it
at the time. The Gen-ART reviewer picked up the issue but it was only
partially fixed. Fortunately it's only Experimental.

> 
> There's deleting and deleting. One could move any succeeding options forward 8 bytes (not six, as the document says), shorten the HBH header by 8 bytes, remove the HBH option entirely if it is now empty perhaps, and move everything else forward by 8+ bytes as well. Or, one could overwrite the quickstart option with an 8 byte PAD option. Guess which one I would do...

Yes, and if overwriting with a PAD had been mandated in the RFC, we wouldn't
be discussing this example.

>> Note that routers that do this have no idea about the proposed
>> offset-option, so this will interfere with the calculated offset.
>>
>> That's one example. I wonder how many other existing IPv6 HBH headers
>> are *not prohibited* from changing length, being added, or being deleted
>> en-route.

Yes. It's a bug in RFC2460 that this ambiguity arises.

   Brian

v2.23.0 | Report a Bug | By Email