2 How Packets Find a Next Hop
Next Hops, Forwarding Tables, Loop Limits, and IoT Mesh Evidence
routing basics, forwarding, routing table, default route, TTL, Hop Limit, RPL
2.1 Start With One Packet at a Fork
Imagine a sensor packet arriving at a node with more than one possible way forward. The node does not understand the whole application story; it has a destination, a table, a next hop, and a loop limit that keeps a bad path from lasting forever.
Routing basics are the rules behind that small fork in the road. Once you can explain why the node picks one next hop, why the table entry exists, and what evidence proves the packet moved, the larger RPL and IoT routing choices become easier to audit.
Overview: Routing Chooses the Next Hop
Routing is the network-layer decision that tells a packet where to go next. A router receives an IP packet, reads the destination address, searches a routing table, and sends the packet toward one selected next hop or directly connected destination.
The key idea is hop-by-hop decision making. A sensor does not need to know the entire path to a cloud service. It may know only a gateway. The gateway may know only the next router toward an uplink. Each hop repeats the lookup until the packet reaches the destination network or a router drops it because no usable route exists.
For example, a battery sensor may send every cloud-bound packet to the gateway because the gateway is its only default route. The gateway then chooses an ISP router as its next hop, while the ISP router chooses a cloud-side path from its own table. The packet keeps the same IP destination, but each router makes a local forwarding decision.
If you only need the intuition, this layer is enough: routing builds or maintains the path information, while forwarding uses that information for each packet. The router normally chooses the most specific matching route, protects against loops with TTL or Hop Limit, and falls back to a default route only when no better match exists.
Routing
Control-plane work that learns networks, chooses paths, reacts to change, and installs table entries.
Forwarding
Data-plane work that handles an individual packet by looking up the destination and transmitting toward the next hop.
Next Hop
The neighboring router or local destination selected for the packet's next step.
Default Route
The least-specific fallback entry, used when no more specific destination prefix matches.
Routing matters in IoT because many deployments combine gateway paths, local prefixes, mesh relays, constrained radios, sleeping nodes, and upstream services. A path can work for one packet and still be fragile if the next hop, return path, loop limit, and failure behavior are not reviewable.
Practitioner: Build the Routing Evidence Record
A routing evidence record should name the traffic scope, route source, selected next hop, packet proof, and changed condition that would reopen the decision. Keep it small enough to maintain and specific enough to diagnose a changed link, parent, route, or gateway rule.
Use longest-prefix match as the first lookup rule. A route for `10.42.18.0/24` is more specific than `10.42.0.0/16`, so it wins for a destination such as `10.42.18.33`. A default route such as `0.0.0.0/0` or `::/0` is useful for unknown destinations, but it is intentionally the least specific match.
Accept
The chosen route, next hop, return path, loop guard, and failure behavior match the traffic scope.
Constrain
Keep local prefixes local, route only cloud-bound traffic upstream, or limit a route to a named interface or gateway.
Retest
Reopen review when a prefix, default gateway, route metric, parent choice, border router, or sleep pattern changes.
Hold
Do not trust the design when next-hop choice, return path, loop behavior, or constrained-device fit is undocumented.
For a simple gateway, the record may be a short route table plus a packet trace to the local service and upstream service. For a mesh, the record also needs parent or neighbor state, because a packet may depend on intermediate constrained devices that sleep, move, or lose link quality.
Under the Hood: Forwarding, Loop Limits, and Why RPL Appears
At each hop, a router receives a link-layer frame, extracts the IP packet, decrements IPv4 TTL or IPv6 Hop Limit, applies a routing-table lookup, resolves the next-hop link-layer address when needed, and transmits a new frame on the outgoing interface. The IP destination normally stays the same across the path even though the link-layer envelope changes at every hop.
The under-the-hood rule is practical: forwarding is local, loop prevention is mandatory, and route freshness matters. If the packet cannot be matched to a usable route, or if the loop limit reaches zero, the packet is dropped rather than forwarded blindly.
Lookup
The router uses destination prefix, preference, and metric rules to identify the outgoing interface and next hop.
Loop Limit
TTL or Hop Limit is reduced at each router so packets cannot circulate indefinitely.
Neighbor Resolution
Local delivery may need ARP for IPv4 Ethernet or Neighbor Discovery for IPv6 links before the next frame can be sent.
No Route
If no matching route and no default route exist, the router drops the packet and may report the destination as unreachable.
Constrained IoT meshes add another layer of difficulty. Devices may run on batteries, sleep to save energy, have small routing tables, and communicate over lossy wireless links. A stable enterprise routing design may assume more memory, bandwidth, and neighbor stability than those devices can offer.
RPL, the IPv6 Routing Protocol for Low-Power and Lossy Networks, addresses that environment by organizing nodes around a destination-oriented directed acyclic graph rooted near a border router. Nodes choose parents according to an objective function and maintain enough state to forward traffic without requiring every constrained node to know a full network map.
The takeaway is not that every IoT network needs RPL. Star topologies, Ethernet gateways, and industrial networks may use other routing arrangements. The point is that low-power mesh routing needs evidence about parent choice, link quality, control-message budget, repair behavior, and return paths, not just a generic statement that routing exists.
2.2 Summary
Routing chooses where packets go next; forwarding applies that choice to each packet. A router reads the destination address, applies longest-prefix match, handles TTL or Hop Limit, and transmits toward a next hop, directly connected destination, or default route. If there is no usable route, the safe outcome is a drop rather than a guess.
In IoT systems, routing evidence has to include the traffic scope, next hop, route source, return path, loop guard, and failure behavior. Low-power meshes add constraints such as sleeping nodes, lossy links, limited memory, parent changes, and repair behavior, which is why RPL becomes a core concept later in this module.
2.3 Key Takeaway
Trust a routing design only when the next-hop decision, fallback route, loop limit, constrained-device fit, and retest trigger are visible for the traffic that matters.
2.4 See Also
Routing Tables
Read route entries, metrics, connected routes, static routes, and default-route behavior in more detail.
TTL and Loop Prevention
Trace how TTL and Hop Limit prevent packets from circulating forever.
Packet Switching
Connect forwarding decisions to packet-switched network behavior.
RPL Core Concepts
Continue from basic next-hop routing into low-power IPv6 mesh routing and DODAG construction.