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

[Brian E Carpenter <[e-mail]>]

On 2018-10-31 22:59, Simon Hobson wrote:
> Brian E Carpenter <[e-mail]> 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. 

You're completely correct**. But that doesn't actually change the logic
of my example. If a safety-critical device is (incorrectly) attached to
the wrong network, it's going to do whatever it can to correct the situation,
and no RFC can stop it.

   Brian

** Speaking as someone who in about 1980 ditrectly caused a beam dump
in the CERN Antiproton Accumulator because some idiot had connected the
power supply for the human safety systm to our computer room's UPS,
and I switched on a new computer that had a hard-wired ground fault
that tripped the UPS.


> 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 :-(
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> .
>