Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

Simon Hobson <linux@thehobsons.co.uk> Wed, 31 October 2018 09:59 UTC

Return-Path: <linux@thehobsons.co.uk>
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 17503128A6E for <ipv6@ietfa.amsl.com>; Wed, 31 Oct 2018 02:59:58 -0700 (PDT)
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] 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 YPLKjrdcEVnU for <ipv6@ietfa.amsl.com>; Wed, 31 Oct 2018 02:59:56 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270A112958B for <ipv6@ietf.org>; Wed, 31 Oct 2018 02:59:56 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from simons-macbookpro.thehobsons.co.uk (Simons-MacBookPro.thehobsons.co.uk [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 3F2B01A071 for <ipv6@ietf.org>; Wed, 31 Oct 2018 09:59:52 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <97ce4bf9-ae09-653f-b161-6c5e5456ff68@gmail.com>
Date: Wed, 31 Oct 2018 09:59:51 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <04903F24-ADD5-4A13-B757-8CF348B9C65F@thehobsons.co.uk>
References: <0d6008a4-337b-2ccb-2d9f-837f786eca65@gmail.com> <bfa4397a-aa7a-1184-4147-4cbfbfd13603@si6networks.com> <8C587906-F0EE-4A61-9046-2BFAC52588C0@isc.org> <E8DE18B5-94FC-411C-A310-E49A382E0079@thehobsons.co.uk> <e0fa8fad1b4249c9af79788323b0a922@boeing.com> <3A03A073-72E2-43A8-90A4-5C29DF445361@thehobsons.co.uk> <27fdbd71125842d888c5136684bf6e7b@boeing.com> <9A4368D6-E4B1-474C-9838-B584AF6D70C8@thehobsons.co.uk> <m1gHUMI-0000I6C@stereo.hq.phicoh.net> <9e3f31a2-2a38-cb47-a7b0-73a4c3cbf21b@gmail.com> <20181030210331.rnwwn6sh23bgo4ot@faui48f.informatik.uni-erlangen.de> <97ce4bf9-ae09-653f-b161-6c5e5456ff68@gmail.com>
To: 6man WG <ipv6@ietf.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/MSMkqWzXrkjvbrP11Xt-o1toqoA>
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: Wed, 31 Oct 2018 09:59:58 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> The example I've used is a an IP-based smoke detector trying to connect
> to an IP-based central fire alarm system. Because human safety is
> involved it needs to try every possible type of connectivity in any case,
> so giving up on IPv4 because the IPv6 routers say so is not the right
> answer.

I very strongly disagree with this example.
As it's a "safety of life" issue, these devices should NEVER EVER be on anything but a safely segregated network. If they aren't, then they are NOT part of a proper fire detection system. There's a reason that fire detection and alarm systems are normally hard wired, with their own systems, using fire resistant cables (at least for the alarm annunciators). I find it hard to believe that any IP based system just randomly plugged into a general purpose network would pass even the basics of requirements for a fire detection & alarm system.
Having a little knowledge of how commercial fire detection systems operate - there is a lot of work goes into fault detection and mitigation. Once you get past the basic small systems, they even have automated faulty cable detection and isolation - so get a cable short, no problem, the system will isolate that section (losing a few sensors but not the whole loop) and raise a fault alarm.

Given the number of failure modes for such an arrangement (detectors plugged into random IP network with everything else), the only sane option would be that upon loss of connectivity with the sensor, the system would have to go into fire alarm mode - there is no other option as the control system could not differentiate between a fire that's taken out power to the sensors, fire that's taken out the non-fire rated cable to the sensor, a switch failure, a power failure taking out the switch, something nicking the IP address, or an admin being unaware of this safety critical system on the network and "turning off" IPv4.

Mind you, if the system did lose connectivity by setting this flag - then it presumably understands IPv6 and will be using it, so the failure mode of setting this flag incorrectly is moot. On the other hand, if the admin decides that IPv4 is dead and filters IPv4 traffic at L2 in the switches (and the fire detection system is IPv4 only) - well that would break things and he'd get to know about it fairly quickly.
From experience, it's "a tad embarrassing" to set off the fire alarm because you've forgotten that part of one of your systems links into it when you're doing the periodic checks - and before you can get to the alarm panel to cancel the alarm, people are already heading out of the door :-(