7 Datagrams and Packet Structure

7.2 Overview: Datagrams Make Packets Self-Contained

What has to travel with a reading so the network can move it without help? Figure 7.1 lays one packet out field by field.

+

Read Figure 7.1 from left to right. The first four fields are the header, and none of them is the message. Source and destination say which endpoints are talking, the sequence field lets a receiver put pieces back in order, and the flag bits carry control information. Only the last block holds the sensor reading itself. That split makes independent forwarding possible: a router can use fields in the packet header to choose the next hop without needing to inspect the payload. It is also why the payload can be encrypted end to end while the network still works, and why a header field alone can reveal which devices are talking.

The important design habit is to treat packet structure as a contract. Every byte spent on headers, options, security tags, or fragmentation is a byte that cannot be used for application data on the same frame.

That contract is also what lets engineers reason from a packet capture. A source address explains who claimed to send the packet, a destination address explains the intended next delivery target, a protocol or next-header field explains which parser should receive the payload, and length fields set the boundary between real payload and stray bytes. Routers normally need only the forwarding fields, while endpoints need the full chain of fields to hand the right bytes to UDP, TCP, CoAP, MQTT-SN, or custom device logic. When a datagram is malformed, duplicated, or larger than the path can carry cleanly, those same fields become the first evidence for debugging.

Delivery Models: What the Destination Address Asks For

The destination address does more than name a single recipient. It also declares a delivery model -- how many receivers the network should try to reach with this one packet. Most IoT traffic is unicast: one source, one destination, the default assumption behind a sensor reading, a command, or an acknowledgement. Three other models exist for the cases where more than one receiver matters.

IPv4 reserves specific destination address ranges to carry this out: 255.255.255.255 is the limited local broadcast address (RFC 919), and 224.0.0.0 through 239.255.255.255 is the multicast range (RFC 1112). A parser can read which delivery model a packet is asking for straight from the destination address, before it looks at anything else in the header.

7.3 Practitioner: Budget the Packet Before Release

When you design or debug an IoT datagram, start with the packet budget. The useful payload must fit inside the smallest link on the path after every lower layer has added its own headers and trailers.

A useful budget is written as a byte ledger, not as a vague warning about overhead. Start with the link limit, then subtract the link header and trailer, security material, adaptation headers, the network header, the transport header, and any application envelope. For example, IEEE 802.15.4 gives constrained stacks a small frame budget, while IPv6 has a 40-byte base header and UDP adds 8 bytes before application data. 6LoWPAN header compression can recover space, but only when addresses, prefixes, and flow fields match the compression rules. The release question is therefore concrete: what is the largest normal message that still fits after the real deployed stack has wrapped it?

Keep the boundary named when doing the arithmetic. On a path with a 1,500-byte IP MTU and no options or extension headers, a TCP segment can carry at most 1,460 bytes of application data over IPv4 (1,500 - 20 IPv4 - 20 TCP) or 1,440 bytes over IPv6 (1,500 - 40 IPv6 - 20 TCP). These are example MSS values, not guaranteed end-to-end values: tunnels and smaller path MTUs reduce them. IPv6 requires each link to support a 1,280-byte IPv6 packet, or to provide adaptation below IPv6; that minimum is not a promise that a 1,500-byte packet will cross the path.

Follow Figure 7.2 to see how a two-byte sensor value grows as each layer adds delivery information.

+

Start with the sensor firmware’s 23.5 °C value encoded as 0x41BC in 2 bytes. The application format gives those bytes meaning, then transport adds endpoint and integrity fields, the network layer adds addresses, and the link layer creates the frame used on the local medium. At the receiver, each layer removes and checks its own wrapper before delivering the original value. The figure explains why payload size alone cannot predict airtime, fragmentation, or energy. A packet budget must include every header, trailer, security field, acknowledgement, and retry used on the deployed path.

Read Figure 7.3 and notice that the payload block never changes; only the cost of carrying it does.

+

Every row in Figure 7.3 sends the same seventeen-byte reading, so the payload block is identical down the figure. What grows beside it is the framing. The top row carries the reading over a general-purpose stack and spends most of the packet on headers, leaving efficiency well under a quarter. Moving down, a leaner request-response stack recovers some of that, and the two rows built for low-power links recover much more, because their framing was designed for small messages. Read the closing rule with that in mind. The largest saving is not switching stacks at all. It is sending fewer packets, because each one pays its framing cost whether the reading changed or not.

7.4 Under the Hood: Parsers Trust Fields Only After Checks

Under the hood, datagram handling is a parsing pipeline. Each layer reads the fields it owns, verifies enough structure to trust the next step, then passes the remaining payload upward or forwards the packet onward.

+

Fragmentation changes this pipeline. The receiver cannot deliver the original network-layer payload until all required fragments arrive and pass reassembly checks. That is why constrained IoT protocols often prefer smaller application chunks over one large datagram.

Robust parsers treat every length, flag, and next-header value as untrusted input until it has been checked against the bytes actually present. A declared length that exceeds the captured frame, a header chain that points past the payload, or a fragment offset that overlaps an earlier fragment should be rejected before the application sees the data. Diagnostics also depend on where the packet was captured. A checksum failure near the radio points toward corruption or framing trouble; a checksum warning on a host capture can be a hardware-offload artifact; a clean packet at the gateway but not at the service points toward forwarding, NAT, firewall, or application demultiplexing behavior.