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

"Fred Baker (fred)" <fred@cisco.com> Mon, 28 March 2016 23:44 UTC

Return-Path: <fred@cisco.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 E162112D0EC for <v6ops@ietfa.amsl.com>; Mon, 28 Mar 2016 16:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.531
X-Spam-Level:
X-Spam-Status: No, score=-114.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 CRuQjXhZqaGW for <v6ops@ietfa.amsl.com>; Mon, 28 Mar 2016 16:44:39 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8039F12D0CF for <v6ops@ietf.org>; Mon, 28 Mar 2016 16:44:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3132; q=dns/txt; s=iport; t=1459208679; x=1460418279; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0nNP1v/clxk5Sw66vNimsWx28tGcNQq+39xg3DG8yIs=; b=f59DfgyWw8CLqmrooZSun45nADvyMlhvPrCrqB7UjHvuBRmdKSHs4oM/ piLcopjTDTcwTr/THHaZ8P7aknSwA/ypDeTvbnQja8iLw0DaxYBuQQKmo z1J0/ZpXx1lj1eIAR33B55e93EeLaxhpqHVS4sxgsplMyEPbXeRXp8vpQ 4=;
X-Files: signature.asc : 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DOAgC9wflW/4YNJK1dDoMgU30Gum8OgXAhhWwCgSU4FAEBAQEBAQFkJ4RBAQEBAwF5BQsCAQgYLjIlAgQOBQ6IEQgOwFEBAQEBAQEBAQEBAQEBAQEBAQEBAQENBASIEIJRh2eCKwWXYQGDHYFmbYgVjwuPCgEeAUOCAByBDjtsh3x+AQEB
X-IronPort-AV: E=Sophos;i="5.24,408,1454976000"; d="asc'?scan'208";a="254710386"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Mar 2016 23:44:38 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u2SNiclk029066 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Mar 2016 23:44:38 GMT
Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Mar 2016 18:44:37 -0500
Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Mon, 28 Mar 2016 18:44:37 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: Joe Touch <touch@isi.edu>
Thread-Topic: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops
Thread-Index: AQHRiTnjuC9r2YC2skGBfdtx5Op9bQ==
Date: Mon, 28 Mar 2016 23:44:37 +0000
Message-ID: <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com>
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>
In-Reply-To: <56F9BEA3.9050409@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3124)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.64.123]
Content-Type: multipart/signed; boundary="Apple-Mail=_576A2565-1EBA-414B-81C6-A8B519957671"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/TiwMtKX8fCdeMQqdjsLKoV8DEBg>
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: Mon, 28 Mar 2016 23:44:42 -0000

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

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

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