Computer NetworksIPv4 Options

IPv4 Options

LevelIntermediate

Duration75 mins

TopicIPv4 Options

1 / 5

IPv4 Options Format

The Extensibility Mechanism of IPv4

The designers of IPv4 faced a fundamental challenge: how do you create a protocol flexible enough to accommodate features that haven't been invented yet, while keeping the base header efficient for the common case? Their solution was elegant—optional header extensions.

The IPv4 options field is a variable-length extension that follows the fixed 20-byte header. It enables advanced functionality like route recording, source routing, and timestamping without burdening every packet with rarely-used fields. Understanding options is essential for deep protocol analysis, network troubleshooting, and security assessment.

What You Will Learn

By the end of this page, you will understand the complete structure of IPv4 options, including the type field encoding, length semantics, copying behavior, and how options are padded to maintain 32-bit alignment. You'll be able to decode any IPv4 option from raw packet data.

The Options Field in Context

Before diving into the format details, let's understand where the options field sits within the IPv4 header and why it exists.

IPv4 Header Structure Recap:

The IPv4 header consists of two parts:

Fixed header (20 bytes): Contains essential fields like version, IHL, total length, TTL, protocol, source and destination addresses
Options field (0-40 bytes): Variable-length extension for additional functionality

The Internet Header Length (IHL) field indicates the total header size in 32-bit words. With a minimum value of 5 (20 bytes) and maximum of 15 (60 bytes), the options field can consume up to 40 bytes.

IPv4 Header Size Relationship
IHL Value	Header Size (bytes)	Options Size (bytes)	Description
5	20	0	Minimum header, no options
6	24	4	One 32-bit word of options
7	28	8	Two 32-bit words of options
10	40	20	Five 32-bit words of options
15	60	40	Maximum header, full options

The 40-Byte Limit

The maximum options size of 40 bytes is a hard constraint of IPv4. This limit proved challenging for features like Record Route, which can only record 9 router addresses. This limitation influenced IPv6's design, which uses extension headers without such constraints.

Option Format Categories

IPv4 options come in two distinct formats, distinguished by their structure:

1. Single-Byte Options (Type Only)

These options consist of just the 1-byte type field. They carry no additional data and are used for control purposes.

2. Multi-Byte Options (Type + Length + Data)

These options use a Type-Length-Value (TLV) structure:

Type (1 byte): Identifies the option
Length (1 byte): Total option size including type and length bytes
Data (variable): Option-specific payload

Converting Mermaid diagram...

Single-Byte vs Multi-Byte Options Comparison
Aspect	Single-Byte	Multi-Byte
Structure	Type only	Type + Length + Data
Size	1 byte fixed	Variable (minimum 2 bytes)
Examples	EOL (0), NOP (1)	Record Route, Source Routing, Timestamp
Purpose	Padding and list termination	Functional capabilities
Parsing	Read 1 byte, done	Read type, read length, read (length-2) data bytes

The Type Field Encoding

The 1-byte type field is not merely an identifier—it's a carefully encoded structure with three distinct subfields:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| C |Class| Number                |
+---+---+---+---+---+---+---+---+
|1b | 2b |      5 bits           |

Bit 0 - Copy Flag (C):

0: Option is NOT copied to all fragments during fragmentation
1: Option IS copied to every fragment

Bits 1-2 - Option Class:

00 (0): Control options
10 (2): Debugging and measurement options
01 (1) and 11 (3): Reserved for future use

Bits 3-7 - Option Number:

Identifies the specific option within its class
Provides space for 32 options per class

Understanding the Copy Flag

The copy flag determines option behavior during fragmentation. If an option must be present in every fragment for proper interpretation (like Source Route), the copy flag is set. Options needed only by the first fragment (like Record Route progress) don't require copying.

Type Field Encoding for Common Options
Option Name	Type Value (Binary)	Copy	Class	Number	Decimal
End of Options List	00000000	0	00	00000	0
No Operation	00000001	0	00	00001	1
Record Route	00000111	0	00	00111	7
Timestamp	01000100	0	10	00100	68
Loose Source Routing	10000011	1	00	00011	131
Strict Source Routing	10001001	1	00	01001	137

Decoding Example:

Let's decode option type value 137 (0x89 in hexadecimal):

Binary representation: 10001001
Copy flag (bit 0): 1 → Option is copied to all fragments
Class (bits 1-2): 00 → Control option
Number (bits 3-7): 01001 = 9 → Strict Source Routing

This encoding tells us that Strict Source Routing must be present in every fragment because routers along the path need routing instructions for each fragment they receive.

The Length Field Semantics

The length field in multi-byte options deserves careful attention because its interpretation differs from some other protocols.

Critical Point: Length Includes Type and Length Bytes

The length value indicates the total size of the option, including:

1 byte for the type field
1 byte for the length field itself
Variable bytes for the data

Therefore:

Minimum valid length is 2 (type + length, no data)
Data payload size = Length - 2

Converting Mermaid diagram...

Common Implementation Mistake

A frequent bug in packet parsing code is treating the length field as the data-only length. If you read 'length' bytes of data after the length field, you'll read 2 bytes too many, corrupting your parse and potentially causing security vulnerabilities.

option_parsing.c
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
// INCORRECT: Common mistake in option parsing
void parse_option_wrong(uint8_t *option) {
    uint8_t type = option[0];
    uint8_t length = option[1];
    // Bug: Reading 'length' bytes of data reads 2 extra bytes!
    uint8_t data[length];
    memcpy(data, &option[2], length);  // WRONG!
}
 
// CORRECT: Proper option parsing
void parse_option_correct(uint8_t *option) {
    uint8_t type = option[0];
    uint8_t length = option[1];
    
    // Validate minimum length
    if (length < 2) {
        // Invalid option - handle error
        return;
    }
    
    // Data length is total length minus type and length bytes
    uint8_t data_length = length - 2;
    uint8_t data[data_length];
    memcpy(data, &option[2], data_length);  // CORRECT!
}

End of Options List (EOL) - Type 0

The End of Options List (EOL) option, type value 0, is a single-byte option that marks the absolute end of the options area. After encountering EOL, no further option processing occurs—remaining bytes until the IHL-indicated header end are padding.

Key Characteristics:

Type: 0 (binary: 00000000)
Size: 1 byte
Copy flag: 0 (not copied during fragmentation)
Behavior: Terminates option parsing immediately

Usage Rules:

EOL is only required if options don't naturally end at a 32-bit boundary
After EOL, parsers ignore remaining bytes (treated as padding)
Unlike NOP, EOL indicates "no more options exist" rather than "skip this byte"

EOL vs NOP

EOL (End of Options List) terminates parsing entirely. NOP (No Operation) is just a 1-byte skip that allows parsing to continue. Using NOP where EOL is intended can cause security issues, as parsers may continue processing garbage data as options.

Converting Mermaid diagram...

No Operation (NOP) - Type 1

The No Operation (NOP) option, type value 1, is a single-byte padding option used to align subsequent options on specific boundaries.

Key Characteristics:

Type: 1 (binary: 00000001)
Size: 1 byte
Copy flag: 0 (not copied during fragmentation)
Behavior: Parser skips this byte and continues processing

Primary Uses:

Alignment: Align multi-byte options to 16-bit or 32-bit boundaries for efficient memory access
Separation: Insert visual separation between options in debugging output
Placeholder: Reserve space that might be filled later by intermediate devices

nop_usage_example.txt
Example: Using NOP for 32-bit alignment
 
Options area structure:
Offset 0: Type = 1 (NOP) - 1 byte padding
Offset 1: Type = 1 (NOP) - 1 byte padding  
Offset 2: Type = 1 (NOP) - 1 byte padding
Offset 3: Type = 68 (Timestamp) 
Offset 4: Length = 12
Offset 5-14: Timestamp data
 
Without NOPs, Timestamp would start at offset 0.
With NOPs, Timestamp is aligned to 32-bit boundary (offset 3).
 
Benefits:
- Faster memory access on aligned architectures
- Cleaner debugging display
- Predictable option positions

Alignment Best Practices

While alignment using NOP is optional, some systems perform better with aligned options. The Timestamp option, in particular, often benefits from 32-bit alignment since it contains 32-bit timestamp values. However, in memory-constrained scenarios, omitting alignment NOPs conserves the precious 40-byte options budget.

Option Processing by Routers

Options processing significantly impacts router performance and behavior. Unlike the fixed header fields, which can be processed in hardware at line rate, options require software handling and careful security consideration.

Processing Flow:

Detection: Router checks IHL field; if > 5, options are present
Parsing: Options area is scanned byte-by-byte
Interpretation: Each option is processed according to its type
Action: Router performs required actions (record address, follow route, etc.)
Forwarding: Packet continues with potentially modified options

Converting Mermaid diagram...

Performance Impact

Packets with options bypass hardware fast-path processing on most modern routers. A router that handles millions of packets per second in fast-path may only handle thousands in slow-path. This performance differential is why options are rarely used in production traffic and why many networks filter or drop packets containing options.

Security Considerations:

IPv4 options have significant security implications:

Source Routing Abuse: Attackers can bypass firewall rules by specifying routes that avoid security devices
Reconnaissance: Record Route and Timestamp reveal network topology information
DoS Potential: Complex options processing can exhaust router CPU
Filtering Policies: Many enterprise and ISP networks now block packets with options

RFC 7126 (Internet Architecture Board) recommends filtering source-routed packets at network borders.

Padding and 32-bit Alignment

The IPv4 header must always be a multiple of 32 bits (4 bytes). Since options have variable lengths, padding is required when options don't naturally end on a 32-bit boundary.

Padding Rules:

The options area must end on a 32-bit boundary
Padding is added after the last option (or after EOL)
Padding bytes are zero-filled
The IHL field reflects the total padded header size

Calculation:

Total options size = Sum of all option lengths
Padding needed = (4 - (options size mod 4)) mod 4
Final header size = 20 + options size + padding
IHL = Final header size / 4

Padding Examples
Options Total	Mod 4	Padding Needed	Final Options Area	IHL Value
3 bytes	3	1 byte	4 bytes	6
7 bytes	3	1 byte	8 bytes	7
8 bytes	0	0 bytes	8 bytes	7
15 bytes	3	1 byte	16 bytes	9
39 bytes	3	1 byte	40 bytes	15

padding_calculation.py
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
def calculate_ipv4_header_size(options_bytes: int) -> dict:
    """
    Calculate IPv4 header size with padding for options.
    
    Args:
        options_bytes: Total size of all options (without padding)
    
    Returns:
        Dictionary with padding details
    """
    if options_bytes > 40:
        raise ValueError("Options cannot exceed 40 bytes")
    
    # Calculate padding needed for 32-bit alignment
    remainder = options_bytes % 4
    padding = (4 - remainder) % 4  # This handles the 0 case correctly
    
    # Calculate final sizes
    options_area = options_bytes + padding
    header_size = 20 + options_area
    ihl = header_size // 4
    
    return {
        "options_bytes": options_bytes,
        "padding_bytes": padding,
        "options_area_total": options_area,
        "header_size": header_size,
        "ihl_value": ihl
    }
 
# Examples
print(calculate_ipv4_header_size(7))
# Output: {'options_bytes': 7, 'padding_bytes': 1, 
#          'options_area_total': 8, 'header_size': 28, 'ihl_value': 7}
 
print(calculate_ipv4_header_size(39))
# Output: {'options_bytes': 39, 'padding_bytes': 1,
#          'options_area_total': 40, 'header_size': 60, 'ihl_value': 15}

Complete Options Parsing Algorithm

Let's consolidate everything into a complete algorithm for parsing IPv4 options. This algorithm handles all option types, validates lengths, and properly terminates on EOL or area exhaustion.

ipv4_options_parser.c
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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
#include <stdint.h>
#include <stdbool.h>
 
#define OPT_EOL     0    // End of Options List
#define OPT_NOP     1    // No Operation
#define OPT_RR      7    // Record Route
#define OPT_TS      68   // Timestamp (0x44)
#define OPT_LSR     131  // Loose Source Routing (0x83)
#define OPT_SSR     137  // Strict Source Routing (0x89)
 
typedef struct {
    uint8_t type;
    uint8_t length;       // Total length (includes type and length bytes)
    uint8_t *data;        // Pointer to option data
    uint8_t data_length;  // Actual data length (length - 2)
} IPv4Option;
 
/**
 * Parse IPv4 options from header
 * 
 * @param options_start  Pointer to start of options area
 * @param options_length Length of options area (from IHL: (IHL - 5) * 4)
 * @param parsed_options Array to hold parsed options
 * @param max_options    Maximum options to parse
 * @return Number of options parsed, or -1 on error
 */
int parse_ipv4_options(
    uint8_t *options_start,
    int options_length,
    IPv4Option *parsed_options,
    int max_options
) {
    int offset = 0;
    int count = 0;
    
    while (offset < options_length && count < max_options) {
        uint8_t type = options_start[offset];
        
        // Case 1: End of Options List
        if (type == OPT_EOL) {
            // Parsing complete - remaining bytes are padding
            break;
        }
        
        // Case 2: No Operation (single-byte)
        if (type == OPT_NOP) {
            parsed_options[count].type = OPT_NOP;
            parsed_options[count].length = 1;
            parsed_options[count].data = NULL;
            parsed_options[count].data_length = 0;
            offset += 1;
            count++;
            continue;
        }
        
        // Case 3: Multi-byte option (TLV format)
        // Ensure we have room for length byte
        if (offset + 1 >= options_length) {
            return -1;  // Truncated option
        }
        
        uint8_t length = options_start[offset + 1];
        
        // Validate length
        if (length < 2) {
            return -1;  // Invalid: length must include type and length bytes
        }
        
        if (offset + length > options_length) {
            return -1;  // Option extends beyond options area
        }
        
        // Parse the option
        parsed_options[count].type = type;
        parsed_options[count].length = length;
        parsed_options[count].data_length = length - 2;
        parsed_options[count].data = (length > 2) ? 
            &options_start[offset + 2] : NULL;
        
        offset += length;
        count++;
    }
    
    return count;
}
 
// Example usage
void process_packet(uint8_t *ip_header) {
    uint8_t ihl = ip_header[0] & 0x0F;  // Extract IHL from first byte
    
    if (ihl < 5) {
        // Invalid header
        return;
    }
    
    if (ihl == 5) {
        // No options present
        return;
    }
    
    int options_length = (ihl - 5) * 4;
    uint8_t *options_start = ip_header + 20;  // Options start after fixed header
    
    IPv4Option options[10];  // Support up to 10 options
    int num_options = parse_ipv4_options(
        options_start, options_length, options, 10
    );
    
    if (num_options < 0) {
        // Parse error - malformed options
        return;
    }
    
    // Process each option
    for (int i = 0; i < num_options; i++) {
        switch (options[i].type) {
            case OPT_RR:
                // Handle Record Route
                break;
            case OPT_TS:
                // Handle Timestamp
                break;
            case OPT_LSR:
            case OPT_SSR:
                // Handle Source Routing
                break;
        }
    }
}

Summary: IPv4 Options Format

We've covered the complete structure and semantics of IPv4 options. Let's consolidate the key points:

Key Takeaways

•Options are variable-length header extensions — Maximum 40 bytes, indicated by IHL values 6-15
•Two option formats exist — Single-byte (EOL, NOP) and multi-byte (TLV structure)
•Type field is encoded — Contains copy flag, option class, and option number in a single byte
•Length includes all bytes — The length field counts type, length, and data bytes together
•EOL terminates parsing — Type 0 signals absolute end of options area
•NOP provides alignment — Type 1 allows padding for boundary alignment
•32-bit alignment required — Options area must be padded to 4-byte boundary
•Router performance impact — Options force slow-path processing and may be filtered

What's Next:

Now that you understand the options format, we'll explore the first major option type: Record Route. This option allows capturing the path a packet takes through the network, providing valuable diagnostic information for troubleshooting and network mapping.

Page Complete

You now have a complete understanding of IPv4 options format. You can decode any option from raw packet data, understand the type field encoding, and properly parse TLV-structured options. Next, we'll apply this knowledge to the Record Route option.

1 / 5

Loading learning content...

Computer NetworksIPv4 Options

IPv4 Options

LevelIntermediate

Duration75 mins

TopicIPv4 Options

1 / 5

IPv4 Options Format

The Extensibility Mechanism of IPv4

What You Will Learn

The Options Field in Context

Before diving into the format details, let's understand where the options field sits within the IPv4 header and why it exists.

IPv4 Header Structure Recap:

The IPv4 header consists of two parts:

Fixed header (20 bytes): Contains essential fields like version, IHL, total length, TTL, protocol, source and destination addresses
Options field (0-40 bytes): Variable-length extension for additional functionality

IPv4 Header Size Relationship
IHL Value	Header Size (bytes)	Options Size (bytes)	Description
5	20	0	Minimum header, no options
6	24	4	One 32-bit word of options
7	28	8	Two 32-bit words of options
10	40	20	Five 32-bit words of options
15	60	40	Maximum header, full options

The 40-Byte Limit

Option Format Categories

IPv4 options come in two distinct formats, distinguished by their structure:

1. Single-Byte Options (Type Only)

These options consist of just the 1-byte type field. They carry no additional data and are used for control purposes.

2. Multi-Byte Options (Type + Length + Data)

These options use a Type-Length-Value (TLV) structure:

Type (1 byte): Identifies the option
Length (1 byte): Total option size including type and length bytes
Data (variable): Option-specific payload

Converting Mermaid diagram...

Single-Byte vs Multi-Byte Options Comparison
Aspect	Single-Byte	Multi-Byte
Structure	Type only	Type + Length + Data
Size	1 byte fixed	Variable (minimum 2 bytes)
Examples	EOL (0), NOP (1)	Record Route, Source Routing, Timestamp
Purpose	Padding and list termination	Functional capabilities
Parsing	Read 1 byte, done	Read type, read length, read (length-2) data bytes

The Type Field Encoding

The 1-byte type field is not merely an identifier—it's a carefully encoded structure with three distinct subfields:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| C |Class| Number                |
+---+---+---+---+---+---+---+---+
|1b | 2b |      5 bits           |

Bit 0 - Copy Flag (C):

0: Option is NOT copied to all fragments during fragmentation
1: Option IS copied to every fragment

Bits 1-2 - Option Class:

00 (0): Control options
10 (2): Debugging and measurement options
01 (1) and 11 (3): Reserved for future use

Bits 3-7 - Option Number:

Identifies the specific option within its class
Provides space for 32 options per class

Understanding the Copy Flag

Type Field Encoding for Common Options
Option Name	Type Value (Binary)	Copy	Class	Number	Decimal
End of Options List	00000000	0	00	00000	0
No Operation	00000001	0	00	00001	1
Record Route	00000111	0	00	00111	7
Timestamp	01000100	0	10	00100	68
Loose Source Routing	10000011	1	00	00011	131
Strict Source Routing	10001001	1	00	01001	137

Decoding Example:

Let's decode option type value 137 (0x89 in hexadecimal):

Binary representation: 10001001
Copy flag (bit 0): 1 → Option is copied to all fragments
Class (bits 1-2): 00 → Control option
Number (bits 3-7): 01001 = 9 → Strict Source Routing

This encoding tells us that Strict Source Routing must be present in every fragment because routers along the path need routing instructions for each fragment they receive.

The Length Field Semantics

The length field in multi-byte options deserves careful attention because its interpretation differs from some other protocols.

Critical Point: Length Includes Type and Length Bytes

The length value indicates the total size of the option, including:

1 byte for the type field
1 byte for the length field itself
Variable bytes for the data

Therefore:

Minimum valid length is 2 (type + length, no data)
Data payload size = Length - 2

Converting Mermaid diagram...

Common Implementation Mistake

option_parsing.c
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
// INCORRECT: Common mistake in option parsing
void parse_option_wrong(uint8_t *option) {
    uint8_t type = option[0];
    uint8_t length = option[1];
    // Bug: Reading 'length' bytes of data reads 2 extra bytes!
    uint8_t data[length];
    memcpy(data, &option[2], length);  // WRONG!
}
 
// CORRECT: Proper option parsing
void parse_option_correct(uint8_t *option) {
    uint8_t type = option[0];
    uint8_t length = option[1];
    
    // Validate minimum length
    if (length < 2) {
        // Invalid option - handle error
        return;
    }
    
    // Data length is total length minus type and length bytes
    uint8_t data_length = length - 2;
    uint8_t data[data_length];
    memcpy(data, &option[2], data_length);  // CORRECT!
}

End of Options List (EOL) - Type 0

Key Characteristics:

Type: 0 (binary: 00000000)
Size: 1 byte
Copy flag: 0 (not copied during fragmentation)
Behavior: Terminates option parsing immediately

Usage Rules:

EOL is only required if options don't naturally end at a 32-bit boundary
After EOL, parsers ignore remaining bytes (treated as padding)
Unlike NOP, EOL indicates "no more options exist" rather than "skip this byte"

EOL vs NOP

Converting Mermaid diagram...

No Operation (NOP) - Type 1

The No Operation (NOP) option, type value 1, is a single-byte padding option used to align subsequent options on specific boundaries.

Key Characteristics:

Type: 1 (binary: 00000001)
Size: 1 byte
Copy flag: 0 (not copied during fragmentation)
Behavior: Parser skips this byte and continues processing

Primary Uses:

Alignment: Align multi-byte options to 16-bit or 32-bit boundaries for efficient memory access
Separation: Insert visual separation between options in debugging output
Placeholder: Reserve space that might be filled later by intermediate devices

nop_usage_example.txt
Example: Using NOP for 32-bit alignment
 
Options area structure:
Offset 0: Type = 1 (NOP) - 1 byte padding
Offset 1: Type = 1 (NOP) - 1 byte padding  
Offset 2: Type = 1 (NOP) - 1 byte padding
Offset 3: Type = 68 (Timestamp) 
Offset 4: Length = 12
Offset 5-14: Timestamp data
 
Without NOPs, Timestamp would start at offset 0.
With NOPs, Timestamp is aligned to 32-bit boundary (offset 3).
 
Benefits:
- Faster memory access on aligned architectures
- Cleaner debugging display
- Predictable option positions

Alignment Best Practices

Option Processing by Routers

Processing Flow:

Detection: Router checks IHL field; if > 5, options are present
Parsing: Options area is scanned byte-by-byte
Interpretation: Each option is processed according to its type
Action: Router performs required actions (record address, follow route, etc.)
Forwarding: Packet continues with potentially modified options

Converting Mermaid diagram...

Performance Impact

Security Considerations:

IPv4 options have significant security implications:

Source Routing Abuse: Attackers can bypass firewall rules by specifying routes that avoid security devices
Reconnaissance: Record Route and Timestamp reveal network topology information
DoS Potential: Complex options processing can exhaust router CPU
Filtering Policies: Many enterprise and ISP networks now block packets with options

RFC 7126 (Internet Architecture Board) recommends filtering source-routed packets at network borders.

Padding and 32-bit Alignment

The IPv4 header must always be a multiple of 32 bits (4 bytes). Since options have variable lengths, padding is required when options don't naturally end on a 32-bit boundary.

Padding Rules:

The options area must end on a 32-bit boundary
Padding is added after the last option (or after EOL)
Padding bytes are zero-filled
The IHL field reflects the total padded header size

Calculation:

Total options size = Sum of all option lengths
Padding needed = (4 - (options size mod 4)) mod 4
Final header size = 20 + options size + padding
IHL = Final header size / 4

Padding Examples
Options Total	Mod 4	Padding Needed	Final Options Area	IHL Value
3 bytes	3	1 byte	4 bytes	6
7 bytes	3	1 byte	8 bytes	7
8 bytes	0	0 bytes	8 bytes	7
15 bytes	3	1 byte	16 bytes	9
39 bytes	3	1 byte	40 bytes	15

padding_calculation.py
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
def calculate_ipv4_header_size(options_bytes: int) -> dict:
    """
    Calculate IPv4 header size with padding for options.
    
    Args:
        options_bytes: Total size of all options (without padding)
    
    Returns:
        Dictionary with padding details
    """
    if options_bytes > 40:
        raise ValueError("Options cannot exceed 40 bytes")
    
    # Calculate padding needed for 32-bit alignment
    remainder = options_bytes % 4
    padding = (4 - remainder) % 4  # This handles the 0 case correctly
    
    # Calculate final sizes
    options_area = options_bytes + padding
    header_size = 20 + options_area
    ihl = header_size // 4
    
    return {
        "options_bytes": options_bytes,
        "padding_bytes": padding,
        "options_area_total": options_area,
        "header_size": header_size,
        "ihl_value": ihl
    }
 
# Examples
print(calculate_ipv4_header_size(7))
# Output: {'options_bytes': 7, 'padding_bytes': 1, 
#          'options_area_total': 8, 'header_size': 28, 'ihl_value': 7}
 
print(calculate_ipv4_header_size(39))
# Output: {'options_bytes': 39, 'padding_bytes': 1,
#          'options_area_total': 40, 'header_size': 60, 'ihl_value': 15}

Complete Options Parsing Algorithm

Let's consolidate everything into a complete algorithm for parsing IPv4 options. This algorithm handles all option types, validates lengths, and properly terminates on EOL or area exhaustion.

ipv4_options_parser.c
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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
#include <stdint.h>
#include <stdbool.h>
 
#define OPT_EOL     0    // End of Options List
#define OPT_NOP     1    // No Operation
#define OPT_RR      7    // Record Route
#define OPT_TS      68   // Timestamp (0x44)
#define OPT_LSR     131  // Loose Source Routing (0x83)
#define OPT_SSR     137  // Strict Source Routing (0x89)
 
typedef struct {
    uint8_t type;
    uint8_t length;       // Total length (includes type and length bytes)
    uint8_t *data;        // Pointer to option data
    uint8_t data_length;  // Actual data length (length - 2)
} IPv4Option;
 
/**
 * Parse IPv4 options from header
 * 
 * @param options_start  Pointer to start of options area
 * @param options_length Length of options area (from IHL: (IHL - 5) * 4)
 * @param parsed_options Array to hold parsed options
 * @param max_options    Maximum options to parse
 * @return Number of options parsed, or -1 on error
 */
int parse_ipv4_options(
    uint8_t *options_start,
    int options_length,
    IPv4Option *parsed_options,
    int max_options
) {
    int offset = 0;
    int count = 0;
    
    while (offset < options_length && count < max_options) {
        uint8_t type = options_start[offset];
        
        // Case 1: End of Options List
        if (type == OPT_EOL) {
            // Parsing complete - remaining bytes are padding
            break;
        }
        
        // Case 2: No Operation (single-byte)
        if (type == OPT_NOP) {
            parsed_options[count].type = OPT_NOP;
            parsed_options[count].length = 1;
            parsed_options[count].data = NULL;
            parsed_options[count].data_length = 0;
            offset += 1;
            count++;
            continue;
        }
        
        // Case 3: Multi-byte option (TLV format)
        // Ensure we have room for length byte
        if (offset + 1 >= options_length) {
            return -1;  // Truncated option
        }
        
        uint8_t length = options_start[offset + 1];
        
        // Validate length
        if (length < 2) {
            return -1;  // Invalid: length must include type and length bytes
        }
        
        if (offset + length > options_length) {
            return -1;  // Option extends beyond options area
        }
        
        // Parse the option
        parsed_options[count].type = type;
        parsed_options[count].length = length;
        parsed_options[count].data_length = length - 2;
        parsed_options[count].data = (length > 2) ? 
            &options_start[offset + 2] : NULL;
        
        offset += length;
        count++;
    }
    
    return count;
}
 
// Example usage
void process_packet(uint8_t *ip_header) {
    uint8_t ihl = ip_header[0] & 0x0F;  // Extract IHL from first byte
    
    if (ihl < 5) {
        // Invalid header
        return;
    }
    
    if (ihl == 5) {
        // No options present
        return;
    }
    
    int options_length = (ihl - 5) * 4;
    uint8_t *options_start = ip_header + 20;  // Options start after fixed header
    
    IPv4Option options[10];  // Support up to 10 options
    int num_options = parse_ipv4_options(
        options_start, options_length, options, 10
    );
    
    if (num_options < 0) {
        // Parse error - malformed options
        return;
    }
    
    // Process each option
    for (int i = 0; i < num_options; i++) {
        switch (options[i].type) {
            case OPT_RR:
                // Handle Record Route
                break;
            case OPT_TS:
                // Handle Timestamp
                break;
            case OPT_LSR:
            case OPT_SSR:
                // Handle Source Routing
                break;
        }
    }
}

Summary: IPv4 Options Format

We've covered the complete structure and semantics of IPv4 options. Let's consolidate the key points:

Key Takeaways

•Options are variable-length header extensions — Maximum 40 bytes, indicated by IHL values 6-15
•Two option formats exist — Single-byte (EOL, NOP) and multi-byte (TLV structure)
•Type field is encoded — Contains copy flag, option class, and option number in a single byte
•Length includes all bytes — The length field counts type, length, and data bytes together
•EOL terminates parsing — Type 0 signals absolute end of options area
•NOP provides alignment — Type 1 allows padding for boundary alignment
•32-bit alignment required — Options area must be padded to 4-byte boundary
•Router performance impact — Options force slow-path processing and may be filtered

What's Next:

Page Complete

1 / 5