Each host that could have multiple discoverable applications installed should have a standalone LocalDiscoveryServer installed. The LocalDiscoveryServer shall expose one or more Endpoints which support the FindServers and GetEndpoints services defined in OPC 10000-4. In addition, the LocalDiscoveryServer shall provide at least one Endpoint which implements the RegisterServer service for these applications.

The FindServers Service returns the information for the LocalDiscoveryServer and all Servers that are known to the LDS.The GetEndpoints Service returns the EndpointDescriptions for the LocalDiscoveryServer that allow Servers to call the RegisterServer or RegisterServer2 Services. The LocalDiscoveryServer does not support Sessions so information needed for establishing Sessions, such as supported UserTokenPolicies, is not provided.

In systems (usually embedded systems) with exactly one Server installed this Server may also be the LDS (see 4.2.3).

An LDS-ME will announce all applications that it knows about on the local MulticastSubnet. In order to support this, a LocalDiscoveryServer supports the RegisterServer2 Service defined in OPC 10000-4. For backward compatibility a LocalDiscoveryServer also supports the RegisterServer Service which is defined in OPC 10000-4.

Each host with OPC UA Applications (Clients and Servers) installed should have a LocalDiscoveryServer with a MulticastExtension.

The MulticastExtension incorporates the functionality of the mDNS Responder described in the Multicast DNS (mDNS) specification (see mDNS). In addition the LocalDiscoveryServer that supports the MulticastExtension supports the FindServersOnNetwork Service described in OPC 10000-4.

The Multicast DNS (mDNS) specification is used for various commercial and consumer applications. This provides a benefit in that implementations exist, however, system administrators could choose to disable Multicast DNS operations. For this reason, Applications shall not rely on Multicast DNS capabilities.

Multicast DNS operations are insecure because of their nature; therefore they should be disabled in environments where an attacker could cause problems by impersonating another host. This risk is minimized if OPC UA security is enabled and all Applications use Certificate TrustLists to control access.

The discovery mechanisms defined in this standard are expected to be used in many different network architectures. The following three architectures are Illustrated:

• Single MulticastSubnet;
• Multiple MulticastSubnets;
• No MulticastSubnet (or multiple MulticastSubnets with exactly one host each);

A MulticastSubnet is a network segment where all hosts on the segment can receive multicast packets from the other hosts on the segment. A physical LAN segment is typically a MulticastSubnet unless the administrator has specifically disabled multicast communication. In some cases multiple physical LAN segments can be connected as a single MulticastSubnet

The Single MulticastSubnet Architecture is shown in Figure 8.

Figure 8 – The Single MulticastSubnet Architecture

In this architecture every host has an LDS-ME and uses mDNS to maintain a cache of the applications on the MulticastSubnet. A Client can call FindServersOnNetwork on any LDS-ME and receive the same set of applications. When a Client calls FindServers it only receives the applications running on the same host as the LDS.

The Multiple MulticastSubnet Architecture is shown in Figure 9.

Figure 9 – The Multiple MulticastSubnet Architecture

This architecture is the same as the previous architecture except in this architecture the mDNS messages do not pass through routers connecting the MulticastSubnets. This means that a Client calling FindServersOnNetwork will only receive a list of applications running on the MulticastSubnets that the LDS-ME is connected to.

A Client that wants to connect to a remote MulticastSubnet shall use out of band discovery (i.e. manual entry) of a HostName or DiscoveryUrl. Once a Client finds an LDS-ME on a remote MulticastSubnet it can use FindServersOnNetwork to discover all applications on that MulticastSubnet.

The No MulticastSubnet Architecture is shown in Figure 10.

Figure 10 – The No MulticastSubnet Architecture

In this architecture the mDNS is not used at all because the Administrator has disabled multicast at a network level or by turning off multicast capabilities of each LDS-ME.

A Client that wants to discover applications needs to use an out of band mechanism to find the HostName and call FindServers on the LDS of that host. FindServersOnNetwork may also work but it will never return more than what FindServers returns. Clients could also use a GDS if one is available.

The mDNS specification requires that fully qualified domain name be announced on the network. If a Server is not configured with a fully qualified domain name then mDNS requires that the ‘local’ top level domain be appended to the domain names. The ‘local’ top level domain indicates that the domain can only be considered to be unique within the subnet where the domain name was used. This means Clients need to be aware that URLs received from any LDS-ME other than the one on the Client’s computer could contain ‘local’ domains which are not reachable or will connect to a different computer with the same domain name that happens to be on the same subnet as the Client. It is recommended that Clients ignore all URLs with the ‘local’ top level domain unless they are returned from the LDS-ME running on the same computer.

System administrators can eliminate this problem by configuring a normal DNS with the fully qualified domain names for all computers which need to be accessed by Clients outside the MulticastSubnet.

Servers configured with fully qualified domain names should specify the fully qualified domain name in its ApplicationInstance Certificate. Servers shall not append the ‘local’ top level domain to any domains declared in their Certificate; an unqualified domain name is used if a more appropriate qualifer does not exist. Clients using a URL returned from an LDS-ME shall ignore the ‘local’ top level domain when checking the domain against the Server Certificate.

Note that domain name validation is a necessary but not sufficient check against rogue Servers or man-in-the-middle attacks when Server Certificates do not contain fully qualified domain names. The Certificate trust relationship established by administrators is the primary mechanism used to protect against these risks.