OPC UA UDP is a simple UDP based protocol that is used to transport UADP NetworkMessages.

A PubSubConnection for UDP shall have a unique Address across all PubSubConnections of an OPC UA Application.

If the Address specifies a domain name then the resolution to an IP address requires access to a domain name resolution service (e.g., the DNS protocol) that maps the domain name onto a usable network address. OPC 10000-7 defines Profiles for different name resolution protocols that Publisher or Subscriber may support.

For OPC UA UDP it is recommended to limit the MaxNetworkMessageSize plus additional headers to a MTU size. The number of frames used for a UADP NetworkMessage influences the probability that UADP NetworkMessages get lost.

Note: The MaxNetworkMessageSize that fits into one MTU is maximum 1472 Byte for IPv4 and 1452 Byte for IPv6. The additional headers have a size of 22 Byte for Ethernet, 20 Byte for IPv4 or 40 Byte for IPv6 and 8 Byte for UDP. This is based on IETF RFC 8200 for IPv6, RFC 791 for IPv4 and RFC 768 for UDP.

For OPC UA UDP the MaxNetworkMessageSize plus additional headers shall be limited to 65535 Byte.

The transport of a UADP NetworkMessage in a UDP packet is defined in Table 195.

Table 195 – UADP message transported over UDP

Name	Description
Frame Header	The frame header.
IP Header	The IP header for the frame contains information like source IP address and destination IP address. IPv4 and IPv6 addresses can be used. The size of the IP header depends on the used version.
UDP Header	The UDP header for the frame contains the source port, destination port, length and checksum. Each field is two byte long. The total size of the UDP header is 8 byte.
UADP NetworkMessage	The UADP NetworkMessage is sent as UDP data.
Frame Footer	The frame footer.

The IANA registered IPv4 multicast address for discovery is 224.0.2.14. It shall only be used for OPC UA discovery purposes. The recommended port for discovery is 4840. Therefore the default DiscoveryAddress has the following form:

opc.udp://224.0.2.14

The default DiscoveryMaxMessageSize for UDP is 4096 bytes.

The transport protocol URL for UDP multicast and broadcast communication is configured on a PubSubConnection for Publisher and Subscriber. The Address parameter for a PubSubConnection is defined in 6.2.7.3.

The Url field in the Address is used as destination address for NetworkMessages sent as UDP datagram. The Address is also used to receive UDP datagrams from the multicast IP address. All DataSetWriters and DataSetReaders that send to and receive from the multicast IP address shall be configured on one PubSubConnection. The Address parameter for WriterGroup datagram TransportSettings shall be null. If an Address is configured on a WriterGroup, the WriterGroup PubSubState shall be Error. The NetworkInterface field in the Address is required if more than one network interface is available.

The syntax of the UDP transport protocol URL used in the Address has the following form:

opc.udp://<address>[:<port>]

The address is either an multicast or broadcast IP address or a registered name like a domain name that can be resolved to a multicast or broadcast IP address.. It is the destination of the UDP datagram.

The IANA registered OPC UA port for UDP communication is 4840. This is the default and recommended port for broadcast and multicast communication. Alternative ports may be used.

It is recommended to use switches with IGMP and MLD support to limit the distribution of multicast traffic to the interested participants.

Note: The Internet Group Management Protocol (IGMP) is a standard protocol used by hosts to report their IP multicast group memberships for IPv4 and needs to be implemented by any host that wishes to receive IP multicast datagrams. IGMP messages are used by multicast routers to learn which multicast groups have members on their attached networks. IGMP messages are also used by switches capable of supporting “IGMP snooping” whereby the switch listens to IGMP messages and only sends the multicast NetworkMessages to ports that have joined the multicast group. The corresponding protocol for IPv6 is the Multicast Listener Discovery (MLD).There are different versions of IGMP and MLD: - IGMP V1 is defined in IETF RFC 1112. - IGMP V2 is defined in IETF RFC 2236. - IGMP V3 is defined in IETF RFC 3376.

- IGMP V3 and MLD V2 are defined in IETF RFC 4604.

IETF RFC 2236 and IETF RFC 3376 discuss host and router requirements for interoperation with older IGMP versions.If OPC UA devices make extensive use of IP multicast for UDP transport, consistent IGMP and MLD usage by OPC UA devices is essential in order to create well-functioning OPC UA Application networks.

OPC UA Applications shall issue an IGMP membership report message (V1, V2 or V3 as appropriate) for IPv4 or a MLD membership report message for IPv6 when enabling a PubSub connection on which they will receive UDP multicast NetworkMessages.

For UDP unicast, the address information for the Subscriber is configured on the PubSubConnection and the address information for the Publisher is configured on the WriterGroup.

The receive port for UDP unicast communication is configured on a PubSubConnection. The Address parameter for a PubSubConnection is defined in 6.2.7.3. All NetworkMessages for one port are received through one PubSubConnection. The filtering and assignment of NetworkMessages for the Subscriber is done based on the PublisherId. The hostname for the Url in the PubSubConnection Address parameter is set to ‘localhost’ since the source address is not used for filtering. The NetworkInterface field in the Address is not required and is only configured if the Subscriber should listen only on the configured interface. If the NetworkInterface is null or empty, the Subscriber should listen on all interfaces.

The syntax of the Url field in the PubSubConnection Address parameter has the following form:

opc.udp://localhost[:<port>]

The destination address is configured on the datagram TransportSettings of a WriterGroup. The Address parameter for a WriterGroup datagram TransportSetting is defined in 6.4.1.3.4. The Address parameter for WriterGroup datagram TransportSettings shall be configured. If no Address is configured on a WriterGroup, the WriterGroup PubSubState shall be Error. The NetworkInterface field in the Address is not required and should be null or empty and shall be ignored.

The syntax of Url field in the WriterGroup datagram TransportSettings Address parameter has the following form:

opc.udp://<host>[:<port>]

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

The syntax is also used for the ResponseAddress in the ActionHeader of ActionRequest messages. If the ResponseAddress is not provided, the sender IP address and port of the ActionRequest is used.

The IANA registered OPC UA port for UDP communication is 4840. This is the default and recommended port for unicast communication. Alternative ports may be used.

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.

The DTLS transport does not support multicast of PubSub, and therefore can only be used for unicast communication. If multicast is needed other transports should be used. By definition the DTLS transport is only providing transport security, no notion of user level or application level security is provided. There are other OPC UA mechanisms which provide this, but by itself DTLS does not provide security at the user or application layer.

The DTLS transport supports the ability to use different cipher suites for a given PubSub Connection. This is configured via the ConnectionProperties of the PubSubConnectionDataType structure. A default value is configured in the ConfigurationProperties of the PubSubConfiguration. The properties are defined through the KeyValuePair array in the ConnectionProperties. The NamespaceIndex of the QualifiedName in the KeyValuePair shall be 0 for DTLS standard properties. The Name of the QualifiedName is constructed from a prefix and the DTLS property name with the following syntax. The intended use is for the DTLS client to include a single cipher suite in the handshake, which is the cipher suite to be used for that connection. To facilitate this, the DTLS server may have a list of cipher suites that are accepted if sent by a DTLS client in the handshake.

The NamespaceIndex of the QualifiedName in the KeyValuePair for properties defined in this document shall be 0. The Name of the QualifiedName is the property key from Table 202. The DataType of the Value in the KeyValuePair shall be the DataType defined in Table 202.

Table 202 formally defines the DTLS configuration properties

Table 196 – OPC UA DTLS standard properties

Key	DataTypes	Description
0:DtlsConnectionSettings	DtlsPubSubConnectionDataType	The DTLS configuration for the PubSubConnection or WriterGroup. The DtlsPubSubConnectionDataType is defined in 6.4.1.7.6.
0:DtlsClientCipherSuite	String	Cipher suite for the PubSubConnection or WriterGroup. The ClientCipherSuite is defined in 6.4.1.7.1.