supernets/wiki
1
Fork 1
Code Issues Pull Requests Wiki Activity
Page: RFC2813
Pages
BAN POLICY CHANNEL MODES CHANNELS CLIENTS COMMANDS Home INCOG vs NUNYA Drama MODES RFC RFC2810 RFC2811 RFC2812 RFC2813 SNOMASKS USER MODES USERS
Clone
1
RFC2813
acidvegas edited this page 2026-02-14 19:53:45 -05:00
Table of Contents

RFC 2813 - Internet Relay Chat: Server Protocol

Network Working Group: C. Kalt
Request for Comments: 2813
Updates: 1459
Category: Informational
Date: April 2000

Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

While based on the client-server model, the IRC (Internet Relay Chat) protocol allows servers to connect to each other effectively forming a network.

This document defines the protocol used by servers to talk to each other. It was originally a superset of the client protocol but has evolved differently.

First formally documented in May 1993 as part of RFC 1459 [IRC], most of the changes brought since then can be found in this document as development was focused on making the protocol scale better. Better scalability has allowed existing world-wide networks to keep growing and reach sizes which defy the old specification.

Table of Contents

1. Introduction

The IRC protocol was developed since 1989. Although it has remained mostly compatible with the 2.10 implementation, some issues had to be addressed in order to let the protocol scale properly. This document aims at providing a reference for the server to server protocol of the current implementation. Changes to the client to server protocol are minor.

This document is mainly intended for server implementors.

The IRC (Internet Relay Chat) protocol has been designed over a number of years, with multitudinous implementations and increasing complexity. While based on a client-server model, there are a vast number of design decisions and implementation choices that determine the overall behavior and scalability of any given IRC network.

RFC 1459 [IRC] has been the sole formal specification of IRC protocol for many years. As implementations evolved, it was shown that the protocol described in RFC 1459 has serious weaknesses and deficiencies. This document attempts to provide documentation for the working protocol used by the majority of IRC servers connected to what is sometimes referred to as the "IRC network".

2. Global database

IRC servers SHALL maintain the following database about the state of the whole network:

  • a list of all servers;
  • a list of all users;
  • a list of all channels.

Each server MUST keep the database synchronized with the rest of the network. It is important to note here that the messages used to maintain the database synchronized are ONLY passed server-to-server.

2.1 Servers

Each server MUST know about all other servers on the network. Each server is identified by its name which has a maximum length of sixty three (63) characters. It is RECOMMENDED that the server name be chosen as the DNS name of the host on which the server runs.

2.2 Clients

For each client, servers MUST keep the following information:

  • a nickname (See "IRC Client Protocol" [IRC-CLIENT]);
  • a username (as provided by the USER command) (See [IRC-CLIENT]);
  • a hostname (as determined by the server);
  • a servername (which server the client is connected to);
  • the realname or "GECOS" (as provided by USER command) (See [IRC-CLIENT]);
  • any user modes (defined in [IRC-CLIENT]).

2.2.1 Users

Users are clients which have registered with the server. They are distinguished from other connections which have not successfully registered (such as clients still performing authentication).

2.2.2 Services

Services are special kind of clients. They are introduced to the network and can send messages. However, they MUST NOT be the target of commands sent by users (such as MODE, KICK, etc.).

2.3 Channels

Channels are groups of one or more clients. Messages sent to a channel are received by all clients which are members of that channel.

Details on channels are covered in "Internet Relay Chat: Channel Management" [IRC-CHAN].

For each channel, the server MUST keep the following information:

  • the channel name;
  • the current members;
  • the channel modes.

It is to be noted here that various servers MAY store additional (local) state information for each channel, such as local bans, local exceptions, etc.

3. The IRC Server Specification

3.1 Overview

The protocol as described herein is for use with server to server connections.

3.2 Character codes

No specific character set is specified. The protocol is based on a set of codes which are composed of eight (8) bits, making up an octet. Each message may be composed of any number of these octets; however, some octet values are used for control codes, which act as message delimiters.

Regardless of being an 8-bit protocol, the delimiters and keywords are such that protocol is mostly usable from US-ASCII terminal and a telnet connection.

Because of IRC's Scandinavian origin, the characters {}|^ are considered to be the lower case equivalents of the characters []\~, respectively. This is a critical issue when determining the equivalence of two nicknames or channel names.

3.3 Messages

Servers and clients send each other messages, which may or may not generate a reply. If the message contains a valid command, as described in later sections, the client should expect a reply as specified but it is not advised to wait forever for the reply; client to server and server to server communication is essentially asynchronous by nature.

Each IRC message may consist of up to three main parts: the prefix (OPTIONAL), the command, and the command parameters (maximum of fifteen (15)). The prefix, command, and all parameters are separated by one ASCII space character (0x20) each.

The presence of a prefix is indicated with a single leading ASCII colon character (':', 0x3b), which MUST be the first character of the message itself. There MUST be NO gap (whitespace) between the colon and the prefix. The prefix is used by servers to indicate the true origin of the message.

The command MUST either be a valid IRC command or a three (3) digit number represented in ASCII text.

IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and these messages SHALL NOT exceed 512 characters in length, counting all characters including the trailing CR-LF. Thus, there are 510 characters maximum allowed for the command and its parameters. There is no provision for continuation of message lines.

3.3.1 Message format in Augmented BNF

The protocol messages must be extracted from the contiguous stream of octets. The current solution is to designate two characters, CR and LF, as message separators. Empty messages are silently ignored, which permits use of the sequence CR-LF between messages without extra problems.

The extracted message is parsed into the components , and list of parameters ().

The Augmented BNF representation for this is found in [IRC-CLIENT]. In addition to the client to server messages, the following messages are available for server to server communication.

3.4 Numeric replies

Most of the messages sent to the server generate a reply of some sort. The most common reply is the numeric reply, used for both errors and normal replies. Refer to [IRC-CLIENT] for more information on numeric replies.

4. Message Details

On the following pages are descriptions of each server to server message recognized by the IRC server. Server to client messages are described in [IRC-CLIENT].

Where the reply ERR_NOSUCHSERVER is returned, it means that the target of the message could not be found. The server MUST NOT send any other replies after this error for that command.

4.1 Connection Registration

The commands described here are used to register a connection with another IRC server.

4.1.1 Password message

Command: PASS
Parameters: []

The PASS command is used to set a 'connection password'. The password supplied MUST match the one contained in the C/N lines (for servers) or I lines (for clients). It is possible to send multiple PASS commands before registering but only the last one sent is used for verification and it may not be changed once registered.

The parameter consists of two substrings separated by one (1) dot ('.'), the leftmost being the generation and the rightmost being the server version number.

The optional parameter is a string of characters representing server flags (see below).

The optional parameter is a list of space separated string options.

Numeric Replies: ERR_NEEDMOREPARAMS, ERR_ALREADYREGISTRED

Example:

PASS secretpasswordhere 0210 IRC|aBgH

4.1.2 Server message

Command: SERVER
Parameters:

The SERVER message is used to tell a server that the other end of a new connection is a server. This message is also used to pass server data over whole net.

When a new server connection is established, each side sends SERVER and PASS messages to the other side. The SERVER message carries information about the sending server. If the information is acceptable, the other side responds with its own SERVER and PASS messages otherwise it should close the connection.

When the SERVER command is received, a server SHOULD check that it is authenticated. This can be done various ways, the most common being:

  • the hostname of the server matches the server's host configuration;
  • the password provided by the server with the PASS command matches the expected password.

The parameter is used by servers to indicate how far away the introduced server is. When sending SERVER, servers MUST set the to 1. When relaying SERVER, servers MUST increment the by 1.

The parameter contains information about the server, and is displayed by various commands. It may include network name, city, owner, etc.

Numeric Replies:

  • ERR_ALREADYREGISTRED

Example:

SERVER tolsun.oulu.fi 1 :Experimental server

:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server

4.1.3 Nick

Command: NICK
Parameters:

The NICK message is used by servers to inform other servers about new users. This is also how servers transmit nickname changes.

The NICK message MUST be sent to all servers that need to know about the user. Each parameter has the same meaning as in the USER and MODE commands (See [IRC-CLIENT]).

For newly introduced clients, the SHALL be set to 1. When propagating NICK to other servers, MUST be incremented by 1 for each hop.

Numeric Replies: None for servers

Example:

:csd.bu.edu NICK WiZ 7 ~john csd.bu.edu 1 +i :John Doe

NICK syrk 1 kalt millennium.stealth.net tolsun.oulu.fi 0 :Christophe Kalt

4.1.4 Service message

Command: SERVICE
Parameters:

The SERVICE command is used by servers to introduce a service to the rest of the network. The meaning of the parameters is the same as in the SERVICE client command (See [IRC-CLIENT]).

Numeric Replies: None for servers

Example:

SERVICE dict * *.fr 0 0 :French Dictionary

4.1.5 Quit

Command: QUIT
Parameters:

A client session is ended with a quit message. The server MUST send the quit message to all servers to which it is directly connected, which then MUST broadcast it to all clients which have common channels with the quitting client.

When a server connection is closed, a QUIT message is generated for each client connected only to that server.

Numeric Replies: None

Example:

:WiZ QUIT :Gone to have lunch

:tolsun.oulu.fi QUIT :Bad link

4.1.6 Server quit message

Command: SQUIT
Parameters:

The SQUIT message is needed to tell about quitting or dead servers. If a server wishes to break the connection to another server it MUST send a SQUIT message to the other server, using the name of the other server as the server parameter.

When a server link is closed, a SQUIT message is broadcast to the network. Each server that receives it removes from its database all servers and users that were connected through the server that was removed from the network.

Numeric Replies: None for servers

Example:

SQUIT tolsun.oulu.fi :Bad Link

:csd.bu.edu SQUIT bar.foo.com :Link inactive

4.2 Channel operations

These messages are used by servers to distribute channel information.

4.2.1 Join message

Command: JOIN
Parameters:

The JOIN command is used by servers to tell other servers that a user is now a member of a particular channel. When a user joins a channel, the server generates a JOIN message for that channel and sends it to all servers.

Numeric Replies: None for servers

Example:

:WiZ JOIN #Twilight_zone

4.2.2 Njoin message

Command: NJOIN
Parameters:

The NJOIN message is used between servers only. It is used to efficiently distribute a whole list of users that have joined a channel (for example, after a netjoin) instead of a series of JOIN messages.

The parameter is a list of nicknames, with their channel status indicated by a prefix character. The characters are:

  • @ indicates channel operator status;
  • + indicates voice privilege;
  • No prefix indicates normal channel member.

Numeric Replies: None for servers

Example:

:services.fr NJOIN #welcome :@WiZ,+guest,user1,user2

NJOIN #test :@Alice,+Bob,Charlie

4.2.3 Mode message

Command: MODE
Parameters: <channel/nick> []

The MODE command is a dual-purpose command in IRC. It allows both channel modes and user modes to be changed. When used with a channel name, it changes channel modes; when used with a nickname, it changes user modes.

MODE messages between servers are used to distribute channel and user mode changes throughout the network.

Numeric Replies: None for servers

Example:

:WiZ MODE #Fins +o Kilroy

:csd.bu.edu MODE WiZ +iw

:WiZ MODE #eu-opers +l 10

5. Implementation details

This section deals with the various implementation problems and choices for IRC servers.

5.1 Connection 'Liveness'

It is important for servers to be able to check if the other end of the connection is alive. For this purpose, the server SHALL send PING messages at regular intervals (typical value is 90 seconds) to all of its neighbors. Every connection which has not shown any activity (i.e., neither sending nor receiving any data) for 2*ping_frequency MUST be dropped.

When a server receives a PING message, it MUST reply with an appropriate PONG message.

5.2 Accepting a client to server connection

When a new client connects to a server, the server SHALL begin the authentication process to verify whether the connection is from a legitimate user or from another server.

5.2.1 Users

For a connection to be accepted as a user connection, it MUST provide a password (if required) and complete the registration sequence with USER and NICK commands. The server SHOULD also perform hostname and ident lookups.

5.2.2 Services

Services are a special type of client. They are introduced to the network and can send messages. They have limited interaction with normal users and channels. The SERVICE command is used to register a service.

5.3 Establishing a server-server connection

When two servers connect, they MUST exchange PASS and SERVER messages. A server SHOULD NOT send any other information until this is done.

5.3.1 Link options

5.3.1.1 Compressed server to server links

To reduce the amount of bandwidth used by server to server links, servers MAY compress the data stream. This is typically implemented using the zlib compression library.

5.3.1.2 Anti abuse protections

Servers MAY implement various anti-abuse protections to limit the impact of abusive servers on the network. This can include rate limiting, filtering, etc.

5.3.2 State information exchange when connecting

When a new server-to-server connection is established, each side must inform the other about the state of the network as it sees it. This is done by sending:

  • SERVER messages for all known servers;
  • NICK messages for all known users;
  • SERVICE messages for all known services;
  • Information about channel states.

5.4 Terminating server-client connections

When terminating a server-client connection, the server MUST send a QUIT message for that client to all servers, which will in turn propagate it to their clients that shared channels with the quitting client.

5.5 Terminating server-server connections

When a server connection is terminated, the server MUST send a SQUIT message for the removed server to all its neighbors. Those servers will then remove from their database all servers and clients that were connected through the broken link.

5.6 Tracking nickname changes

When a client changes nickname, the server MUST send a NICK message to all other servers. This ensures that the nickname change is propagated throughout the network and that all servers update their database.

5.7 Tracking recently used nicknames

To prevent nickname collisions and abuse, servers SHOULD keep track of recently used nicknames and make them unavailable for a short period after they are released. This is particularly important after a netspli

t where multiple users might try to grab the same nickname.

5.8 Flood control of clients

Servers SHOULD implement flood protection to prevent clients from sending too many commands too quickly. This helps protect the server and network from abuse.

Typical implementations use a "token bucket" algorithm or similar approach to rate-limit commands from clients.

5.9 Non blocking lookups

To avoid blocking the server while performing hostname and ident lookups, these lookups SHOULD be performed asynchronously.

5.9.1 Hostname (DNS) lookups

When a client connects, the server SHOULD perform a DNS lookup on the client's IP address to determine the hostname. This lookup SHOULD be done asynchronously to avoid blocking the server.

5.9.2 Username (Ident) lookups

In addition to DNS lookups, servers MAY perform ident lookups (RFC 1413) to verify the username of connecting clients. Like DNS lookups, these SHOULD be done asynchronously.

5.10 Configuration File

Servers typically use configuration files to determine:

  • What servers they are allowed to connect to;
  • What clients are allowed to connect;
  • Operator passwords;
  • Connection classes and limits;
  • Channel and user modes available;
  • etc.

The exact format and options of configuration files are implementation-specific.

5.11 Channel Membership

Servers MUST track which clients are members of which channels. This information is essential for:

  • Distributing channel messages to the correct recipients;
  • Enforcing channel modes;
  • Handling channel operations like kicks and bans.

6. Current problems

There are a number of recognized problems with the IRC Server Protocol, this section addresses the problems related to the architecture of the protocol.

6.1 Scalability

It is widely recognized that this protocol does not scale sufficiently well when used in a large arena. The main problem comes from the requirement that all servers know about all other servers, clients and channels and that information regarding them be updated as soon as it changes.

While this issue is also present in the architecture (See [IRC-ARCH]), it is compounded by the protocol itself which doesn't provide for more sophisticated routing. Servers need to broadcast most messages to all other servers.

6.2 Labels

6.2.1 Nicknames

The issue of nicknames is discussed in [IRC-CLIENT].

With the current protocol, it is possible for two clients to pick the same nickname at the same time on different servers (nick collision). The protocol provides a way to detect and solve such conflicts but it remains a problem.

While the protocol allows for collision detection and resolution through KILL messages, this mechanism has serious weaknesses and deficiencies.

6.2.2 Channels

Channel names suffer from the same issue as nicknames. When two channels with the same name are created on different servers (channel collision), the protocol has to deal with merging them.

The current protocol handles channel collisions as inclusive events: all users from both channels become members of the resulting channel. This can lead to various problems, especially with channel modes and privileges.

6.2.3 Servers

Server names are currently required to be unique across the entire network. While this is generally not a problem (as server names typically use DNS hostnames), it can become an issue when servers need to be renamed or when experimental servers are connected.

The protocol does not provide any mechanism to handle server name collisions; a server is expected to disconnect if it detects a name collision.

6.3 Algorithms

The core routing algorithm is simple: most messages are broadcast to all servers. While this ensures that all servers receive all updates, it has severe scalability limitations.

More sophisticated routing algorithms would be required to scale to larger networks, but implementing such algorithms while maintaining backward compatibility is extremely difficult.

7. Security Considerations

7.1 Authentication

Server to server connections rely on a simple password authentication mechanism. This is vulnerable to various attacks:

  • Passwords are often transmitted in clear text;
  • There is no protection against replay attacks;
  • Compromised passwords grant full access to the network.

More sophisticated authentication mechanisms (such as public key cryptography) would provide better security.

7.2 Connection Hijacking

The protocol does not provide any protection against connection hijacking. If an attacker can inject or modify packets in a server-to-server connection, they can:

  • Introduce fake servers, clients, or services;
  • Modify channel modes and privileges;
  • Send messages on behalf of other users.

Using encrypted connections (such as TLS/SSL) would help mitigate this risk.

7.3 Denial of Service

The IRC protocol is vulnerable to various denial of service attacks:

Message Flooding: An attacker can flood a server with messages, consuming bandwidth and CPU resources.

Split Attacks: By causing network splits (disconnecting servers), an attacker can:

  • Create nickname collisions;
  • Take over channels;
  • Disrupt service.

Resource Exhaustion: Attackers can attempt to exhaust server resources by:

  • Creating many channels;
  • Joining many channels;
  • Setting many channel modes;
  • etc.

Servers SHOULD implement various protections against these attacks, such as:

  • Rate limiting;
  • Connection limits;
  • Flood protection;
  • Resource limits.

7.4 Channel Takeover

Because channel collisions are treated as inclusive events (all users from both channels are merged), it is possible for malicious users to "take over" channels by:

  • Causing a network split;
  • Creating a channel with the same name on the split network;
  • Gaining operator privileges;
  • Waiting for the network to rejoin.

When the networks rejoin, the malicious users will become part of the original channel, potentially with operator privileges. Various mechanisms have been proposed to address this issue:

  • Channel delay (See [IRC-CHAN]);
  • "Safe" channels (See [IRC-CHAN]);
  • Channel timestamps;
  • etc.

However, each mechanism has its own limitations and none completely solve the problem.

8. Current support and availability

Mailing lists for IRC related discussion:

Software implementations:

  • ftp://ftp.irc.org/irc/server
  • ftp://ftp.funet.fi/pub/unix/irc
  • ftp://coombs.anu.edu.au/pub/irc

Newsgroup: alt.irc

9. Acknowledgements

Parts of this document were copied from the RFC 1459 [IRC] which first formally documented the IRC Protocol. It has also benefited from many rounds of review and comments. In particular, the following people have made significant contributions to this document:

Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.

10. References

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.

[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.

[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.

[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.

11. Author's Address

Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
USA

EMail: kalt@stealth.net

12. Full Copyright Statement

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.

IRC
Lore

© SuperNETs 2026