List of IP protocol numbers
List of IP protocol numbers
Main page
L

List of IP protocol numbers

logo
Community Hub0 subscribers
Read side by side
List of IP protocol numbers
View on Wikipedia
from Wikipedia

This is a list of the IP protocol numbers found in the 8-bit Protocol field of the IPv4 header and the 8-bit Next Header field of the IPv6 header. It is an identifier for the encapsulated protocol and determines the layout of the data that immediately follows the header. Because both fields are eight bits wide, the possible values are limited to the 256 values from 0 (0x00) to 255 (0xFF), of which just over half had been allocated as of 2025.

Protocol numbers are maintained and published by the Internet Assigned Numbers Authority (IANA).[1]

Hex Protocol Number Keyword Protocol References/RFC
0x00 0 HOPOPT IPv6 Hop-by-Hop Option RFC 8200
0x01 1 ICMP Internet Control Message Protocol RFC 792
0x02 2 IGMP Internet Group Management Protocol RFC 1112
0x03 3 GGP Gateway-to-Gateway Protocol RFC 823
0x04 4 IP-in-IP IP in IP (encapsulation) RFC 2003
0x05 5 ST Internet Stream Protocol RFC 1190, RFC 1819
0x06 6 TCP Transmission Control Protocol RFC 793
0x07 7 CBT Core-based trees RFC 2189
0x08 8 EGP Exterior Gateway Protocol RFC 888
0x09 9 IGP Interior gateway protocol (any private interior gateway, for example Cisco's IGRP)
0x0A 10 BBN-RCC-MON BBN RCC Monitoring
0x0B 11 NVP-II Network Voice Protocol RFC 741
0x0C 12 PUP Xerox PUP
0x0D 13 ARGUS ARGUS
0x0E 14 EMCON EMCON
0x0F 15 XNET Cross Net Debugger IEN 158[2]
0x10 16 CHAOS Chaos
0x11 17 UDP User Datagram Protocol RFC 768
0x12 18 MUX Multiplexing IEN 90[3]
0x13 19 DCN-MEAS DCN Measurement Subsystems
0x14 20 HMP Host Monitoring Protocol RFC 869
0x15 21 PRM Packet Radio Measurement
0x16 22 XNS-IDP XEROX NS IDP
0x17 23 TRUNK-1 Trunk-1
0x18 24 TRUNK-2 Trunk-2
0x19 25 LEAF-1 Leaf-1
0x1A 26 LEAF-2 Leaf-2
0x1B 27 RDP Reliable Data Protocol RFC 908
0x1C 28 IRTP Internet Reliable Transaction Protocol RFC 938
0x1D 29 ISO-TP4 ISO Transport Protocol Class 4 RFC 905
0x1E 30 NETBLT Bulk Data Transfer Protocol RFC 998
0x1F 31 MFE-NSP MFE Network Services Protocol
0x20 32 MERIT-INP MERIT Internodal Protocol
0x21 33 DCCP Datagram Congestion Control Protocol RFC 4340
0x22 34 3PC Third Party Connect Protocol
0x23 35 IDPR Inter-Domain Policy Routing Protocol RFC 1479
0x24 36 XTP Xpress Transport Protocol
0x25 37 DDP Datagram Delivery Protocol
0x26 38 IDPR-CMTP IDPR Control Message Transport Protocol
0x27 39 TP++ TP++ Transport Protocol
0x28 40 IL IL Transport Protocol
0x29 41 IPv6 IPv6 Encapsulation (6to4 and 6in4) RFC 2473
0x2A 42 SDRP Source Demand Routing Protocol RFC 1940
0x2B 43 IPv6-Route Routing Header for IPv6 RFC 8200
0x2C 44 IPv6-Frag Fragment Header for IPv6 RFC 8200
0x2D 45 IDRP Inter-Domain Routing Protocol
0x2E 46 RSVP Resource Reservation Protocol RFC 2205
0x2F 47 GRE Generic Routing Encapsulation RFC 2784, RFC 2890
0x30 48 DSR Dynamic Source Routing Protocol RFC 4728
0x31 49 BNA Burroughs Network Architecture
0x32 50 ESP Encapsulating Security Payload RFC 4303
0x33 51 AH Authentication Header RFC 4302
0x34 52 I-NLSP Integrated Net Layer Security Protocol TUBA
0x35 53 SwIPe SwIPe RFC 5237
0x36 54 NARP NBMA Address Resolution Protocol RFC 1735
0x37 55 MOBILE IP Mobility (Min Encap) RFC 2004
0x38 56 TLSP Transport Layer Security Protocol (using Kryptonet key management)
0x39 57 SKIP Simple Key-Management for Internet Protocol RFC 2356
0x3A 58 IPv6-ICMP ICMP for IPv6 RFC 4443, RFC 4884
0x3B 59 IPv6-NoNxt No Next Header for IPv6 RFC 8200
0x3C 60 IPv6-Opts Destination Options for IPv6 RFC 8200
0x3D 61 Any host internal protocol
0x3E 62 CFTP CFTP
0x3F 63 Any local network
0x40 64 SAT-EXPAK SATNET and Backroom EXPAK
0x41 65 KRYPTOLAN Kryptolan
0x42 66 RVD MIT Remote Virtual Disk Protocol
0x43 67 IPPC Internet Pluribus Packet Core
0x44 68 Any distributed file system
0x45 69 SAT-MON SATNET Monitoring
0x46 70 VISA VISA Protocol
0x47 71 IPCU Internet Packet Core Utility
0x48 72 CPNX Computer Protocol Network Executive
0x49 73 CPHB Computer Protocol Heart Beat
0x4A 74 WSN Wang Span Network
0x4B 75 PVP Packet Video Protocol
0x4C 76 BR-SAT-MON Backroom SATNET Monitoring
0x4D 77 SUN-ND SUN ND PROTOCOL-Temporary
0x4E 78 WB-MON WIDEBAND Monitoring
0x4F 79 WB-EXPAK WIDEBAND EXPAK
0x50 80 ISO-IP International Organization for Standardization Internet Protocol
0x51 81 VMTP Versatile Message Transaction Protocol RFC 1045
0x52 82 SECURE-VMTP Secure Versatile Message Transaction Protocol RFC 1045
0x53 83 VINES VINES
0x54 84 TTP TTP (Transaction Transport Protocol) (obsoleted March 2023)
0x54 84 IPTM Internet Protocol Traffic Manager
0x55 85 NSFNET-IGP NSFNET-IGP
0x56 86 DGP Dissimilar Gateway Protocol
0x57 87 TCF TCF
0x58 88 EIGRP EIGRP Informational RFC 7868
0x59 89 OSPF Open Shortest Path First RFC 2328
0x5A 90 Sprite-RPC Sprite RPC Protocol
0x5B 91 LARP Locus Address Resolution Protocol
0x5C 92 MTP Multicast Transport Protocol
0x5D 93 AX.25 AX.25
0x5E 94 OS KA9Q NOS compatible IP over IP tunneling
0x5F 95 MICP Mobile Internetworking Control Protocol
0x60 96 SCC-SP Semaphore Communications Sec. Pro
0x61 97 ETHERIP Ethernet-within-IP Encapsulation RFC 3378
0x62 98 ENCAP Encapsulation Header RFC 1241
0x63 99 Any private encryption scheme
0x64 100 GMTP GMTP
0x65 101 IFMP Ipsilon Flow Management Protocol
0x66 102 PNNI PNNI over IP
0x67 103 PIM Protocol Independent Multicast
0x68 104 ARIS IBM's ARIS (Aggregate Route IP Switching) Protocol
0x69 105 SCPS SCPS (Space Communications Protocol Standards) SCPS-TP[4]
0x6A 106 QNX QNX
0x6B 107 A/N Active Networks
0x6C 108 IPComp IP Payload Compression Protocol RFC 3173
0x6D 109 SNP Sitara Networks Protocol
0x6E 110 Compaq-Peer Compaq Peer Protocol
0x6F 111 IPX-in-IP IPX in IP
0x70 112 VRRP Virtual Router Redundancy Protocol, Common Address Redundancy Protocol (not IANA assigned) RFC 5798
0x71 113 PGM PGM Reliable Transport Protocol RFC 3208
0x72 114 Any 0-hop protocol
0x73 115 L2TP Layer Two Tunneling Protocol Version 3 RFC 3931
0x74 116 DDX D-II Data Exchange (DDX)
0x75 117 IATP Interactive Agent Transfer Protocol
0x76 118 STP Schedule Transfer Protocol
0x77 119 SRP SpectraLink Radio Protocol
0x78 120 UTI Universal Transport Interface Protocol
0x79 121 SMP Simple Message Protocol
0x7A 122 SM Simple Multicast Protocol draft-perlman-simple-multicast-03
0x7B 123 PTP Performance Transparency Protocol
0x7C 124 IS-IS over IPv4 Intermediate System to Intermediate System (IS-IS) Protocol over IPv4 RFC 1142 and RFC 1195
0x7D 125 FIRE Flexible Intra-AS Routing Environment
0x7E 126 CRTP Combat Radio Transport Protocol
0x7F 127 CRUDP Combat Radio User Datagram
0x80 128 SSCOPMCE Service-Specific Connection-Oriented Protocol in a Multilink and Connectionless Environment ITU-T Q.2111 (1999)
0x81 129 IPLT
0x82 130 SPS Secure Packet Shield
0x83 131 PIPE Private IP Encapsulation within IP Expired I-D draft-petri-mobileip-pipe-00.txt
0x84 132 SCTP Stream Control Transmission Protocol RFC 4960
0x85 133 FC Fibre Channel
0x86 134 RSVP-E2E-IGNORE Reservation Protocol (RSVP) End-to-End Ignore RFC 3175
0x87 135 Mobility Header Mobility Extension Header for IPv6 RFC 6275
0x88 136 UDPLite Lightweight User Datagram Protocol RFC 3828
0x89 137 MPLS-in-IP Multiprotocol Label Switching Encapsulated in IP RFC 4023, RFC 5332
0x8A 138 manet MANET Protocols RFC 5498
0x8B 139 HIP Host Identity Protocol RFC 5201
0x8C 140 Shim6 Site Multihoming by IPv6 Intermediation RFC 5533
0x8D 141 WESP Wrapped Encapsulating Security Payload RFC 5840
0x8E 142 ROHC Robust Header Compression RFC 5856
0x8F 143 Ethernet Segment Routing over IPv6 RFC 8986
0x90 144 AGGFRAG AGGFRAG Encapsulation Payload for ESP RFC 9347
0x91 145 NSH Network Service Header draft-ietf-spring-nsh-sr
0x92 146 Homa Homa transport protocol Homa research paper, HomaModule
0x93 147 BIT-EMU Bit-stream Emulation RFC 9801
0x94-0xFC 148-252 Unassigned
0xFD-0xFE 253-254 Use for experimentation and testing RFC 3692
0xFF 255 Reserved

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

List of IP protocol numbers

View on Grokipedia
from Grokipedia
The list of IP protocol numbers is a registry of unique 8-bit integer values (ranging from 0 to 255) maintained by the Internet Assigned Numbers Authority (IANA) to identify the specific protocols or headers encapsulated within Internet Protocol (IP) datagrams.[1] These numbers enable the proper demultiplexing and processing of packet payloads by network devices, supporting the coexistence of multiple transport, management, and tunneling protocols over IP.[2][3] In IPv4, the protocol number occupies the 8-bit Protocol field in the IP header, which specifies the higher-layer protocol (such as TCP or UDP) or the type of encapsulated data immediately following the IP header.[2] Similarly, in IPv6, the 8-bit Next Header field serves this purpose but also chains multiple extension headers before reaching the upper-layer protocol, allowing for flexible packet processing like routing or fragmentation.[3] The registry includes assigned numbers for standardized protocols, unassigned values available for future allocation, and reserved entries for experimental or deprecated uses, with each entry often accompanied by a keyword for reference in implementations.[1] IANA manages the registry in coordination with the Internet Engineering Task Force (IETF), assigning numbers upon request in published RFCs to ensure global interoperability and prevent conflicts.[4] Notable assigned numbers include 1 for ICMP (Internet Control Message Protocol), used for diagnostics and error reporting; 6 for TCP (Transmission Control Protocol), providing reliable, connection-oriented communication; and 17 for UDP (User Datagram Protocol), offering lightweight, connectionless datagram delivery.[1] Other significant entries cover tunneling protocols like 41 for IPv6 encapsulation and security mechanisms such as 50 for ESP (Encapsulating Security Payload) and 51 for AH (Authentication Header).[1] The list is periodically updated to reflect new protocol developments, with the most recent revisions as of July 2025 incorporating ongoing IETF standardizations.[1]

Background

Definition and Purpose

IP protocol numbers are 8-bit unsigned integer values ranging from 0 to 255 that serve as identifiers for the protocols encapsulated within Internet Protocol (IP) datagrams.[5] In the IPv4 header, these numbers occupy the Protocol field, which indicates the type of header or protocol following the IP header in the datagram.[6] Similarly, in the IPv6 header, the equivalent Next Header field uses the same set of protocol numbers to specify the header immediately following the IPv6 header.[7] The primary purpose of IP protocol numbers is to enable demultiplexing at the network layer, allowing routers and endpoint hosts to identify and hand off the encapsulated payload to the appropriate higher-layer protocol for further processing.[6] This mechanism ensures that IP datagrams are routed correctly across networks and delivered to the correct protocol handler, such as a transport-layer protocol, without ambiguity in protocol interpretation.[7] By specifying the encapsulated protocol, these numbers facilitate interoperability among diverse network protocols within the IP suite. In practice, IP protocol numbers support demultiplexing by directing packets to specific protocols; for instance, a value of 6 indicates TCP, handing off the payload to the Transmission Control Protocol module, while a value of 1 directs to ICMP for Internet Control Message Protocol processing.[6] A key distinction arises in IPv6, where the Next Header field can chain multiple protocol numbers through extension headers, allowing sequential processing of optional headers (e.g., authentication or fragmentation) before reaching the final upper-layer protocol.[7] This chaining capability in IPv6 extends the flexibility of protocol identification beyond the single-field approach in IPv4. The Internet Assigned Numbers Authority (IANA) maintains the official registry of these numbers to ensure global consistency.[5]

Historical Development

The origins of IP protocol numbers trace back to the early internetworking efforts of the ARPANET project in the 1970s, where researchers sought to enable communication across heterogeneous packet-switched networks. In their seminal 1974 paper, Vint Cerf and Robert Kahn proposed a protocol for packet network intercommunication that laid the groundwork for distinguishing transport and higher-level services, though without a dedicated field for protocol identification at that stage.[8] This initial Transmission Control Program (TCP) evolved through early RFCs, such as RFC 675 in 1974, which specified socket numbers for higher-level protocols but predated the formal IP layer separation.[9] The protocol numbers as a distinct mechanism were formalized with the definition of the Internet Protocol in RFC 791, published in September 1981, which introduced an 8-bit Protocol field in the IPv4 header to identify the next-level protocol encapsulated in the datagram.[2] Concurrently, RFC 790 provided the first comprehensive list of assigned numbers, including initial protocols like ICMP (1) for error reporting and TCP (6) for reliable transport, managed informally by Jon Postel at the University of Southern California. This coincided with the 1983 transition of ARPANET to TCP/IP as a Department of Defense standard, marking a key milestone in standardizing internetworking and expanding the need for protocol identification amid growing network interconnections.[6] Subsequent evolution reflected the internet's expansion, with the original TCP being split into separate IP (RFC 791) and TCP (RFC 793) protocols in 1981, alongside UDP (17) defined in RFC 768 (1980) for connectionless transport.[10][11] As the internet grew beyond military applications in the 1990s, new protocols were incorporated, such as SCTP (132) in RFC 2960 (2000) for multi-streaming and multi-homing.[1] IPv6 adaptations in RFC 2460 (1998) extended the system with a Next Header field reusing the same numbering space, accommodating extension headers while maintaining compatibility with IPv4 protocols.[12] By the late 1990s, management shifted to the global IETF framework, enabling sustained growth from dozens to over 130 assigned numbers amid worldwide adoption.[13]

Management and Assignment

IANA Oversight

The Internet Assigned Numbers Authority (IANA) functions are operated by Public Technical Identifiers (PTI), an affiliate of the Internet Corporation for Assigned Names and Numbers (ICANN), and have stewarded the assignment and maintenance of Internet protocol parameters, including IP protocol numbers, since ICANN's establishment in 1998.[13][14] This role was formally defined in the Memorandum of Understanding (MoU) between the Internet Engineering Task Force (IETF) and ICANN, documented in RFC 2860, which outlines IANA's responsibilities for technical protocol parameter assignments while excluding policy decisions on domains and IP addresses.[15] Prior to this centralized structure, oversight of protocol parameters in the 1980s and 1990s was handled informally by the Internet Activities Board (IAB) and its executive committee, the Internet Engineering Steering Group (IESG), through documents like the periodic "Assigned Numbers" RFCs, which listed protocols and parameters under Jon Postel's de facto management at the University of Southern California's Information Sciences Institute (ISI).[16][17] The transition to IANA's formalized role under ICANN in 1998 marked a shift to a more structured, global authority, ensuring consistent documentation and assignment processes as the Internet scaled.[13] IANA maintains the official registry of assigned IP protocol numbers at iana.org/assignments/protocol-numbers, a publicly accessible resource that lists numbers from 0 to 255, with updates triggered by requests from the IETF.[1] In collaboration with the IETF, IANA reviews and implements allocations proposed in Request for Comments (RFC) documents approved by the IESG, publishing revisions to the registry to reflect new protocols or changes while preserving global interoperability and avoiding conflicts.[15][18] This process ensures that protocol numbers remain a stable, coordinated resource for Internet implementations worldwide.

Assignment Policies and Procedures

The assignment of IP protocol numbers is governed by specific criteria to ensure global interoperability and efficient use of the limited 256-value namespace. New allocations require a public specification documenting the protocol, demonstration of its stability and expected user base, and evidence that alternatives such as transport-layer port numbers are insufficient for the intended use.[19] Allocations must avoid conflicts with existing protocols, with the Internet Engineering Steering Group (IESG) evaluating requests to confirm necessity and long-term viability.[19] This process aligns with broader IANA guidelines for protocol parameters, emphasizing transparency and review to prevent namespace exhaustion.[20] IP protocol numbers fall into several categories based on their intended scope and permanence. Permanent assignments, typically for protocols advancing through the IETF standards track, require Standards Action via publication as an RFC.[1] Temporary or experimental assignments are handled through IESG Approval and may use reserved values such as 253 and 254, designated for testing and experimentation under RFC 3692-style procedures to allow innovation without permanent commitment.[21] Specific numbers are also allocated for private or local use, such as 61 (any host-internal protocol), 63 (any local network), and 99 (any private encryption scheme), enabling non-global deployments without IANA coordination.[1] Unassigned numbers, comprising a significant portion of the 128–255 range (e.g., 148–252), remain available for future allocations but are not designated for private experimentation.[1] Requests for new assignments begin with submission to the IETF, where authors include an IANA Considerations section in an Internet-Draft outlining the required number, justification, and registry updates.[20] The IESG reviews the draft for technical merit and policy compliance, potentially involving area director consultation or community feedback before approval.[19] For Standards Action, the draft must progress through IETF consensus and RFC publication; for other cases like experimental use, direct IESG endorsement suffices, though expert input may inform decisions without formal review.[20] This procedure, revised from earlier guidelines in RFC 2780 to eliminate non-public allocations, ensures all assigned values are documented and verifiable.[19] Assignment policies prioritize IETF consensus for broadly deployed protocols while allowing IESG Approval for narrower applications, without a first-come, first-served mechanism due to the namespace's scarcity.[19] Conflicts are mitigated by requiring proposers to survey existing uses and justify uniqueness, with IANA maintaining the authoritative registry to track assignments.[1] Updates, such as promoting an experimental protocol to permanent status, occur via a new RFC that revises the specification and requests registry changes, as seen in cases where initial IESG-approved values transition to Standards Action upon maturation.[20] Deprecations or reassignments are rare but handled similarly, requiring evidence that legacy uses have ceased to avoid disrupting deployments; for instance, obsolete protocols like Gateway-to-Gateway Protocol (number 3) remain assigned indefinitely to preserve compatibility with historical systems.[1] This approach balances innovation with stability in the IP ecosystem.[19]

Protocol List

Assigned Numbers

The assigned IP protocol numbers are unique identifiers allocated by the Internet Assigned Numbers Authority (IANA) for protocols operating above the IP layer, specified in the 8-bit Protocol field of IPv4 headers or the Next Header field of IPv6 headers. These numbers ensure unambiguous demultiplexing of packets to the appropriate protocol handlers. As of July 2025, IANA has assigned various numbers between 0 and 147, with unassigned ranges including 148–252, experimental numbers 253–254, and reserved number 255; the full registry is maintained for interoperability across the global Internet.[1] The assignments are categorized broadly by function, such as core Internet protocols, transport protocols, routing and multicast protocols, security protocols, IPv6-specific extensions, and tunneling or encapsulation protocols. The table below presents representative examples from each category, including the decimal number, keyword (used in implementations), full protocol name, and primary reference document. This selection highlights seminal and widely deployed protocols, prioritizing those with high impact on Internet architecture; the complete list exceeds 100 entries and can be consulted via the IANA registry for exhaustive details.[1]

Core Internet Layer Protocols

NumberKeywordNameReference
1ICMPInternet Control Message ProtocolRFC 792
2IGMPInternet Group Management ProtocolRFC 1112
4IPIPIP in IP EncapsulationRFC 2003
41IPv6IPv6 EncapsulationRFC 8200
58IPv6-ICMPICMP for IPv6RFC 4443

Transport Layer Protocols

NumberKeywordNameReference
6TCPTransmission Control ProtocolRFC 793
17UDPUser Datagram ProtocolRFC 768
33DCCPDatagram Congestion Control ProtocolRFC 4340
132SCTPStream Control Transmission ProtocolRFC 9260

Routing and Multicast Protocols

NumberKeywordNameReference
8EGPExterior Gateway ProtocolRFC 904
89OSPFIGPOpen Shortest Path First (OSPF) v2 and v3RFC 2328; RFC 5340
102PIMProtocol Independent MulticastRFC 7761

Security Protocols

NumberKeywordNameReference
50ESPEncapsulating Security PayloadRFC 4303
51AHAuthentication HeaderRFC 4302

IPv6 Extension and Tunneling Protocols

NumberKeywordNameReference
0HOPOPTIPv6 Hop-by-Hop OptionRFC 8200
43SRHRouting Extension HeaderRFC 8754
44IPv6-OptsDestination Options HeaderRFC 8200
115L2TPLayer Two Tunneling ProtocolRFC 2661
Recent assignments as of July 2025 include 145 for NSH (Network Service Header) for service function chaining and 146 for Homa, a transport protocol designed for datacenter networks, reflecting ongoing evolution in protocol support for modern applications such as web browsing and cloud services.[1]

Unassigned and Reserved Numbers

Unassigned IP protocol numbers represent values within the 8-bit field (0–255) that the Internet Assigned Numbers Authority (IANA) has not yet allocated to any specific upper-layer protocol. These numbers are held in reserve for potential future permanent assignments following IETF consensus or other designated procedures, ensuring global interoperability across networks. Examples of unassigned ranges include 148–252, which remain available as of the latest registry update.[22] Implementing devices or software using unassigned numbers is strongly discouraged, as this could lead to conflicts if the number is later assigned to a standard protocol; developers must instead reference the current IANA registry for updates.[22] Reserved numbers, in contrast, are explicitly set aside by IANA and unavailable for assignment to avoid ambiguity in protocol identification. A prominent example is 255, which is permanently reserved and must not be used for any protocol implementation.[22] Such reservations help maintain the integrity of the protocol number space, preventing unintended interactions in mixed environments. For experimental purposes, IANA designates specific numbers for temporary, non-production use in research, development, and testing without requiring formal registration. Per RFC 3692, the values 253 and 254 are allocated for this purpose, allowing innovators to prototype new protocols while minimizing risks to operational networks.[23] These experimental numbers should be employed judiciously, with documentation in publications or implementations to inform the community, and relinquished if the protocol advances to standardization.[23][22] Unlike IP address spaces, which include private ranges for local use (e.g., per RFC 1918), the IP protocol number space lacks designated private or local-use allocations due to the need for universal uniqueness in packet processing.[24] Any non-standard or vendor-specific protocols must seek formal IANA assignment to ensure compatibility, and the registry serves as the authoritative source for verifying availability and status changes.[22]
CategoryExample Numbers/RangesDescriptionReference
Unassigned148–252Available for future permanent assignmentIANA Protocol Numbers
Reserved255Permanently unavailable for useIANA Protocol Numbers
Experimental253–254For testing and experimentation; non-production onlyRFC 3692
User Avatar
No comments yet.