ICMP, TCP, UDP, ports and sockets: how IP reaches the right process
What ICMP does inside IP, how TCP and UDP differ, and why a port identifies a process rather than a trusted service.

IP delivers a packet to an address. Reaching the right process on that host also needs a protocol number in the IP header, naming what is inside the payload, and port numbers in the transport header, naming which process receives the data. This sheet covers what ICMP does, how TCP and UDP differ here, and why a port identifies a process, not a trusted service.
The model: from frame to process
Reception is de-multiplexing: each layer adds one selector on the way out, and the receiver reads the selectors back in order.
frame arrives, addressed to this host
|
v
IP header — Protocol field selects the transport protocol
|
v
ICMP (1) TCP (6) UDP (17)
|
v
transport header — destination port selects the endpoint
|
v
socket bound to that port -> the process
The link layer hands the frame to the host; IP reads the Protocol field and passes the payload to the matching transport module; that module reads the destination port and hands the data to the socket bound to it. Each step narrows the destination until one process owns the data.
Terms. Protocol number: the IP-header value naming the payload protocol — 1 for ICMP, 6 for TCP, 17 for UDP. Port: a 16-bit value in the transport header. Socket: an Internet address plus a port, the endpoint the stack de-multiplexes on. Session: the two addresses and two ports of one transport conversation.
ICMP is part of IP, not above it
ICMP (the Internet Control Message Protocol, RFC 792) lets hosts and gateways report problems and run diagnostics. RFC 792 states that it uses the basic support of IP as if it were a higher-level protocol, but is actually an integral part of IP, implemented by every IP module.
The messages are small reports: Destination Unreachable, Time Exceeded, and the echo request and echo reply pair (types 8 and 0) behind diagnostics. An ICMP error is never sent about another ICMP error, and it carries the original IP header plus the first 64 bits of the original datagram.
ICMP gives feedback; it does not make IP reliable. RFC 792 guarantees neither delivery of a datagram nor return of a control message. IPv6 keeps the idea in ICMPv6 (RFC 4443), Next Header 58. Its messages are not authenticated either: RFC 4443 lists forged sources, redirected replies and denial of service, and points to IPsec as the mitigation. An ICMP message is a signal, never proof.
TCP and UDP: the difference that matters here
Both sit directly on IP and carry a 16-bit source port and destination port; they differ in what they promise:
- TCP (RFC 9293) is connection oriented and provides a reliable, in-order, byte-stream service; its reliability mechanics — sequence numbers, windows and retransmission — belong to a separate sheet.
- UDP (RFC 768) is transaction oriented; delivery and duplicate protection are not guaranteed.
Ports identify processes, not trusted services
RFC 6335, which defines how IANA manages the port registry, gives ports two jobs: they de-multiplex, and they may also identify the application protocol and service. It calls them endpoint process identifiers and application protocol identifiers. The important word is identifier: a port number labels an endpoint, it does not certify it.
IANA assigns the well-known numbers in its port registry:
| Range | Name | Assigned by |
|---|---|---|
| 0–1023 | System ports (well-known) | IANA |
| 1024–49151 | User ports (registered) | IANA |
| 49152–65535 | Dynamic ports (private or ephemeral) | never assigned |
| Port | Transport | Service name | Description (IANA) |
|---|---|---|---|
| 22 | TCP | ssh | The Secure Shell (SSH) Protocol |
| 53 | TCP and UDP | domain | Domain Name Server |
| 80 | TCP | http | World Wide Web HTTP |
| 443 | TCP | https | http protocol over TLS/SSL |
One row already breaks the port-equals-service shortcut: 53 is registered for both TCP and UDP. The registry records assignment and convention, not a live guarantee of what is listening.
The socket the stack de-multiplexes on
RFC 9293 defines a socket as an Internet address plus a TCP port, and a connection as a pair of sockets. Adding the transport protocol gives the key the stack uses to place data:
( protocol , source address , source port , destination address , destination port )
| | | | |
TCP/UDP 192.0.2.10 49152 198.51.100.20 443 -> one session
RFC 6335 adds that the two ports plus the two IP addresses uniquely identify a session of a given transport protocol. One server port serves many clients: each arrives with a different source port, so each pair of sockets is a distinct session.
Common misconception: an open port is a vulnerability
An open port means a process has bound a socket and is reachable there. That is exposure, not risk: RFC 6335’s security considerations say an assignment implies no endorsement, and traffic to an assigned port is not necessarily good, nor necessarily that service.
Two errors follow:
- “A port is open, therefore it is vulnerable.” A listening socket can be intentional; vulnerability belongs to the software and its configuration, and exploitability also depends on reachability and preconditions.
- “Port X always means service Y.” Anyone can bind an unprivileged port, and a process can be reached on a port other than its registered default.
The port number authenticates nothing: any sender can set it freely, and neither the transport nor IP validates the source port or address.
What to remember
- ICMP is an integral part of IP (protocol 1); TCP is connection oriented and reliable, UDP best effort.
- A port identifies a process or a session, never a trusted service, and the number authenticates nothing.
- The stack de-multiplexes on the protocol, both addresses and both ports.
Level and prerequisites. L1 — fundamentals. No prerequisites; knowing what an IP address is helps, and nothing here requires configuration experience.
Where to go next
- Networking — the area this sheet belongs to.
References
- RFC 792 — Internet Control Message Protocol (ICMP).
- RFC 4443 — ICMPv6 for IPv6.
- RFC 9293 — Transmission Control Protocol (TCP).
- RFC 768 — User Datagram Protocol (UDP).
- RFC 6335 — IANA procedures for the service name and port number registry.
- RFC 5737 — IPv4 address blocks reserved for documentation.
- IANA — Protocol Numbers registry.
- IANA — Service Name and Transport Protocol Port Number Registry.