CIP TCP/IP Interface Object Explained (Class 0xF5)

Every EtherNet/IP device has an IP address. Every device has a subnet mask and a gateway. Every device decides whether to get its address from DHCP, BOOTP, or static configuration. Every device that participates in multicast I/O has a multicast address range. All of this lives in one CIP object — the TCP/IP Interface Object, Class 0xF5.

When you use BootP/DHCP Server to assign an IP to a new I/O block, you are writing to its TCP/IP Interface Object. When you configure multicast settings explicitly instead of using the algorithm, you are writing to attribute 9 of the TCP/IP Interface Object. When a device reports “I have valid configuration from DHCP,” that status comes from attribute 1 of the TCP/IP Interface Object.

This article is the complete reference for Class 0xF5 from ODVA’s CIP Networks Library Volume 2, Section 5-3. For broader context, see the CIP Protocol Complete Guide and the CIP Object Model Explained article.

What the TCP/IP Interface Object is in one paragraph

The TCP/IP Interface Object (Class Code 0xF5, decimal 245) is the CIP object that holds a device’s TCP/IP network configuration — IP address, subnet mask, default gateway, DNS servers, domain name, host name, multicast settings, and the device’s startup behavior (DHCP vs BOOTP vs static). Per Volume 2 Section 5-3, every TCP/IP-capable EtherNet/IP device must have exactly one instance of this object for each TCP/IP-capable communications interface. The underlying physical interface (Ethernet, ATM, SLIP, PPP) is identified through an attribute that links to the corresponding Ethernet Link Object (Class 0xF6) or equivalent link-specific object.

Where the TCP/IP Interface Object fits

EtherNet/IP devices have a clean two-object split for network configuration:

Object	Class	Layer	What it holds
TCP/IP Interface Object	0xF5	TCP/IP (Layer 3-4)	IP, subnet, gateway, DNS, multicast
Ethernet Link Object	0xF6	Ethernet (Layer 1-2)	MAC, link speed, error counters

The TCP/IP Interface Object handles “network layer and above.” The Ethernet Link Object handles “data link layer and below.” Each device has one of each per network interface, and they are linked together by an attribute that points from one to the other. The Physical Link Object attribute (Attribute 4) in the TCP/IP Interface Object identifies which Ethernet Link Object instance it sits on top of.

A device with two Ethernet ports (for daisy-chained DLR topologies, for example) has two Ethernet Link Object instances but typically one TCP/IP Interface Object instance — because both physical ports share one IP address through the device’s internal switch.

The class attributes

Per Volume 2 Table 5-3.1:

Attr ID	Need	Access	Name	Type	Purpose
1	Optional	Get	Revision	UINT	Object revision (described in Vol 1 Ch 4)
2	Conditional	Get	Max Instance	UINT	Highest instance ID currently created
3	Conditional	Get	Number of Instances	UINT	Number of instances at this class
4-7	Optional	Get	Various optional class attributes	—	See Vol 1 Ch 4

For most devices the class attributes don’t matter much — they have exactly one instance and engineers go straight to instance 1.

The instance attributes — what engineers actually read and write

Per Volume 2 Table 5-3.2:

Attr ID	Need	Access	Name	Type	Purpose
1	Required	Get	Status	DWORD	Interface configuration status
2	Required	Get	Configuration Capability	DWORD	What configuration methods device supports
3	Required	Set	Configuration Control	DWORD	How device should configure itself
4	Required	Get	Physical Link Object	STRUCT	Path to underlying Ethernet Link Object
5	Required	Set	Interface Configuration	STRUCT	IP, mask, gateway, DNS, domain
6	Required	Set	Host Name	STRING	Device’s host name
7	Conditional	—	Safety Network Number	6 octets	For CIP Safety devices only
8	Conditional	Get/Set	TTL Value	USINT	Multicast Time-to-Live
9	Conditional	Get/Set	Mcast Config	STRUCT	Multicast address allocation

(Later editions of the spec — Edition 1.5 and beyond — added more attributes: Address Conflict Detection (Attribute 10), Quick Connect (Attribute 12), Encapsulation Inactivity Timeout (Attribute 13), and others. Read your device’s documentation or EDS for what it actually implements.)

The first six attributes are required on every TCP/IP-capable device. We’ll walk through each.

Attribute 1 — Status

A DWORD bitmap that shows the current state of the network interface. Per Volume 2 Table 5-3.3:

Bits	Field	Meaning
0-3	Interface Configuration Status	0 = Not configured, 1 = Valid config from BOOTP/DHCP/NVRAM, 2 = Valid config from hardware switches, 3-15 = Reserved
4	Mcast Pending	1 = TTL or Mcast Config changed but not yet applied (cleared on next startup)
5-31	Reserved	Must be 0

Reading attribute 1 tells you immediately whether the device has working network configuration:

• Value 0x00000001 → Interface configured from BOOTP, DHCP, or non-volatile storage
• Value 0x00000002 → Interface configured from hardware switches (rotary, pushwheel, etc.)
• Value 0x00000000 → No configuration — the device needs one

A device returning 0 in the low nibble cannot do TCP/IP — it’s waiting for someone to give it an IP address.

Attribute 2 — Configuration Capability

A DWORD bitmap that tells you what configuration methods the device supports. Per Volume 2 Table 5-3.4:

Bit	Name	Meaning
0	BOOTP Client	Device can obtain configuration via BOOTP
1	DNS Client	Device can resolve host names via DNS
2	DHCP Client	Device can obtain configuration via DHCP
3	DHCP-DNS Update	Device can send host name in DHCP request
4	Configuration Settable	The Interface Configuration attribute (Attribute 5) can be set via CIP
5-31	Reserved	Must be 0

This is a read-only attribute — the device tells you what it can do, you don’t get to change it.

The Configuration Settable bit (bit 4) matters: some devices (especially PCs running EtherNet/IP stacks for monitoring) cannot have their IP set via CIP — bit 4 is 0 for those. Field devices typically have bit 4 set to 1 so configuration tools can write the IP directly.

The spec requires that every conformant device support at least one method of obtaining an initial IP address — so at minimum one of bits 0, 2, or 4 is always set.

Attribute 3 — Configuration Control

A DWORD bitmap you write to tell the device how it should configure itself at startup. Per Volume 2 Table 5-3.5:

Bits	Field	Meaning
0-3	Startup Configuration	0 = Use stored values, 1 = BOOTP at startup, 2 = DHCP at startup, 3-15 = Reserved
4	DNS Enable	1 = Resolve hostnames via DNS
5-31	Reserved	Must be 0

This is the attribute you set to decide whether the device uses DHCP, BOOTP, or static configuration.

Value 0x00000000 → “Use stored values” (static IP from non-volatile storage) Value 0x00000001 → “Use BOOTP at startup” Value 0x00000002 → “Use DHCP at startup” Value 0x00000010 → “DNS lookup enabled, static IP” Value 0x00000012 → “DHCP at startup + DNS enabled”

A typical commissioning workflow:

1. Device ships with bits 0-3 = 1 (BOOTP) or 2 (DHCP) and zero IP address
2. Engineer uses BootP/DHCP Server to assign an IP
3. Engineer writes Attribute 3 with value 0 (Use stored values)
4. Engineer writes Attribute 5 with desired static IP, mask, gateway
5. Device stores both in NVRAM and uses them on all future power-ups

The spec explicitly warns: never set bits 0-3 to 0 unless Attribute 5 has a valid IP. Doing so could render the device unable to communicate on the network.

Attribute 4 — Physical Link Object

A STRUCT containing a Path that points to the underlying link object — typically an Ethernet Link Object (Class 0xF6) instance. Per Volume 2 Section 5-3.2.2.4:

Field	Type	Purpose
Path size	UINT	Size of the path in 16-bit words
Path	Padded EPATH	EPATH to the link object (typically Class 0xF6, Instance N)

For a standard EtherNet/IP device with one Ethernet port, this typically points to Class 0xF6 (Ethernet Link Object), Instance 1. For a device with two ports (DLR-capable), it might point to a specific port instance.

This attribute is what links the two-object pair (TCP/IP Interface + Ethernet Link) together. When a configuration tool wants to read MAC address or port statistics, it follows this path from the TCP/IP Interface Object to the corresponding Ethernet Link Object.

Attribute 5 — Interface Configuration

The big one. A STRUCT containing the complete IP-layer network configuration:

Field	Type	Purpose
IP Address	UDINT	The device’s IP address
Network Mask	UDINT	Subnet mask
Gateway Address	UDINT	Default gateway
Name Server	UDINT	Primary DNS server
Name Server 2	UDINT	Secondary DNS server
Domain Name	STRING	Default domain name (up to 48 characters)

When you write Attribute 5, you write all six fields together. Set unused fields to 0 (e.g., Name Server = 0 if you don’t have DNS).

Per the spec:

• IP Address = 0 means no IP address has been configured
• IP Address must be a valid Class A, B, or C address — not the loopback (127.0.0.1)
• Network Mask = 0 means no mask configured
• Same loopback restriction applies to Gateway and Name Server fields
• Domain Name length 0 means no domain configured

A typical write to Attribute 5 to set 192.168.1.10 with mask 255.255.255.0 and gateway 192.168.1.1:

IP Address:     0xC0A8010A  (192.168.1.10)
Network Mask:   0xFFFFFF00  (255.255.255.0)
Gateway:        0xC0A80101  (192.168.1.1)
Name Server:    0x00000000  (none)
Name Server 2:  0x00000000  (none)
Domain Length:  0
Domain:         (empty)

These values are transmitted little-endian on the wire per CIP convention.

When does the new configuration take effect?

Per Volume 2 Section 5-3.4: “The TCP/IP Interface Object shall apply the new configuration upon completion of the Set Attribute request.” So the IP change takes effect immediately after the Set succeeds. Be aware: if you change the IP from the same connection that’s writing the change, you will lose communication immediately after the device acknowledges the Set.

The common safe pattern: write the new IP, wait for the acknowledgment, then reconnect to the new IP.

Attribute 6 — Host Name

A STRING (up to 64 characters) containing the device’s host name. Used in DHCP-DNS update (when the device announces itself by name to DNS) and for general identification.

Some devices auto-generate the host name from their serial number or MAC address; others let you set it explicitly. This attribute is settable on most field devices.

Attribute 7 — Safety Network Number

A 6-octet identifier defined by the CIP Safety specification (Volume 5). Only present on EtherNet/IP safety devices. Non-safety devices must not implement this attribute.

The Safety Network Number (SNN) uniquely identifies the safety subnet that this device belongs to and is used by CIP Safety to validate safety connection establishment. For more on safety networking, see our CIP Safety Explained article.

Attribute 8 — TTL Value

A USINT (1 byte) containing the Time-to-Live value used for IP multicast packets sent by this device. Per Volume 2 Section 5-3.2.2.7:

• Default value: 1 (multicast stays on local subnet)
• Minimum: 1
• Maximum: 255

Common values:

TTL	Scope
1	Local subnet only (default)
16	Within a site
64	Within a region
255	Unrestricted

For a plant where I/O traffic must stay on one VLAN, TTL = 1 is correct. For multicast that needs to cross subnet boundaries (with appropriate router configuration), use a higher TTL.

Per the spec, if either Attribute 8 (TTL) or Attribute 9 (Mcast Config) is implemented, both must be implemented. They’re a paired optional capability.

Attribute 9 — Mcast Config

The multicast configuration STRUCT. This is where you override the default algorithmic multicast addressing with explicit values. Per Volume 2 Section 5-3.2.2.8:

Field	Type	Purpose
Alloc Control	USINT	0 = use algorithm, 1 = use Mcast Start Addr
Reserved	USINT	Must be 0
Num Mcast	UINT	Number of multicast addresses to allocate
Mcast Start Addr	UDINT	Starting multicast address (Class D)

When Alloc Control = 0 (default), the device uses the algorithmic multicast address generation described in Volume 2 Section 3-5.3 (see our EtherNet/IP I/O Messaging on UDP Port 2222 article).

When Alloc Control = 1, the device uses the explicit Mcast Start Addr + Num Mcast values. So a device configured with Alloc Control = 1, Num Mcast = 32, Mcast Start Addr = 0xEFFF0100 (239.255.1.0) would produce its multicast traffic on addresses 239.255.1.0 through 239.255.1.31.

Explicit multicast configuration is useful in installations where the algorithmic addresses would collide across subnets, or where the network administrator wants explicit control over which multicast addresses are used.

Common services on the TCP/IP Interface Object

The standard services that work:

Service	Code	Common usage
Get_Attribute_Single	0x0E	Read one attribute (e.g., Status, Configuration Capability)
Get_Attributes_All	0x01	Read all attributes in one transaction
Set_Attribute_Single	0x10	Set IP configuration, TTL, multicast settings

To assign a static IP to a freshly DHCP-configured device, the typical sequence is:

1. Read Attribute 1 (Status) to confirm device is configured
2. Read Attribute 2 (Configuration Capability) to confirm Configuration Settable bit is set
3. Write Attribute 5 (Interface Configuration) with new IP, mask, gateway, DNS, domain
4. Write Attribute 3 (Configuration Control) with value 0 to switch to “use stored values”
5. Read Attribute 1 again to confirm successful configuration

For details on the underlying services, see our CIP Service Codes Complete Reference.

How devices boot — DHCP vs BOOTP vs static

When an EtherNet/IP device powers up, it consults Attribute 3 (Configuration Control) to decide how to get its IP:

Startup Configuration = 0 (Use stored values)

The device uses the IP address, mask, gateway, and DNS values previously stored in non-volatile memory. This is the typical operational mode for production devices — boot up, use the IP that was configured during commissioning, no DHCP needed.

If the device has never been configured (all stored values are 0), it cannot communicate until someone configures it through another method.

Startup Configuration = 1 (BOOTP)

The device sends a BOOTP request at startup with its MAC address. A BOOTP server on the network responds with the assigned IP configuration. Common during initial commissioning — Rockwell’s BootP/DHCP Server tool can serve BOOTP responses to assign IPs to factory-fresh devices.

After BOOTP succeeds, the device has working network configuration. Most engineers then write Attribute 3 = 0 (Use stored values) to switch the device to static mode for production.

Startup Configuration = 2 (DHCP)

The device sends a DHCP request at startup. A DHCP server responds with an IP lease. Common for office/IT-oriented network deployments and some plant networks with DHCP infrastructure.

The downside: DHCP can result in the device getting a different IP each power-up if the server isn’t configured for DHCP reservations. For industrial use, DHCP reservations (also called “static DHCP”) are recommended — the DHCP server always assigns the same IP to the same MAC.

Switching from DHCP/BOOTP to static

The common commissioning pattern:

1. Power up device → it asks for DHCP/BOOTP
2. Server assigns initial IP
3. Engineer uses configuration tool to:
   • Write the desired permanent IP to Attribute 5
   • Write 0 to Attribute 3 (Use stored values)
4. Future power cycles → device uses the stored IP, no DHCP/BOOTP needed

For more on commissioning with EDS files, see our EDS Files Explained article.

Common TCP/IP Interface Object errors

Symptom	Likely cause	What to check
Set_Attribute_Single returns 0x0E (Attribute not settable)	Configuration Settable bit in Attribute 2 is 0	Device doesn’t allow CIP-based IP configuration (rare for field devices)
Set_Attribute_Single returns 0x09 (Invalid attribute value)	Invalid IP (loopback, multicast, broadcast)	Use valid unicast IP in Class A/B/C ranges
Device unreachable after IP change	New IP and gateway don’t match the network	Verify new IP is reachable from your configuration tool
Multicast traffic on wrong addresses	Algorithm-based addresses colliding	Configure explicit multicast via Attribute 9
Device keeps DHCP-ing after assigning static IP	Attribute 3 still set to DHCP	Write Attribute 3 = 0 to switch to stored values
Status (Attribute 1) low nibble = 0	Device has no configuration	Use BootP/DHCP or hardware switches to provide initial config
TTL change doesn’t take effect	Mcast Pending bit set in Status	Some devices apply TTL only on next startup

Reading TCP/IP Interface Object in Wireshark

Useful filters:

cip                                       # All CIP traffic
cip.class == 0xF5                         # All TCP/IP Interface Object access
cip.class == 0xF5 && cip.service == 0x0E  # Read attribute requests
cip.class == 0xF5 && cip.service == 0x10  # Set attribute (IP changes)
cip.attribute == 5                        # Specifically the Interface Configuration attribute

When engineers report “the IP keeps changing on me,” capturing CIP traffic and filtering on Class 0xF5 with Set_Attribute_Single quickly reveals which tool or PLC is writing to the device.

For broader Wireshark workflows, see our Wireshark for EtherNet/IP guide.

Frequently asked questions