11 IPv4 Addressing Fundamentals

11.2 Overview: An IPv4 Address Names a Host in a Network Context

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.

Ground overview: an ipv4 address names a host in a network context with the visual at Figure 11.1. Start from IPv4 Address Structure, but keep Octet 1 visible while evaluating ipv4 is a 32-bit address. dotted-decimal notation is a human-readable view of those bits.

Compare IPv4 Address Structure with Octet 1 inside the visual at Figure 11.1. Next find 8 bits, which completes the scope of ipv4 is a 32-bit address. dotted-decimal notation is a human-readable view of those bits. The decision in overview: an ipv4 address names a host in a network context must preserve that labelled boundary.

The next claim about overview: an ipv4 address names a host in a network context depends on Figure 11.2. Its diagram makes IPv4 Address Classes A-E and Class explicit within classful addressing is historical context. modern designs use cidr and subnet evidence instead of default class boundaries.

Compare IPv4 Address Classes A-E with Class inside the visual at Figure 11.2. Next find First Octet, which completes the scope of classful addressing is historical context. modern designs use cidr and subnet evidence instead of default class boundaries. The decision in overview: an ipv4 address names a host in a network context must preserve that labelled boundary.

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.

Public IPv4 addresses are not self-assigned. ICANN, through IANA, holds the global IPv4 and IPv6 space and delegates large blocks to five Regional Internet Registries such as ARIN, RIPE NCC, APNIC, and LACNIC. Those registries allocate smaller blocks to ISPs, and ISPs in turn assign addresses to the enterprises and networks they serve. That chain is why a public address on an IoT gateway can usually be traced back to a specific ISP and registry, which matters for compliance and abuse response. Private RFC 1918 ranges skip this chain entirely: any organization can reuse them internally without registry involvement, which is exactly why they need a locally documented plan instead of a global one.

11.3 Practitioner: Plan Subnets Around Device Groups and Traffic Rules

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.

Pause at Figure 11.3 before carrying practitioner: plan subnets around device groups and traffic rules forward. Its visual vocabulary joins IPv4 Subnet Mask to Bits with value, which frames the subnet mask determines whether two ipv4 addresses are local peers or require a gateway.

Trace the visual from IPv4 Subnet Mask to Bits with value in Figure 11.3; verify = Network portion (prefix) before concluding. Together those labels make the subnet mask determines whether two ipv4 addresses are local peers or require a gateway testable. Apply their boundary when working through practitioner: plan subnets around device groups and traffic rules.

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.

11.4 Under the Hood: Packets Carry Addresses, Routers Use Prefixes

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.

To test under the hood: packets carry addresses, routers use prefixes, open the diagram in Figure 11.4. IPv4 Packet Header supplies one named condition; 20-byte minimum header — 32 bits per row supplies the necessary comparison for the ipv4 header carries source and destination addresses, ttl, protocol, length, fragmentation fields, and checksum information.

Compare IPv4 Packet Header with 20-byte minimum header — 32 bits per row inside the visual at Figure 11.4. Next find Byte 0, which completes the scope of the ipv4 header carries source and destination addresses, ttl, protocol, length, fragmentation fields, and checksum information. The decision in under the hood: packets carry addresses, routers use prefixes must preserve that labelled boundary.

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.