0
Summary
- // if you see it open
- Reserved port; real-world port-0 traffic is predominantly IPv4 fragmentation artifacts (fragment header parsed as a port-0 segment) and BitTorrent side-effects, with network scanning a smaller share. Active probing found an unexpectedly high TCP SYN response rate for IPv4 port-0 probes. Snort ships a destination-port-0 TCP signature (miscellaneous suspicious activity); router logs have documented port-0 DDoS campaigns. A scanner reporting port 0 'open' is usually a scanner artifact, not a bound service.
- // analyst note
- An observed port-0 flow is an anomaly — most often a fragmentation/parsing artifact or P2P side-effect, sometimes scanning or DDoS — never a normal bound service. Investigate as a signal, not a listener.
About port 0/tcp.
Port 0/tcp is registered with IANA as Reserved, with no service name and no assignee; the registry reference is RFC 6335 (the IANA port-assignment process document), the registration-date column is blank, and the entry's last modification date is 2024-12-20. Port 0 is dual-registered: 0/udp carries the identical "Reserved" status, the same RFC 6335 reference, and the same 2024-12-20 modification date. The convention originates in the early Internet — RFC 675 (1974) permitted a zero port value to indicate a partially specified or wildcard socket, and RFC 870 (1983, Reynolds and Postel) formally declared it reserved, prohibiting its use as a real source or destination port in TCP segments or UDP datagrams. At the operating-system level, passing 0 to the bind() system call does not bind to port 0; instead the kernel selects an ephemeral port from the dynamic range, so emitting a genuine port-0 packet requires a raw socket. No mainstream application protocol is assigned here. For an analyst, port 0 is significant almost entirely as an anomaly signal rather than a service: despite being reserved, measurement studies have recorded substantial port-0 traffic on the public Internet — a 2020 IXP study (arXiv:2004.03653) and a March 2021 follow-up (arXiv:2103.13055) each captured roughly 73–74 GB of port-0 traffic in a single week at a European Internet Exchange Point, with most packets having both source and destination ports set to 0. The 2021 study attributed the majority of that volume to IPv4 fragmentation artifacts (a fragment header parsed as a port-zero segment) and BitTorrent side-effects, with scanning a smaller share — yet active probing found an unexpectedly high TCP SYN response rate to IPv4 port-0 probes, suggesting many hosts answer this traffic. Snort ships a signature for destination-port-0 TCP flows (classified as miscellaneous suspicious activity), router logs have documented port-0 DDoS campaigns, and the packet-crafting tool hping3 uses port 0 as its default destination. A scanner reporting port 0 "open" is usually a scanner artifact, not a bound service.
- IANA assignment
- Reserved — no service name, no assignee; reference RFC 6335; dual-registered 0/tcp + 0/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry)
- Range class
- well-known (0–1023); the boundary value of the well-known range
- Modification date
- 2024-12-20 (registry last-modified for the 0/tcp row); registration date blank [Confirmed] — IANA registry CSV
- Related ports
- 0/udp (identically Reserved); ephemeral/dynamic range (49152–65535) as the real home of "let the OS pick"
Primary use
none — reserved by IANA; not a legitimate application port
Protocol origin
RFC 675 (1974) allowed port 0 as a partially-specified/wildcard socket; RFC 870 (1983) formally reserved it
Other/unofficial uses
hping3 default destination port; isolated anomalies (IPower IP9258 power switch, a legacy SSH server on port 0, Akamai-sourced port-0 traffic)
Security implications
Snort destination-port-0 TCP signature (misc suspicious activity); documented port-0 DDoS campaigns; scanner "open port 0" is typically an artifact, not a service
- OS behavior
bind()to port 0 triggers kernel ephemeral-port selection; a true port-0 packet requires a raw socket [Likely] — z3r0trust socket-programming writeup- Real-world traffic
- ~73–74 GB/week observed at a European IXP (2020 and 2021 studies); majority is IPv4 fragmentation artifacts + BitTorrent, with scanning a smaller share; active probing found a high TCP SYN response rate [Confirmed] — arXiv:2004.03653, arXiv:2103.13055
- Analyst note
- An observed port-0 flow is an anomaly — most often a fragmentation/parsing artifact or P2P side-effect, sometimes scanning or DDoS — never a normal bound service. Investigate as a signal, not a listener.
About port 0/udp.
Port 0/udp is recorded in the IANA Service Name and Transport Protocol Port Number Registry as Reserved, with no service name and no assignee; the same row exists for 0/tcp, so port 0 is reserved on both transports. The only reference cited is [RFC6335], the registry-procedure document — there is no protocol-assignment RFC, because port 0 names no protocol. In the BSD socket API port 0 is a sentinel, not a wire value: passing 0 to bind() tells the kernel to pick an ephemeral port from the dynamic range, so the host never actually places 0 in a UDP header. Producing a genuine on-wire packet with source or destination port 0 therefore requires a raw socket, and almost no legitimate software does this. As a result, "port 0" entries in packet captures and flow records are overwhelmingly monitoring artifacts: ICMP and non-initial IP fragments carry no Layer-4 port field, and capture tools label them port 0 by convention. For an analyst, port-0 traffic is a documented DDoS and scanning-evasion vector — attackers send source-port-0 fragments to slip past firewalls that cannot match a port header that is not present in non-initial fragments. Measurement work (PAM 2021, "Zeroing in on Port 0 Traffic in the Wild") found the bulk of port-0 traffic at an IXP was fragmentation, with smaller shares attributable to DDoS, OS fingerprinting, and scanning. Cloudflare's Magic Firewall minimal ruleset explicitly recommends blocking UDP source port 0. No CVE is specific to port 0/udp; the exposure is structural — a protocol-design plus firewall-gap interaction — rather than a named vulnerability. Treat any genuine on-wire port-0 UDP packet as malformed, an artifact, or hostile, never as a normal service.
- IANA assignment
- Reserved — no service name recorded; no assignee recorded; reference
[RFC6335]; dual-registered 0/tcp + 0/udp (both Reserved, same reference, same modification date 2024-12-20) [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry) - Range class
- well-known (0–1023) — port 0 is the reserved boundary value [Confirmed] — IANA registry
- IANA reference
[RFC6335]only — the registry-procedure RFC, not a protocol-assignment RFC; no other RFC is listed [Confirmed] — IANA registry CSV- Modification date
- 2024-12-20 — this is the IANA registry record's last-modified timestamp, NOT a protocol creation date [Confirmed] — IANA registry CSV
- Registration date
- blank in the registry (genuinely blank, recorded as Unknown) [Confirmed] — IANA registry CSV
- Related ports
- 0/tcp (same Reserved registration); the ephemeral/dynamic range (49152–65535) that
bind(0)draws from
Primary use
none — in the socket API, bind() to port 0 requests an OS-selected ephemeral port; the kernel never binds 0 on the wire, so a true on-wire port-0 packet needs a raw socket
Other/observed uses
no legitimate application binds 0/udp; port-0-labelled captures are dominated by ICMP and non-initial IP fragments (e.g. fragmented BitTorrent or large DNS responses misclassified as port 0 by capture tools)
Security implications
documented DDoS / scanning-evasion vector — source-port-0 fragments evade firewalls that cannot filter on an absent port field; Endace reported port-0 DDoS rising from ~10% to ~25% of incidents 2012→2013, with ~11 Gbps fragment floods observed; PAM 2021 measured ~73 GB of port-0 traffic in one week at an IXP, mostly fragmentation, with shares from DDoS (~10% of source IPs), OS fingerprinting (~6%), and scanning (packet-count-dominant). No port-0/udp-specific CVE — the risk is structural
Typically seen on
nothing legitimate — appearances are fragmentation/ICMP artifacts, DDoS abuse, or fingerprinting probes
- Firewall guidance
- Cloudflare Magic Firewall minimal ruleset recommends blocking UDP source port 0 ("Reserved — should not be used by applications; commonly used in DDoS attacks"), grouped with other abusive source ports; blanket blocks can break legitimate ICMP and fragmented DNS, so surgical blocking needs stateful fragment tracking[Confirmed] — Cloudflare Magic Firewall docs; Cloudflare IP-fragmentation blog
- Analyst note
- A genuine on-wire UDP packet with port 0 is never normal — treat as malformed, a capture artifact, or hostile, and check whether the "port 0" label is really a fragment/ICMP monitoring convention before acting.