Experimental Physics and
Industrial Control System

"Johnson, Andrew N. via Core-talk" <core-talk at aps.anl.gov> · Wed, 17 Mar 2021 17:47:37 +0000

Hi Mark,

On Mar 17, 2021, at 11:08 AM, Mark Rivers <rivers at cars.uchicago.edu> wrote:
> 
> At the APS, and I suspect at most EPICS facilities there are a large number of expensive devices that use IPv4: motion controllers, oscilloscopes, PLCs, detectors, cameras, other instrumentation, etc.  Much of this will never be able to run IPv6 because the vendors won't provide new firmware for it.  Replacing it would cost tens of millions of dollars.  So I accept it as a fact that EPICS IOCs are going to need to communicate with IPv4 devices for the foreseeable future.  If that is so, then why is it necessary that IOCs communicate with EPICS clients over IPv6?
> 
> I certainly understand that public-facing computers will need to transition to IPv6.

We don’t know what the rules are going to be or what exemptions DOE will provide for existing facilities, although I’m sure they won’t want this to cause them to shut down. The preamble to the OMB memo is quite readable, explaining the reasoning behind this push. It imposes this as one of the requirements on the DOE:

> 4. Develop an IPv6 implementation plan by the end of FY 2021, and update the Information Resources Management (IRM) Strategic Plan as appropriate, to update all networked Federal information systems (and the IP-enabled assets associated with these systems) to fully enable native IPv6 [11] operation. The plan shall describe the agency transition process and include the following milestones and actions:

> a. At least 20% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2023;
> b. At least 50% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2024;
> c. At least 80% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2025; and
> d. Identify and justify Federal information systems that cannot be converted to use IPv6 and provide a schedule for replacing or retiring these systems;

> [11] Native IPv6 refers to direct support of IPv6 in a system or service without requiring the use ofIPv4 for basic communications.

That’s an interesting time-line, I wonder what counts as a Federal network? 

I could see one possible way to move towards that by partitioning a control system into separate subnets for IPv4-only and IPv6-only traffic, with gateways between them to translate. Individual IOCs might not have to speak both though, which could simplify the job of adding IPv6 support to our code.

Later on the memo also talks about Acquisition Requirements, which I suspect might impose hard requirements on the development of new DOE-funded facilities:

> 1. Continue to use the USGv6 Profile to define agency or acquisition specific requirements for IPv6 capabilities when purchasing networked information technology and services. Going forward, this should include specifying the requirement for hardware and software to be capable of operating in an IPv6-only environment;
> 2. Continue to require potential vendors to document compliance with such IPv6 requirement statements through the USGv6 Test Program; and
> 3. In rare circumstances where requiring demonstrated IPv6 capabilities would pose undue burden on an acquisition action, provide a process for agency Chief Information Officers to waive this requirement on a case-by-case basis. In such cases, the purchasing agency shall request documentation from vendors detailing explicit plans (e.g., timelines) to incorporate IPv6 capabilities to their offerings.

That tells me we would at minimum need to have a plan and a timeline for this work before EPICS could be chosen for use at a new DOE facility.

I don’t particularly want to speculate about how existing installations might handle the requirements until we hear from the DOE what they are going to be. We should however start looking at how we might add IPv6 support to our network interface code, and see whether it makes sense for the same code to handle both (it might for some things like ASYN, but maybe not for CA).

I could see us using this as one way to simplify the RSRV and libCa code while adding IPv6-only support: By duplicating it and ripping out all the old CA protocol version support since no older client or IOC could ever use IPv6, so the new copies don’t need to handle the older CA messages at all. Maybe we could provide a new libCa6 but with the same API so existing client code can be built with no code changes, just swap the library they link with to upgrade?

- Andrew

> -----Original Message-----
> From: J. Lewis Muir <jlmuir at imca-cat.org> 
> Sent: Wednesday, March 17, 2021 9:12 AM
> To: Torsten Bögershausen <Torsten.Bogershausen at ess.eu>
> Cc: Timo Korhonen <Timo.Korhonen at ess.eu>; Mark Rivers <rivers at cars.uchicago.edu>; 'Michael Davidsaver' <mdavidsaver at gmail.com>; Johnson, Andrew N. <anj at anl.gov>; Ben Franksen <benjamin.franksen at helmholtz-berlin.de>; EPICS core-talk <core-talk at aps.anl.gov>
> Subject: Re: IPv6
> 
> On 03/17, Torsten Bögershausen via Core-talk wrote:
>> The paper says "IPv6 only", right ?
>> In order to get an idea what needs to be done, I imagined that the 
>> switches don't transport
>> IPV4 any more.
>> Those switches do probably not exist in reality. You need to imagine them.
>> There are not datasheets, they do not exist.
>> 
>> Imagine them.
> 
> The point is that it doesn't make sense to imagine them; they will never exist.  I haven't read the paper or memo or whatever it is, but if it's talking about a requirement to move away from IPv4 to IPv6, then it's limited to just the things that are IPv4, not things that are not IPv4.
> It doesn't say that something that is not IPv4 must be converted to IPv6; that would be ridiculous.  I think that's the point that's trying to be made here about the switch: a traditional network switch is a layer 2 device (i.e., data link layer); it doesn't know anything about communications schemes from layer 3 and up (IPv4 and IPv6 are at layer 3), and therefore would have no way to disallow IPv4.
> 
> Lewis

-- 
Complexity comes for free, simplicity you have to work for.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System