556

Port 556/tcp is registered with IANA as remotefs with the description "rfs server" and blank assignee, contact, and reference fields (dual-registered on TCP and UDP); the classic /etc/services file expands the comment as "rfs_server rfs # Brunhoff remote filesystem." It denotes an early remote-filesystem server protocol that is distinct from NFS. The lineage is genuinely uncertain: the BSD /etc/services annotation credits a "Brunhoff remote filesystem," while the name RFS is also widely associated with AT&T Remote File Sharing, a System V Release 3 (1980s) distributed filesystem that was connection-oriented and preserved full UNIX file semantics (stateful, unlike early NFS), built on the STREAMS Transport Provider Interface and shipping in SVR3/SVR4 before being eclipsed by NFS and removed by Sun from Solaris 2.4. Either way, RFS here is an obscure, historic remote filesystem with a minimal modern footprint. The IANA reference field is blank, and confidence is Medium because the precise origin of the 556 assignment predates clear public documentation. Security-wise there is effectively no modern exposure — the service is legacy and almost never seen — so an open 556 most likely reflects a stale /etc/services label or a niche or embedded implementation rather than active RFS. For an analyst, an open 556/tcp is rare and should be treated as legacy or anomalous, with investigation of what is actually listening rather than an assumption of RFS.

IANA assignment

remotefs — "rfs server"; reference (blank — no RFC cited in IANA registry); assignee/contact blank; dual-registered 556/tcp + 556/udp [IANA-assigned] — IANA Service Name and Transport Protocol Port Number Registry

Range class

well-known (0–1023)

Prevalence

nmap-services open-frequency ~0.000125 (de-facto; rare) [Well-established] — nmap-services file

Related ports

2049 (NFS), 111 (sunrpc/portmapper)

Primary use

early remote-filesystem server protocol (RFS), distinct from NFS

Other/unofficial uses

none today [Well-established]

Security implications

effectively none in modern environments; legacy and almost never seen [Unverified]

Typically seen on

legacy Unix RFS (rare)

Analyst note

An open 556/tcp is rare; treat as legacy/anomalous and investigate what is actually listening rather than assuming RFS.

Port 556/udp carries remotefs, an IANA-registered name whose lineage is genuinely uncertain: the BSD /etc/services annotation credits a "Brunhoff remote filesystem," while the name RFS is also widely associated with AT&T Remote File Sharing, a legacy Unix distributed-filesystem service; either way, it is obsolete and should never be exposed to the public internet.

RFS was developed at Bell Laboratories/AT&T and first shipped with UNIX System V Release 3 (SVR3), later included in SVR4. It used a stateful, client-server model — the server tracked what each client was doing to shared files — built on the STREAMS Transport Provider Interface. The same assignment appears in RFC 1340 (July 1992) as remotefs 556/udp rfs server.

RFS lost out commercially to Sun's NFS, which had broader TCP/IP industry support. Sun dropped RFS from Solaris 2.4, and most other AT&T Unix licensees removed it from later distributions; the port is dual-registered with an identical 556/tcp assignment.

The nmap-services corpus records an open-frequency of approximately 0.000428 for 556/udp and 0.000125 for the companion 556/tcp entry — both near zero, consistent with a service that has seen essentially no legitimate deployment since the mid-1990s. No CVE or named malware family tied specifically to this port surfaced in research as of a September 2026 search.

Exposure

Internal-only file-sharing service in the same class as NFS/SMB; RFS was never designed for, and should never be reachable from, the public internet.

Obsolescence

RFS was abandoned by the mid-1990s in favor of NFS and dropped from Solaris 2.4 and most later Unix distributions, so legitimate traffic on this port is not expected in current environments.

Malware/CVE

No CVE or named trojan/malware family is recorded against 556/udp as of a September 2026 search; a generic "bad ports" disclaimer page carries no positive verdict for this port and is cited here only for the negative finding.

Anomaly signal

Because RFS is essentially extinct, a responsive 556/udp on a modern host is unusual and worth treating as a legacy artifact, scan noise, or a signal worth investigating rather than assuming benign.

IANA assignment

remotefs — "rfs server"; reference blank; assignee not listed; dual-registered 556/tcp + 556/udp [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry

Range class

well-known (0–1023) [Confirmed]

Prevalence

nmap-services open-frequency 556/udp ≈0.000428 (~0.043%); 556/tcp ≈0.000125 (companion registration) [Confirmed] — this site's own tooling

Related ports

556/tcp (identical dual-registered assignment) [Confirmed]

Primary use

uncertain lineage — the BSD /etc/services annotation credits a "Brunhoff remote filesystem," while the name is also widely associated with AT&T Remote File Sharing (RFS), an early Unix System V distributed-filesystem service; IANA's own registry carries only the bare description "rfs server" [Likely] — the IANA Service Name and Transport Protocol Port Number Registry; /etc/services (Brunhoff annotation); https://en.wikipedia.org/wiki/Remote_File_Sharing (background on the AT&T RFS protocol; does not name port 556)

Other/unofficial uses

none documented [Unknown]

Security implications

no CVE or named malware family recorded against this port as of a September 2026 search; RFS's obsolescence makes legitimate current traffic unlikely

Typically seen on

legacy AT&T/Unix System V hosts still running RFS; otherwise anomalous [Likely]

Analyst note

An open 556/udp is rare in current environments given RFS's obsolescence since the mid-1990s; treat a live responder as a legacy artifact or investigate as anomalous. [Likely]