Service Name and Transport Protocol Port Number Registry

Last Updated

  • 2026-11-10

Expert(s)

  • TCP/UDP: Joe Touch; Eliot Lear, Kumiko Ono, Wes Eddy, Brian Trammell, and Michael Scharf
  • SCTP: Michael Tuexen
  • DCCP: Eddie Kohler and Yoshifumi Nishida

Reference

  • RFC 6335: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry

Note

Service names and port numbers are used to distinguish between different services that run over transport protocols such as TCP, UDP, DCCP, and SCTP.

Service names are assigned on a First Come First Served basis, as described in RFC 6335.

Port numbers are divided into three ranges, with their uses and assignment procedures specified in Section 8.1.2 of RFC 6335:

The registration procedures for service names and port numbers are specified in RFC 6335, while the registration policies referenced above are defined in RFC 8126.

Assigned ports both System and User ports SHOULD NOT be used without or prior to IANA registration.

Assignment of a port number does not in any way imply an endorsement of an application or product, and the fact that network traffic is flowing to or from a registered port does not mean that it is "good" traffic, nor that it necessarily corresponds to the assigned service. Firewall and system administrators should choose how to configure their systems based on their knowledge of the traffic in question, not whether there is a port number registered or not.

Registration Forms

Available Formats

Service Name Port Number Transport Protocol Description Assignee Contact Registration Date Modification Date Reference Service Code Unauthorized Use Reported Assignment Notes
hap 661 tcp HAP Igor Plotnikov Igor Plotnikov
hap 661 udp HAP Igor Plotnikov Igor Plotnikov
netview-aix-1 1661 tcp netview-aix-1
netview-aix-1 1661 udp netview-aix-1
radsec 2083 tcp Secure Radius Service IESG IETF Chair 2005-05 RFC 6614 The TCP port 2083 was already previously assigned by IANA for "RadSec", an early implementation of RADIUS/TLS, prior to issuance of this RFC. This early implementation can be configured to be compatible to RADIUS/TLS as specified by the IETF. See RFC 6614, Appendix A for details.
olhost 2661 tcp OLHOST Robert Ripberger Robert Ripberger
olhost 2661 udp OLHOST Robert Ripberger Robert Ripberger
can-ferret-ssl 3661 tcp IBM Tivoli Directory Service using SSL Nic Catrambone Nic Catrambone 2003-01
can-ferret-ssl 3661 udp IBM Tivoli Directory Service using SSL Nic Catrambone Nic Catrambone 2003-01
kar2ouche 4661 tcp Kar2ouche Peer location service Andy Krouwel Andy Krouwel
kar2ouche 4661 udp Kar2ouche Peer location service Andy Krouwel Andy Krouwel
bencher 6610 tcp Bencher API Bencher Everett Pompeii 2026-06-17
bencher 6610 udp Bencher API Bencher Everett Pompeii 2026-06-17
6611-6618 Unassigned
odette-ftps 6619 tcp ODETTE-FTP over TLS/SSL Ieuan Friend Ieuan Friend 2006-03 RFC 5024
odette-ftps 6619 udp ODETTE-FTP over TLS/SSL Ieuan Friend Ieuan Friend 2006-03 RFC 5024
mipv6tls 7872 udp TLS-based Mobile IPv6 Security IESG IETF Chair 2012-04-12 RFC 6618
15661-15739 Unassigned
16386-16618 Unassigned
xoms 16619 tcp X509 Objects Management Service Francis GASCHET Francis GASCHET 2008-09-08
16619 udp Reserved

Contact Information

Name Organization Contact URI Last Updated
Andy Krouwel andy&kar2ouche.com
Bencher info&bencher.dev 2026-06-17
Everett Pompeii everett&bencher.dev 2026-06-17
Francis GASCHET NUMLOG fg&numlog.fr 2008-09-08
IESG iesg&ietf.org
IETF Chair IETF chair&ietf.org
Ieuan Friend ieuan.friend&dip.co.uk 2006-03
Igor Plotnikov igor&uroam.com
Nic Catrambone ncatramb&us.ibm.com 2003-01
Robert Ripberger rip&lan-aces.com 2017-02-08