IPv6 header insertion in a controlled domain

otroan@employees.org Sun, 08 December 2019 09:34 UTC

Return-Path: <otroan@employees.org>
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 E5057120088 for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 01:34:09 -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 mEEmTQpIpCxq for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 01:34:08 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B256F12004E for <ipv6@ietf.org>; Sun, 8 Dec 2019 01:34:08 -0800 (PST)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:47d8:a132:2dc:5bc7:9ba]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 57F954E11ADE; Sun, 8 Dec 2019 09:34:08 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id C3949254CF7A; Sun, 8 Dec 2019 10:34:02 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: IPv6 header insertion in a controlled domain
From: otroan@employees.org
In-Reply-To: <CAO42Z2xMF5TM3BT=tA63A7QmiYRChPJywb1pSJquy_i5K_h=iA@mail.gmail.com>
Date: Sun, 08 Dec 2019 10:34:02 +0100
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <324D4E35-97E8-42A2-912F-27C9FE033879@employees.org>
References: <CALx6S3588ja9AZzBQ0dqwx0j-ki6A5tusye+odQKPyAyF+hEww@mail.gmail.com> <10E890EA-3278-44EE-881E-EBC91D419587@employees.org> <88287cb0-c0c3-f990-4dd7-338df87c7fb2@joelhalpern.com> <4E76C386-FB1E-4E48-814D-BB626466BEE3@employees.org> <CAO42Z2ze7tmkGh=E-YrPuJHMeD8V6EuxgjjaJ33iz+Ms3abNsA@mail.gmail.com> <FDD7B5F4-B60D-425A-96C1-979BE647C0DA@employees.org> <CAO42Z2xMF5TM3BT=tA63A7QmiYRChPJywb1pSJquy_i5K_h=iA@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/utJekBUdNOb_GjyZtMoiEiV4CMA>
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: Sun, 08 Dec 2019 09:34:10 -0000

Mark,

> In the example I gave, "do you in principle see any reason why it could not be made to work"?
> 
> 
> Sure, it could be made to work. Anything that can be implemented in software or hardware can be made to work.

I don't think that's correct. At least not for my definition of work.
We agree on a higher success threshold.

> However, that's a low success threshold.

Your points below are quite abstract.
Can you think of anything that would break?
Or make it "unsafe"?

I am not suggesting that header insertion is the _best_ approach. That I tihnk has to be evaluated on a per use case basis.
I just want to see if we can reach agreement that it's a solution candidate, that given the deployment restrictions is technically sound.
Deployment restrictions that aren't conceptually very different from deploying e.g. OSPF.

> It is ignoring other factors like if the mechanism is efficient (doing things right) and effective (doing the right things).
> 
> It is ignoring whether the mechanism is the best performing for the least cost (efficient restated).
> 
> It is ignoring how the mechanism fits within an existing architecture.
> 
> It is ignoring how obvious the mechanism's operation is, and how well it utilises and aligns with existing, proven and well known mechanisms.
> 
> It is ignoring how easy and quickly it is to rectify faults when they inevitably occur, a critical factor in production commercial networks.
> 
> It is ignoring how consistent the mechanism is with existing specifications and existing knowledge.
> 
> Showing something works doesn't really prove anything other than it can be made to work with software or hardware.
> 
> Something working well expects all these other factors are used as judgement criteria.
> 
> In my experience there is a big gap between working* and working well.
> 
> These other "works well" factors are ones that matter the more when the mechanism is deployed operationally, because operators can automatically assume it works when they buy it as it has become a commercial product.

Best regards,
Ole