The IP protocol, on which the functionality of the entire Internet is based, has been with us since 1974, when the IEEE institute published a document called "A Protocol for Packet Network Intercommunication". In 1981, a version of the IPv4 protocol (RFC 791) was created, which is still used today. IPv4 is based on a 4-byte network address, which seemed sufficient at the time of the standard's inception, but already in the 1990s, the exponential growth of the Internet caused concerns about the exhaustion of public IP addresses and contributed to the further development of the IP protocol.
There has been a version of IPv6 since 1998 (version 5 was only "developmental" and never became a standard). Currently, IPv4 and IPv6 protocols coexist - according to Google statistics (April 2022), IPv6 is used by about 34-38% of users, while in some countries it is even more than 50% (Germany, India).
How about SCADA systems and industrial communications? According to our information, IPv6 is just starting to gain traction.
The early adopters also exist in our country - see the recent blog "Communication - DLMS and the Iskraemeco AC750 concentrator" about the concentrator of electricity meters, which on the one hand communicates via powerline with electricity meters exclusively via IPv6 and on the other hand can be used to communicate with the SCADA system via IPv4 or IPv6. In IPv6 mode, it can also function as a router that forwards messages to the target electricity meters, so that the SCADA system communicates directly with them.
And because of these emerging IPv6 communications, the new D2000 version 22 brings support for IPv6 communications. How is it implemented?
The existing TCP-IP/TCP and TCP-IP/TCP Redundant, TCP-IP/UDP lines as well as various variants of serial lines over UDP (SerialOverUDP Device Redundant, SerialOverUDP Line Redundant, SerialOverUDP System&Line Redundant) and the RFC2217 Client line now support both IPv4 and IPv6 functionality. How?
• IPv4 addresses and symbolic computer names are specified as before, e.g. 10.0.0.1 or SrvKom1.
• IPv6 addresses are specified in IPv6 notation, e.g. fd00::ee:ff:fe00:4 or ::1.
• Symbolic computer names to be translated to an IPv6 address are entered in square brackets, e.g. [SrvKom1]. Why? When working as a concentrator of electricity meters, we were inspired by the majority Chrome browser, which requires the entry of an IPv6 address in square brackets (in accordance with RFC3986). To maintain backward compatibility and for unambiguity, we have preserved the translation of symbolic names to an IPv4 address if the symbolic name is not in square brackets and implemented the translation to an IPv6 address if the symbolic name is in square brackets.
• Note: the IPv6 address can also be put in brackets, e.g. [::1].
If there are multiple IP addresses in the configuration of TCP-IP/TCP and TCP-IP/TCP Redundant, TCP-IP/UDP and RFC2217 Client lines, they can be a mixture of IPv4 and IPv6. In this way, for example, gradual migration of communication from IPv4 to IPv6 is possible, or operation on redundant networks using different versions of the IP protocol.
Variants of serial lines via UDP must have either IPv4 or IPv6 addresses within one configuration corresponding to the physical line (this follows from the fact that this line must listen on the selected port and whether it listens on an IPv4 or IPv6 port is derived from the specified name or IP addresses).
So for SerialOverUDP Line Redundant, for example, the primary line configuration can use IPv4 addresses and the secondary line configuration can use IPv6 addresses, as shown in the following figure.
And for the SerialOverUDP System&Line Redundant line, each of the four "physical" lines can use either IPv4 or IPv6 addressing.
IPv6 support also applies to protocols created using KomAPI, which are used by our OEM partners (OEM protocols).
Detailed rules for working with IPv4 and IPv6 addresses are described in the online documentation.
In addition, support for IPv6 addresses was also added to the system structured variable SV._System_NetStatus, so it is possible to monitor the network availability of IPv6 devices using ICMP packets (ping).
Conclusion
IPv6 protocol support brought by D2000 v22 is one of the steps that prepares the Ipesoft D2000 real-time application server for the future and guarantees that SCADA and MES systems built on this technology will be able to communicate with an ever-wider set of devices.
September 19, 2022, Ing. Peter Humaj, www.ipesoft.com