Before a DNP3 master can read a single point, it has to reach the right device, and DNP3 identifies devices with its own link-layer addresses that live inside every frame - independent of any IP address. Each conversation carries a source address for the sender and a destination address for the intended receiver, and if those numbers do not match what a device expects, the frame is ignored without so much as an error. This guide explains DNP3 master and outstation addressing, how it coexists with IP on a TCP link, and why one wrong address number can make an entire poll disappear.
DNP3 Master and Outstation Addresses in one line: In DNP3, every device has a link-layer address - a number, typically in the range 0 to 65519 for individual devices - carried in the data-link header of each frame. A master uses its own address as the source and the target outstation's address as the destination; the outstation replies with those roles reversed. These addresses are separate from IP addresses and identify DNP3 devices on both multi-drop serial lines and TCP links, where DNP3 usually runs on port 20000. If a device's configured address does not match the destination in the incoming frame, the frame is silently discarded.
DNP3's data-link layer wraps each message with a header that contains two addresses: the source, identifying the device that sent the frame, and the destination, identifying the device meant to process it. When a master polls, it sets the destination to the outstation's address and the source to its own; the outstation checks that the destination matches its configured address, acts on the request, and sends a reply with the source and destination swapped so the frame comes back to the master. This addressing is what lets many devices share one communication channel and still know which traffic is theirs.
The addresses are 16-bit numbers, giving a large range, though certain values are reserved - for example, a broadcast destination lets a master address all outstations on a line at once without expecting individual replies. In normal operation each master and each outstation is assigned a unique address for a given network, and those assignments are part of the site's configuration just like point indexes are. The address is not derived from anything physical; it is a logical identifier a commissioning engineer sets on both ends and must keep consistent.
It is worth stressing that these are DNP3's own addresses, not IP addresses and not hardware MAC addresses. A device can have an IP address of one value and a DNP3 outstation address of a completely unrelated number, and both must be correct for communication to work. The DNP3 address exists so the protocol can route frames among logical devices regardless of the underlying medium - the same addressing scheme works whether the frames travel over a serial radio link or inside TCP packets.
When DNP3 runs over serial, the link-layer address is the only way to tell devices apart, because a multi-drop line is a shared wire with no other addressing. Several outstations can hang off one radio or one RS-485 bus, and the destination address in each frame is what selects which one responds. Get the address right and the correct outstation answers; get it wrong and none do. There is no IP layer involved at all in that scenario.
Over a network, DNP3 is commonly carried inside TCP, and by convention the master connects to the outstation on TCP port 20000. Now there are two addressing systems stacked on top of each other. The IP address and port get the TCP packets to the right physical endpoint - the right RTU or gateway on the network - and the DNP3 source and destination addresses inside those packets identify the logical DNP3 devices. On a simple link, one IP endpoint hosts one outstation, but a data concentrator or gateway can present many DNP3 outstations behind a single IP address, and there the link-layer destination address is essential to reach the intended one.
This layering is a frequent source of confusion during commissioning. An engineer can confirm the RTU answers a network ping and even accepts a TCP connection on port 20000, yet still see no data, because reaching the IP endpoint proves nothing about the DNP3 addresses matching. The TCP connection establishes the pipe; the DNP3 addresses determine whether the device on the far end will actually respond to the frames flowing through it. Both must line up, and each is configured separately.
The defining trap of DNP3 addressing is that a mismatch produces silence rather than an error. If a master polls destination address 10 but the outstation is configured as address 11, the outstation sees a frame that is not addressed to it and simply drops it - it does not reply, does not raise a fault, and does not tell anyone why. From the master's side the poll times out with no data, which looks the same as a dead radio, a wiring fault, or a powered-down RTU. There is no protocol message that says the address was wrong, so the failure gives no clue to its own cause.
This makes address configuration one of the first things to verify when a DNP3 link will not come up, and one of the easiest to get wrong when copying a working configuration from one site to another. Two outstations accidentally sharing an address on the same channel, a master and outstation whose numbers were transposed, or an off-by-one from a template - all present as a total loss of communication with no diagnostic. Because DNP3 also has an application-layer confirmation and its own timers, an address problem can sometimes masquerade as intermittent behavior, but the core symptom is the whole poll vanishing.
For a cloud SCADA such as Merobix polling remote outstations, the platform's connection settings must carry the correct DNP3 master address, the correct destination address for each outstation, and the right IP endpoint and port 20000 for TCP links. Because a mismatch fails silently, Merobix relies on connection health and communication-status indicators to surface the problem as a failed link rather than leaving an operator staring at stale values. Getting the addresses right once, and treating them as controlled configuration when a field is expanded, is what keeps a fleet of remote RTUs reporting reliably - the addresses rarely change, but a single wrong number quietly removes a whole site from view.
No. A DNP3 outstation address is a link-layer number inside each DNP3 frame, while an IP address identifies the device on the network. They are configured independently and both must be correct on a TCP link. A gateway can even present several DNP3 outstation addresses behind one IP address, so the two addressing systems are genuinely separate.
By convention DNP3 over TCP uses port 20000, with the master initiating the connection to the outstation. The IP address and port 20000 get the TCP packets to the right physical endpoint, and the DNP3 source and destination addresses inside those packets identify the logical DNP3 devices. Both the network endpoint and the DNP3 addresses have to match for data to flow.
Because an outstation simply ignores any frame whose destination address is not its own - it drops the frame without replying or raising a fault. The master then just times out with no data, which looks identical to a dead link. There is no protocol response that tells you the address was the problem, so mismatched addresses are one of the first things to check on a silent link.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.