The DTLS option is provided mainly for use in high speed device to device communication where hardware may be particularly optimized for DTLS (for either the DTLS handshake and/or the DTLS record layer). This option supports DTLS 1.3, previous versions of DTLS are not supported. Note in DTLS application data (OPC UA PubSub) and handshake messages are multiplexed on the same channel which could have an impact on applications requiring a high level of determinism. Certificates are required for the DTLS Transport, and in order to manage these certificates the DTLS Transport requires the OPC UA GDS CertificateManager. Pull Management or Push Management of certificates shall be supported by any Publisher or Subscriber that supports the DTLS Transport (see Part 12 for more information on the CertificateManager). DTLS makes use of the same Certificates and Trust List that are used for OPC UA Client Server communication, as well as the same procedure for validation of the certificates (see Part 4 “Determining if a Certificate is Trusted” for more information on this). That is, the DefaultApplicationGroup Object is used as the Certificate and TrustList for DTLS communication. A separate certificate group may optionally be used for the DTLS transport. See Part 7 for information on what certificate types may be used for DTLS.

DTLS is not supported for broker-based PubSub transports.

When DTLS Transport is used the DTLS handshake sets up a secure session prior to the PubSub data exchange. In this case either the Subscriber or the Publisher acts as the DTLS Client, with the other one acting as the DTLS Server. Once a DTLS session is established between two endpoints PubSub data is then sent. Different Reader/Writer groups will use the same DTLS session to send data betweent two endpoints. DTLS allows for authentication of just the server or of the client and the server; both cases are supported and can be configured via the VerifyClientCertificate parameter. The high level data flow for a Subscriber acting as the DTLS client is shown in Figure 39 and Figure 40 shows the high level data flow for a Publisher acting as the DTLS client. Note these figures are shown for illustrative purposes, precise details of messages may differ depending on configuration options.

Figure 39 – Subscriber as DTLS Client

Figure 40 – Publisher as DTLS Client

Addressing for DTLS is similar to UADP unicast.

The receive address for DTLS unicast communication is configured on a PubSubConnection. The Address parameter for a PubSubConnection is defined in 6.2.7.3.

The syntax of the URL used in the PubSubConnection Address parameter has the following form:

opc.dtls://localhost:<port>

The send address is configured on the datagram TransportSettings of a WriterGroup. The Address parameter for a datagram TransportSetting is defined in 6.4.1.3.4.

The syntax of the URL used in the datagram TransportSettings Address parameter has the following form:

opc.dtls://<host>:<port>

The host is either a unicast IP address or a registered name like a hostname or domain name that can be resolved to a unicast IP address. The IP address and the port are the destination of the DTLS UDP datagram.

The IANA registered OPC UA port for PubSub over DTLS is 4843. This is the default and recommended port for any PubSub communication using DTLS. Alternative ports may be used.