Encapsulation

How data gets wrapped at each layer for transmission

What Is Encapsulation?

Encapsulation is the process by which each layer of the networking stack wraps the data from the layer above with its own header (and sometimes a trailer). Each layer treats the entire output of the layer above as an opaque payload — it doesn't inspect or modify it, just wraps it.

Encapsulation — Layer by Layer

Here's what happens when an HTTP GET request is encapsulated for transmission:

Full Packet Walkthrough — HTTP Request from App to Wire

Let's trace exactly what happens when your browser sends GET /api/health HTTP/1.1 to 10.0.1.50:8080.

1. Application Layer — HTTP
   The browser constructs an HTTP request:

   GET /api/health HTTP/1.1
   Host: 10.0.1.50:8080
   Accept: application/json
   Connection: keep-alive

   This is just a text payload — approximately 120 bytes of ASCII. The application hands it to the OS via the socket API: send(sockfd, data, len, 0).
2. Transport Layer — TCP
   The kernel's TCP stack prepends a 20-byte TCP header containing:

   • Source port: 49152 (ephemeral port assigned by the OS)
   • Destination port: 8080
   • Sequence number: tracks byte position in the stream
   • Acknowledgment number: confirms received data
   • Flags: PSH, ACK (push data to application, acknowledge previous segment)
   • Window size: how much more data the sender can accept
   • Checksum: covers the header + data + a pseudo-header from IP

   The result is a TCP segment: [TCP Header (20B) | HTTP Data (~120B)] = ~140 bytes.
3. Internet Layer — IPv4
   The kernel's IP stack prepends a 20-byte IPv4 header containing:

   • Source IP: 10.0.1.10 (our host)
   • Destination IP: 10.0.1.50 (the server)
   • TTL: 64 (decremented by each router; packet dies at 0)
   • Protocol: 6 (indicates the payload is TCP)
   • Total Length: 160 bytes (20B IP + 20B TCP + ~120B data)
   • Header checksum: covers only the IP header itself

   The result is an IP packet: [IP Header (20B) | TCP Segment (140B)] = ~160 bytes.
4. Link Layer — Ethernet
   The NIC driver prepends a 14-byte Ethernet header and appends a 4-byte FCS trailer:

   • Destination MAC: aa:bb:cc:dd:ee:ff (next hop — gateway or destination NIC)
   • Source MAC: 11:22:33:44:55:66 (our NIC)
   • EtherType: 0x0800 (indicates the payload is IPv4)
   • FCS: CRC-32 checksum over the entire frame for error detection

   The result is an Ethernet frame: [Eth Header (14B) | IP Packet (160B) | FCS (4B)] = 178 bytes.
5. Physical Layer
   The NIC prepends an 8-byte preamble (7 bytes of 10101010 + 1 byte SFD 10101011) for clock synchronization, transmits the frame as electrical signals, and appends a 12-byte inter-frame gap (silence between frames).
   
   Total on the wire: 8 + 178 + 12 = 198 bytes to send ~120 bytes of HTTP text.

Ethernet Frame Anatomy

Here is the complete structure of an Ethernet II frame carrying an IPv4/TCP payload:

Ethernet Header (14 bytes)

IPv4 Header (20 bytes, no options)

TCP Header (20 bytes, no options)

Payload + Trailer

Critical Header Fields Explained

ARP — The Bridge Between L2 and L3

ARP Request / Reply Flow

Host A (10.0.1.10, MAC AA:AA:AA:AA:AA:AA) wants to send data to Host B (10.0.1.50):

1. Host A checks its ARP cache: Does it already have a MAC for 10.0.1.50?

   ip neigh show 10.0.1.50
   # If empty or STALE, ARP request is needed

2. Host A sends an ARP Request as an Ethernet broadcast (dst MAC: FF:FF:FF:FF:FF:FF). The ARP payload says: "Who has IP 10.0.1.50? Please tell 10.0.1.10 (MAC AA:AA:AA:AA:AA:AA)."
3. Every host on the segment receives the broadcast. Only Host B (which owns 10.0.1.50) responds. All others silently discard it.
4. Host B sends an ARP Reply as a unicast back to Host A's MAC. The reply says: "10.0.1.50 is at MAC BB:BB:BB:BB:BB:BB."
5. Host A caches the mapping (10.0.1.50 → BB:BB:BB:BB:BB:BB) and can now construct the Ethernet frame.

   ip neigh show 10.0.1.50
   10.0.1.50 dev eth0 lladdr bb:bb:bb:bb:bb:bb REACHABLE

ARP Packet Structure

ARP Security Concerns

De-encapsulation on the Receiving Side

When Host B receives the Ethernet frame, the process reverses — headers are stripped as the data moves up the stack:

1. NIC receives bits

   Physical signals → frame

2. Ethernet processing

   Check dst MAC, verify FCS, strip Ethernet header. EtherType 0x0800 → pass to IP.

3. IP processing

   Check dst IP, decrement TTL, verify checksum, strip IP header. Protocol 6 → pass to TCP.

4. TCP processing

   Check dst port, manage sequence/ACK, strip TCP header. Port 8080 → pass to application.

5. Application receives

   HTTP server reads "GET /api/health"

What Happens at a Router (L3 Hop)

When a packet crosses a router to reach a different subnet, the Ethernet header is stripped and replaced while the IP packet remains intact:

1. Router receives frame on ingress interface. Ethernet header says dst MAC = router's MAC. It strips the Ethernet header and reads the IP packet.
2. Router performs a routing table lookup on the destination IP to determine the next hop and egress interface.
3. Router decrements TTL by 1 and recalculates the IP header checksum. If TTL reaches 0, the packet is dropped and an ICMP Time Exceeded message is sent back.
4. Router constructs a new Ethernet frame on the egress interface with the next hop's MAC address as the destination MAC (found via ARP on that segment) and the router's egress interface MAC as the source.
5. The IP packet inside is unchanged (except TTL and checksum). Source IP and destination IP remain the original sender and final receiver. Only the L2 addressing changes at each hop.

Seeing Encapsulation with tcpdump

You can observe encapsulation directly with packet capture tools:

# Capture packets on eth0, show link-layer headers (-e), verbose (-v)
tcpdump -i eth0 -e -v -n host 10.0.1.50 and port 8080

# Output shows all layers:
12:34:56.789 AA:AA:AA:AA:AA:AA > BB:BB:BB:BB:BB:BB, ethertype IPv4 (0x0800), length 178:
    10.0.1.10.49152 > 10.0.1.50.8080: Flags [P.], seq 1:121, ack 1, win 502,
    length 120: HTTP: GET /api/health HTTP/1.1

In one line, tcpdump shows you:

# Even more detail with -xx (hex dump of entire frame)
tcpdump -i eth0 -xx -n host 10.0.1.50 and port 8080

# Or use Wireshark for a GUI with per-layer dissection:
tshark -i eth0 -V host 10.0.1.50 and port 8080

# Find the pod's PID
PID=$(crictl inspect --output go-template --template '{{.info.pid}}' $(crictl ps --name mycontainer -q))
# Enter its network namespace and capture
nsenter -t $PID -n tcpdump -i eth0 -e -n -v