Address
The host identifier written in dotted decimal. Each octet has a value from 0 to 255 because it represents 8 bits.
An IPv4 address is not just a label on a device. It tells the device which neighbors are local, which traffic needs a gateway, and which replies can find their way back.
Before memorizing dotted-decimal patterns, ask the field question: if this sensor sends a message now, does its address put it in the right network, behind the right gateway, with enough evidence to troubleshoot the path?
IPv4 uses a 32-bit address, usually written as four decimal octets such as 192.168.1.100. The address is only useful when the device also knows which bits identify the local network, which bits identify the host, and where to send traffic that is not local.
That context is why two devices can have similar-looking addresses but different reachability. A sensor at 192.168.10.25/24 treats 192.168.10.80 as local, but treats 192.168.20.80 as a remote destination that needs a gateway. A sensor at 192.168.10.25/16 would make a different local decision. The dotted address did not change; the prefix changed the boundary.
In IoT deployments, IPv4 addressing is also an inventory and policy signal. A camera VLAN, a building-automation controller subnet, and a maintenance laptop subnet may all use private addresses, but the prefix tells switches, routers, firewalls, DHCP servers, and monitoring tools which operational group the device belongs to. A useful address record therefore includes address, prefix, gateway, assignment method, device role, owner, and intended traffic path.
The host identifier written in dotted decimal. Each octet has a value from 0 to 255 because it represents 8 bits.
The boundary between network bits and host bits. CIDR notation writes this as a prefix such as /24.
The next-hop router used when the destination is outside the local subnet.
The network address, broadcast address, loopback range, link-local range, and multicast range all have special meanings.
Modern IPv4 design should not rely on historical class defaults such as "Class C means /24." CIDR lets an engineer choose the prefix that fits the device count and routing boundary: a small point-to-point link might use a very small subnet, a dense camera floor might need more host addresses, and an enterprise summary route might cover many smaller subnets. The review question is whether the selected prefix matches operations, not whether the first octet belongs to an old class.
For IoT work, IPv4 planning usually starts with private RFC 1918 ranges. Use 10.0.0.0/8 for large estates, 172.16.0.0/12 for medium internal networks, and 192.168.0.0/16 for small sites. Then divide the range by building, floor, device type, trust zone, or operating responsibility.
A practitioner should turn that range choice into a deployable record before devices arrive. Count endpoints, gateways, controller interfaces, management ports, DHCP reservations, static addresses, test equipment, spares, and expected growth. Reserve obvious infrastructure addresses consistently, but document the convention instead of assuming everyone knows it. A subnet that technically has enough host addresses can still fail if the DHCP pool overlaps static assignments or if the gateway address is absent from the runbook.
During commissioning, verify the plan from both the device and the network side. On the device, record the assigned address, prefix, default gateway, DNS server, and whether the assignment came from DHCP or static configuration. On the network side, compare DHCP lease records, reservations, ARP tables, switch MAC-address tables, and firewall logs. This catches common rollout faults such as duplicate static addresses, masks copied from another VLAN, gateways pointing at the wrong SVI, and DHCP scopes that hand out addresses outside the intended policy boundary.
IPv4 packets carry source and destination addresses in the header. Routers do not read those addresses as building names or device types; they match destination prefixes in routing tables. That is why a clean addressing plan must align human grouping with prefixes that routers and firewall rules can use.
The forwarding path starts before a packet leaves the host. The host applies its prefix to decide whether the destination is local. If it is local, the host resolves the destination MAC address with ARP and sends the frame directly on the LAN. If it is remote, the host resolves the gateway MAC address and sends the IPv4 packet to that gateway. The destination IP address remains the final endpoint address; only the local Ethernet destination changes for the next hop.
The host applies its mask to decide whether the destination is on the same subnet.
If the destination is not local, the host sends the packet to a configured gateway.
Routers and firewalls can enforce policy when prefixes match operational zones.
TTL, route absence, wrong gateway, duplicate address, or wrong mask can all produce different failure symptoms.
Routers then apply longest-prefix match, decrement TTL, update the IPv4 header checksum, and forward toward the selected next hop if policy permits. If the packet is too large for the outgoing link and fragmentation is allowed, IPv4 can fragment the packet; if fragmentation is blocked or the Don't Fragment bit is set, the path needs a smaller packet size and an ICMP error path that reaches the sender. These mechanics matter for IoT gateways that bridge Ethernet, Wi-Fi, cellular, VPN, and low-power links with different MTUs and firewall rules.
Different failures leave different evidence. A wrong local mask often produces ARP for a destination that should have gone to the gateway. A missing default route keeps remote traffic on the device. A wrong gateway MAC appears in ARP but fails after the first hop. A firewall or route-table denial may show successful local delivery but no permitted service path. Reading packet captures, route tables, ARP caches, and gateway logs together keeps IPv4 troubleshooting grounded in the actual forwarding sequence.
IPv4 addresses are 32-bit identifiers written as four decimal octets, but an address alone does not make a device reachable. The mask or prefix defines the local subnet, the gateway handles non-local destinations, and private RFC 1918 ranges provide reusable internal space for IoT deployments. A good IoT address plan groups devices by operational responsibility and keeps enough evidence to troubleshoot local reachability, routing, and policy failures.
Treat IPv4 addressing as an operations contract: record the address range, prefix, gateway, owner, device group, growth allowance, and traffic policy before the deployment depends on it.