Computer NetworksTTL and Protocol

TTL and Protocol Fields in IPv4

LevelIntermediate

Duration90 mins

TopicTTL and Protocol

5 / 5

Options Field

The Extensibility Mechanism That Time Forgot

When designing IPv4, the architects faced a fundamental tension: the protocol needed to be efficient for fast forwarding, yet flexible enough to accommodate future needs. Their solution was the Options field—a variable-length extension to the standard 20-byte header that could carry additional control information.

This design seemed elegant: most packets would use the minimal 20-byte header for speed, while special cases could include options for debugging, routing control, security, and features not yet imagined. The Internet Header Length (IHL) field—expressing header size in 4-byte units—enabled headers up to 60 bytes (15 × 4), leaving 40 bytes for options.

What the designers didn't anticipate was that this flexibility would become IPv4's Achilles' heel. Processing options requires routers to examine variable-length data, make complex decisions, and potentially modify header contents—operations that destroy forwarding performance. Worse, options became a vector for attacks: malformed options crashed routers, source routing enabled bypass of security controls, and options-heavy packets created denial-of-service opportunities.

Today, most networks filter IP options at their borders; many routers drop options-bearing packets entirely. Understanding options is nonetheless essential for security analysis, troubleshooting legacy systems, and appreciating why IPv6 took a radically different approach to extensibility.

What You Will Learn

By the end of this page, you will understand the options field structure, common option types, processing requirements, security vulnerabilities, filtering practices, and how IPv6 improved upon this design with extension headers.

Options Field Structure and Location

The Options field occupies the variable-length tail of the IPv4 header, beginning at byte 20 (immediately after the Destination Address) and extending to the byte count specified by the Internet Header Length (IHL) field.

IPv4 Header with Options
Byte Range	Field	Notes
0-19	Fixed header fields	Always present: Version, IHL, ToS, Length, ID, Flags, Fragment Offset, TTL, Protocol, Checksum, Source/Dest addresses
20-59	Options (if present)	Variable length, 0-40 bytes
After options	Padding	Zeros to align to 32-bit boundary

IHL and Options Length:

The IHL field in bytes 0 (bits 4-7) indicates the total header length in 32-bit (4-byte) words:

IHL = 5: Standard 20-byte header, no options
IHL = 6: 24 bytes (4 bytes of options)
IHL = 15: 60 bytes (40 bytes of options, maximum)

This encoding means:

Options must be padded to 32-bit boundaries
Maximum options size is 40 bytes
Header length is always divisible by 4

ihl-options-calculation.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# Calculating header length from IHL
 
# Example 1: Standard header, no options
IHL = 5
Header length = IHL × 4 = 5 × 4 = 20 bytes
Options length = Header length - 20 = 0 bytes
 
# Example 2: Header with Record Route option
IHL = 9
Header length = IHL × 4 = 9 × 4 = 36 bytes
Options length = 36 - 20 = 16 bytes
 
# Example 3: Maximum header size
IHL = 15
Header length = IHL × 4 = 15 × 4 = 60 bytes
Options length = 60 - 20 = 40 bytes
 
# Binary representation in first byte:
# Version (4) | IHL (5) = 0100 0101 = 0x45 (no options)
# Version (4) | IHL (9) = 0100 1001 = 0x49 (with options)
 
# Wireshark filter for packets WITH options:
ip.hdr_len > 20
 
# Wireshark filter for packets WITHOUT options:
ip.hdr_len == 20

Payload Offset Shifts

When options are present, the payload begins at byte 20 + options_length instead of byte 20. Code that assumes payload starts at offset 20 will break. Always read IHL and calculate header_length = IHL × 4.

Individual Option Format

Each option within the options field follows a Type-Length-Value (TLV) format, with some single-byte exceptions.

Single-Byte Options:

Two special options consist of only a single type byte:

End of Option List (Type 0): Marks the end of options. Remaining bytes until IHL boundary should be treated as padding.
No Operation (Type 1): Padding byte used for alignment. Has no semantic meaning.

Multi-Byte Options:

All other options use this format:

Multi-Byte Option Format
Field	Size	Description
Type	1 byte	Option type code (see below)
Length	1 byte	Total option length including Type and Length fields
Data	Length-2 bytes	Option-specific data

Type Byte Structure:

The Type byte itself encodes three pieces of information in its 8 bits:

Option Type Byte Breakdown
Bits	Name	Meaning
Bit 7 (MSB)	Copied flag	1 = Copy this option to all fragments. 0 = Copy only to first fragment.
Bits 6-5	Class	Option class: 0=Control, 2=Debugging/Measurement, 1 and 3=Reserved
Bits 4-0	Number	Option-specific identifier within class

option-type-decoding.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# Option Type Byte Decoding
 
# Type = 0x00 (End of Option List)
Binary: 0 00 00000
Copied: 0 (don't copy to fragments)
Class:  0 (control)
Number: 0
 
# Type = 0x01 (No Operation)
Binary: 0 00 00001
Copied: 0
Class:  0 (control)
Number: 1
 
# Type = 0x07 (Record Route)
Binary: 0 00 00111
Copied: 0 (only first fragment)
Class:  0 (control)
Number: 7
 
# Type = 0x44 (Timestamp)
Binary: 0 10 00100
Copied: 0
Class:  2 (debugging/measurement)
Number: 4
 
# Type = 0x83 (Loose Source Route)
Binary: 1 00 00011
Copied: 1 (copy to all fragments!)
Class:  0 (control)
Number: 3
 
# Type = 0x89 (Strict Source Route)
Binary: 1 00 01001
Copied: 1 (copy to all fragments)
Class:  0 (control)
Number: 9
 
# Key insight: Security options (source routing) have Copied=1
# because route must be preserved across all fragments

Common Option Types

RFC 791 defined several options. While rarely used today, understanding them is essential for security analysis and legacy system support.

Record Route Option (Type 7)

Records the route a packet takes by having each router append its IP address.

Structure:

Type: 7 (0x07)
Length: Variable, typically 39 (max 9 addresses)
Pointer: Position for next address (starts at 4)
Route Data: Space for IP addresses (4 bytes each)

How It Works:

Sender creates option with empty address slots
Each router writes its address at position indicated by Pointer
Router increments Pointer by 4
When Pointer > Length, no more addresses can be recorded
Destination reads recorded addresses

Limitation: Maximum 9 addresses (36 bytes + 3 bytes header = 39 bytes). Internet paths often exceed 9 hops, making this option useless for diagnosing modern paths.

record-route-example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Record Route Option Structure
 
Byte 0: 0x07 (Type 7 = Record Route)
Byte 1: 0x27 (Length 39 = max size)
Byte 2: 0x04 (Pointer = 4, first slot)
Bytes 3-6:   [First router address slot]
Bytes 7-10:  [Second router address slot]
...
Bytes 35-38: [Ninth router address slot]
 
# After traversing 3 routers:
07 27 10 c0 a8 01 01 c0 a8 02 01 0a 00 00 01 00 00 00 00 ...
      ^^ Pointer now at 16 (4 + 3*4 = 16)
         ^^^^^^^^^^^^ Router 1: 192.168.1.1
                      ^^^^^^^^^^^^ Router 2: 192.168.2.1
                                   ^^^^^^^^^^^^ Router 3: 10.0.0.1
 
# Ping with record route (Linux/macOS):
ping -R www.example.com
 
# Windows:
ping -r 9 www.example.com  # 9 = max hops to record
 
# Note: Many routers ignore or drop packets with this option

Option Processing Requirements

Processing IP options is expensive. Unlike the fixed header fields that can be processed in hardware with predictable operations, options require variable-length parsing, conditional logic, and potentially header modification.

Processing Steps for Options-Bearing Packets:

Detect presence: Check if IHL > 5
Parse options loop: Starting at byte 20, process each option:
- Read type byte
- If type 0: End of options, stop parsing
- If type 1: Skip this byte (NOP), continue
- Otherwise: Read length byte, process option data, advance by length
Option-specific action: Each option type has different requirements
Modify header: Record Route, Timestamp may require writing data
Recalculate checksum: Any header modification requires checksum update
Make forwarding decision: Source routing may override normal routing

Converting Mermaid diagram...

Performance Impact

Options processing typically requires moving packets from the hardware fast path to the router's CPU (slow path). This can reduce throughput by orders of magnitude—from millions of packets per second to thousands. A single malformed options packet can consume significant CPU time.

Fragmentation and Options:

The "Copied" flag in the option type determines behavior during fragmentation:

Copied = 1: Option is copied to ALL fragments (e.g., source routing—all fragments must follow the same route)
Copied = 0: Option appears only in the FIRST fragment (e.g., Record Route—intermediate addresses only need to be recorded once)

This design ensures security-critical options like source routing cannot be circumvented by sending some fragments without the option.

Security Vulnerabilities and Attack Vectors

IP options have been a rich source of security vulnerabilities throughout Internet history. Understanding these risks is essential for defensive network engineering.

Historical IP Options Vulnerabilities
Vulnerability	Mechanism	Impact	Mitigation
Pointer overflow	Malformed pointer field exceeds option length	Router crash, memory corruption	Strict bounds checking
Ping of Death	Fragmented ICMP with overlapping options	System crash	Fragment reassembly limits
Source route spoofing	Control reply path to spoofed source	Bypass authentication	Block source routing
Option length attacks	Length > 40 or Length > remaining header	Buffer overflow	Validate length fields
Zero-length options	Length = 0 causing infinite parsing loop	CPU exhaustion	Minimum length checks
Record Route amplification	Force traffic through multiple paths	DDoS amplification	Block Record Route

Case Study: Source Routing Attack

Consider this attack scenario:

Attacker at IP 203.0.113.100 wants to access internal server 192.168.1.50
Internal server trusts connections from internal management network 192.168.100.0/24
Firewall blocks external access to 192.168.1.50

Without source routing: Attack blocked by firewall.

With source routing (if not blocked):

source-route-attack.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Attack packet structure:
 
IPv4 Header:
  Source IP: 203.0.113.100 (attacker, spoofed as 192.168.100.5)
  Destination IP: 192.168.1.50 (target server)
  Options: Loose Source Route
    Route: 203.0.113.100 → 10.0.0.1 (firewall) → 192.168.1.50
    
# Attack flow:
1. Attacker sends packet with spoofed source 192.168.100.5
2. Source route forces packet through specific path
3. Firewall sees packet destined for internal network, may forward
4. Target server receives packet appearing from trusted 192.168.100.5
5. Responses follow source route BACK to attacker
 
# Why this works:
- Source routing overrides normal routing decisions
- Responses use recorded route in reverse
- Attacker receives replies despite spoofed source address
 
# Defense: Block ALL source-routed packets at network edge

Defense in Depth for IP Options

Block source-routed packets at all borders. 2. Drop packets with unrecognized options. 3. Rate-limit options processing to prevent DoS. 4. Disable source routing in all operating systems. 5. Monitor for options-bearing packets as potential attack indicators.

Modern Network Filtering Practices

Given the security risks and performance impact, most modern networks aggressively filter IP options. Understanding these practices helps design secure network architectures.

options-filtering.sh

# Linux iptables: Drop packets with IP options
 
# Drop ALL packets with any IP options
iptables -A INPUT -m u32 --u32 "0>>22&0x3C@0>>24&0xF!=5" -j DROP
# Explanation: Extract IHL field, drop if > 5 (meaning options present)
 
# More specific: Drop source-routed packets
iptables -A INPUT -m ipv4options --lsrr -j DROP
iptables -A INPUT -m ipv4options --ssrr -j DROP
iptables -A FORWARD -m ipv4options --lsrr -j DROP
iptables -A FORWARD -m ipv4options --ssrr -j DROP
 
# Drop Record Route option
iptables -A INPUT -m ipv4options --rr -j DROP
 
# Drop Timestamp option  
iptables -A INPUT -m ipv4options --ts -j DROP
 
# Log before dropping (for monitoring)
iptables -A INPUT -m ipv4options --any-opt -j LOG --log-prefix "IP_OPTION: "
iptables -A INPUT -m ipv4options --any-opt -j DROP
 
# nftables equivalent (modern Linux):
nft add rule ip filter input ip hdrlength > 20 drop

Recommended Filtering Stance

•Enterprise Networks: Block all options at border routers. Log and alert on any options-bearing packets.
•ISPs: Drop source routing and Record Route. May need to permit Router Alert for RSVP/IGMP.
•Cloud Providers: Strip all options before forwarding to customer VMs. Options present attack surface.
•End Hosts: Disable source routing acceptance. Drop packets with options in host firewall.

Evolution: IPv6 Extension Headers

IPv6 learned from IPv4's options mistakes. Instead of a variable-length options field within a single header, IPv6 uses extension headers—a chain of separate headers between the fixed IPv6 header and the upper-layer payload.

IPv4 Options vs. IPv6 Extension Headers
Aspect	IPv4 Options	IPv6 Extension Headers
Location	Variable tail of main header	Separate headers after fixed header
Size Limit	40 bytes maximum	No inherent limit (64KB practical)
Processing	All options examined by every router	Most extensions only processed by endpoints
Performance	Slow path required	Only Hop-by-Hop option needs router processing
Chaining	All options in single block	Headers chain via Next Header field
Flexibility	Limited by size constraint	Unlimited extension types

Key IPv6 Extension Headers:

Hop-by-Hop Options (0): Examined by every router (similar to IPv4 options, rarely used)
Routing (43): Type 0 deprecated due to attacks; Type 2 used for Mobile IPv6
Fragment (44): Fragmentation information (only source can fragment in IPv6)
Authentication Header (51): IPsec authentication
Encapsulating Security Payload (50): IPsec encryption
Destination Options (60): Options for destination only

The Critical Improvement:

Most IPv6 extension headers are processed only by the destination, not by intermediate routers. This eliminates the performance penalty that plagued IPv4 options. Only Hop-by-Hop Options require router processing, and even those can be ignored by overloaded routers.

Extension Header Filtering Controversy

Despite the improved design, IPv6 extension headers have also faced filtering. Large operators drop packets with extension headers due to processing concerns and attack potential. This has caused deployment challenges for Mobile IPv6 and other extension-dependent protocols.

Summary: IPv4 Options Field

The IPv4 Options field represents a well-intentioned extensibility mechanism that became a liability in practice. Let's consolidate the key concepts:

Key Takeaways

•Variable-length extension — Options occupy bytes 20-59 of the IPv4 header, with size indicated by IHL. Maximum 40 bytes of options.
•TLV format — Most options use Type-Length-Value encoding. Two single-byte options exist: End (0) and NOP (1).
•Common types — Record Route (7), Timestamp (68), Loose Source Route (131), Strict Source Route (137), and Router Alert (148).
•Security nightmare — Source routing enables firewall bypass and spoofing enhancement. Block it everywhere.
•Performance killer — Options processing moves packets to slow path. Modern routers may refuse to process options entirely.
•Universally filtered — Most networks drop options-bearing packets. Only Router Alert sees legitimate modern use.
•IPv6 improved — Extension headers separate from main header, processed only by endpoints, with no size limit.

Module Complete:

You have now completed the comprehensive exploration of TTL and Protocol in IPv4. This module covered:

Time to Live — Structure, defaults, decrementing mechanics
TTL Purpose — Loop prevention, diagnostics, security
Protocol Field — Upper-layer multiplexing
Header Checksum — Integrity verification
Options Field — Extensibility and security

These fields work together to enable reliable, secure packet delivery across the Internet. Understanding them deeply is essential for network engineering, security analysis, and protocol design.

Module Complete

Congratulations! You have mastered the TTL and Protocol module. You understand the full lifecycle of packets from lifetime management through upper-layer delivery, integrity verification, and optional extensions. This knowledge forms a critical foundation for advanced network engineering.

5 / 5

Loading learning content...

Computer NetworksTTL and Protocol

TTL and Protocol Fields in IPv4

LevelIntermediate

Duration90 mins

TopicTTL and Protocol

5 / 5

Options Field

The Extensibility Mechanism That Time Forgot

What You Will Learn

Options Field Structure and Location

IPv4 Header with Options
Byte Range	Field	Notes
0-19	Fixed header fields	Always present: Version, IHL, ToS, Length, ID, Flags, Fragment Offset, TTL, Protocol, Checksum, Source/Dest addresses
20-59	Options (if present)	Variable length, 0-40 bytes
After options	Padding	Zeros to align to 32-bit boundary

IHL and Options Length:

The IHL field in bytes 0 (bits 4-7) indicates the total header length in 32-bit (4-byte) words:

IHL = 5: Standard 20-byte header, no options
IHL = 6: 24 bytes (4 bytes of options)
IHL = 15: 60 bytes (40 bytes of options, maximum)

This encoding means:

Options must be padded to 32-bit boundaries
Maximum options size is 40 bytes
Header length is always divisible by 4

ihl-options-calculation.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# Calculating header length from IHL
 
# Example 1: Standard header, no options
IHL = 5
Header length = IHL × 4 = 5 × 4 = 20 bytes
Options length = Header length - 20 = 0 bytes
 
# Example 2: Header with Record Route option
IHL = 9
Header length = IHL × 4 = 9 × 4 = 36 bytes
Options length = 36 - 20 = 16 bytes
 
# Example 3: Maximum header size
IHL = 15
Header length = IHL × 4 = 15 × 4 = 60 bytes
Options length = 60 - 20 = 40 bytes
 
# Binary representation in first byte:
# Version (4) | IHL (5) = 0100 0101 = 0x45 (no options)
# Version (4) | IHL (9) = 0100 1001 = 0x49 (with options)
 
# Wireshark filter for packets WITH options:
ip.hdr_len > 20
 
# Wireshark filter for packets WITHOUT options:
ip.hdr_len == 20

Payload Offset Shifts

Individual Option Format

Each option within the options field follows a Type-Length-Value (TLV) format, with some single-byte exceptions.

Single-Byte Options:

Two special options consist of only a single type byte:

End of Option List (Type 0): Marks the end of options. Remaining bytes until IHL boundary should be treated as padding.
No Operation (Type 1): Padding byte used for alignment. Has no semantic meaning.

Multi-Byte Options:

All other options use this format:

Multi-Byte Option Format
Field	Size	Description
Type	1 byte	Option type code (see below)
Length	1 byte	Total option length including Type and Length fields
Data	Length-2 bytes	Option-specific data

Type Byte Structure:

The Type byte itself encodes three pieces of information in its 8 bits:

Option Type Byte Breakdown
Bits	Name	Meaning
Bit 7 (MSB)	Copied flag	1 = Copy this option to all fragments. 0 = Copy only to first fragment.
Bits 6-5	Class	Option class: 0=Control, 2=Debugging/Measurement, 1 and 3=Reserved
Bits 4-0	Number	Option-specific identifier within class

option-type-decoding.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# Option Type Byte Decoding
 
# Type = 0x00 (End of Option List)
Binary: 0 00 00000
Copied: 0 (don't copy to fragments)
Class:  0 (control)
Number: 0
 
# Type = 0x01 (No Operation)
Binary: 0 00 00001
Copied: 0
Class:  0 (control)
Number: 1
 
# Type = 0x07 (Record Route)
Binary: 0 00 00111
Copied: 0 (only first fragment)
Class:  0 (control)
Number: 7
 
# Type = 0x44 (Timestamp)
Binary: 0 10 00100
Copied: 0
Class:  2 (debugging/measurement)
Number: 4
 
# Type = 0x83 (Loose Source Route)
Binary: 1 00 00011
Copied: 1 (copy to all fragments!)
Class:  0 (control)
Number: 3
 
# Type = 0x89 (Strict Source Route)
Binary: 1 00 01001
Copied: 1 (copy to all fragments)
Class:  0 (control)
Number: 9
 
# Key insight: Security options (source routing) have Copied=1
# because route must be preserved across all fragments

Common Option Types

RFC 791 defined several options. While rarely used today, understanding them is essential for security analysis and legacy system support.

Record Route Option (Type 7)

Records the route a packet takes by having each router append its IP address.

Structure:

Type: 7 (0x07)
Length: Variable, typically 39 (max 9 addresses)
Pointer: Position for next address (starts at 4)
Route Data: Space for IP addresses (4 bytes each)

How It Works:

Sender creates option with empty address slots
Each router writes its address at position indicated by Pointer
Router increments Pointer by 4
When Pointer > Length, no more addresses can be recorded
Destination reads recorded addresses

Limitation: Maximum 9 addresses (36 bytes + 3 bytes header = 39 bytes). Internet paths often exceed 9 hops, making this option useless for diagnosing modern paths.

record-route-example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Record Route Option Structure
 
Byte 0: 0x07 (Type 7 = Record Route)
Byte 1: 0x27 (Length 39 = max size)
Byte 2: 0x04 (Pointer = 4, first slot)
Bytes 3-6:   [First router address slot]
Bytes 7-10:  [Second router address slot]
...
Bytes 35-38: [Ninth router address slot]
 
# After traversing 3 routers:
07 27 10 c0 a8 01 01 c0 a8 02 01 0a 00 00 01 00 00 00 00 ...
      ^^ Pointer now at 16 (4 + 3*4 = 16)
         ^^^^^^^^^^^^ Router 1: 192.168.1.1
                      ^^^^^^^^^^^^ Router 2: 192.168.2.1
                                   ^^^^^^^^^^^^ Router 3: 10.0.0.1
 
# Ping with record route (Linux/macOS):
ping -R www.example.com
 
# Windows:
ping -r 9 www.example.com  # 9 = max hops to record
 
# Note: Many routers ignore or drop packets with this option

Option Processing Requirements

Processing Steps for Options-Bearing Packets:

Detect presence: Check if IHL > 5
Parse options loop: Starting at byte 20, process each option:
- Read type byte
- If type 0: End of options, stop parsing
- If type 1: Skip this byte (NOP), continue
- Otherwise: Read length byte, process option data, advance by length
Option-specific action: Each option type has different requirements
Modify header: Record Route, Timestamp may require writing data
Recalculate checksum: Any header modification requires checksum update
Make forwarding decision: Source routing may override normal routing

Converting Mermaid diagram...

Performance Impact

Fragmentation and Options:

The "Copied" flag in the option type determines behavior during fragmentation:

Copied = 1: Option is copied to ALL fragments (e.g., source routing—all fragments must follow the same route)
Copied = 0: Option appears only in the FIRST fragment (e.g., Record Route—intermediate addresses only need to be recorded once)

This design ensures security-critical options like source routing cannot be circumvented by sending some fragments without the option.

Security Vulnerabilities and Attack Vectors

IP options have been a rich source of security vulnerabilities throughout Internet history. Understanding these risks is essential for defensive network engineering.

Historical IP Options Vulnerabilities
Vulnerability	Mechanism	Impact	Mitigation
Pointer overflow	Malformed pointer field exceeds option length	Router crash, memory corruption	Strict bounds checking
Ping of Death	Fragmented ICMP with overlapping options	System crash	Fragment reassembly limits
Source route spoofing	Control reply path to spoofed source	Bypass authentication	Block source routing
Option length attacks	Length > 40 or Length > remaining header	Buffer overflow	Validate length fields
Zero-length options	Length = 0 causing infinite parsing loop	CPU exhaustion	Minimum length checks
Record Route amplification	Force traffic through multiple paths	DDoS amplification	Block Record Route

Case Study: Source Routing Attack

Consider this attack scenario:

Attacker at IP 203.0.113.100 wants to access internal server 192.168.1.50
Internal server trusts connections from internal management network 192.168.100.0/24
Firewall blocks external access to 192.168.1.50

Without source routing: Attack blocked by firewall.

With source routing (if not blocked):

source-route-attack.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Attack packet structure:
 
IPv4 Header:
  Source IP: 203.0.113.100 (attacker, spoofed as 192.168.100.5)
  Destination IP: 192.168.1.50 (target server)
  Options: Loose Source Route
    Route: 203.0.113.100 → 10.0.0.1 (firewall) → 192.168.1.50
    
# Attack flow:
1. Attacker sends packet with spoofed source 192.168.100.5
2. Source route forces packet through specific path
3. Firewall sees packet destined for internal network, may forward
4. Target server receives packet appearing from trusted 192.168.100.5
5. Responses follow source route BACK to attacker
 
# Why this works:
- Source routing overrides normal routing decisions
- Responses use recorded route in reverse
- Attacker receives replies despite spoofed source address
 
# Defense: Block ALL source-routed packets at network edge

Defense in Depth for IP Options

Block source-routed packets at all borders. 2. Drop packets with unrecognized options. 3. Rate-limit options processing to prevent DoS. 4. Disable source routing in all operating systems. 5. Monitor for options-bearing packets as potential attack indicators.

Modern Network Filtering Practices

Given the security risks and performance impact, most modern networks aggressively filter IP options. Understanding these practices helps design secure network architectures.

options-filtering.sh

# Linux iptables: Drop packets with IP options
 
# Drop ALL packets with any IP options
iptables -A INPUT -m u32 --u32 "0>>22&0x3C@0>>24&0xF!=5" -j DROP
# Explanation: Extract IHL field, drop if > 5 (meaning options present)
 
# More specific: Drop source-routed packets
iptables -A INPUT -m ipv4options --lsrr -j DROP
iptables -A INPUT -m ipv4options --ssrr -j DROP
iptables -A FORWARD -m ipv4options --lsrr -j DROP
iptables -A FORWARD -m ipv4options --ssrr -j DROP
 
# Drop Record Route option
iptables -A INPUT -m ipv4options --rr -j DROP
 
# Drop Timestamp option  
iptables -A INPUT -m ipv4options --ts -j DROP
 
# Log before dropping (for monitoring)
iptables -A INPUT -m ipv4options --any-opt -j LOG --log-prefix "IP_OPTION: "
iptables -A INPUT -m ipv4options --any-opt -j DROP
 
# nftables equivalent (modern Linux):
nft add rule ip filter input ip hdrlength > 20 drop

Recommended Filtering Stance

•Enterprise Networks: Block all options at border routers. Log and alert on any options-bearing packets.
•ISPs: Drop source routing and Record Route. May need to permit Router Alert for RSVP/IGMP.
•Cloud Providers: Strip all options before forwarding to customer VMs. Options present attack surface.
•End Hosts: Disable source routing acceptance. Drop packets with options in host firewall.

Evolution: IPv6 Extension Headers

IPv4 Options vs. IPv6 Extension Headers
Aspect	IPv4 Options	IPv6 Extension Headers
Location	Variable tail of main header	Separate headers after fixed header
Size Limit	40 bytes maximum	No inherent limit (64KB practical)
Processing	All options examined by every router	Most extensions only processed by endpoints
Performance	Slow path required	Only Hop-by-Hop option needs router processing
Chaining	All options in single block	Headers chain via Next Header field
Flexibility	Limited by size constraint	Unlimited extension types

Key IPv6 Extension Headers:

Hop-by-Hop Options (0): Examined by every router (similar to IPv4 options, rarely used)
Routing (43): Type 0 deprecated due to attacks; Type 2 used for Mobile IPv6
Fragment (44): Fragmentation information (only source can fragment in IPv6)
Authentication Header (51): IPsec authentication
Encapsulating Security Payload (50): IPsec encryption
Destination Options (60): Options for destination only

The Critical Improvement:

Extension Header Filtering Controversy

Summary: IPv4 Options Field

The IPv4 Options field represents a well-intentioned extensibility mechanism that became a liability in practice. Let's consolidate the key concepts:

Key Takeaways

•Variable-length extension — Options occupy bytes 20-59 of the IPv4 header, with size indicated by IHL. Maximum 40 bytes of options.
•TLV format — Most options use Type-Length-Value encoding. Two single-byte options exist: End (0) and NOP (1).
•Common types — Record Route (7), Timestamp (68), Loose Source Route (131), Strict Source Route (137), and Router Alert (148).
•Security nightmare — Source routing enables firewall bypass and spoofing enhancement. Block it everywhere.
•Performance killer — Options processing moves packets to slow path. Modern routers may refuse to process options entirely.
•Universally filtered — Most networks drop options-bearing packets. Only Router Alert sees legitimate modern use.
•IPv6 improved — Extension headers separate from main header, processed only by endpoints, with no size limit.

Module Complete:

You have now completed the comprehensive exploration of TTL and Protocol in IPv4. This module covered:

Time to Live — Structure, defaults, decrementing mechanics
TTL Purpose — Loop prevention, diagnostics, security
Protocol Field — Upper-layer multiplexing
Header Checksum — Integrity verification
Options Field — Extensibility and security

These fields work together to enable reliable, secure packet delivery across the Internet. Understanding them deeply is essential for network engineering, security analysis, and protocol design.

Module Complete

5 / 5