Encapsulation and de-encapsulation

In The OSI model and The TCP/IP model you learned that networking is split into layers. This lesson shows what that means for real data: each layer wraps the data in its own label before it leaves, and the receiver unwraps those labels in reverse. By the end you should be able to:

• Name the PDU at each layer: data, segment, packet, frame, bits.
• Say which addresses each header carries: ports, IP addresses, MAC addresses.
• Walk through encapsulation on the sender and de-encapsulation on the receiver.
• Explain exactly what a router changes when it forwards a packet, and what it leaves alone.

💡 In simple terms: think of Russian nesting dolls, or a letter in an envelope, inside a parcel, inside a delivery van. Each wrapper has its own label for its own job. The van driver only reads the van's route sheet; nobody along the way opens the letter.

What is encapsulation?

Encapsulation is the process of adding control information to data as it moves down the layers on the sending device. Each layer takes what the layer above gave it, treats it as its payload (the contents it carries), and puts a header in front of it. A header is a small block of fields, such as addresses and numbers, that the same layer on the other device will read. Ethernet also adds a trailer at the end.

De-encapsulation (also spelled decapsulation) is the reverse, on the receiving device: each layer reads its own header, acts on it, removes it and passes the rest up to the next layer.

Why encapsulation exists

Encapsulation is what makes the layered model work in practice. It solves several problems at once:

The PDU at each layer

A PDU (protocol data unit) is what a piece of data is called at a given layer. The name changes as headers are added:

💡 Memory trick for the PDUs from the top: Do Some People Fear Birthdays? Data, Segment, Packet, Frame, Bits.

Where encapsulation happens

Full encapsulation and de-encapsulation, through every layer, happen only on the two end hosts: the device that creates the data and the device it is for. Devices in the middle only unwrap as far as they need to:

The example network

Every diagram below follows the same request. PC-A opens the company intranet page at http://intranet.example. The web server is on a different subnet, so the traffic must pass through router R1. There is no NAT here, which keeps the example clear. (The example uses plain HTTP so you can see the request; with HTTPS the data would be encrypted by TLS, but the headers below it would look the same.)

Assume the TCP connection is already open (the three-way handshake is done) and that PC-A and R1 already know the MAC addresses they need from ARP.

Encapsulation on the sender, step by step

Read from the top. Each row is one layer on PC-A, and the strip shows the whole PDU at that point: the newest header is always on the outside (the left).

1. Application: the browser creates the HTTP request GET / HTTP/1.1 with Host: intranet.example. It hands this data to TCP through the operating system.
2. Transport: TCP puts a header in front with source port 51524 and destination port 80, plus sequence and acknowledgement numbers. Data + TCP header = a segment. If the data were too big, TCP would split it across several segments first.
3. Internet: IP adds a header with source 192.168.10.20 and destination 192.168.20.80. The Protocol field is set to 6 so the receiver knows TCP is inside, and the TTL (time to live) starts at 64. Segment + IP header = a packet.
4. Next-hop decision: PC-A compares the destination with its own subnet. 192.168.20.80 is not in 192.168.10.0/24, so the packet must go to the default gateway 192.168.10.1. ARP tells PC-A that the gateway's MAC is 02:00:00:00:00:01.
5. Network Access: Ethernet adds a header with destination MAC 02:00:00:00:00:01 (R1, not the server!), source MAC 02:00:00:00:00:aa and EtherType 0x0800 (IPv4), then a 4-byte FCS trailer. Packet + Ethernet header + FCS = a frame.
6. Physical: the NIC sends a preamble so the receiver can lock on, then the frame as electrical signals on the cable: bits.

Here is the finished frame, field by field:

The key idea: the IP header says where the packet is ultimately going (the server). The Ethernet header only says who should receive it on this link (R1). See ARP for local and remote destinations for why.

Watch the frame travel

Now follow the frame across the network. Pay attention to the router step: that is where the outer wrapper changes.

What changes at a router hop

This is one of the most important ideas in networking. When R1 receives the frame, it de-encapsulates up to the IP header, makes its routing decision, then encapsulates the same packet in a brand-new frame for the next link. Compare the two frames:

In the IPv4 header below, the highlighted fields are the ones a router rewrites on every hop. The source and destination addresses stay the same.

The NAT exception. A home router usually does NAT: it replaces the private source IP (and often the source port) with its own public address before the packet goes to the internet. That is an extra job on top of routing, not part of normal forwarding. See Why NAT exists and How NAT and PAT work.

If the path had five routers, this would happen five times: five different frames on five links, but one packet with the same IP addresses inside all of them. The full journey is in Different-subnet communication.

De-encapsulation on the receiver, step by step

The web server unwraps the frame from the outside in. Read from the top: the full frame arrives first, and one header disappears per row. Notice the MAC addresses are the ones R1 wrote, and the TTL is 63.

1. Bits to frame: the NIC turns the electrical signals back into bits and finds the start of the frame.
2. Check the frame: it recalculates the FCS. If it doesn't match, the frame was damaged and is dropped silently.
3. Is it for me? The destination MAC 02:00:00:00:00:bb is the server's own, so it keeps the frame. (Frames for other MACs are ignored, except broadcasts.)
4. Which protocol is inside? EtherType 0x0800 says IPv4, so the packet goes to IP.
5. IP: the destination IP 192.168.20.80 is the server's own address. Protocol 6 says pass the payload to TCP.
6. TCP: destination port 80 belongs to the web server program. TCP checks the sequence number, sends an acknowledgement and hands the data up.
7. Application: the web server reads GET / HTTP/1.1 and starts building its reply, which will be encapsulated the same way, in the other direction.

How each layer knows what's inside

A receiver never has to guess. Every header has a field that names the protocol in the next layer up. Using these to pass data to the right place is called demultiplexing:

On the sending side the opposite happens: many programs share one network card, and their data is mixed onto the same link. That is multiplexing. Ports are what keep the conversations apart; see Port numbers and sockets.

The cost of all those headers

Every header takes space that could have carried data. This is called overhead. On standard Ethernet, the largest packet a frame can carry is 1500 bytes: the MTU (maximum transmission unit). Here is how a full-size TCP segment fills it:

So about 1460 ÷ 1538 ≈ 95% of the bits on the wire are your data at best. Small packets are much less efficient: a minimum-size 64-byte frame carrying a bare TCP acknowledgement holds no user data at all, only headers and padding. If you add more headers, for example a VPN, the space left for data shrinks further; see VPN basics.

A real capture: seeing the headers

Packet capture tools such as Wireshark and tcpdump show every header. Here is the first segment of the connection (the TCP SYN) captured on both LANs. Compare the MAC addresses and the TTL.

$ sudo tcpdump -e -n -v -i eth0 tcp port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:15:02.114233 02:00:00:00:00:aa > 02:00:00:00:00:01, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 4821, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.20.51524 > 192.168.20.80.80: Flags [S], cksum 0x8c3e (correct), seq 2814375120, win 64240, options [mss 1460,sackOK,TS val 1593001 ecr 0,nop,wscale 7], length 0

$ sudo tcpdump -e -n -v -i eth0 tcp port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:15:02.114871 02:00:00:00:00:02 > 02:00:00:00:00:bb, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 63, id 4821, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.20.51524 > 192.168.20.80.80: Flags [S], cksum 0x8c3e (correct), seq 2814375120, win 64240, options [mss 1460,sackOK,TS val 1593001 ecr 0,nop,wscale 7], length 0

What happens when it goes wrong

Because every layer checks its own header, a problem is usually caught at one specific layer, and the PDU is dropped there:

The ICMP lesson covers those error messages, and Traceroute uses the TTL rule on purpose to map the routers on a path.

Troubleshooting with encapsulation in mind

Knowing which header holds which address tells you where to look:

• Frames damaged? Look at interface error counters (Layer 1 and 2).
• Wrong next hop? Check the ARP cache: does the gateway's IP map to the right MAC? (arp -a on Windows, ip neigh on Linux)
• Packets going the wrong way? Check IP settings and routes (ipconfig, ip route).
• Reaching the host but not the service? Check the port (Test-NetConnection -Port, ss -tln on the server).
• Still unsure? Capture packets on both sides and compare the headers, as above.

$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 02:00:00:00:00:aa brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      48213907   61822    214       0       0     312
    TX:  bytes packets errors dropped carrier collsns
       9921842   40217      0       0       0       0

Common mistakes

• Thinking the destination MAC is the final host's MAC. For a remote destination it is the default gateway's MAC. Only the IP header names the final host.
• Thinking routers change IP addresses. Normal routing keeps both IP addresses. Only NAT rewrites them.
• Thinking switches rebuild frames. A Layer 2 switch forwards the frame unchanged; only routers build new frames.
• Mixing up the PDU names. Segment = layer 4, packet = layer 3, frame = layer 2. A "frame" has MAC addresses; a "packet" has IP addresses.
• Forgetting the trailer. Ethernet is the only common layer that adds something at the end: the FCS.
• Thinking every layer adds a header in every packet. There is no separate session or presentation header. TLS, when used, adds its own record header as part of the application data.

Knowledge check

Where to go next

You have now finished the Network Models unit. Next, look closely at the outer wrapper in Ethernet fundamentals, The Ethernet frame and MAC addresses. The TCP header is covered field by field in The TCP header, and the complete hop-by-hop story, including ARP, is in Different-subnet communication.