Re: Usable extension headers [Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt]

Enno Rey <erey@ernw.de> Thu, 28 November 2019 13:49 UTC

Return-Path: <erey@ernw.de>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32C7120878 for <ipv6@ietfa.amsl.com>; Thu, 28 Nov 2019 05:49:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 0D7TCtqooA6K for <ipv6@ietfa.amsl.com>; Thu, 28 Nov 2019 05:49:48 -0800 (PST)
Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C4312087B for <6man@ietf.org>; Thu, 28 Nov 2019 05:49:47 -0800 (PST)
Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 4186927308 for <6man@ietf.org>; Thu, 28 Nov 2019 14:49:46 +0100 (CET)
Received: from ws26.ernw.net (ws26.ernw.net [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 1538D389E7C for <6man@ietf.org>; Thu, 28 Nov 2019 14:49:46 +0100 (CET)
Received: by ws26.ernw.net (Postfix, from userid 1002) id CACD04D43A; Thu, 28 Nov 2019 14:49:45 +0100 (CET)
Date: Thu, 28 Nov 2019 14:49:45 +0100
From: Enno Rey <erey@ernw.de>
To: 6man@ietf.org
Subject: Re: Usable extension headers [Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt]
Message-ID: <20191128134945.GB82618@ernw.de>
References: <CALx6S36L5AWEaXmccpKoENxOEv-XRCmTsq1bCqi06J_YgJGZdg@mail.gmail.com> <ecb3c877-c347-fd3a-86de-8f05fe8b7459@gmail.com> <CALx6S353m9b9b2b+Yt3x-g=BZuE6vwcOoGGfq4BPONVscnQ=xg@mail.gmail.com> <d9c2e11b-53b4-e281-e869-28802a76c72f@gmail.com> <CALx6S346p=M09ZPY_xM2X3gkPp_0KUVZU_u4UeLUagomRnjhPw@mail.gmail.com> <79d22e5a-0145-9ad9-e965-d3744b58c3bf@gmail.com> <d791c9eee34c4e019292fc74d629217c@boeing.com> <5d2af468-be61-d2ca-5bf0-35d5f71fdb6c@gmail.com> <6A41AB04-F56B-46E1-8B8B-3E24B928A042@jisc.ac.uk> <1B629A88-AE10-4F65-8D3D-FD2702B6D63D@employees.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1B629A88-AE10-4F65-8D3D-FD2702B6D63D@employees.org>
User-Agent: Mutt/1.11.3 (2019-02-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Nov 2019 13:49:51 -0000

Hi,

On Thu, Nov 28, 2019 at 12:03:01PM +0100, Ole Troan wrote:
> > Certainly not a bad time to re-run tests, and maybe run tests between co-operative end points/domains.  Nearly 4 years have passed since the RFC7872 tests were run.  How much have things changed?
> 
> RFC7872 was (IMNSHO) based on the flawed belief that any end-host/service end-point should accept arbitrary extension headers.

isn't IPv6 supposed to be an end-to-end protocol?
Based on that assumption pretty much all IPv6 stacks of operating systems implement full processing capabilities for the full set of extension headers as of RFC 8200.

Fully serious question: which guidance re: the implementation of an IPv6 stack, plus its capabilities, would you suggest to read & follow for a party working on an IPv6 stack used on a billion devices? I know a few people who would be very interested in a response here. I could imagine they might even be happy to get rid of all the code taking care of EHs right now.

Maybe there should be an IPv6 variant for routers, and one for end-points in the future? 
This could also allow for a 6man sub-WG for routers. Oh wait, in reality it already is. 
That fictional router-oriented 6man sub-WG could then be populated mainly by folks from router vendors. Oh wait...


cheers

Enno


-- 
Enno Rey

Twitter: @Enno_Insinuator