IP Addressing

In this lesson:

• IP addresses as logical, routable (layer-3) addresses; IPv4 vs IPv6
• the subnet mask: splitting an address into network + host
• the same-subnet-vs-gateway decision (and ARP)
• DHCP (automatic addressing) and NAT (private↔public)
• why NAT means IoT devices dial out, and the addressing gotchas

Logical addresses that route

A MAC address delivers within one link; an IP address is the logical (layer-3) address that routes a packet across networks to any device on the internet. Two versions:

• IPv4, 32 bits, written as four decimals: 192.168.1.42. ~4 billion addresses (exhausted, hence NAT).
• IPv6, 128 bits, written in hex groups: 2001:db8::1. Effectively unlimited; designed to remove the need for NAT.

The subnet mask: network + host

An IP address has two parts: a network portion (which network it's on) and a host portion (which device on that network). The subnet mask says where the split is, the 1-bits are network, the 0-bits are host. CIDR notation writes the count of network bits:

 IP:    192.168.1.42      11000000.10101000.00000001.00101010
 Mask:  255.255.255.0     11111111.11111111.11111111.00000000   = /24
                          └────── network (24 bits) ──────┘└host┘
 Network: 192.168.1.0     Host range: .1 – .254   (.0 = network, .255 = broadcast)

A /24 gives 256 addresses, 254 usable hosts. The mask is how a device decides whether a destination is local (same network) or remote.

Same subnet, or via the gateway?

Before sending, a device checks: is the destination on my subnet? It ANDs both its own IP and the destination IP with the mask and compares the network parts:

// Is dst on the same subnet as me?
bool same_subnet(uint32_t my_ip, uint32_t dst_ip, uint32_t mask) {
    return (my_ip & mask) == (dst_ip & mask);   // same network bits?
}

• Same subnet → deliver directly on the local link. The device uses ARP (Address Resolution Protocol) to find the destination's MAC, then sends the frame straight to it.
• Different subnet → send to the default gateway (a router's IP). The device ARPs for the gateway's MAC and hands it the packet; the router forwards it onward.

flowchart TD
  A[Send to dst IP] --> B{dst & mask == my & mask?}
  B -- yes, same subnet --> C[ARP for dst MAC → send directly]
  B -- no, remote --> D[ARP for gateway MAC → send to router]

This is why a wrong subnet mask breaks things: get it wrong and the device either tries to ARP for a host that isn't local (no reply) or routes local traffic through the gateway unnecessarily.

Special and private addresses

DHCP: automatic addressing

Rather than configure every device by hand, DHCP (Dynamic Host Configuration Protocol) hands out addresses automatically. The handshake is DORA:

 Device → Discover  (broadcast: "any DHCP server?")
 Server → Offer     ("here's 192.168.1.42, mask, gateway, DNS")
 Device → Request   ("I'll take it")
 Server → Ack       ("it's yours, lease = N seconds")

The lease must be renewed. An embedded device either runs a DHCP client (convenient, plug-and-play) or uses a static IP (deterministic, no server dependency, common for fixed infrastructure). If DHCP fails, you typically see a 169.254.x.x link-local address, a tell-tale "no DHCP."

NAT: why IoT devices dial out

IPv4 addresses are scarce, so home/office networks use private addresses internally and NAT (Network Address Translation) on the router to share one public IP. The router rewrites the source address/port of outbound packets and remembers the mapping to return replies.

The consequence for IoT: a device behind NAT has no public address, so the cloud cannot initiate a connection to it. The device must connect outbound to a public server and keep that connection open. This is exactly why IoT architectures use a broker/cloud the device dials into (MQTT, next lessons) rather than the cloud reaching in, NAT traversal shapes the whole pattern.

 IoT device (192.168.1.42) ──outbound──▶ NAT router (1 public IP) ──▶ cloud broker
   the cloud can't reach IN; the device reaches OUT and stays connected

Gotchas

• Wrong subnet mask = broken reachability. A mask that misclassifies local vs remote means failed ARP or traffic wrongly sent to the gateway. Match the mask to the actual network.
• 169.254.x.x means DHCP failed. An IPv4 link-local address is the fallback when no DHCP server answered, check the DHCP server/cable, don't assume the device "has an IP."
• DHCP vs static conflicts / duplicate IPs. A static IP inside the DHCP pool can be handed to another device → duplicate-IP chaos. Reserve static addresses outside the pool, or use DHCP reservations.
• NAT blocks inbound. You can't directly reach a device behind NAT; it must initiate the connection (hence cloud brokers, hole-punching, or VPNs). Design IoT to connect out.
• Lease renewal & DNS. A DHCP device must renew its lease and usually needs the DNS server DHCP provided; forgetting either causes intermittent loss of connectivity or name resolution.

TL;DR

• An IP address is the logical, routable (layer-3) address; IPv4 is 32-bit (dotted decimal, scarce) and IPv6 is 128-bit (hex, abundant, no NAT needed).
• The subnet mask splits an address into network + host (CIDR /24 etc.); a device ANDs with the mask to decide same-subnet (deliver directly via ARP) vs remote (send to the default gateway).
• Know the special ranges: private (10/172.16/192.168), loopback (127.0.0.1), link-local 169.254.x.x (= DHCP failed on IPv4), broadcast.
• DHCP auto-assigns address/mask/gateway/DNS via DORA (with a lease to renew); the alternative is a static IP for deterministic infrastructure.
• NAT lets many private hosts share one public IP, so a device behind NAT can't be reached inbound and must dial out to a cloud/broker, which is why IoT uses MQTT-style outbound connections.