Computer NetworksTTL and Protocol

TTL and Protocol Fields in IPv4

LevelIntermediate

Duration90 mins

TopicTTL and Protocol

3 / 5

Protocol Field

The Multiplexing Key of IP

When a network interface card receives an IP packet, the kernel faces a critical question: Which upper-layer protocol should handle this data? The packet might contain a TCP segment destined for a web server, a UDP datagram for a DNS resolver, an ICMP echo request for the ping utility, or any of dozens of other protocol units.

Without a reliable mechanism to identify the payload type, the IP layer would have no way to deliver packets to the correct protocol handler. The result would be chaos—TCP segments interpreted as ICMP messages, UDP datagrams fed to ESP decryption, and complete communication failure.

The Protocol field is the IPv4 header's solution to this demultiplexing challenge. This 8-bit field contains a standardized number identifying the upper-layer protocol, allowing the receiving IP implementation to route the payload to the correct handler. It's the reason your web browser's TCP connections coexist seamlessly with your DNS client's UDP queries and your operating system's ICMP diagnostics—all traversing the same network interfaces and IP addresses.

As a Principal Engineer, understanding the Protocol field is essential for debugging connection issues, implementing custom protocols, understanding firewall rules, and analyzing packet captures. This page provides the comprehensive foundation you need.

What You Will Learn

By the end of this page, you will understand the Protocol field's position in the IPv4 header, IANA protocol number assignments, the demultiplexing process, common protocol numbers, and how the Protocol field interacts with firewalls, NAT, and packet classification.

Field Structure and Header Location

The Protocol field occupies 8 bits (1 byte) at a fixed position immediately following the Time to Live (TTL) field in the IPv4 header. Its position is constant regardless of IP options or other header variations.

Protocol Field Position in IPv4 Header
Byte Offset	Bit Range	Field Name	Size
0	0-7	Version + IHL	8 bits
1	8-15	Type of Service (DSCP/ECN)	8 bits
2-3	16-31	Total Length	16 bits
4-5	32-47	Identification	16 bits
6-7	48-63	Flags + Fragment Offset	16 bits
8	64-71	Time to Live (TTL)	8 bits
9	72-79	Protocol	8 bits
10-11	80-95	Header Checksum	16 bits
12-15	96-127	Source Address	32 bits
16-19	128-159	Destination Address	32 bits

Value Range:

As an 8-bit unsigned integer, the Protocol field can represent values from 0 to 255. These values are assigned and maintained by IANA (Internet Assigned Numbers Authority) in the "Assigned Internet Protocol Numbers" registry.

Important Characteristics:

Fixed Position: Byte 9 (0-indexed) in every IPv4 packet, regardless of options
Mandatory Field: Cannot be omitted or extended
One Protocol Only: Each IP packet carries exactly one upper-layer protocol
No Chaining: Unlike IPv6 extension headers, IPv4 Protocol identifies only one next header

protocol-field-location.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
# Example IPv4 header in hexadecimal (20 bytes, no options)
45 00 00 54 1c 46 40 00 40 01 b1 e6 c0 a8 01 64 08 08 08 08
                              ^^
                              |
                              Protocol field (byte 9)
                              
# Breakdown:
45          Version (4) + IHL (5) = 20 bytes header
00          Type of Service
00 54       Total Length = 84 bytes
1c 46       Identification
40 00       Flags + Fragment Offset (DF set)
40          TTL = 64
01          Protocol = 1 (ICMP) <-- HERE
b1 e6       Header Checksum
c0 a8 01 64 Source IP: 192.168.1.100
08 08 08 08 Destination IP: 8.8.8.8
 
# Common protocol values in hex:
# 0x01 = 1 = ICMP
# 0x06 = 6 = TCP
# 0x11 = 17 = UDP
# 0x32 = 50 = ESP (IPsec)
# 0x33 = 51 = AH (IPsec)
# 0x59 = 89 = OSPF

Quick Protocol Recognition

In packet captures, memorize: 01=ICMP, 06=TCP, 11=UDP (hex). When you see byte 9 of an IPv4 header, you can instantly identify the protocol. Combined with TTL (byte 8), these two bytes tell you the packet's OS family and transport protocol at a glance.

IANA Protocol Number Registry

The Internet Assigned Numbers Authority (IANA) maintains the authoritative registry of protocol numbers. This registry has existed since the earliest days of IP and continues to be updated as new protocols are standardized.

Registry Organization:

The 256 possible protocol values are organized into several categories:

Protocol Number Categories
Range	Category	Assignment Method
0	Reserved (HOPOPT)	IPv6 Hop-by-Hop Option
1-60	Well-known protocols	Standards Action required
61	Any host internal protocol	Local use, no IANA assignment
62-134	Standardized protocols	Standards Action or IESG Approval
135-252	Unassigned	Available for future allocation
253-254	Experimental	RFC 3692 experimentation
255	Reserved	Reserved for future use

Complete List of Common Protocol Numbers:

The following table covers the most frequently encountered protocol numbers in real-world networks:

Essential Protocol Numbers
Number	Hex	Abbreviation	Full Name	RFC
0	0x00	HOPOPT	IPv6 Hop-by-Hop Option	RFC 8200
1	0x01	ICMP	Internet Control Message Protocol	RFC 792
2	0x02	IGMP	Internet Group Management Protocol	RFC 1112
4	0x04	IP-in-IP	IP in IP (encapsulation)	RFC 2003
6	0x06	TCP	Transmission Control Protocol	RFC 793
8	0x08	EGP	Exterior Gateway Protocol	RFC 904
17	0x11	UDP	User Datagram Protocol	RFC 768
41	0x29	IPv6	IPv6 Encapsulation	RFC 2473
43	0x2B	IPv6-Route	Routing Header for IPv6	RFC 8200
44	0x2C	IPv6-Frag	Fragment Header for IPv6	RFC 8200
47	0x2F	GRE	Generic Routing Encapsulation	RFC 2784
50	0x32	ESP	Encapsulating Security Payload	RFC 4303
51	0x33	AH	Authentication Header	RFC 4302
58	0x3A	ICMPv6	ICMP for IPv6	RFC 4443
59	0x3B	No Next	No Next Header for IPv6	RFC 8200
89	0x59	OSPF	Open Shortest Path First	RFC 2328
103	0x67	PIM	Protocol Independent Multicast	RFC 7761
112	0x70	VRRP	Virtual Router Redundancy Protocol	RFC 5798
115	0x73	L2TP	Layer Two Tunneling Protocol	RFC 3931
132	0x84	SCTP	Stream Control Transmission Protocol	RFC 4960
136	0x88	UDPLite	UDP-Lite	RFC 3828
137	0x89	MPLS-IP	MPLS-in-IP	RFC 4023

IPv6 Relationship

IPv6 uses the same protocol number space but calls it the 'Next Header' field. The values are identical—TCP is still 6, UDP is still 17. This compatibility was intentional to ease transition between IP versions.

Core Protocol Numbers in Detail

Most network traffic uses just a handful of protocol numbers. Understanding these core protocols and their characteristics is essential for network engineering.

Internet Control Message Protocol (Protocol 1)

ICMP is the network layer's signaling protocol, used for error reporting and operational queries.

Key Characteristics:

Not a transport protocol: ICMP doesn't carry application data
Essential for diagnostics: Enables ping, traceroute, path MTU discovery
Integral to IP operation: Error messages (destination unreachable, TTL exceeded) use ICMP
Often filtered by firewalls: Security concerns lead to partial ICMP blocking

Common ICMP Message Types:

Type 0/8: Echo Reply/Request (ping)
Type 3: Destination Unreachable
Type 11: Time Exceeded (traceroute)
Type 5: Redirect

Security Note: ICMP can be abused for covert channels and smurf attacks. However, completely blocking ICMP breaks path MTU discovery and makes troubleshooting nearly impossible.

icmp-packet-example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# ICMP Echo Request (ping) packet structure
# IP Header with Protocol=1, followed by ICMP header
 
IP Header (Protocol=1):
45 00 00 54 12 34 40 00 40 01 xx xx c0 a8 01 01 08 08 08 08
                        ^^ Protocol = 0x01 = ICMP
 
ICMP Header:
08 00 xx xx 00 01 00 01 ...
^^       
Type=8 (Echo Request)
 
# ICMP is special: no ports, just Type and Code
# Filtering must use Type/Code values, not port numbers

The Demultiplexing Process

When an IP packet arrives at a host, the kernel must route the payload to the correct protocol handler. This process, called demultiplexing, uses the Protocol field as the primary key.

Converting Mermaid diagram...

Demultiplexing Layers:

The demultiplexing process operates at multiple layers, each using different identifiers:

Layer 2 (Data Link): EtherType field determines if payload is IPv4 (0x0800), IPv6 (0x86DD), ARP (0x0806), etc.
Layer 3 (Network): Protocol field determines upper-layer handler (TCP=6, UDP=17, ICMP=1, etc.)
Layer 4 (Transport): Port numbers route to specific applications (HTTP=80, DNS=53, SSH=22, etc.)

This hierarchical demultiplexing allows multiple protocols and applications to share a single network connection.

demultiplexing-kernel.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
/*
 * Simplified Linux kernel IPv4 receive path
 * Demonstrates protocol demultiplexing
 */
 
/* Protocol handler registration (simplified) */
static struct net_protocol tcp_protocol = {
    .handler     = tcp_v4_rcv,
    .protocol    = IPPROTO_TCP,  /* 6 */
};
 
static struct net_protocol udp_protocol = {
    .handler     = udp_rcv,
    .protocol    = IPPROTO_UDP,  /* 17 */
};
 
static struct net_protocol icmp_protocol = {
    .handler     = icmp_rcv,
    .protocol    = IPPROTO_ICMP, /* 1 */
};
 
/* Main IP receive function (simplified) */
int ip_local_deliver_finish(struct sk_buff *skb) {
    struct iphdr *iph = ip_hdr(skb);
    int protocol = iph->protocol;
    struct net_protocol *ipprot;
    
    /* Look up handler for this protocol number */
    ipprot = protocol_table[protocol];
    
    if (ipprot) {
        /* Call the appropriate handler */
        return ipprot->handler(skb);  /* tcp_v4_rcv, udp_rcv, etc. */
    } else {
        /* No handler registered - drop packet */
        kfree_skb(skb);
        return -ENOENT;
    }
}
 
/* Protocol numbers from kernel headers */
#define IPPROTO_ICMP     1
#define IPPROTO_TCP      6
#define IPPROTO_UDP      17
#define IPPROTO_GRE      47
#define IPPROTO_ESP      50
#define IPPROTO_AH       51
#define IPPROTO_OSPF     89
#define IPPROTO_SCTP     132

Raw Sockets and Custom Protocols

Applications can receive raw IP packets using raw sockets, filtering by protocol number. This is how custom protocol implementations work—they register interest in a specific protocol number and receive all matching packets directly, bypassing the kernel's normal transport handlers.

Protocol Field in Firewalls and NAT

Firewalls and NAT devices use the Protocol field extensively for packet classification, filtering, and connection tracking. Understanding this interaction is critical for security policy design.

Firewall Rule Matching:

Most firewalls allow rules based on the Protocol field, often using protocol names or numbers:

firewall-protocol-rules.sh

# Filter by protocol number/name
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
 
# Using protocol number directly
iptables -A INPUT -p 47 -j ACCEPT  # GRE (protocol 47)
iptables -A INPUT -p 50 -j ACCEPT  # ESP (protocol 50)
iptables -A INPUT -p 89 -j ACCEPT  # OSPF (protocol 89)
 
# Block specific protocol
iptables -A INPUT -p gre -j DROP   # Block all GRE tunnels
 
# Match TCP states (requires protocol context)
iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# View protocols in /etc/protocols
cat /etc/protocols | head -20
# ip      0       IP              # internet protocol, pseudo protocol number
# icmp    1       ICMP            # internet control message protocol
# igmp    2       IGMP            # Internet Group Management
# tcp     6       TCP             # transmission control protocol
# udp     17      UDP             # user datagram protocol

NAT and Protocol Awareness:

NAT devices must understand protocol formats to rewrite addresses correctly:

TCP/UDP (6/17): NAT rewrites IP addresses AND ports. The protocol field tells NAT to look for port numbers in the transport header.
ICMP (1): NAT uses the Identifier field in Echo Request/Reply as a pseudo-port. Error messages require parsing embedded original packet headers.
GRE (47): No ports available. NAT must use GRE Key field or cannot distinguish multiple GRE sessions. Many NATs cannot handle multiple GRE tunnels.
ESP (50): No ports. NAT uses SPI (Security Parameter Index) for session tracking. NAT-T encapsulates ESP in UDP to restore port-based NAT.

NAT Limitations for Non-TCP/UDP Protocols

Protocols without port numbers (GRE, ESP, AH, OSPF, SCTP) often fail through NAT. Only one session per unique external IP can work, or special NAT handling (NAT-T for IPsec) must be used. This is a fundamental limitation of NAT architecture.

Protocol Classification for QoS

Quality of Service (QoS) implementations often use the Protocol field to classify traffic and apply appropriate treatment policies.

Protocol-Based QoS Classification
Protocol	Number	Typical QoS Treatment	Rationale
OSPF	89	Highest priority (EF)	Routing protocol stability critical
VRRP	112	Highest priority (EF)	Gateway failover must not be delayed
PIM	103	High priority	Multicast routing signaling
ICMP	1	Medium-high priority	Network diagnostics, PMTUD
TCP	6	Standard (varies by port)	Web, email, file transfer
UDP	17	Varies by application	DNS=high, streaming=medium, bulk=low
GRE	47	Inherit from inner packet	Tunnel should preserve inner QoS
ESP	50	Preserve inner DSCP	VPN should maintain service quality

protocol-based-qos.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
# Cisco IOS: QoS policy based on protocol
 
class-map match-any ROUTING-PROTOCOLS
 match protocol ospf
 match protocol eigrp
 
class-map match-any NETWORK-CONTROL
 match protocol icmp
 match protocol igmp
 match protocol vrrp
 
class-map match-any VPN-TRAFFIC
 match protocol esp
 match protocol gre
 
policy-map WAN-QOS
 class ROUTING-PROTOCOLS
   priority percent 5
   set dscp ef
 class NETWORK-CONTROL
   bandwidth percent 5
   set dscp cs6
 class VPN-TRAFFIC
   bandwidth percent 40
   ! Preserve inner packet DSCP for ESP
 class class-default
   fair-queue
 
interface GigabitEthernet0/1
 service-policy output WAN-QOS

Protocol vs. Port-Based Classification

Protocol-based QoS is coarse but reliable. Port-based classification is finer-grained but requires deep packet inspection for TCP/UDP. Routing protocols (OSPF, BGP, EIGRP) use distinct protocol numbers, making them easy to prioritize without port analysis.

Summary: Protocol Field

The Protocol field is the IPv4 header's multiplexing mechanism, enabling multiple upper-layer protocols to share a single IP infrastructure. Let's consolidate the key concepts:

Key Takeaways

•8-bit identifier at byte 9 — The Protocol field is a fixed-position, 8-bit value identifying the encapsulated upper-layer protocol.
•IANA-assigned numbers — Protocol numbers are standardized: 1=ICMP, 6=TCP, 17=UDP, 47=GRE, 50=ESP, 89=OSPF, and 100+ more.
•Enables demultiplexing — The kernel uses Protocol to route incoming packets to the correct handler (TCP stack, UDP stack, etc.).
•Same space as IPv6 Next Header — Protocol numbers are shared between IPv4 and IPv6 for compatibility.
•Critical for firewalls — Security policies match on Protocol to allow/deny specific traffic types.
•NAT complexity — Only TCP and UDP have ports for NAT translation. Other protocols require special handling or encapsulation.

What's Next:

Now that you understand the Protocol field, the next page explores the Header Checksum—the IPv4 header's integrity verification mechanism. You'll learn how the checksum is calculated, why it must be recalculated at every hop, and how hardware accelerates this critical operation.

Page Complete

You now have a comprehensive understanding of the Protocol field—its structure, common values, demultiplexing role, and interaction with firewalls and NAT. This knowledge is essential for packet analysis, security policy design, and understanding network protocol architecture.

3 / 5

Loading learning content...

Computer NetworksTTL and Protocol

TTL and Protocol Fields in IPv4

LevelIntermediate

Duration90 mins

TopicTTL and Protocol

3 / 5

Protocol Field

The Multiplexing Key of IP

What You Will Learn

Field Structure and Header Location

Protocol Field Position in IPv4 Header
Byte Offset	Bit Range	Field Name	Size
0	0-7	Version + IHL	8 bits
1	8-15	Type of Service (DSCP/ECN)	8 bits
2-3	16-31	Total Length	16 bits
4-5	32-47	Identification	16 bits
6-7	48-63	Flags + Fragment Offset	16 bits
8	64-71	Time to Live (TTL)	8 bits
9	72-79	Protocol	8 bits
10-11	80-95	Header Checksum	16 bits
12-15	96-127	Source Address	32 bits
16-19	128-159	Destination Address	32 bits

Value Range:

Important Characteristics:

Fixed Position: Byte 9 (0-indexed) in every IPv4 packet, regardless of options
Mandatory Field: Cannot be omitted or extended
One Protocol Only: Each IP packet carries exactly one upper-layer protocol
No Chaining: Unlike IPv6 extension headers, IPv4 Protocol identifies only one next header

protocol-field-location.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
# Example IPv4 header in hexadecimal (20 bytes, no options)
45 00 00 54 1c 46 40 00 40 01 b1 e6 c0 a8 01 64 08 08 08 08
                              ^^
                              |
                              Protocol field (byte 9)
                              
# Breakdown:
45          Version (4) + IHL (5) = 20 bytes header
00          Type of Service
00 54       Total Length = 84 bytes
1c 46       Identification
40 00       Flags + Fragment Offset (DF set)
40          TTL = 64
01          Protocol = 1 (ICMP) <-- HERE
b1 e6       Header Checksum
c0 a8 01 64 Source IP: 192.168.1.100
08 08 08 08 Destination IP: 8.8.8.8
 
# Common protocol values in hex:
# 0x01 = 1 = ICMP
# 0x06 = 6 = TCP
# 0x11 = 17 = UDP
# 0x32 = 50 = ESP (IPsec)
# 0x33 = 51 = AH (IPsec)
# 0x59 = 89 = OSPF

Quick Protocol Recognition

IANA Protocol Number Registry

Registry Organization:

The 256 possible protocol values are organized into several categories:

Protocol Number Categories
Range	Category	Assignment Method
0	Reserved (HOPOPT)	IPv6 Hop-by-Hop Option
1-60	Well-known protocols	Standards Action required
61	Any host internal protocol	Local use, no IANA assignment
62-134	Standardized protocols	Standards Action or IESG Approval
135-252	Unassigned	Available for future allocation
253-254	Experimental	RFC 3692 experimentation
255	Reserved	Reserved for future use

Complete List of Common Protocol Numbers:

The following table covers the most frequently encountered protocol numbers in real-world networks:

Essential Protocol Numbers
Number	Hex	Abbreviation	Full Name	RFC
0	0x00	HOPOPT	IPv6 Hop-by-Hop Option	RFC 8200
1	0x01	ICMP	Internet Control Message Protocol	RFC 792
2	0x02	IGMP	Internet Group Management Protocol	RFC 1112
4	0x04	IP-in-IP	IP in IP (encapsulation)	RFC 2003
6	0x06	TCP	Transmission Control Protocol	RFC 793
8	0x08	EGP	Exterior Gateway Protocol	RFC 904
17	0x11	UDP	User Datagram Protocol	RFC 768
41	0x29	IPv6	IPv6 Encapsulation	RFC 2473
43	0x2B	IPv6-Route	Routing Header for IPv6	RFC 8200
44	0x2C	IPv6-Frag	Fragment Header for IPv6	RFC 8200
47	0x2F	GRE	Generic Routing Encapsulation	RFC 2784
50	0x32	ESP	Encapsulating Security Payload	RFC 4303
51	0x33	AH	Authentication Header	RFC 4302
58	0x3A	ICMPv6	ICMP for IPv6	RFC 4443
59	0x3B	No Next	No Next Header for IPv6	RFC 8200
89	0x59	OSPF	Open Shortest Path First	RFC 2328
103	0x67	PIM	Protocol Independent Multicast	RFC 7761
112	0x70	VRRP	Virtual Router Redundancy Protocol	RFC 5798
115	0x73	L2TP	Layer Two Tunneling Protocol	RFC 3931
132	0x84	SCTP	Stream Control Transmission Protocol	RFC 4960
136	0x88	UDPLite	UDP-Lite	RFC 3828
137	0x89	MPLS-IP	MPLS-in-IP	RFC 4023

IPv6 Relationship

Core Protocol Numbers in Detail

Most network traffic uses just a handful of protocol numbers. Understanding these core protocols and their characteristics is essential for network engineering.

Internet Control Message Protocol (Protocol 1)

ICMP is the network layer's signaling protocol, used for error reporting and operational queries.

Key Characteristics:

Not a transport protocol: ICMP doesn't carry application data
Essential for diagnostics: Enables ping, traceroute, path MTU discovery
Integral to IP operation: Error messages (destination unreachable, TTL exceeded) use ICMP
Often filtered by firewalls: Security concerns lead to partial ICMP blocking

Common ICMP Message Types:

Type 0/8: Echo Reply/Request (ping)
Type 3: Destination Unreachable
Type 11: Time Exceeded (traceroute)
Type 5: Redirect

Security Note: ICMP can be abused for covert channels and smurf attacks. However, completely blocking ICMP breaks path MTU discovery and makes troubleshooting nearly impossible.

icmp-packet-example.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# ICMP Echo Request (ping) packet structure
# IP Header with Protocol=1, followed by ICMP header
 
IP Header (Protocol=1):
45 00 00 54 12 34 40 00 40 01 xx xx c0 a8 01 01 08 08 08 08
                        ^^ Protocol = 0x01 = ICMP
 
ICMP Header:
08 00 xx xx 00 01 00 01 ...
^^       
Type=8 (Echo Request)
 
# ICMP is special: no ports, just Type and Code
# Filtering must use Type/Code values, not port numbers

The Demultiplexing Process

When an IP packet arrives at a host, the kernel must route the payload to the correct protocol handler. This process, called demultiplexing, uses the Protocol field as the primary key.

Converting Mermaid diagram...

Demultiplexing Layers:

The demultiplexing process operates at multiple layers, each using different identifiers:

Layer 2 (Data Link): EtherType field determines if payload is IPv4 (0x0800), IPv6 (0x86DD), ARP (0x0806), etc.
Layer 3 (Network): Protocol field determines upper-layer handler (TCP=6, UDP=17, ICMP=1, etc.)
Layer 4 (Transport): Port numbers route to specific applications (HTTP=80, DNS=53, SSH=22, etc.)

This hierarchical demultiplexing allows multiple protocols and applications to share a single network connection.

demultiplexing-kernel.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
/*
 * Simplified Linux kernel IPv4 receive path
 * Demonstrates protocol demultiplexing
 */
 
/* Protocol handler registration (simplified) */
static struct net_protocol tcp_protocol = {
    .handler     = tcp_v4_rcv,
    .protocol    = IPPROTO_TCP,  /* 6 */
};
 
static struct net_protocol udp_protocol = {
    .handler     = udp_rcv,
    .protocol    = IPPROTO_UDP,  /* 17 */
};
 
static struct net_protocol icmp_protocol = {
    .handler     = icmp_rcv,
    .protocol    = IPPROTO_ICMP, /* 1 */
};
 
/* Main IP receive function (simplified) */
int ip_local_deliver_finish(struct sk_buff *skb) {
    struct iphdr *iph = ip_hdr(skb);
    int protocol = iph->protocol;
    struct net_protocol *ipprot;
    
    /* Look up handler for this protocol number */
    ipprot = protocol_table[protocol];
    
    if (ipprot) {
        /* Call the appropriate handler */
        return ipprot->handler(skb);  /* tcp_v4_rcv, udp_rcv, etc. */
    } else {
        /* No handler registered - drop packet */
        kfree_skb(skb);
        return -ENOENT;
    }
}
 
/* Protocol numbers from kernel headers */
#define IPPROTO_ICMP     1
#define IPPROTO_TCP      6
#define IPPROTO_UDP      17
#define IPPROTO_GRE      47
#define IPPROTO_ESP      50
#define IPPROTO_AH       51
#define IPPROTO_OSPF     89
#define IPPROTO_SCTP     132

Raw Sockets and Custom Protocols

Protocol Field in Firewalls and NAT

Firewalls and NAT devices use the Protocol field extensively for packet classification, filtering, and connection tracking. Understanding this interaction is critical for security policy design.

Firewall Rule Matching:

Most firewalls allow rules based on the Protocol field, often using protocol names or numbers:

firewall-protocol-rules.sh

# Filter by protocol number/name
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
 
# Using protocol number directly
iptables -A INPUT -p 47 -j ACCEPT  # GRE (protocol 47)
iptables -A INPUT -p 50 -j ACCEPT  # ESP (protocol 50)
iptables -A INPUT -p 89 -j ACCEPT  # OSPF (protocol 89)
 
# Block specific protocol
iptables -A INPUT -p gre -j DROP   # Block all GRE tunnels
 
# Match TCP states (requires protocol context)
iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# View protocols in /etc/protocols
cat /etc/protocols | head -20
# ip      0       IP              # internet protocol, pseudo protocol number
# icmp    1       ICMP            # internet control message protocol
# igmp    2       IGMP            # Internet Group Management
# tcp     6       TCP             # transmission control protocol
# udp     17      UDP             # user datagram protocol

NAT and Protocol Awareness:

NAT devices must understand protocol formats to rewrite addresses correctly:

TCP/UDP (6/17): NAT rewrites IP addresses AND ports. The protocol field tells NAT to look for port numbers in the transport header.
ICMP (1): NAT uses the Identifier field in Echo Request/Reply as a pseudo-port. Error messages require parsing embedded original packet headers.
GRE (47): No ports available. NAT must use GRE Key field or cannot distinguish multiple GRE sessions. Many NATs cannot handle multiple GRE tunnels.
ESP (50): No ports. NAT uses SPI (Security Parameter Index) for session tracking. NAT-T encapsulates ESP in UDP to restore port-based NAT.

NAT Limitations for Non-TCP/UDP Protocols

Protocol Classification for QoS

Quality of Service (QoS) implementations often use the Protocol field to classify traffic and apply appropriate treatment policies.

Protocol-Based QoS Classification
Protocol	Number	Typical QoS Treatment	Rationale
OSPF	89	Highest priority (EF)	Routing protocol stability critical
VRRP	112	Highest priority (EF)	Gateway failover must not be delayed
PIM	103	High priority	Multicast routing signaling
ICMP	1	Medium-high priority	Network diagnostics, PMTUD
TCP	6	Standard (varies by port)	Web, email, file transfer
UDP	17	Varies by application	DNS=high, streaming=medium, bulk=low
GRE	47	Inherit from inner packet	Tunnel should preserve inner QoS
ESP	50	Preserve inner DSCP	VPN should maintain service quality

protocol-based-qos.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
# Cisco IOS: QoS policy based on protocol
 
class-map match-any ROUTING-PROTOCOLS
 match protocol ospf
 match protocol eigrp
 
class-map match-any NETWORK-CONTROL
 match protocol icmp
 match protocol igmp
 match protocol vrrp
 
class-map match-any VPN-TRAFFIC
 match protocol esp
 match protocol gre
 
policy-map WAN-QOS
 class ROUTING-PROTOCOLS
   priority percent 5
   set dscp ef
 class NETWORK-CONTROL
   bandwidth percent 5
   set dscp cs6
 class VPN-TRAFFIC
   bandwidth percent 40
   ! Preserve inner packet DSCP for ESP
 class class-default
   fair-queue
 
interface GigabitEthernet0/1
 service-policy output WAN-QOS

Protocol vs. Port-Based Classification

Summary: Protocol Field

The Protocol field is the IPv4 header's multiplexing mechanism, enabling multiple upper-layer protocols to share a single IP infrastructure. Let's consolidate the key concepts:

Key Takeaways

•8-bit identifier at byte 9 — The Protocol field is a fixed-position, 8-bit value identifying the encapsulated upper-layer protocol.
•IANA-assigned numbers — Protocol numbers are standardized: 1=ICMP, 6=TCP, 17=UDP, 47=GRE, 50=ESP, 89=OSPF, and 100+ more.
•Enables demultiplexing — The kernel uses Protocol to route incoming packets to the correct handler (TCP stack, UDP stack, etc.).
•Same space as IPv6 Next Header — Protocol numbers are shared between IPv4 and IPv6 for compatibility.
•Critical for firewalls — Security policies match on Protocol to allow/deny specific traffic types.
•NAT complexity — Only TCP and UDP have ports for NAT translation. Other protocols require special handling or encapsulation.

What's Next:

Page Complete

3 / 5