Loading learning content...
Every byte that traverses a network is part of a carefully structured message. From the Ethernet preamble that synchronizes receivers to the TCP sequence number that enables reliable delivery, packet structure is the vocabulary of network communication. Understanding this structure at the field level is what separates network engineers from network users.
Packet analysis is the skill of reading raw bytes and understanding their meaning—identifying protocols, extracting addresses, diagnosing errors, and even detecting attacks. With tools like Wireshark, tcpdump, or a raw hex dump, a skilled analyst can reconstruct exactly what happened on a network, byte by byte.
This page provides an exhaustive guide to packet structure across all major protocols, from physical framing through application headers. By the end, you will be able to examine any network capture and confidently interpret its contents.
By the end of this page, you will understand: (1) Ethernet frame structure and MAC addressing, (2) IPv4 and IPv6 packet headers field-by-field, (3) TCP segment structure including options, (4) UDP datagram format, (5) Common application protocol headers, and (6) Practical packet analysis techniques.
The Ethernet frame (IEEE 802.3) is the fundamental unit of data transmission on wired LANs. Every IP packet, every TCP segment, every HTTP request travels encapsulated within Ethernet frames on local networks.
Complete Ethernet Frame Structure:
┌─────────────────────────────────────────────────────────────────────────────┐│ ETHERNET FRAME STRUCTURE │├─────────────────────────────────────────────────────────────────────────────┤│ Field │ Size │ Description │├─────────────────────┼───────────┼──────────────────────────────────────────┤│ Preamble │ 7 bytes │ Alternating 10101010... for clock sync ││ SFD (Start Frame │ 1 byte │ 10101011 - signals frame start ││ Delimiter) │ │ │├─────────────────────┼───────────┼──────────────────────────────────────────┤│ Destination MAC │ 6 bytes │ Recipient hardware address ││ Source MAC │ 6 bytes │ Sender hardware address ││ EtherType/Length │ 2 bytes │ Protocol (≥1536) or length (≤1500) │├─────────────────────┼───────────┼──────────────────────────────────────────┤│ Payload │ 46-1500 │ IP packet or other upper layer data ││ │ bytes │ (padded if < 46 bytes) │├─────────────────────┼───────────┼──────────────────────────────────────────┤│ FCS (Frame Check │ 4 bytes │ CRC-32 for error detection ││ Sequence) │ │ │└─────────────────────┴───────────┴──────────────────────────────────────────┘ TOTAL: 64-1518 bytes (without preamble/SFD typically counted in captures) 18 bytes overhead + 46-1500 bytes payload Note: 802.1Q VLAN tag adds 4 bytes between Source MAC and EtherType| EtherType (hex) | Protocol | Description |
|---|---|---|
| 0x0800 | IPv4 | Internet Protocol version 4 |
| 0x86DD | IPv6 | Internet Protocol version 6 |
| 0x0806 | ARP | Address Resolution Protocol |
| 0x8100 | 802.1Q | VLAN tagged frame |
| 0x8847 | MPLS | MPLS unicast |
| 0x88CC | LLDP | Link Layer Discovery Protocol |
| 0x8863/0x8864 | PPPoE | PPP over Ethernet (Discovery/Session) |
MAC Address Format:
MAC (Media Access Control) addresses are 48-bit identifiers:
AA:BB:CC:DD:EE:FF
└──┬──┘ └──┬──┘
OUI NIC-specific
Special MAC addresses:
FF:FF:FF:FF:FF:FF — Broadcast (all hosts on segment)01:00:5E:xx:xx:xx — IPv4 multicast33:33:xx:xx:xx:xx — IPv6 multicastStandard Ethernet limits payload to 1500 bytes (MTU). Jumbo frames extend this to 9000+ bytes for high-performance environments (storage networks, cluster interconnects). They reduce overhead and CPU interrupts but require end-to-end support—a single non-jumbo link will fragment traffic.
The IPv4 header is the workhorse of Internet routing. Despite its age (RFC 791, 1981), it remains the dominant network layer protocol. Understanding every field is essential for packet analysis.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Version| IHL |Type of Service| Total Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identification |Flags| Fragment Offset |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Time to Live | Protocol | Header Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Destination Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Options (if IHL > 5) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Minimum header size: 20 bytes (IHL = 5)Maximum header size: 60 bytes (IHL = 15)| Field | Bits | Description | Typical Values |
|---|---|---|---|
| Version | 4 | IP version number | 4 (for IPv4) |
| IHL (Header Length) | 4 | Header length in 32-bit words | 5 (no options) to 15 |
| Type of Service / DSCP+ECN | 8 | QoS marking (DSCP 6 bits, ECN 2 bits) | 0x00 (best effort), varies |
| Total Length | 16 | Entire packet size in bytes | 20-65535 |
| Identification | 16 | Fragment identification | Random/sequential |
| Flags | 3 | DF (Don't Fragment), MF (More Fragments) | 0x02 (DF set, typical) |
| Fragment Offset | 13 | Offset in 8-byte units | 0 (unfragmented) |
| Time to Live (TTL) | 8 | Hop limit | 64, 128, 255 common |
| Protocol | 8 | Upper layer protocol | 6 (TCP), 17 (UDP), 1 (ICMP) |
| Header Checksum | 16 | Header integrity check | Calculated per-hop |
| Source Address | 32 | Sender's IP address | 192.168.1.100, etc. |
| Destination Address | 32 | Recipient's IP address | 93.184.216.34, etc. |
Critical Fields in Detail:
TTL (Time to Live): Despite its name, TTL is a hop count, not time. Each router decrements TTL by 1. When TTL reaches 0, the packet is discarded and ICMP Time Exceeded is sent. This prevents routing loops. Traceroute works by sending packets with increasing TTLs.
Protocol Field: Identifies the encapsulated payload:
Fragmentation: When an IP packet exceeds a link's MTU, it may be fragmented. The Identification field groups fragments; Fragment Offset indicates position; MF (More Fragments) flag indicates if more follow. IPv6 eliminates router fragmentation—only the source may fragment.
IP fragmentation has security implications (fragment overlap attacks), performance costs (all fragments must arrive), and firewall complications (only first fragment has port numbers). Modern best practice uses Path MTU Discovery to avoid fragmentation entirely. The DF (Don't Fragment) bit is commonly set.
The IPv6 header was designed to address IPv4's limitations: address exhaustion, header complexity, and the need for extension mechanisms. It is simpler despite supporting larger addresses.
Key design improvements:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Version| Traffic Class | Flow Label |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Payload Length | Next Header | Hop Limit |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ +| |+ Source Address +| |+ (128 bits) +| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ +| |+ Destination Address +| |+ (128 bits) +| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fixed header size: 40 bytes (always)| Field | Bits | Description | Notes |
|---|---|---|---|
| Version | 4 | IP version number | 6 (for IPv6) |
| Traffic Class | 8 | QoS marking (DSCP + ECN) | Same semantics as IPv4 ToS |
| Flow Label | 20 | Flow identification for QoS | Optional, set by source |
| Payload Length | 16 | Payload size in bytes | Does NOT include 40-byte header |
| Next Header | 8 | Next header type | Same values as IPv4 Protocol field |
| Hop Limit | 8 | Hop count limit | Equivalent to IPv4 TTL |
| Source Address | 128 | Sender's IPv6 address | 2001:db8::1, etc. |
| Destination Address | 128 | Recipient's IPv6 address | 2001:db8::2, etc. |
Extension Headers:
IPv6 uses extension headers for optional functionality, chained via the Next Header field:
| Next Header Value | Type | Purpose |
|---|---|---|
| 0 | Hop-by-Hop Options | Options processed at each hop |
| 43 | Routing | Source routing specification |
| 44 | Fragment | Fragmentation information |
| 50 | ESP | Encapsulating Security Payload |
| 51 | AH | Authentication Header |
| 60 | Destination Options | Options for destination only |
| 59 | No Next Header | Payload ends here |
Extension header chain example:
IPv6 Header (Next Header = 44) → Fragment Header (Next Header = 6) → TCP Segment
IPv6 addresses are written as eight 16-bit groups in hexadecimal: 2001:0db8:0000:0000:0000:0000:0000:0001. Leading zeros within groups can be omitted, and consecutive groups of zeros can be replaced with :: once. Thus: 2001:db8::1. Understanding this notation is essential for packet analysis.
TCP (Transmission Control Protocol) provides reliable, ordered, byte-stream communication. Its header is rich with state information—understanding each field is essential for troubleshooting connection issues, diagnosing performance problems, and analyzing application behavior.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source Port | Destination Port |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Sequence Number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Acknowledgment Number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Data | |C|E|U|A|P|R|S|F| || Offset| Rsrvd |W|C|R|C|S|S|Y|I| Window || | |R|E|G|K|H|T|N|N| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Checksum | Urgent Pointer |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Options (if Data Offset > 5) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Minimum header size: 20 bytesMaximum header size: 60 bytes| Field | Bits | Description |
|---|---|---|
| Source Port | 16 | Sending application port (ephemeral 49152-65535 for clients) |
| Destination Port | 16 | Receiving application port (well-known 0-1023 for servers) |
| Sequence Number | 32 | Byte offset of first data byte in this segment |
| Acknowledgment Number | 32 | Next expected byte from peer (if ACK flag set) |
| Data Offset | 4 | Header length in 32-bit words (5-15) |
| Flags | 9 | Control flags (see below) |
| Window | 16 | Receive window size in bytes (scaled with Window Scale option) |
| Checksum | 16 | Header + data integrity check (includes pseudo-header) |
| Urgent Pointer | 16 | Offset of urgent data (if URG flag set) |
TCP Flags in Detail:
| Flag | Name | Meaning |
|---|---|---|
| SYN | Synchronize | Initiating connection, contains ISN |
| ACK | Acknowledge | Acknowledgment number field is valid |
| FIN | Finish | Sender has finished sending data |
| RST | Reset | Connection abort / error |
| PSH | Push | Receiver should deliver data immediately |
| URG | Urgent | Urgent pointer field is valid |
| ECE | ECN-Echo | Echoes CE (Congestion Experienced) |
| CWR | Congestion Window Reduced | Sender reduced congestion window |
| NS | ECN-nonce | Experimental nonce protection |
Common flag combinations:
[SYN] — Connection initiation (first packet of 3-way handshake)[SYN, ACK] — Connection acceptance (second packet)[ACK] — Acknowledgment (data flow, third packet of handshake)[FIN, ACK] — Connection termination[RST] — Connection reset (error, rejection)[PSH, ACK] — Data with immediate delivery requestWireshark's 'Statistics → TCP Stream Graphs' provides powerful visualization of sequence numbers, round-trip times, throughput, and window scaling. The 'tcp.analysis' expert info highlights retransmissions, duplicate ACKs, and other anomalies. Mastering these tools accelerates TCP troubleshooting significantly.
UDP (User Datagram Protocol) provides minimal transport services—just port multiplexing and optional integrity checking. Its simplicity is its strength: no connection state, no retransmission logic, no ordering guarantees—just fast, lightweight datagram delivery.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source Port | Destination Port |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Length | Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fixed header size: 8 bytes (always)| Field | Bits | Description | Notes |
|---|---|---|---|
| Source Port | 16 | Sending application port | Optional (can be 0) |
| Destination Port | 16 | Receiving application port | Required |
| Length | 16 | Total datagram size (header + data) | Minimum 8 bytes |
| Checksum | 16 | Integrity check | Optional in IPv4, mandatory in IPv6 |
Common UDP Applications:
| Port | Protocol | Why UDP? |
|---|---|---|
| 53 | DNS | Fast queries; reliability at application layer |
| 67/68 | DHCP | Broadcast required; no existing IP address |
| 123 | NTP | Real-time accuracy more important than reliability |
| 161/162 | SNMP | Simple queries; traps are best-effort |
| 500/4500 | IKE/IPsec | Tunneling; reliability at IPsec layer |
| 5060 | SIP | Real-time signaling; TCP also used |
| Various | VoIP/RTP | Real-time media; late packets are useless |
| Various | Games | Latency-critical; state updates are frequent |
Like TCP, UDP checksum includes a 'pseudo-header' containing IP source/destination addresses and protocol number. This binds the UDP datagram to its IP context, catching misdelivery. In IPv4, checksum is optional (0 means not computed); in IPv6, it's mandatory due to removal of IP header checksum.
ICMP (Internet Control Message Protocol) provides error reporting and diagnostics for IP. It's the protocol behind ping and traceroute. Unlike TCP/UDP, ICMP operates at the network layer alongside IP.
ICMP HEADER (Minimum 8 bytes) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Code | Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type-specific |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ECHO REQUEST/REPLY (Type 8/0):+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Code | Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identifier | Sequence Number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Data ... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Name | Codes | Purpose |
|---|---|---|---|
| 0 | Echo Reply | 0 | Response to ping |
| 3 | Destination Unreachable | 0-15 | Packet delivery failed |
| 4 | Source Quench | 0 | Congestion (deprecated) |
| 5 | Redirect | 0-3 | Better route available |
| 8 | Echo Request | 0 | Ping request |
| 11 | Time Exceeded | 0-1 | TTL expired or fragment reassembly timeout |
| 12 | Parameter Problem | 0-2 | Invalid header field |
Destination Unreachable Codes (Type 3):
| Code | Meaning | Typical Cause |
|---|---|---|
| 0 | Network Unreachable | No route to network |
| 1 | Host Unreachable | ARP failure, host down |
| 2 | Protocol Unreachable | No handler for protocol |
| 3 | Port Unreachable | No listener on UDP port |
| 4 | Fragmentation Needed | DF set, MTU exceeded |
| 5 | Source Route Failed | Source routing not supported |
| 13 | Administratively Prohibited | Firewall blocked packet |
ICMPv6 Differences: ICMPv6 (RFC 4443) has additional responsibilities including Neighbor Discovery (like ARP for IPv6), Router Discovery, and Path MTU Discovery. It uses different type numbers: Echo Request is 128, Echo Reply is 129.
ICMP can be abused for reconnaissance (ping sweeps), denial of service (ICMP floods), and covert channels. Many networks filter ICMP—especially inbound Echo Requests. However, blocking ALL ICMP breaks Path MTU Discovery (Type 3 Code 4) and other essential functions. Selective filtering is recommended.
Application layer protocols have their own header structures, though they're often text-based (HTTP) or have variable formats (DNS). Understanding these structures enables deep packet inspection and application-level troubleshooting.
HTTP Request Structure:
GET /path/to/resource HTTP/1.1\r\n ← Request lineHost: www.example.com\r\n ← Required headerUser-Agent: Mozilla/5.0 ...\r\n ← Client identificationAccept: text/html,application/xml\r\n ← Acceptable content typesAccept-Language: en-US,en\r\n ← Preferred languagesAccept-Encoding: gzip, deflate\r\n ← Compression supportConnection: keep-alive\r\n ← Connection preferenceCookie: session=abc123\r\n ← Session state\r\n ← Empty line (end of headers)[Request body if POST/PUT] ← Optional payload HTTP RESPONSE:HTTP/1.1 200 OK\r\n ← Status lineDate: Tue, 17 Jan 2026 12:00:00 GMT\r\n ← Response timestampServer: nginx/1.18.0\r\n ← Server identificationContent-Type: text/html; charset=utf-8\r\n ← Payload typeContent-Length: 3842\r\n ← Body size in bytesCache-Control: max-age=3600\r\n ← Caching directive\r\n ← End of headers<!DOCTYPE html>... ← Response bodyDNS Message Structure:
DNS MESSAGE FORMAT: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Transaction ID | Flags |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Question Count | Answer Count |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Authority Count | Additional Count |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Questions |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Answers |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Authority |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Additional |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS BREAKDOWN (16 bits):+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|QR| Opcode |AA|TC|RD|RA|Z |AD|CD| RCODE |+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ QR: 0=Query, 1=ResponseOpcode: 0=Standard, 1=Inverse, 2=StatusAA: Authoritative AnswerTC: Truncated (use TCP)RD: Recursion DesiredRA: Recursion AvailableRCODE: 0=OK, 3=NXDOMAIN, 5=RefusedWhen capturing packets: (1) Filter early to reduce capture size (capture filters vs. display filters), (2) Capture at the right point—client, server, or transit, (3) Consider encryption—TLS traffic requires keys for decryption, (4) Capture enough context—include connection setup, not just the problem packet, (5) Use ring buffers for continuous capture with limited disk.
Mastering packet structure is essential for network professionals. The ability to examine raw bytes and understand their meaning—to see the sequence number that reveals retransmission, the TTL that traces the path, the flag that indicates connection state—transforms network analysis from guesswork into science.
What's Next:
With comprehensive knowledge of packet structure, we'll next explore Protocol Selection—the methodology for choosing the right protocol for specific requirements. This synthesizes comparison knowledge with practical decision-making frameworks.
You now possess detailed knowledge of packet structure across all major network layers. This byte-level understanding enables you to interpret packet captures, diagnose protocol issues, and understand exactly what flows across networks. Continue to the next page to learn protocol selection methodology.