Day 10: IPv4 Header

The IPv4 Header

Overview

What is the IPv4 Header?

The IPv4 header is the Layer 3 (Network Layer) Protocol Data Unit that enables:

• Routing — Sending data between devices on separate networks

• Global connectivity — Reaching devices across the Internet

• Protocol identification — Knowing what Layer 4 protocol is encapsulated

• Error checking — Detecting corruption in the header itself

Position in the Stack:

Application Data

     ↓ (encapsulated in)

TCP/UDP Segment (Layer 4)

     ↓ (encapsulated in)

IPv4 Packet (Layer 3) ← IPv4 Header

     ↓ (encapsulated in)

Ethernet Frame (Layer 2)

Key Purpose: The IPv4 header tells routers where the packet came from (source IP) and where it's going (destination IP), allowing them to make forwarding decisions.

 

---

 

IPv4 Header Structure

Overall Header Layout

32-bit boundaries (4-byte words)

[VERSION][IHL][DSCP][ECN] [TOTAL LENGTH]

[IDENTIFICATION] [FLAGS][FRAGMENT OFFSET]

[TTL][PROTOCOL] [HEADER CHECKSUM]

[SOURCE IP ADDRESS (32 bits)]

[DESTINATION IP ADDRESS (32 bits)]

[OPTIONS (Optional, Variable Length)]

Header Size

• Minimum size: 20 bytes (no options)

• Maximum size: 60 bytes (with options)

The minimum 20 bytes is the standard for most packets.

Complete Field Reference

 

---

 

Field Definitions

Version (4 bits)

Identifies the Internet Protocol version being used.

Note: The first field of every IP header is the version, so a device can immediately identify which IP version is being used.

 

---

 

IHL — Internet Header Length (4 bits)

Specifies the total length of the IPv4 header in 4-byte increments.

Why is this needed?

The Options field (last part of header) is variable in length. The IHL field tells the device where the actual data payload begins.

Calculation:

IHL value × 4 bytes = Header length in bytes

Example:

IHL = 5 → 5 × 4 = 20 bytes (standard minimum)

IHL = 15 → 15 × 4 = 60 bytes (maximum with options)

Valid Range:

Default: IHL = 5 (20 bytes) for packets without options.

 

---

 

DSCP — Differentiated Services Code Point (6 bits)

Used for Quality of Service (QoS) — prioritizing certain types of traffic.

What it does:

• Marks packets with a priority/class level

• Routers use this to make forwarding decisions

• Can prioritize delay-sensitive traffic (VoIP, video streaming)

• Can deprioritize non-critical traffic (file transfers, email)

Common Uses:

• Voice over IP (VoIP) — High priority (low latency needed)

• Video streaming — Medium-high priority

• Regular web traffic — Standard priority

• Backup/FTP transfers — Low priority

Note: Only meaningful if routers are configured to respect QoS markings.

 

---

 

ECN — Explicit Congestion Notification (2 bits)

Provides congestion feedback without dropping packets.

Traditional Approach (old):

• Routers detect congestion → Drop packets

• Sender notices packet loss → Reduces sending rate

• Works, but wastes the dropped packets

ECN Approach (modern, optional):

• Routers detect congestion → Mark packet with ECN bit (don't drop it)

• Packet reaches destination → Receiver knows congestion occurred

• Receiver notifies sender → Sender reduces rate

• All devices still receive their data (more efficient)

Requirements:

• Both sender and receiver must support ECN

• Routers/network must be configured to use it

• Not always enabled (legacy network compatibility)

 

---

 

Total Length (16 bits)

Specifies the total size of the entire IP packet — header + encapsulated data.

Important Details:

• Measured in bytes (not 4-byte increments)

• Minimum value: 20 bytes (IPv4 header with no data)

• Maximum value: 65,535 bytes (2^16 - 1)

Example:

IPv4 Header: 20 bytes

TCP Segment: 40 bytes

Data: 400 bytes

Total Length: 20 + 40 + 400 = 460 bytes

MTU (Maximum Transmission Unit):

• Typical MTU for Ethernet: 1500 bytes

• If packet total length exceeds MTU, packet is fragmented

 

---

 

Identification (16 bits)

Groups fragmented packets together so they can be reassembled.

What it does:

• If a packet is too large (exceeds MTU), it's split into fragments

• Each fragment gets its own IPv4 header

• All fragments from the same packet have the same Identification value

• Receiving device uses this value to know which fragments belong together

Example Scenario:

Original packet: 4000 bytes (exceeds 1500 MTU)

Fragment 1: Header (20 bytes) + Data (1480 bytes) = 1500

Fragment 2: Header (20 bytes) + Data (1480 bytes) = 1500

Fragment 3: Header (20 bytes) + Data (1020 bytes) = 1040

All three fragments have: Identification = 5000 (same value)

Receiving host reassembles using this identifier

 

---

 

Flags (3 bits)

Control packet fragmentation behavior.

Usage Examples:

DF Bit = 1 (Don't Fragment):

• Used when fragmentation is undesirable

• Example: Some VPN or tunneling protocols

• If packet exceeds MTU and DF=1, router drops packet and sends ICMP error

• Sender receives error and resends with smaller size

MF Bit = 1 (More Fragments):

• Set to 1 on all fragments except the last one

• Last fragment (or unfragmented packet) has MF = 0

• Helps receiver know when it has received all fragments

Example:

Original: 3000 bytes, Identification = 100

Fragment 1: FLAGS = 001 (DF=0, MF=1 — more fragments coming)

Fragment 2: FLAGS = 001 (DF=0, MF=1 — more fragments coming)

Fragment 3: FLAGS = 000 (DF=0, MF=0 — last fragment, no more)

Receiver sees MF=0 on third fragment and stops waiting

 

---

 

Fragment Offset (13 bits)

Indicates the position of this fragment within the original unfragmented packet.

Measured in: 8-byte increments

Why it's needed:

• Fragments can arrive out of order

• Receiver uses offset to reassemble in correct order

• Offset allows fragments as small as 8 bytes (efficiency)

Calculation:

Actual byte position = Fragment Offset × 8

Example:

Fragment Offset = 0 → Bytes 0–7 (first fragment)

Fragment Offset = 185 → Bytes 1480–1487 (fragment 2, after 185×8)

Fragment Offset = 370 → Bytes 2960–2967 (fragment 3)

 

---

 

TTL — Time To Live (8 bits)

Prevents packets from circulating infinitely through the network.

Original Purpose (historical):

• Meant to represent packet's maximum lifetime in seconds

• In practice, became a hop count mechanism

Modern Usage (hop count):

• Each router decrements TTL by 1

• When TTL reaches 0, router drops the packet

• Prevents infinite loops (routing loops)

Common Default Values:

Example Journey:

PC sends packet with TTL = 64

Router 1: TTL = 64 → Decrements to 63 → Forwards

Router 2: TTL = 63 → Decrements to 62 → Forwards

Router 3: TTL = 62 → Decrements to 61 → Forwards

...

Router 64: TTL = 1 → Decrements to 0 → DROPS packet

Prevents packet from traveling more than ~64 hops

Traceroute Uses TTL:

The traceroute command intentionally uses increasing TTL values to discover the path packets take:

Send packet with TTL=1 → Router 1 drops it, sends ICMP error

Send packet with TTL=2 → Router 2 drops it, sends ICMP error

Send packet with TTL=3 → Router 3 drops it, sends ICMP error

... continues until destination reached

 

---

 

Protocol (8 bits)

Identifies which Layer 4 protocol is encapsulated in the packet.

Common Protocol Numbers:

Why routers need this:

• Router reads protocol number

• Knows what Layer 4 protocol to expect

• Can make forwarding decisions based on protocol (e.g., route all TCP port 80 via certain interface)

Complete Protocol Numbers:

Internet Assigned Numbers Authority (IANA) Protocol Numbers

 

---

 

Header Checksum (16 bits)

Detects errors in the IPv4 header only.

How it works:

1. Sender calculates a checksum of all header fields

2. Sender stores checksum in Header Checksum field

3. Router receives packet

4. Router recalculates checksum from header fields

5. Router compares calculated checksum to Header Checksum field

6. If they don't match → packet is corrupted → packet is dropped

7. If they match → packet is valid → forward it

Important:

• Only checks the IPv4 header, not the data payload

• Does NOT check TCP/UDP segment or application data

• TCP and UDP have their own checksum fields for data integrity

• If header corrupted, packet is discarded (not retransmitted by IP layer)

Why separate checksums?

• IP header is critical (routing decisions depend on source/destination)

• Data errors are handled by Layer 4 protocols (TCP/UDP)

• Separating concerns improves efficiency

 

---

 

Source and Destination IP Addresses (32 bits each)

Source IP Address:

• IP address of the device that originated the packet

• Set by the sender

• Does not change during transit (unless NAT is involved)

Destination IP Address:

• IP address of the device the packet is destined for

• Set by the sender

• Routers use this to make forwarding decisions

Routing Decision:

Router receives packet

↓

Router looks at Destination IP

↓

Router checks routing table: "Where do I send packets destined for X.X.X.X?"

↓

Router forwards packet out appropriate interface

↓

Packet travels to next hop (another router or destination)

 

---

 

Options (0–320 bits, variable)

Optional and rarely used — present only if IHL > 5.

When Options exist:

• IHL field will be > 5

• Example: IHL = 6 means 24 bytes (20 + 4 bytes of options)

• IHL = 7 means 28 bytes (20 + 8 bytes of options)

Rare Options Examples:

• Strict Routing — Specify exact route packet must take

• Loose Routing — Specify certain routers packet must pass through

• Record Route — Track which routers packet passes through

• Timestamp — Record timestamps at each router

Why rarely used?

• Add overhead (increased header size)

• Not supported by many routers (security/efficiency reasons)

• Can slow down routing decisions

• Modern protocols (IPv6) handle these features differently

 

---

 

Fragmentation Example

Scenario: Packet Too Large for MTU

Application sends 3000 bytes to network with 1500 MTU

IPv4 Header created:

  Source: 192.168.1.100

  Destination: 192.168.1.200

  Total Length: 3020 (20 header + 3000 data)

  

Router sees: 3020 > 1500 (MTU exceeded)

Fragmentation occurs:

Fragment 1:

  IPv4 Header (20 bytes)

  + Data (1480 bytes)

  = 1500 bytes total

  Identification: 5000

  Flags: 001 (DF=0, MF=1)

  Fragment Offset: 0 (starts at byte 0)

Fragment 2:

  IPv4 Header (20 bytes)

  + Data (1480 bytes)

  = 1500 bytes total

  Identification: 5000 (SAME)

  Flags: 001 (DF=0, MF=1)

  Fragment Offset: 185 (starts at byte 1480 = 185×8)

Fragment 3:

  IPv4 Header (20 bytes)

  + Data (40 bytes)

  = 60 bytes total

  Identification: 5000 (SAME)

  Flags: 000 (DF=0, MF=0 — last fragment)

  Fragment Offset: 370 (starts at byte 2960 = 370×8)

Receiving host:

  Gets Fragment 1 (offset 0)

  Gets Fragment 3 (offset 370) — arrives first

  Gets Fragment 2 (offset 185) — arrives last

  

  Uses offsets to reassemble in correct order:

  Bytes 0–1479 (Fragment 1)

  Bytes 1480–2959 (Fragment 2)

  Bytes 2960–2999 (Fragment 3)

  

  Result: Complete 3000-byte data message

 

---

 

Summary Table: IPv4 Header Fields Quick Reference

 

---

 

Key Concepts for Routing

How Routers Use the IPv4 Header

Router's processing:

1. Read Source IP → know where it came from

2. Read Destination IP → look up in routing table

3. Read TTL → decrement by 1

4. Recalculate Header Checksum → verify no corruption

5. Read Protocol → identify Layer 4 payload

6. Read Total Length → know packet size

7. Check if fragmentation needed (MTU comparison)

8. Forward out appropriate interface

TTL as a Loop Prevention Mechanism

Network with routing loop:

PC1 sends to 10.0.0.5 with TTL=64

  ↓

Router A: TTL 64→63, forwards to Router B

  ↓

Router B: TTL 63→62, forwards to Router A (loop!)

  ↓

Router A: TTL 62→61, forwards to Router B

  ↓

[continues looping...]

  ↓

Router: TTL=1, decrements to 0 → DROPS packet

  ↓

Packet never reaches destination, but network not flooded

Without TTL, the packet would loop infinitely, consuming bandwidth.

 

---

 

Practical Example: Complete IPv4 Header

Scenario: PC1 sends HTTP request to web server

PC1 (192.168.1.100) → Web Server (8.8.8.8)

IPv4 Header created:

Version: 4 (0100 in binary)

IHL: 5 (20 bytes, no options)

DSCP: 0 (normal priority)

ECN: 0 (no congestion)

Total Length: 546 (20 header + 40 TCP + 486 HTTP data)

Identification: 34521 (random ID for this packet)

Flags: 010 (DF bit set — don't fragment)

Fragment Offset: 0 (not fragmented)

TTL: 64 (default from Windows/Linux)

Protocol: 6 (TCP)

Header Checksum: 0xA2B4 (calculated checksum)

Source IP: 192.168.1.100

Destination IP: 8.8.8.8

Options: (none)

Routing decision:

Router looks at destination 8.8.8.8

Checks routing table: "8.8.8.0/24 → send via ISP gateway"

Forwards packet toward ISP gateway

Decrements TTL from 64 to 63

Recalculates checksum (TTL changed)

Forwards on WAN interface

 

---

 

Key Takeaways for CCNA

✅ IPv4 header minimum 20 bytes (no options), maximum 60 bytes (with options)

✅ IHL field indicates header length in 4-byte increments (5 = 20 bytes standard)

✅ Total Length = entire packet size (header + data), can be up to 65,535 bytes

✅ TTL prevents routing loops; decremented at each router; default ~64

✅ Protocol field identifies Layer 4 protocol (6=TCP, 17=UDP, 1=ICMP)

✅ Fragmentation happens when packet exceeds MTU (usually 1500 bytes)

✅ Identification field groups fragments; all fragments of same packet have same ID

✅ Flags control fragmentation: DF (don't fragment), MF (more fragments)

✅ Fragment Offset in 8-byte increments allows out-of-order reassembly

✅ Header Checksum verifies header integrity only (not data)

✅ Source and Destination IP addresses never change in transit (IP layer perspective)

✅ DSCP used for QoS prioritization (optional)

✅ ECN enables congestion notification without packet drop (optional)

✅ Options field rarely used in modern networks

✅ Routers examine destination IP to make forwarding decisions based on routing table

✅ Traceroute works by sending packets with increasing TTL values to trace route to destination