Packets, routes, and the OSI seven-layer model

Follow the message without mixing the addresses

After name resolution, an application uses a destination address and transport port. The OS consults its route table. If the destination is outside the connected network, the next hop is typically a gateway. That gateway's link-layer address is different from the remote site's IP address.

On an Ethernet-like IPv4 link, ARP discovers the next hop's MAC address when needed. IPv6 uses Neighbor Discovery, which also supports router discovery. A populated neighbor cache avoids another discovery exchange. These mechanisms apply to the local link; they do not resolve the remote site's MAC across the internet. ARP↗, IPv6 Neighbor Discovery↗.

A simplified outbound path is:

Browser HTTP data
  -> encrypted transport data
  -> IP packets
  -> local-link frames
  -> Wi-Fi/Ethernet signals
  -> access network / gateway
  -> routed networks
  -> destination endpoint

This is encapsulation: one protocol carries another's data. At a routed hop, the incoming link framing ends and the next link gets appropriate new framing. Routers forward using IP routing information and decrement IPv4 TTL or IPv6 Hop Limit; reaching zero prevents indefinite loops. They are not normally decrypting HTTPS page content to decide the next hop. Internet host layering↗, IPv6 forwarding fields↗.

A NAT example, not LearnWithSK's actual route

The following addresses are a labeled teaching example. The public-looking ranges are reserved for documentation and must not be used as live targets.

The gateway tracks the translation. Ordinary routers do not all rewrite the source IP or source port. Not every connection uses NAT; a globally addressed IPv6 client is a common alternative. NAT and a firewall have different responsibilities, even when one device supplies both. Traditional NAT/NAPT↗, documentation addresses↗.

A reverse proxy terminates one connection and can open another toward an origin. This produces separate connection legs, not merely another router hop. Route symmetry is not guaranteed, and a trace of the outbound direction does not establish the reply route.

Work through the first hop

Imagine the laptop 192.168.50.20/24 needs to reach the documentation-only address 203.0.113.20. The destination is outside its local /24, so an applicable default route selects its local gateway, for example 192.168.50.1. The laptop needs the gateway's local-link address, not the remote site's MAC address.

The outgoing IP packet still names the remote destination, while the local frame is addressed to the next hop. At the router, that link frame ends. The router chooses another route and places the packet in the next link's framing, with the hop count reduced. A NAPT gateway may also translate the source address/port as in the preceding table. These are three distinct changes: new link framing, hop-count decrement, and translation only where configured.

Practice without sending traffic: sketch two boxes for laptop and router, then a third for the remote endpoint. Put the IP destination above all routed legs, and a separate link destination on each local leg. For the return direction, draw the translation-table lookup at the NAPT gateway. The exact return routers remain unknown in this example.

Question: does a router need the site's private TLS key to forward the packet? Normally no. IP forwarding uses network-layer information. A terminating reverse proxy is different: it is an endpoint for one protected connection and may open another.

Use the seven layers as questions

OSI is a reference model. The internet stack does not implement seven separate handshakes, processes, or header sets for every request. The assignments below explain responsibilities; TLS, QUIC, and application-session behavior do not map perfectly to one OSI box. ITU-T X.200↗.

For practical internet diagnosis, group upper-layer responsibilities into the application stack and use application → transport → internet → link as the broad TCP/IP view. DNS is an application protocol, even though a page request often depends on it early. HTTPS can fail at certificate validation after basic connectivity works. TCP/IP layering↗.

Responses and failure boundaries

A traceroute estimates responding hops with probes of increasing TTL/Hop Limit. Asterisks can mean filtering or lack of replies, not a proven broken link. Different protocols, load balancing, tunnels, and time can give a different path from the browser. It is evidence, not a full topology map.

Checkpoint

Draw an outbound packet and its reply. Label domain, destination IP, destination port, local next hop, and local-link address separately. Mark which values may change through NAT or a proxy. Name the smallest observation that distinguishes DNS, transport, TLS, and HTTP failures.

For a worked layer classification, compare “Wi-Fi disconnected,” “name not found,” “certificate hostname mismatch,” and “404.” The first points to the local link/physical context. Name lookup is an application-protocol dependency. Certificate checking happens after some connectivity has already worked. A 404 is a valid HTTP response about the requested resource. The useful question is which observation distinguishes the failure, not which single OSI number can be attached to every symptom.

Continue with the browser observation lab. Later Linux networking lessons revisit these concepts with local tools and a server you control.

Apply this to MicroBank

Choose one proposed MicroBank connection: API caller to Accounts. Label application protocol, transport, source/destination address, and the local link. Draw Accounts-to-database and publisher-to-messaging as separate connections. A packet does not travel through Accounts, the database, and Ledger as one uninterrupted HTTP request. Use the diagram to explain which connection a later timeout concerns.

Keep this observation in the MicroBank readiness project.