Encapsulation and protocol data units

In Module 1, you learned that each layer has a specific job. Encapsulation is the process that makes those layers work together. As your data moves down the stack, each layer wraps the data from the layer above with its own header. On the receiving end, each layer strips its header and passes the remaining data up.

Think of it like posting a letter. You write a message (the application data). You put it in an envelope with the recipient's address (transport layer, adding port numbers). That envelope goes into a shipping package with a postal address (network layer, adding IP addresses). The package goes onto a delivery truck with a local route number (data link layer, adding MAC addresses).

Where the analogy breaks down: in networking, each layer adds its header to the front of the data, not around it. The result is a stack of headers at the beginning of every piece of data sent across a network. Each header carries the information that layer needs to do its job.

Here is what a typical HTTPS request looks like in terms of raw bytes:

Ethernet header (14 bytes) contains the source and destination MAC addresses plus an EtherType field (0x0800 for IPv4, 0x86DD for IPv6) that tells the receiver what protocol comes next.

IP header (20 bytes for IPv4, 40 bytes for IPv6) contains the source and destination IP addresses, a TTL (Time to Live) counter that prevents packets from looping forever, and a protocol field that identifies what comes next (6 for TCP, 17 for UDP).

TCP header (20 bytes minimum) contains source and destination port numbers, sequence and acknowledgement numbers for reliable delivery, and control flags like SYN, ACK, and FIN.

Application data (variable) is your actual HTTP request, email, or file content.

Ethernet trailer (4 bytes) contains a Frame Check Sequence (FCS), a CRC-32 checksum that detects transmission errors.

Total overhead for one TCP packet on Ethernet: at least 58 bytes of headers and trailers before a single byte of your actual data.

Each layer's combination of header + payload has a specific name. These names are called Protocol Data Units (PDUs). Using the right name tells other engineers exactly which layer you are talking about.

Layers 7-5: Data. At the application, presentation, and session layers, the content is simply called data. An HTTP request body, a JSON payload, an email message.

Layer 4: Segment (TCP) or Datagram (UDP). When TCP wraps the data with port numbers and sequence tracking, the result is a segment (RFC 9293, Section 3.1). When UDP wraps it with just ports and a length field, the result is a datagram (RFC 768).

Layer 3: Packet. When IP wraps the segment or datagram with source and destination IP addresses, the result is a packet. IPv4 packets are defined in RFC 791, Section 3. IPv6 packets are defined in RFC 8200, Section 3.

Layer 2: Frame. When Ethernet wraps the packet with MAC addresses and a checksum (FCS), the result is a frame. An Ethernet frame has a minimum size of 64 bytes and a maximum of 1,518 bytes (or 9,018 with jumbo frames).

Layer 1: Bits. At the physical layer, the frame becomes a stream of ones and zeros, encoded as electrical voltages, light pulses, or radio signals.

The diagram below shows a complete encapsulated HTTPS request. Notice how each layer wraps the layer above it, and the Ethernet trailer sits at the end. The entire structure is what actually travels across the wire.

Try the tool below to build your own PDU stack. Select a scenario (loading a web page or resolving a domain name) and watch how the layers differ depending on which transport protocol is used.

When a packet arrives at a router, something important happens to the encapsulation. The router strips the incoming Ethernet frame completely. It reads the IP header to decide where to send the packet next. Then it builds a brand new Ethernet frame around the packet, with new source and destination MAC addresses for the next network segment.

The IP header stays almost unchanged. Only the TTL counter decreases by one (so packets cannot loop forever) and the header checksum is recalculated. The TCP segment inside is never touched by the router at all.

This is the fundamental difference between Layer 2 and Layer 3:

Layer 2 (MAC addresses) changes at every hop. Your laptop's MAC address is only visible to the first router. After that, each router substitutes its own MAC address as the source and the next-hop router's MAC as the destination.

Layer 3 (IP addresses) stays the same end-to-end. The source IP (your laptop) and destination IP (the web server) remain unchanged from the moment the packet leaves your machine to the moment it arrives at the server, no matter how many routers it crosses.

This is why ARP (Address Resolution Protocol) exists. When a router needs to send a packet to the next hop, it already knows the next-hop's IP address from its routing table. But to build the new Ethernet frame, it needs the next-hop's MAC address. ARP asks: "Who has IP address 10.0.0.1? Tell me your MAC address."

Every network link has an MTU (Maximum Transmission Unit), the largest frame it can carry. Standard Ethernet has an MTU of 1,500 bytes. Jumbo frames push that to 9,000 bytes. If a packet is too large for a link's MTU, something has to give.

IPv4 handles this by fragmenting the packet: splitting it into smaller pieces that each fit within the MTU, and reassembling them at the destination. IPv6 took a different approach. RFC 8200 says that routers must never fragment packets. If a packet is too big, the router drops it and sends an ICMPv6 "Packet Too Big" message back to the sender. The sender is then responsible for sending smaller packets.

This mechanism is called Path MTU Discovery (PMTUD). The sender starts with the largest packet its local link supports and waits for "Packet Too Big" messages from routers along the path. It then reduces its packet size to fit.

PMTUD breaks when firewalls block ICMP messages. If the "Packet Too Big" message never reaches the sender, the sender keeps sending oversized packets, and they keep getting dropped. From the user's perspective, small requests work but large downloads hang forever. This is called a PMTUD black hole, and it is exactly what happened at Hudl.

Tunnels and VPNs make MTU problems worse. Each tunnelling protocol adds its own headers, reducing the space available for actual data:

GRE (Generic Routing Encapsulation) adds 24 bytes of overhead.
IPsec ESP (Encapsulating Security Payload) adds 50 to 73 bytes.
VXLAN (Virtual Extensible LAN) adds 50 bytes.

On a standard 1,500-byte Ethernet link with IPsec, the effective MTU for your actual data drops to around 1,427 to 1,450 bytes. If applications assume a full 1,500 bytes are available, packets get fragmented or dropped.