A packet’s journey

A fictional laptop connected by Ethernet asks a remote library for opening hours. The request feels like one message flying directly to a server. In reality, communication crosses local links, with routers making successive forwarding decisions. Our example follows Ethernet data frames carrying IP packets after each next hop’s MAC address has already been resolved. The useful question is not just “where is it going?” but “who receives this particular next step?”

One message, several envelopes

An application creates data with meaning, such as an HTTP request. Transport protocols organize communication between endpoints. IP carries packets across networks. A link layer, such as Ethernet or Wi-Fi, carries the next local delivery. These layers have different headers and responsibilities.

An envelope-inside-an-envelope drawing is helpful, but one application message need not equal one packet. A transport may divide a stream, combine writes, or retransmit data. Encryption can also make the application content unreadable to forwarding devices. A router can often forward using IP information without understanding the book title in the request.

First decide whether the destination is local

The laptop’s routing information selects a next hop and outgoing interface. In a simple network, a destination on the attached subnet can be reached directly; a remote destination uses a gateway. Real routing can include more specific routes and multiple interfaces, so “everything goes to the default gateway” is too broad.

For an Ethernet IPv4 next hop, ARP can resolve the neighbor’s IPv4 address to a local link address. An ARP request can use a broadcast frame before that mapping is known. IPv6 uses Neighbor Discovery, with different messages and rules. Our laptop already has its chosen gateway’s MAC address when it sends the IP-carrying data frame. Wi-Fi has additional address roles; this drawing specifically follows Ethernet delivery.

PredictIn our Ethernet example, the laptop already knows the gateway’s MAC address. The outgoing data frame names that gateway as its destination, while its enclosed IP packet names the remote library. Is this a contradiction?

No. The IP destination describes where the packet is headed. The link destination identifies who should receive it on the current link. The gateway receives the frame and can forward the enclosed packet onward.

Each router makes another decision

An ordinary IP router removes the incoming link framing, consults routing information, and prepares delivery on an outgoing link. Across routed Ethernet links, the frame addresses therefore change. Without translation or tunneling, the packet’s original source and destination IP addresses normally remain the same; some other header fields change. IPv6 Hop Limit decreases at each forwarding router, preventing endless circulation through a routing loop.

The return message also needs routing and policy that allow delivery. Its route need not be an exact mirror of the outgoing route. Common stateful NAT deployments maintain mapping state; stateless translation also exists. Translation is an additional mechanism rather than a definition of routing.

Explain delays without guessing blame

A slow page can involve queues, retransmission, name resolution, or application work. Wireless paths can also involve radio contention. A single arrow on a diagram hides these possibilities. Split the journey into links and decisions, and state which parts are known. You now have a way to explain a network symptom without treating every delay as a security failure.