Service Name and Transport Protocol Port Number Registry

Last Updated

2026-10-15

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:

System Ports (0-1023) are assigned using the IETF Review or IESG Approval procedures.
User Ports (1024-49151) are assigned using the IETF Review, IESG Approval, or Expert Review procedures.
Dynamic and/or Private Ports (49152-65535) are not assigned.

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

To request a new assignment, please use the Application for Service Names and User Port Numbers form.
To modify an existing assignment, please use the Modify a Port Number Assignment form.

Available Formats

Service Name	Port Number	Transport Protocol	Description	Assignee	Contact	Registration Date	Reference	Assignment Notes
xmpp-client	5222	tcp	XMPP Client Connection				RFC 6120
xmpp-server	5269	tcp	XMPP Server Connection				RFC 6120
xmpp-bosh	5280	tcp	Bidirectional-streams Over Synchronous HTTP (BOSH)	Peter Saint-Andre	Peter Saint-Andre	2009-11-25
presence	5298	tcp	XMPP Link-Local Messaging	Eric St. Onge	Eric St. Onge	2008-01-14		Defined TXT keys: See http://www.xmpp.org/registrar/linklocal.html
presence	5298	udp	XMPP Link-Local Messaging	Eric St. Onge	Eric St. Onge	2008-01-14		Defined TXT keys: See http://www.xmpp.org/registrar/linklocal.html
clique		udp	Clique Link-Local Multicast Chat Room	Telepathy project	Telepathy project			Defined TXT keys: see http://telepathy.freedesktop.org/xmpp/clique
presence			Peer-to-peer messaging / Link-Local Messaging	XMPP Registrar	XMPP Registrar			Defined TXT keys: See http://www.xmpp.org/registrar/linklocal.html Note: Registration updated May 2007. Was formerly listed as "iChat AV" (Apple's IM client for Mac OS X) with TXT keys: txtvers, port.p2pj, phsh, vc, 1st, AIM, msg, status, last When first shipped in Mac OS X 10.2, iChat's peer-to-peer messaging protocol was created to solve the problem of serverless messaging between peers on the same link. However, there is nothing inherent in the protocol that limits it to being only link-local; it was simply an artifact of iChat in Mac OS X 10.2 using link-local Multicast DNS to discover peers. With the advent of Wide-Area DNS-SD, it is also possible to use iChat's peer-to-peer messaging between machines on different links.

Contact Information

Name	Contact URI	Last Updated
Eric St. Onge	stonge&apple.com	2008-01-14
Peter Saint-Andre	stpeter&stpeter.im	2009-11-25
Telepathy project	telepathy&lists.freedesktop.org
XMPP Registrar	registrar&xmpp.org