SCADA Distributed Network Protocol (DNP3)

May 21, 2015 by Ixia Blog Team

DNP3 (Distributed Network Protocol) represents a set of communication protocols that are deployed between components in process automation systems. It is mainly used in utilities such as electric and water companies and was developed for communications between different types of data acquisition and control equipment. In SCADA systems, DNP3 is used by SCADA Master Stations (Control Centers), Remote Terminal Units (RTUs) and Intelligent Electronic Devices (IEDs).

Protocol Structure

The DNP3 protocol[1] is composed of three main layers (link layer, transport layer and application layer) and can sit on top of a serial bus connection or a TCP/IP network. In the case of TCP/IP, the protocol messages—which have all three layers—are sent via a TCP stream. For a graphical representation of the DNP3 over a TCP/IP network stack, see Fig. 1, below.


Fig. 1. DNP3 over a TCP/IP Network Stack

Now, we’ll take a closer look into the details behind each layer.

Link Layer

The DNP3 link layer provides functionality similar to the Ethernet layer. It contains:

  • Two magic bytes at the start, with the value 0x0564, signaling that this is a DNP3 packet
  • A one byte length field, which represents the length of all the fields following it, minus the CRCs length
  • A one byte control field, whose structure is presented in Fig. 2, below.
  • Two bytes source and destination fields identifying the sender and receiver of the message
  • A two byte header CRC field

DNP3 Link Layer

Fig. 2. DNP3 Link Layer Control Field Structure

The data following the link layer header (the transport & application layers) are split into 16 byte chunks with a two byte CRC field appended to each chunk.

Transport Layer

The transport layer is presented on only one byte and is mainly used for fragmenting large DNP3 packets. (The length of each packet is bound by the one byte length field, so a maximum of 255 bytes, excluding CRCs, is permitted.) The FIN and FIR bits (see Fig. 1) are used to indicate that this is the final and/or first fragment in the sequence. The six bit sequence number is used for fragment reassembly. In case the payload is only composed of a single fragment, it will have both the FIN and FIR bits set.

Application Layer

The application layer of DNP3 is composed of:

  • A one byte Application Control field, whose structure is detailed in Fig. 3. The field accommodates fragmentation functionality in the application layer, as well as indicates whether the current message is unsolicited or is a confirmation.
  • A one byte Function Code, which identifies the function to be performed by the target DNP3 device (e.g., Confirm, Read, Write, Select, Operate, Cold Restart, Response, etc.).
  • A two byte Internal Indications field, which is only present in packets that have a Response function code and whose goal is to provide details about the status of the requested operation.
  • Zero or more Object Ranges, whose detailed structure is presented in Fig. 4.

DNC3 Application Control

Fig. 3. DNP3 Application Control Field Structure

DNP3 Object Range

Fig. 4. DNP3 Object Range Structure

The object type sent in a DNP3 object range is determined by the object group and variation within that group (e.g., object group 0, variation 252 corresponds to Device Attributes - Device Manufacturer's Name). The object types supported vary by each DNP3 capable device, and each manufacturer generally documents its supported types.

The qualifier field is used to determine the indexing structure of the objects. It has two subfields:

  • Object Prefix Code, which specifies whether each object will be prefixed with either an index or a size field of a specific length.
  • Range Specifier Code, which specifies the range field type. The range field basically determines the number of objects within the range.

Creating an ATI DNP3 Super Flow

The DNP3 ATI protocol exposes three basic actions for sending messages across:

  • Request used for sending a DNP3 request message (the internal indications field is NOT included)
  • Response used for sending a DNP3 response message (the internal indications field is included and configurable via actions parameters)
  • Data Link Frame used for performing link layer-specific DNP3 actions

An example Super Flow is presented in Fig. 5. The Super Flow emulates the messages exchanged between the master station and the device when reading the device attributes.

DNP3 Super Flow

Fig. 5. DNP3 Read Device Attributes Super Flow

The typical configuration parameters for the Request action are available in Fig. 6. These permit the configuration of the fields on all layers of the DNP3 stack. Among them, the most important is the Object Ranges Configuration File parameter. This parameter lets you specify a JSON-formatted file containing the configuration for the object ranges that will be encoded in the application layer.

DNP3 Configuration

Fig. 6. Configurable DNP3 Parameters for the Request Action

An example configuration file for the previous request would be the following:


"ranges" : [


"type" : 0,

"variation" : 252,

"index_prefix" : 0,

"qualifier_code" : 6




For the corresponding response action, the object ranges configuration file would look like the following:


"ranges" : [


"type" : 0,

"variation" : 252,

"index_prefix" : 0,

"qualifier_code" : 0,

"start" : 0,

"stop" : 0,

"points_data" : "010353454c"




The JSON keys correspond to the specific object range fields. The object data is specified in hex format via the points_data key.

DNP3 Testing

We’ve now covered the basics of DNP3 and our implementation of it. Now it’s time for you to put it to good use and commence testing DNP3-capable devices with interesting traffic. Ixia’s DNP3 protocol is now available as of StrikePack 238281. Download the StrikePack from StrikeCenter.[2]

Additional Resources:

Ixia security solutions

ATI subscription