169

Port 169/tcp is registered with IANA under the service name send, with the description given verbatim as "SEND," assignee William Oldwin, and a last-modified date of 2019-04-22. Both the Registration Date and Reference (RFC) columns are genuinely blank in the IANA registry — this is a thin, bare-bones assignment with no accompanying specification document, and an identical entry (same name, assignee, and modification date) exists for 169/udp. No verifiable real-world software, daemon, or protocol implementation was found that actually uses TCP or UDP port 169 in current practice, so beyond the registry stub itself, the port's functional purpose is undocumented. A secondary aggregator page (a Wikipedia port-list gloss) labels this entry "Secure Neighbor Discovery," but that association does not hold up: RFC 3971's SEND (SEcure Neighbor Discovery) is an IPv6 mechanism that runs over ICMPv6 and does not use any registered TCP or UDP port at all, and IANA's own port-169 entry carries no reference tying it to RFC 3971 — the match is almost certainly a naming coincidence rather than fact, and is not recorded as the port's identity here. Port 169 does not appear in the Chebucto trojan/backdoor port reference table, and no scanning-prevalence or exposure telemetry (GreyNoise, Censys, SANS ISC) specifically calling out port 169 was located. It is occasionally confused with the unrelated cloud instance-metadata address 169.254.169.254 (an RFC 3927 link-local address, typically reached over HTTP/HTTPS), which shares no actual relationship with port number 169 beyond the coincidental digits.

IANA assignment

send — description "SEND"; Reference/RFC field blank; assignee William Oldwin; Registration Date blank, last modified 2019-04-22; identical dual registration on 169/tcp + 169/udp [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry-416; https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?page=4

Range class

well-known (0–1023) [Confirmed]

Prevalence / scanning exposure

no scanning-prevalence or internet-exposure data (GreyNoise, Censys, SANS ISC) specifically naming port 169 was found in this pass [Unknown]

Related ports

169/udp — identical dual registration (same service name, assignee, and modification date) [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry

Primary use

undocumented — the IANA registry supplies only the bare service name and description "SEND" with no RFC or specification reference, and no verifiable real-world protocol implementation binding to port 169 was found

Other/unofficial uses

a secondary source (Wikipedia's port-number list) glosses this entry as "Secure Neighbor Discovery" (RFC 3971), but RFC 3971 SEND is an IPv6/ICMPv6 mechanism that registers no TCP/UDP port, and IANA's own port-169 entry cites no such reference — treated as a likely mistaken naming coincidence, not a confirmed use

Security implications

not present in the Chebucto trojan/backdoor port reference table; no confirmed malware or trojan association located

Typically seen on

no documented deployments found; the port is occasionally confused with the unrelated cloud-metadata address 169.254.169.254 (RFC 3927 link-local range), which shares no relationship with port number 169 beyond the coincidental digits [Likely, not a fact about this port]

Analyst note

An open port 169 has no documented legitimate service behind it beyond the bare IANA stub; treat as low-information — worth investigating case-by-case rather than assuming either a known protocol or malicious intent.

Port 169/udp is registered with IANA under the bare service name send, described only as "SEND," assigned to William Oldwin with a modification date of 2019-04-22; both the Registration Date and Reference (RFC) columns are blank in the registry, and no companion specification, informational RFC, or draft ties a defined protocol to this name. An identical registration — same service name, same description, same assignee/contact, same blank date/reference fields, same 2019-04-22 modification date — exists in parallel on 169/tcp, so the pair reads as a paired name reservation rather than a documented, actively-deployed protocol. Web research turned up no vendor implementation, client/server software, or standards document explaining what "SEND" actually does on this port, and no CVEs, published exploits, or scanner/threat-intel writeups reference port 169 specifically. One caveat worth recording explicitly: this send registration is unrelated to IPv6 SEND (SEcure Neighbor Discovery), which is a distinct ICMPv6-based protocol defined in RFC 3971 with no tie to TCP/UDP port 169 — the shared name is coincidental and should not be conflated. Because no real-world deployment could be confirmed, an analyst who observes traffic on 169/udp should treat it as unidentified/anomalous rather than assume it matches any known "send" protocol, and should not read UDP scan results here as conclusive given the general open|filtered ambiguity inherent to UDP scanning.

IANA assignment

send — "SEND"; assignee/contact [William_Oldwin]; Registration Date blank; Modification Date 2019-04-22; Reference blank [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry; https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

Range class

well-known (0–1023) [Confirmed] — port number falls in the IANA well-known range by definition

Related ports

169/tcp (identical paired IANA registration) [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry

Common software

none identified in searches; only bare port-lookup mirrors of the IANA name/description were found (e.g., SpeedGuide, t1shopper), with no independent verification [Unknown]

Security implications / exposure

no CVEs, published exploits, or threat-intel/scanner writeups specific to 169/udp found; general UDP-scan caveat applies — a non-response can mean open|filtered rather than confirmed-open [Unknown, with Well-established general caveat] — https://nmap.org/book/scan-methods-udp-scan.html

Typically seen on

no known deployed hosts or products identified; if observed, treat as unidentified/anomalous rather than assumed-benign [Unknown]

TCP dual registration

169/tcp carries the identical entry — same service name, description, assignee, blank Registration Date/Reference, Modification Date 2019-04-22 [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry

Primary protocol use

no RFC, spec, or informational document found describing what "SEND" implements on this port; IANA registers only the bare name [Unknown] — https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml (no reference listed)

Not to be confused with

IPv6 SEND (SEcure Neighbor Discovery), an unrelated ICMPv6-based protocol (RFC 3971) — name collision only, no evidence of a tie to this port [Confirmed] — RFC 3971 scope (ICMPv6, not TCP/UDP)