Encapsulation: How Data Travels Through Network Layers

If encapsulation is the process of wrapping data in layers of protocol headers for transmission, decapsulation is its mirror image—the systematic unwrapping of those layers to recover the original application data at the destination.

But decapsulation isn't simply running encapsulation in reverse. It involves:

• Validation — Verifying checksums, checking addresses, confirming protocol conformance
• Decision-making — Determining whether data is for this device or needs forwarding
• Error handling — Deciding what to do with corrupted, misdirected, or malformed data
• Demultiplexing — Delivering data to the correct process among many running applications

Every network device performs some level of decapsulation. Switches decapsulate to Layer 2. Routers decapsulate to Layer 3. End hosts decapsulate completely to deliver application data. Understanding this process is essential for troubleshooting connectivity issues and understanding network performance.

Decapsulation is the process of removing protocol headers (and trailers) layer by layer as data ascends the protocol stack at the receiving end. Each layer:

1. Receives a PDU from the layer below
2. Validates the header information (checksums, addresses, format)
3. Processes the header (updates state, makes decisions)
4. Strips the header (and trailer if present)
5. Delivers the payload (SDU) to the layer above

The Symmetry Principle:

Decapsulation perfectly mirrors encapsulation:

• What the sender's Layer 4 prepends, the receiver's Layer 4 removes
• What the sender's Layer 3 prepends, the receiver's Layer 3 removes
• And so on through all layers

This symmetry ensures that the receiver's application sees exactly what the sender's application transmitted—transformed but semantically identical.

Peer Layer Communication:

Conceptually, peer layers communicate directly:

• Sender's TCP talks to receiver's TCP
• Sender's IP talks to receiver's IP
• Sender's Ethernet talks to receiver's Ethernet

Each layer trusts that its header will be read and understood by the corresponding layer at the destination. The intervening layers transport the header opaquely, without interpretation.

Real vs. Conceptual Data Flow:

Conceptual: Application → Application (with transport reliability) Real: Application → Transport → Network → Link → Physical → [Medium] → Physical → Link → Network → Transport → Application

The conceptual view (peer-to-peer) is useful for protocol design. The real view (through all layers) is essential for debugging.

Let's trace the complete decapsulation process when a web server response arrives at your computer.

Physical Layer Reception:

The NIC's physical layer circuitry:

1. Detects signal on the medium (electrical voltage, light, radio)
2. Recovers clock timing from preamble
3. Samples signal at each bit period
4. Decodes symbols into bits (reverse of line coding)
5. Assembles bits into a byte stream
6. Passes raw bytes to data link layer

At this stage, there's no understanding of addressing or structure—just raw bits.

Data Link Layer (Ethernet):

Network Layer (IP):

Transport Layer (TCP):

A running computer might have dozens of network connections simultaneously: a web browser with multiple tabs, email client, Spotify, system updates, and more. Demultiplexing is the process of delivering incoming data to the correct application socket.

The Demultiplexing Challenge:

All incoming packets arrive at the same network interface. How does the OS know which application should receive each one?

The Solution: Multi-Level Addressing

Each layer contributes to demultiplexing:

1. Ethernet EtherType → Which network protocol? (IP, ARP, IPv6)
2. IP Protocol Field → Which transport? (TCP, UDP, ICMP)
3. TCP/UDP Destination Port → Which application socket?
4. For TCP: Connection Tuple → Which specific connection?

TCP Connection Demultiplexing:

TCP sockets are identified by a 5-tuple:

1. Source IP address
2. Source port
3. Destination IP address
4. Destination port
5. Protocol (TCP)

Incoming segments are matched against this tuple:

• A server on port 443 can have thousands of concurrent connections
• Each connection is distinguished by the client's IP and port
• The OS maintains a hash table mapping tuples to sockets

UDP Demultiplexing:

UDP sockets are typically identified by a 2-tuple:

1. Destination IP address
2. Destination port

UDP is connectionless, so there's no "connection" to demux—just deliver to the matching socket.

Listening Sockets:

• A listening socket (e.g., TCP LISTEN on port 80) accepts new connections
• When SYN arrives for port 80, the listener creates a connected socket with the full 5-tuple
• Subsequent packets go to the connected socket, not the listener

Port Numbers:

• Well-known ports (0-1023): Assigned to standard services (HTTP=80, HTTPS=443, SSH=22)
• Registered ports (1024-49151): For specific applications
• Ephemeral ports (49152-65535): Dynamically assigned for client connections

End hosts perform complete decapsulation. Intermediate devices perform partial decapsulation—just enough to make forwarding decisions, then re-encapsulate for the next hop.

Layer 2 Switch:

A switch decapsulates only to Layer 2:

1. Receive electrical signals → decode to bits
2. Parse Ethernet frame header
3. Read destination MAC address
4. Look up MAC in forwarding table
5. Forward frame out appropriate port

The switch does not examine the IP header, TCP header, or payload. The frame (including all inner headers) is forwarded intact.

Layer 3 Router:

A router decapsulates to Layer 3:

Key Observation: New Frame, Same Packet:

The router creates a completely new Layer 2 frame:

• New source MAC (router's outgoing interface)
• New destination MAC (next-hop device)
• New FCS (recomputed over modified frame)

But the IP packet is essentially unchanged (only TTL and checksum differ). Inner layers (TCP, application data) are untouched.

Layer 4 Devices (Firewalls, NAT):

Some devices examine transport layer:

Firewalls:

• Decapsulate to L4 to read ports and flags
• Maintain connection state tables
• Apply rules based on {src IP, dst IP, src port, dst port, protocol}

NAT devices:

• Decapsulate to L4 to read/modify ports
• Modify IP addresses and port numbers
• Recalculate IP and TCP/UDP checksums
• Track connection state for return traffic

Errors can occur at any stage of decapsulation. Each layer handles errors according to its protocol design.

Layer 2 Errors (Ethernet):

FCS Mismatch: The frame is corrupted.

• Action: Silent discard — The frame is dropped with no notification
• Rationale: Layer 2 is unreliable by design; higher layers provide recovery
• Observable: Switch port statistics show "frame errors" or "CRC errors"

Destination MAC Not Matched:

• Action: Discard (unless in promiscuous mode)
• For broadcast/multicast: Accept if subscribed

Layer 3 Errors (IP):

Header Checksum Invalid:

• Action: Silent discard — Corrupted header
• No ICMP generated (can't trust the addresses!)

TTL Expired (reaches 0):

• Action: Discard and send ICMP "Time Exceeded"
• This is how traceroute works—TTL engineered to expire at each hop

Destination Unreachable:

• No route to host: ICMP "Destination Unreachable (Network Unreachable)"
• Host not responding: ICMP "Destination Unreachable (Host Unreachable)"

Fragmentation Needed but DF Set:

• Action: Discard and send ICMP "Fragmentation Needed"
• Used for Path MTU Discovery

Layer 4 Errors (TCP):

Checksum Invalid:

• Action: Silent discard — Segment corrupted
• Recovery: Sender's retransmission timer will trigger resend

No Matching Socket:

• Action: Send TCP RST (reset) to sender
• Indicates that no process is listening

Sequence Number Out of Window:

• Action: Discard and send ACK with correct window
• Protects against obsolete or malicious segments

The End-to-End Argument:

Lower layers' error handling is best-effort. Only end hosts can truly verify successful delivery because:

• Checksums might miss some errors
• Errors can occur after intermediate verification
• Only applications know if data is semantically correct

This is why TCP provides end-to-end checksums even though Ethernet also has FCS.

When a large IP packet is fragmented during transit, the receiving host must reassemble the fragments before delivering to the transport layer. This is a complex aspect of decapsulation.

How Fragments Are Identified:

IP header fields for fragmentation:

• Identification (16 bits): Unique ID for the original datagram
• Flags (3 bits): DF (Don't Fragment), MF (More Fragments)
• Fragment Offset (13 bits): Position in original datagram (units of 8 bytes)

Fragments of the same datagram share the same Identification + Source IP + Destination IP + Protocol.

The Reassembly Process:

Reassembly Challenges:

Out-of-Order Arrival:

• Fragments may arrive out of order via different paths
• Must buffer and wait for all pieces

Missing Fragments:

• If one fragment is lost, entire datagram is lost
• No way to request retransmission at IP layer
• TCP will eventually timeout and retransmit entire segment

Overlapping Fragments:

• Malicious or buggy senders might send overlapping offsets
• Creates security vulnerabilities (Teardrop attack)
• Modern implementations carefully validate offset/length

Resource Exhaustion:

• Attacker can send many first-fragments without completing
• Consumes reassembly buffers
• Mitigated by timeouts and resource limits

Example Fragmentation:

Original packet: 4000 bytes (3980 payload + 20 IP header) Link MTU: 1500 bytes

Fragment 1: IP header (20) + 1480 data, Offset=0, MF=1 Fragment 2: IP header (20) + 1480 data, Offset=185 (185×8=1480), MF=1
Fragment 3: IP header (20) + 1020 data, Offset=370 (370×8=2960), MF=0

Total transmitted: 60 + 1480 + 1500 + 1040 = 4080 bytes (vs. 4020 original) Overhead: 60 extra bytes of IP headers for fragmentation.

Decapsulation happens for every single packet received—potentially millions per second on high-speed interfaces. Performance optimization is critical.

Hardware Offloading:

Modern NICs offload decapsulation tasks:

• Checksum Verification: NIC verifies Ethernet FCS, IP checksum, TCP/UDP checksum before delivering to CPU
• Header Parsing: NIC identifies protocol layers and provides metadata to OS
• Large Receive Offload (LRO): NIC combines multiple segments into larger units
• Receive Side Scaling (RSS): NIC distributes packets across multiple CPU queues

Software Optimization:

Operating system network stacks optimize decapsulation:

The Interrupt Problem:

Packet arrival triggers hardware interrupts. At high rates:

• Interrupt overhead dominates CPU usage
• Context switching becomes bottleneck
• "Interrupt livelock" — System spends all time handling interrupts, no time processing

Solution: NAPI (New API) in Linux:

1. First packet triggers interrupt
2. Interrupt handler schedules polling
3. Subsequent packets are polled without interrupts
4. When queue empties, re-enable interrupts

Kernel Bypass Approaches:

For extreme performance (10-100 Gbps), some applications bypass the kernel:

• DPDK (Data Plane Development Kit): User-space polls NIC directly
• XDP (eXpress Data Path): eBPF programs run in NIC driver context
• io_uring: Async I/O reduces system call overhead

These techniques eliminate per-packet system call and context switch overhead.

Decapsulation is the essential complement to encapsulation—the process that extracts application data from the layered protocol headers added during transmission. Let's consolidate the key points:

What's Next:

With encapsulation and decapsulation understood, the final page brings it all together: end-to-end communication—the complete journey of data from one application to another, integrating all the concepts from this module.