Network Encapsulation: Follow a Packet Across the Stack

Introduction

When an application sends data, network layers add the information needed for delivery; the receiver processes those layers in reverse. The application payload, transport segment, IP packet, and link frame are related, but they are not interchangeable names for the same unit.

This guide follows a request from browser to server, explains how headers and encapsulation fit together, and covers MTU and fragmentation. It also uses that path to diagnose cases where small requests work but larger transfers stall.

The Names and the Layers

Start with application data: bytes produced by HTTP and, for HTTPS, protected by TLS. In a common TCP-based connection, the transport layer groups some of those bytes into a TCP segment. With UDP, the transport unit is a UDP datagram. IP wraps that transport unit in an IP packet (often also called an IP datagram). The link layer then puts the IP packet in a frame for the local network, such as Ethernet or Wi-Fi.

People often use “packet” casually for any unit of network data. In a protocol discussion, be specific: TCP segment, UDP datagram, IP packet, or link frame. The distinctions matter when you inspect headers, calculate sizes, or troubleshoot a path.

What the headers tell each layer

• Application data: HTTP method, path, and headers are inside TLS ciphertext for HTTPS. The TCP/IP stack usually treats the application bytes as opaque.
• Transport header: TCP includes source and destination ports, sequence and acknowledgment information, flags, and other fields. UDP has a smaller header with ports, length, and checksum.
• IP header: Source and destination IP addresses plus fields used to forward and process the packet, including a hop limit (TTL in IPv4).
• Link header and trailer: A frame identifies the local sender and next-hop recipient and indicates what payload it carries. Ethernet also has a frame check sequence trailer for error detection; Wi-Fi has its own frame format and link-layer checks.

The names “header” and “trailer” describe where control information sits relative to the data at that layer. Not every protocol uses both.

One Request, From Browser to Server

Assume a browser opens an HTTPS connection over TCP to a server on another network. The operating system has already resolved the server name to an IP address and selected a route. If the destination is outside the local subnet, the next hop is usually the default gateway.

graph LR
    A[Browser HTTP bytes] --> B[TLS protected data]
    B --> C[TCP segment]
    C --> D[IP packet: client to server]
    D --> E[Ethernet frame: client to gateway]
    E --> F[Router removes incoming frame]
    F --> G[Route IP packet and build next frame]
    G --> H[Server NIC receives frame]
    H --> I[IP and TCP deliver bytes to socket]
    I --> J[Server TLS and HTTP]

1. The process hands data to the operating system

The browser writes to a socket. TLS encrypts the application data before the socket transport carries it. TCP divides the byte stream into segments sized according to connection state and the effective path constraints. Application write boundaries do not have to match segment boundaries: TCP exposes an ordered byte stream, not a message-per-segment service.

2. The host adds IP and local-link information

IP adds the client and server addresses. The routing table decides which interface and next hop to use. The client then resolves the next hop’s link-layer address, using ARP for IPv4 on Ethernet networks or Neighbor Discovery for IPv6. If the server is remote, the frame’s destination MAC address is the gateway’s MAC address, not the server’s.

The link layer wraps the IP packet in a frame and the network interface card (NIC) transmits it. Depending on the driver and hardware, checksum or segmentation offload may handle some work at the NIC. That can make a host-side packet capture look different from the exact frames on the wire.

3. The router forwards the IP packet

The router receives and validates the incoming frame, removes its link-layer envelope, and examines the IP destination. It decrements the packet’s TTL or Hop Limit, selects an outgoing route, and wraps the packet in a new frame for the next link. On IPv4, a router may fragment a packet when fragmentation is allowed and the outgoing MTU is smaller; if the Don’t Fragment flag is set, it must drop an oversized packet and normally send an ICMP message. IPv6 routers do not fragment packets in transit.

So the link-layer addresses change at each routed hop. The source and destination IP addresses usually remain the client and server addresses throughout the route, except when a device such as a NAT gateway rewrites them. Tunnels and proxies can add further layers or create separate connections, so the simple path model has limits.

4. The server removes the wrappers

The server NIC receives a frame addressed to the server’s local interface. The host processes its link header, passes the IP packet upward, and uses the transport header to find the receiving socket. TCP checks sequence information, reorders data if needed, and presents the byte stream to the TLS and HTTP layers. The application sees the request after TLS decrypts it.

The response follows the same basic process in reverse, with the server acting as sender. Each direction can use a different route, MTU, or NAT mapping.

MTU, Segments, and Fragmentation

The Maximum Transmission Unit (MTU) is the largest network-layer packet a link can carry in one frame, excluding the link-layer header and trailer. A common Ethernet MTU is 1500 bytes, but networks can use other values. Tunnels often reduce the usable MTU because encapsulation adds overhead.

TCP uses the Maximum Segment Size (MSS) to limit TCP data in a segment. MSS describes transport payload size, not the whole Ethernet frame. A typical MSS calculation starts with the path MTU and subtracts the IP and TCP headers; options and encapsulation can affect the actual size. For example, with a 1500-byte IPv4 MTU and base 20-byte IP and TCP headers, the nominal MSS is 1460 bytes.

If an IP packet is too large for a link, behavior depends on the protocol and flags:

• IPv4: A router can fragment a packet when permitted. If fragmentation is prohibited, the router drops it and should report the MTU issue with ICMP. The sender can then send smaller packets.
• IPv6: Routers do not fragment packets. The sender must learn the path MTU and adjust, or use IPv6 source fragmentation where appropriate.
• Path MTU Discovery (PMTUD): Hosts infer the usable packet size from the route, traditionally using ICMP feedback. If required ICMP messages are filtered, a connection may establish and then stall when larger packets are sent.
• TCP MSS clamping: Some gateways adjust advertised MSS values to avoid oversized TCP packets on constrained paths. It can work around a mismatch, but it can also hide the underlying MTU or filtering problem.

Fragmentation is not the same as TCP segmentation. TCP segmentation creates transport units at the sender. IP fragmentation splits an already formed IP packet to fit a link and the receiver reassembles it before transport processing. Avoid relying on fragmentation as a routine sizing strategy; loss of one fragment can prevent reassembly of the whole original packet.

Practical Diagnosis: Small Requests Work, Large Transfers Stall

Suppose an HTTPS health check succeeds, but downloading a larger response hangs. A blocked Path MTU Discovery message is one possibility, especially on a tunnel or VPN. It is not the only cause; check for proxy limits, firewall rules, loss, and server-side issues too.

Compare the route and interface MTUs first:

ip route get 203.0.113.20
ip link show

Then inspect the connection while reproducing the issue. Replace the interface, host, and port with values from your environment:

sudo tcpdump -ni eth0 'host 203.0.113.20 and (icmp or tcp port 443)'

Look for repeated TCP retransmissions, ICMP “fragmentation needed” feedback for IPv4, or ICMPv6 Packet Too Big messages. A capture taken on the sending host may show packets larger than the link MTU because segmentation offload combines data before the NIC divides it. Capture at a switch mirror port or the receiving side if you need to confirm on-wire frame sizes.

A useful check is to compare a working path with the failing one: direct internet versus VPN, or a small response versus a large transfer. If only the tunnel path fails, inspect tunnel overhead and whether the relevant ICMP messages can return to the sender. Change MTU or MSS only after the capture and route provide evidence for it.

Trade-Off Table

When to Use

Use the encapsulation model when reading packet captures, reviewing firewall rules, estimating overhead, or deciding where a network request might be dropped. It helps answer concrete questions: did the host send a frame to the gateway, did the router forward the IP packet, and did the server deliver transport data to the right socket?

When NOT to Use

Do not assume every network application follows the TCP example above. QUIC carries HTTP/3 over UDP, VPNs and other tunnels add outer headers, and proxies terminate one connection and create another. Identify the actual protocols and endpoints before interpreting a capture.

Production Failure Scenarios

MTU black hole

Symptom: A connection starts, but larger responses or uploads stall. Small requests continue to work.

Likely cause: A tunnel lowers the path MTU, while required ICMP feedback is dropped or not handled correctly.

Mitigation: Capture both directions, verify interface and tunnel MTUs, allow the relevant ICMP feedback, and confirm the sender reduces packet size. Apply MSS clamping only when the evidence supports it, then keep monitoring for the underlying path change.

Fragment loss or filtering

Symptom: Some UDP exchanges or large IPv4 packets fail while smaller traffic works.

Likely cause: A firewall, NAT device, or congested path drops fragments or lacks state for non-initial fragments.

Mitigation: Keep datagrams within the known path MTU when possible. Check firewall fragment handling and use PMTUD or application-level sizing instead of assuming fragments will pass.

Wrong next-hop resolution

Symptom: The host has an IP route, but frames are sent to an unexpected MAC address or traffic never reaches the gateway.

Likely cause: A stale or incorrect ARP/neighbor entry, VLAN mismatch, or duplicate address.

Mitigation: Inspect ip neigh, confirm the selected route and interface, and compare the resolved neighbor with the expected gateway. Avoid flushing neighbor tables as a first response on a busy host; gather evidence and scope the repair.

NAT or asymmetric-route confusion

Symptom: A capture on one side shows different addresses, or replies take a path that does not match the outbound trace.

Likely cause: NAT rewrites addresses, a load balancer or proxy terminates the connection, or routing differs by direction.

Mitigation: Capture on both sides of the translation point and correlate flows using ports, timestamps, and connection tracking. Confirm whether the device is routing, translating, tunneling, or proxying before comparing endpoint addresses.

Observability Checklist

• Record the source and destination IPs, ports, protocol, interface, and route used for a failing flow.
• Check link MTU, tunnel overhead, route changes, and neighbor resolution on the sending host.
• Capture ICMP and ICMPv6 alongside the relevant TCP or UDP flow.
• Look for TCP retransmissions, duplicate acknowledgments, resets, and stalled acknowledgments.
• Compare packet captures at the sender, gateway, and receiver when the packet appears to disappear.
• Account for checksum, segmentation, and receive offloads before treating host-side capture sizes as wire truth.
• Correlate NAT or proxy logs with captures on both sides of the device.
• Track interface drops, errors, and queue pressure alongside application latency and timeout rates.

Security and Compliance Notes

• Packet headers expose metadata such as IP addresses, ports, and packet sizes even when TLS protects application contents.
• Firewalls should enforce the intended policy at the appropriate layer; allowing arbitrary fragments or disabling ICMP wholesale can create both security and connectivity problems.
• ICMP is part of normal network operation. Filter it deliberately by type and direction rather than treating all ICMP as harmful.
• Validate captures before sharing them. Packet dumps can contain credentials, cookies, personal data, or other unencrypted application content.
• NAT changes addressing but does not provide a substitute for access control or application security.

Common Pitfalls / Anti-Patterns

• Calling every unit a “packet” and then confusing TCP segmentation with IP fragmentation.
• Assuming the server’s MAC address is used when the server is on another subnet; the first frame targets the gateway.
• Expecting link-layer MAC addresses to remain constant across routers.
• Treating the source and destination IP addresses as immutable when NAT, tunnels, or proxies may alter the observed path.
• Assuming MTU means total on-wire frame size; it usually describes the IP packet size supported by a link.
• Diagnosing from one packet capture without checking capture location, offloads, route symmetry, and device translation.

Quick Recap Checklist

• Application bytes may be protected by TLS before transport encapsulates them.
• TCP creates segments; UDP carries datagrams; IP carries them in packets; links carry those packets in frames.
• Headers identify the information each layer needs; some link technologies also add trailers.
• A router removes one link frame and creates another for the next hop.
• Link addresses change hop by hop; IP endpoints usually stay the same unless a device rewrites them.
• TCP MSS helps size TCP data, while PMTUD helps the sender account for the route MTU.
• Fragmentation and segmentation are different operations with different failure modes.
• Check captures at useful points along the path before changing MTU or firewall settings.

Interview Questions

Further Reading

• TCP, IP, and UDP: Understanding Internet Transport Protocols — compare the transport protocols and their delivery guarantees.
• OS Networking Stack — follow packets through Linux kernel networking and socket buffers.
• RFC 8200: Internet Protocol, Version 6 (IPv6) Specification — IPv6 packet handling, including router behavior and fragmentation.
• RFC 1191: Path MTU Discovery — the IPv4 Path MTU Discovery mechanism.

Conclusion

Encapsulation lets each networking layer handle a bounded part of delivery. A TCP segment or UDP datagram sits inside an IP packet, and a local-link frame carries that packet to the next hop. Routers replace the link frame as they forward, while IP endpoints usually remain stable unless NAT or another intermediary rewrites them.

When a transfer stalls, separate the questions: which layer created the unit, what size the path allows, and where the unit disappeared. That distinction makes packet captures and MTU troubleshooting much more useful.