517

Port 517/tcp is registered with IANA as talk with the verbose description "like tenex link, but across machine - unfortunately, doesn't use link protocol (this is actually just a rendezvous port from which a tcp connection is established)" and blank assignee, contact, and reference fields (the identical string is registered on 517/udp). It is the original talk protocol — real-time two-user terminal chat — served by talkd. Per the canonical talkd description, the talk server acts as a repository of invitations: a caller sends a control message look-up, then an announce, the server broadcasts on the callee's login ports, and when the callee responds the clients establish a stream connection through which the conversation takes place. The transport behavior is the key nuance: in practice the control and rendezvous happen over UDP, and the actual conversation uses a separately negotiated TCP stream, which is exactly what the registry note means by "just a rendezvous port from which a tcp connection is established" (this split across UDP and TCP is why talk is notoriously hard to proxy). The original talk uses 517; the incompatible newer protocol moved to 518 (ntalk). The IANA reference field is blank. Security-wise it is an obsolete chat daemon with no encryption or authentication, talkd had historical vulnerabilities, and it has a minimal modern footprint; nmap-services records 517/udp activity but effectively zero on TCP, confirming the UDP-centric behavior. For an analyst, an open 517 (more likely on UDP) indicates an antique Unix host running talkd and is almost always vestigial, so it should be disabled.

IANA assignment

talk — "like tenex link, but across machine - unfortunately, doesn't use link protocol (this is actually just a rendezvous port from which a tcp connection is established)"; reference (blank — no RFC cited in IANA registry); assignee/contact blank; dual-registered 517/tcp + 517/udp (UDP carries the control/rendezvous)

[IANA-assigned] — IANA Service Name and Transport Protocol Port Number Registry

Range class

well-known (0–1023)

Prevalence

nmap-services open-frequency 517/tcp ~0.000000 (UDP ~0.004794) (de-facto) [Well-established] — nmap-services file

Related ports

518 (ntalk — the newer, incompatible talk)

Primary use

real-time two-user terminal chat (talkd) [Well-established]

Other/unofficial uses

none today [Well-established]

Security implications

obsolete; no encryption/auth; historical talkd vulnerabilities; minimal modern footprint [Well-established]

Typically seen on

old Unix hosts running in.talkd

Analyst note

An open 517 (more likely UDP) indicates an antique Unix host running talkd — almost always vestigial; disable.

Port 517/udp carries the legacy Unix talk service; it should stay internal-only rather than be exposed to the public internet. It is a rendezvous port used by old BSD talk daemons to locate a remote user before an interactive chat session is set up.

IANA registers 517 under the service name talk, dual-registered on both TCP and UDP, with blank Assignee and Reference fields in the source registry. The IANA description reads "like tenex link, but across machine — unfortunately, doesn't use link protocol (this is actually just a rendezvous port from which a tcp connection is established)."

The protocol itself is the classic ("old talk"/otalk) Unix chat mechanism: a talkd (or in.talkd) daemon on the target host receives an invitation datagram on 517/udp, looks up the addressed user, and coordinates a split-screen interactive session; the newer ntalk variant commonly used 518/udp instead. It predates and is unrelated to modern chat platforms.

talk and its daemons are widely described as legacy and largely obsolete on the modern internet, with essentially no legitimate reason to expose the rendezvous port publicly. Historical security literature references talkd DNS-spoofing weaknesses, though a citable CVE identifier for that could not be confirmed in an August 2026 search.

Exposure

No authentication or encryption in the talk protocol; sessions can be spoofed or eavesdropped if the port is reachable from an untrusted network. [Likely] — docstore.mik.ua orelly networking_2ndEd fire ch19_03.htm

Malware association

auditmypc.com's port-517 page records "Virus / Trojan: No" as of an August 2026 check; no malware association is documented for this port. [Likely] — auditmypc.com udp-port-517

Notable CVE

none confirmed in the NVD as of an August 2026 search; older secondary literature references a talkd DNS-spoofing issue but no citable CVE identifier surfaced.

Modern relevance

talk/ntalk daemons are described as legacy and largely unused on the modern internet; a responsive 517/udp outside a legacy Unix environment is worth investigating rather than assumed benign. [Likely] — docstore.mik.ua orelly networking_2ndEd fire ch19_03.htm

IANA assignment

talk — "like tenex link, but across machine..."; reference (blank); assignee (blank); dual-registered 517/tcp + 517/udp [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry talk 517/udp

Range class

system/well-known (0–1023, system per the nmap-services frequency data) [Confirmed] — this site's own tooling port 517

Prevalence

nmap-services open-frequency 517/udp = 0.004794 (~0.48%); 517/tcp = 0 (sampled, not observed open) [Confirmed] — this site's own tooling port 517

Related ports

518/udp (ntalk, the newer talk variant); the small-services cluster (7/9/11/13/17/19/37)

Primary use

rendezvous port for the legacy Unix/BSD talk interactive chat protocol; a talkd/in.talkd daemon receives an invitation and coordinates a split-screen session with a remote user

Other/unofficial uses

newer ntalk implementations commonly use 518/udp instead of this port; Juniper Junos ships a TALK Application Layer Gateway (ALG) that recognizes and NATs traffic on this port

Security implications

cleartext, unauthenticated protocol susceptible to spoofing/eavesdropping if exposed; essentially obsolete on the modern public internet; no CVE confirmed as of August 2026; not malware-associated per auditmypc.com

Typically seen on

legacy Unix/BSD hosts running talkd/ntalkd; otherwise an anomaly on modern networks

Analyst note

An open 517/udp outside a known legacy Unix environment is unusual and worth investigating; the protocol carries no authentication or encryption.