Typical maintenance personnel are not qualified to manipulate IP Addresses and must defer to Information Systems (IS) department or other network specialists.
This causes a significant delay in connecting devices, which results in factory down-time.
Alternatively, expensive specialists must be maintained around the clock to handle such problems.
RARP is not as widely used as BOOTP because the tools to implement RARP are not as commonplace.
There is little practical benefit for using PING, as the ARP messages are faster and less intrusive.
Although these existing means are satisfactory in some instances, they do not adequately address the industrial or factory market for devices such as sensors and I / O devices.
And, it is not feasible or cost-effective to employ the existing addressing techniques into certain devices or certain environments.
These settings are important for proper performance otherwise the network becomes unstable and exhibits erratic behavior affecting the performance not just of the device being configured, but also other devices on the network.
In addition, DHCP cannot be used conventionally, to assign an ‘unpredictable’ address within a ‘pool’ of available addresses, because the primary network protocols between industrial devices, such as Modbus / TCP, use explicit knowledge of the IP addresses of the designated targets.
In a factory environment with automated devices running 24 hrs a day×7 days a week, employing a system administrator to assign IP addresses on devices around the clock is not cost-effective.
The technician or engineer replacing the device does not possess the adequate skill or knowledge to also assign the IP address, and having a device failure may cripple the plant operation.
Delaying a factory line until a system administrator can issue an IP address to the device is not a satisfactory option in the highly competitive marketplace.
As noted herein, forcing the wrong IP address to a device on the network can result in unexpected catastrophe.
Use of an alternative protocol such as IPX will cause problems in use of the devices in environments where these protocols are not supported.
IPX protocol implementations have some further inherent difficulty with devices not supporting IPX protocols on the network.
Industrial control devices pose particular problems because of the importance of operation, continuous operation, and location of the devices.
These devices may fail in service and must be replaced rapidly from a spares stock with minimum Mean Time To Repair (MTTR).
For example, the devices may fail because they are exposed to electrical or mechanical stresses that exceed their specifications.
However, the need to assign IP addresses accurately under such critical replacement conditions is usually not practical.
Previously, Ethernet was not considered a viable option to the business community.
One problem with the implementation of Ethernet as a replacement for the device level networks such as ASi or DeviceNet was that you could not require anything more elaborate than the setting of a rotary switch to match the predecessor device.
Such problems diminished as the protocols changed and expanded the Ethernet options.
The mechanism of this system requires foreknowledge of the unique characteristics of the device in order to provide address assignment, and cannot be used to perform automated assignment when replacing one of potentially many identical devices on a network segment.
It is also not designed to work with TCP / IP local area networks.
A flaw in the this system is that it fails to address the case where the address being speculatively assigned has in fact already been assigned to another device, but that device is temporarily inaccessible, such as by being reset or through a temporary network disruption.
The system would complete its assignment of the duplicate address in a finite time period, after which, if the original device were to come back on line, there would be a duplicate address situation that would impede operation of the original device.
This flaw supports the conclusion that it would likely never be permitted on a network used for automation purposes, as multiple devices with the same IP address would result in grave networking problems.
There are several limitations of technique of this system.
Firstly, it requires that the devices being replaced incorporate the capability of reading some sort of ‘logical identifier’ before attempting address assignment.
Secondly, the devices being replaced must incorporate a non-standard protocol capability to transmit that information to the management device for the purpose of address assignment.
These two requirements severely limit the usefulness of the technique, since network administrators would be unwilling to deploy an automated configuration technique unless it applied to a high proportion of devices likely to require such assignment.
Such cooperation would likely not succeed.
However, the IETF would be skeptical about the widespread adoption of such a technique because of its similarity to the BOOTP and DHCP protocols already available.
This latter mechanism is not appropriate for use on a TCP / IP local area network because of the problems caused if the address in question actually had been assigned to another device, but that device was temporarily inaccessible.
Such a situation would likely cause network disruption and possibly a failure of control in an automation system.
Therefore, the methodology would not be acceptable on a network used for automation purposes.
The techniques of this system are not appropriate for TCP / IP local area networks.
Assigning appropriate address ranges for network segments which are subsequently linked together is cumbersome, and cannot generally be overcome by defining an address assignment protocol that would be binding upon the existing devices on those networks.
The existing TCP / IP devices expect stability in address assignment, and the act of interconnecting two networks cannot by itself, cause reassignment of network addresses without knowledge of the devices themselves.
This mechanism is specifically unsuitable for use with arbitrary target devices on a TCP / IP local area network since it relies on assignment of a temporary network address, and a non-operational state known as ‘standby’, in order to allow the device configuration to be completed with manual assistance.
The technique of this system is not appropriate to the problem of automatic reassignment of network IP addresses when a target device is replaced in service, because under those conditions there would be no broadcast traffic to be monitored.
In particular, use of Ethernet switching devices on modern networks severely impedes the value of passive monitoring, since only messages designated as ‘broadcast’ or ‘multicast’ are made available by the switches for monitoring by parties other than the direct participants of the communication.
Devices that make use of this technique must be specifically designed to do so, because the protocols used are non-standard.
In sum, the problem with known systems is that they require involvement of a specialized administrator to oversee the part replacement in order to properly configure the network address.
The state of the art does not have a simple yet disciplined method to automatically designate proper IP addresses while maintaining the highest level of system integrity.