RFC 2813
Internet Relay Chat: Server Protocol
Internet Relay Chat: Server Protocol 💖
Okay bestie, let's get into it 🎀 This is RFC 2813, written by C. Kalt and dated April 2000. It's labelled Informational, so it's giving "useful info" rather than an official Internet standard 🦋 It updates RFC 1459, the original IRC spec, so think of this one as its server-side sequel ✨
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 🌸
IRC is built on the client-server model, but it also lets servers connect to each other, effectively forming a network 🌐
This document defines the protocol servers use to talk to each other. It started out as a superset of the client protocol but has evolved in its own direction 💅
It was first formally documented in May 1993 as part of RFC 1459 [IRC], and most of the changes since then are in this document, because the focus was on making the protocol scale better 📈 That scalability is why existing worldwide networks have kept growing to sizes the old spec never imagined 😭🌍
Table of Contents 📚
1. Introduction ............................................... 3
2. Global database ............................................ 3
2.1 Servers ................................................ 3
2.2 Clients ................................................ 4
2.2.1 Users ............................................. 4
2.2.2 Services .......................................... 4
2.3 Channels ............................................... 4
3. The IRC Server Specification ............................... 5
3.1 Overview ............................................... 5
3.2 Character codes ........................................ 5
3.3 Messages ............................................... 5
3.3.1 Message format in Augmented BNF ................... 6
3.4 Numeric replies ........................................ 7
4. Message Details ............................................ 7
4.1 Connection Registration ................................ 8
4.1.1 Password message .................................. 8
4.1.2 Server message .................................... 9
4.1.3 Nick .............................................. 10
4.1.4 Service message ................................... 11
4.1.5 Quit .............................................. 12
4.1.6 Server quit message ............................... 13
4.2 Channel operations ..................................... 14
4.2.1 Join message ...................................... 14
4.2.2 Njoin message ..................................... 15
4.2.3 Mode message ...................................... 16
5. Implementation details .................................... 16
5.1 Connection 'Liveness' .................................. 16
5.2 Accepting a client to server connection ................ 16
5.2.1 Users ............................................. 16
5.2.2 Services .......................................... 17
5.3 Establishing a server-server connection. ............... 17
5.3.1 Link options ...................................... 17
5.3.1.1 Compressed server to server links ............ 18
5.3.1.2 Anti abuse protections ....................... 18
5.3.2 State information exchange when connecting ........ 18
5.4 Terminating server-client connections .................. 19
5.5 Terminating server-server connections .................. 19
5.6 Tracking nickname changes .............................. 19
5.7 Tracking recently used nicknames ....................... 20
5.8 Flood control of clients ............................... 20
5.9 Non-blocking lookups ................................... 21
5.9.1 Hostname (DNS) lookups ............................ 21
5.9.2 Username (Ident) lookups .......................... 21
6. Current problems ........................................... 21
6.1 Scalability ............................................ 21
6.2 Labels ................................................. 22
6.2.1 Nicknames ......................................... 22
6.2.2 Channels .......................................... 22
6.2.3 Servers ........................................... 22
6.3 Algorithms ............................................. 22
7. Security Considerations .................................... 23
7.1 Authentication ......................................... 23
7.2 Integrity .............................................. 23
8. Current support and availability ........................... 24
9. Acknowledgements ........................................... 24
10. References ................................................ 24
11. Author's Address .......................................... 25
12. Full Copyright Statement ................................... 261. Introduction ✨
This document is for people implementing an IRC server, but it's also useful if you're implementing an IRC service 🧚
Servers provide the three basic services needed for realtime conferencing, as defined in the "Internet Relay Chat: Architecture" [IRC-ARCH]. Those are client locator (handled by the client protocol [IRC-CLIENT]), message relaying (handled by the server protocol in this document), and channel hosting and management (which follows specific rules [IRC-CHAN]) 🫶
2. Global database 🌐
IRC has a pretty distributed model, but every server keeps a "global state database" about the whole IRC network. In theory, this database is identical on every server 👑
2.1 Servers
Servers are uniquely identified by their name, which can be at most sixty three (63) characters long. Check the protocol grammar rules (section 3.3.1) for what's allowed in a server name 💅
Every server is usually known to all the other servers, but you can define a "hostmask" to group servers together by name. Inside a hostmasked area, all the servers have names that match the hostmask, and any other server whose name matches the hostmask SHALL NOT be connected to the IRC network outside that area 🙈 Servers outside the area don't know about the individual servers inside it. They just see a virtual server whose name is the hostmask 🦋
2.2 Clients
For every client, all servers MUST have two things: a netwide unique identifier (its format depends on the type of client) and the server the client is connected to 💜
2.2.1 Users
Each user is told apart from other users by a unique nickname, up to nine (9) characters long. Check section 3.3.1 for what nicknames can contain 🎀 On top of the nickname, all servers MUST have this info about every user: the name of the host the user is on, the user's username on that host, and the server the user is connected to 📝
2.2.2 Services
Each service is identified by a service name made of a nickname and a server name. The nickname can be at most nine (9) characters, and section 3.3.1 has the rules for what's allowed. The server name in the service name is the name of the server the service is connected to. Along with this service name, all servers MUST know the service type 🍓
Services are different from users in two ways. First, the format of their identifier is different. More importantly, they don't get the same access to the server. Services can ask for some or all of the global state information a server keeps, and they get a more restricted set of commands (see "IRC Client Protocol" [IRC-CLIENT] for the details). They also aren't allowed to join channels 🚫 Finally, services usually aren't subject to the "Flood control" mechanism in section 5.8 🛡️
2.3 Channels
Just like services, channels have a scope [IRC-CHAN], and not every server necessarily knows about every channel. When a server knows a channel exists, it MUST keep track of the channel's members and its channel modes 📊
3. The IRC Server Specification 🛠️
3.1 Overview
This protocol is for server-to-server connections. For client-to-server connections, check out the IRC Client Protocol specification 💻
Heads up though: client connections get more restrictions than server connections, because clients are considered untrustworthy 👀
3.2 Character codes
No specific character set is defined here. The protocol is based on codes made of eight (8) bits, which together make an octet. A message can be any number of these octets, but some octet values are used as control codes that act as message delimiters 🔢
Even though it's an 8-bit protocol, the delimiters and keywords are designed so the protocol is mostly usable from a US-ASCII terminal and a telnet connection 📟✨
Because IRC has Scandinavian roots, the characters {}|^ are treated as the lowercase equivalents of []\~, respectively. This matters a lot when you're deciding whether two nicknames or channel names are the same, so don't skip it 🧐🔥
3.3 Messages
okay so servers and clients send each other messages 💌, and some of them get a reply while others don't 🙈. ngl most server-to-server chatter gets NO reply at all, because servers are mostly just routing stuff for the clients 🚚✨
Each IRC message can have up to three main parts: the prefix (OPTIONAL) 🎀, the command, and the command parameters (max fifteen (15) of them 💅). The prefix, the command, and every parameter are each separated by one ASCII space character (0x20).
A prefix is marked by a single leading ASCII colon (:, 0x3b), and that colon MUST be the very first character of the message itself 🦋. There MUST be NO gap (whitespace) between the colon and the prefix. The prefix is how servers show the true origin of a message 👑. If there's no prefix, the message is assumed to have come from whatever connection it arrived on. Clients SHOULD not use a prefix when they're sending something from themselves. If they do use one, the only valid prefix is their registered nickname 💖.
When a server gets a message, it MUST work out where it came from using the (eventually assumed) prefix. If the prefix isn't in the server's internal database, the message MUST be discarded. And if the prefix says the message came from an (unknown) server, the link it arrived on MUST be dropped. Dropping a link is kinda extreme 😭, but it's needed to keep the network healthy and stop future problems 🛡️.
Another common error is when the prefix is in the database but points to a different source. That's usually a source registered from a different link than the one the message came in on. If the message came from a server link and the prefix identifies a client, a KILL message MUST be issued for that client and sent to all servers. In other cases, the link the message arrived on SHOULD be dropped for clients, and MUST be dropped for servers. In every case, the message MUST be discarded 🗑️.
The command MUST either be a valid IRC command or a three (3) digit number written in ASCII text 🔢.
IRC messages are always lines of characters ending in a CR-LF (Carriage Return - Line Feed) pair 📜. They SHALL NOT exceed 512 characters in length, and that count includes every character, even the trailing CR-LF 📏. So the command and its parameters get 510 characters max. There's no provision for continuation lines, so no splitting a message across lines, sorry bestie 🙃. See section 5 for more details about current implementations.
3.3.1 Message format in Augmented BNF
the protocol messages have to be pulled out of the contiguous stream of octets 🌊. The current solution is to use two characters, CR and LF, as message separators. Empty messages are silently ignored 🤫, which means you can use the CR-LF sequence between messages without any extra problems 🌸.
Once extracted, the message gets parsed into the components <prefix>, <command> and a list of parameters (<params>) ✨.
The Augmented BNF representation for this is found in "IRC Client Protocol" [IRC-CLIENT] 📖.
The extended prefix (["!" user "@" host ]) MUST NOT be used in server to server communications 🚫. It's only meant for server to client messages, so clients can see more useful info about who a message is from without needing extra queries 🧚.
3.4 Numeric replies
most of the messages sent to a server generate some kind of reply 💬. The most common one is the numeric reply, which is used for both errors and normal replies 🔥. A numeric reply MUST be sent as one message made up of the sender prefix, the three digit numeric, and the target of the reply. A numeric reply is NOT allowed to come from a client, and any that a server receives get silently dropped 🙅♀️. In every other way, a numeric reply is just like a normal message, except the keyword is made of 3 numeric digits instead of a string of letters 🔢💖. A list of the different replies is in "IRC Client Protocol" [IRC-CLIENT] 📚.
4. Message Details ✨
all the messages recognized by the IRC server and client are described in the IRC Client Protocol specification 📖.
When the reply ERR_NOSUCHSERVER comes back, it means the target of the message couldn't be found 🔍. The server MUST NOT send any other replies after this error for that command 🛑.
The server a client is connected to is REQUIRED to parse the complete message and return any appropriate errors 🧐. If the server hits a fatal error while parsing, an error MUST be sent back to the client and the parsing stops 💀. A fatal error can come from an incorrect command, a destination the server doesn't know (server, client or channel names count here), not enough parameters, or incorrect privileges 🙈.
If a full set of parameters is presented, each one MUST be checked for validity, and appropriate responses MUST be sent back to the client 🎯. For messages whose parameter lists use a comma as the item separator, a reply MUST be sent for each item 💅.
In the examples below, some messages show up in the full format:
:Name COMMAND parameter listThese examples are a message from "Name" in transit between servers 📨. Including the name of the original sender is essential, so remote servers can send a reply back along the correct path 🛤️.
The message details for client to server communication are described in the "IRC Client Protocol" [IRC-CLIENT] 💌. Some sections on the following pages apply to some of these messages. They're additions to the message specs that only matter for server to server communication, or for the server implementation 🛠️. The messages introduced here are ONLY used for server to server communication 🦋.
4.1 Connection Registration
the commands here are used to register a connection with another IRC server 🤝.
4.1.1 Password message
Command: PASS
Parameters: <password> <version> <flags> [<options>]The PASS command sets a 'connection password' 🔐. The password MUST be set before any attempt to register the connection is made. Right now that means servers MUST send a PASS command before any SERVER command 🙌. Only one (1) PASS command SHALL be accepted from a connection 🚫.
The last three (3) parameters MUST be ignored if they're received from a client (like a user or a service) 🙅♀️. They only matter when they come from a server 💅.
The <version> parameter is a string of at least four (4) characters and up to fourteen (14) characters 🔢. The first four (4) characters MUST be digits and show the protocol version the issuing server knows about 🌈. The protocol in this document is version 2.10, which is encoded as "0210" ✨. The remaining OPTIONAL characters are implementation dependent, and they should describe the software version number 🎀.
The <flags> parameter is a string of up to one hundred (100) characters 💜. It's made of two substrings separated by the character "|" (%x7C). If present, the first substring MUST be the name of the implementation. The reference implementation (See Section 8, "Current support and availability") uses the string "IRC" 👑. If a different implementation is written that needs an identifier, that identifier should be registered through publication of an RFC 📜. The second substring is implementation dependent. Both substrings are OPTIONAL, but the character "|" is REQUIRED 🫶. The character "|" MUST NOT appear in either substring 🚫.
Last but not least, the <options> parameter is for link options 🔗. The only options the protocol defines are link compression (using the character "Z") and an abuse protection flag (using the character "P") 🛡️. For more on these, see sections 5.3.1.1 (Compressed server to server links) and 5.3.1.2 (Anti abuse protections) respectively 📖.
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTREDExample:
PASS moresecretpassword 0210010000 IRC|aBgH$ Z4.1.2 Server message
Command: SERVER
Parameters: <servername> <hopcount> <token> <info>The SERVER command registers a new server 🌳. A new connection introduces itself to its peer as a server 🦋. This message is also used to pass server data over the whole net 🌐. When a new server connects to the net, information about it MUST be broadcast to the whole network 📣.
The <info> parameter may contain space characters 💫.
<hopcount> tells all the servers how far away each server is 📏. Local peers have a value of 0, and each server that gets passed along increments the value 🔢. With a full server list you could map the entire server tree, but hostmasks stop that from happening 🙈.
The <token> parameter is an unsigned number servers use as an identifier 🪪. That identifier is then used to reference a server in the NICK and SERVICE messages sent between servers 💌. Server tokens only mean something for the point-to-point peering they're used on, so they MUST be unique for that connection. They are NOT global 🌍.
The SERVER message MUST only be accepted from either (a) a connection that isn't registered yet and is trying to register as a server, or (b) an existing connection to another server, in which case the SERVER message is introducing a new server behind that server 🚪.
Most errors that happen when a SERVER command is received end with the destination host (target SERVER) terminating the connection 💥. Because it's such a serious event, error replies are usually sent with the "ERROR" command instead of a numeric 😬.
If a SERVER message is parsed and tries to introduce a server that the receiving server already knows, the connection the message arrived from MUST be closed (following the correct procedures) 🚨. That's because a duplicate route to a server has formed, and the acyclic nature of the IRC tree breaks 🌀. In some conditions, the connection the already known server registered on MAY be closed instead 🔄. This kind of error can also come from a second running server 👀. That problem can't be fixed within the protocol and usually needs a human to step in 🧑💻. It's especially sneaky, because it can easily split part of the IRC network off, and then the two servers on each side of the split can't reconnect to unite 💔.
Numeric Replies:
ERR_ALREADYREGISTREDExample:
SERVER test.oulu.fi 1 1 :Experimental server ; New server
test.oulu.fi introducing itself and
attempting to register.
:tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server
tolsun.oulu.fi is our uplink for
csd.bu.edu which is 5 hops away. The
token "34" will be used by
tolsun.oulu.fi when introducing new
users or services connected to
csd.bu.edu.4.1.3 Nick
Command: NICK
Parameters: <nickname> <hopcount> <username> <host> <servertoken>
<umode> <realname>okay so this NICK form is strictly for servers 🖥️ it MUST NOT be allowed from user connections. Users never get to send it. But it MUST be used instead of the NICK/USER pair when servers tell each other about new users joining the IRC network 🫶
This message is basically three messages in a trench coat: NICK, USER and MODE [IRC-CLIENT] 🧥✨
The <hopcount> parameter tells servers how far away a user is from its home server. A local connection has a hopcount of 0, and every server it passes through bumps the count up by one 🦋
The <servertoken> parameter takes the place of the USER message's <servername> parameter. (See section 4.1.2 for more on server tokens 💅)
Examples:
NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New
user with nickname "syrk", username
"kalt", connected from host
"millennium.stealth.net" to server
"34" ("csd.bu.edu" according to the
previous example).
:krys NICK syrk ; The other form of the NICK message,
as defined in "IRC Client Protocol"
[IRC-CLIENT] and used between
servers: krys changed his nickname to
syrkThe first one is a brand new user named syrk, username kalt, connecting from millennium.stealth.net to server 34 (which is csd.bu.edu in the previous example) 🌸 The second is the other NICK form, the one from the IRC Client Protocol [IRC-CLIENT] that servers pass around. Here krys switched his nickname to syrk. Iconic name change 💀
4.1.4 Service message
Command: SERVICE
Parameters: <servicename> <servertoken> <distribution> <type>
<hopcount> <info>The SERVICE command introduces a brand new service 🧚 This form of the SERVICE message SHOULD NOT be allowed from client connections, whether they're unregistered or registered. But it MUST be used between servers to tell each other about new services joining the IRC network 💜
The <servertoken> tells everyone which server the service is plugged into. (See section 4.1.2 for more on server tokens ✨)
The <hopcount> works just like it does for users. It shows how far away a service is from its home server. A local connection has a hopcount of 0, and each server passed adds one 🍓
The <distribution> parameter controls who gets to see the service, which is giving very exclusive 👑 The service may only be known to servers whose names match the distribution. For a matching server to know about the service, every server on the network path between it and the service's server MUST have a name that matches the mask. Plain "*" means no restriction at all 🌈
The <type> parameter is reserved for future use right now 🔮
Numeric Replies:
ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
ERR_ERRONEUSNICKNAME
RPL_YOURESERVICE RPL_YOURHOST
RPL_MYINFOExample:
SERVICE dict@irc.fr 9 *.fr 0 1 :French Dictionary r" registered on
server "9" is being announced to
another server. This service will
only be available on servers whose
name matches "*.fr".So this one announces a French dictionary service registered on server "9" to another server. It only shows up on servers whose names match "*.fr" 🇫🇷📖 Very cute, very exclusive 🎀
4.1.5 Quit
Command: QUIT
Parameters: [<Quit Message>]A client session ends with a quit message 👋 The server MUST close the connection to any client that sends a QUIT message, no exceptions 🚪 If a "Quit Message" is given, it gets shown instead of the default message, which is just the nickname or the service name.
When a "netsplit" (See Section 4.1.6) happens, the "Quit Message" is made of the names of the two servers involved, separated by a space. The first name belongs to the server that's still connected. The second name is either the server that just dropped off, or the server the leaving client was connected to 💔
<Quit Message> = ":" servername SPACE servernameBecause the "Quit Message" has a special meaning during netsplits, servers SHOULD NOT let a client use a <Quit Message> in the format above 🙅♀️
If a client connection closes without the client ever sending QUIT (say the client crashes and EOF hits the socket 💀), the server is REQUIRED to fill in the quit message with something that reflects what happened. Usually that means reporting a system-specific error 🛠️
Numeric Replies:
None.Examples:
:WiZ QUIT :Gone to have lunch ; Preferred message format.Honestly this is so clean 🍰 WiZ leaves with "Gone to have lunch", which is the preferred format.
4.1.6 Server quit message
Command: SQUIT
Parameters: <server> <comment>SQUIT has two very different jobs 🎭
The first one (described in "Internet Relay Chat: Client Protocol" [IRC-CLIENT]) lets operators break a local or remote server link. Servers also end up using this form to break a remote server link eventually 🔌
The second job is for when a "network split" (also called a "netsplit") happens. It tells the other servers that some servers have quit or died. If a server wants to drop its connection to another server, it MUST send a SQUIT message to that other server, using the other server's name as the server parameter. The other server then closes its connection to the quitting one 💅
The <comment> gets filled in by servers, which SHOULD put an error or similar message in there 📝
Both servers on either side of the closing connection are REQUIRED to send out a SQUIT message, to all their other server connections, for every server considered to be behind that link. Lowkey a lot of paperwork, but it keeps everyone in sync 🗂️
A QUIT message MAY also be sent to the other connected servers on behalf of every client behind the quitting link. On top of that, every channel member in a channel that lost someone to the "split" MUST be sent a QUIT message. Those messages to channel members get generated by each client's local server 📣
If a server connection ends prematurely (for example, the server on the other end died), the server that notices the disconnect is REQUIRED to tell the rest of the network that the connection closed, and to fill in the comment field with something appropriate 🫠
When a client gets removed because of a SQUIT message, the server SHOULD add that nickname to its list of temporarily unavailable nicknames. The goal is to prevent future nickname collisions. See section 5.7 (Tracking recently used nicknames) for more on how this works 🕵️♀️
Numeric replies:
ERR_NOPRIVILEGES ERR_NOSUCHSERVER
ERR_NEEDMOREPARAMSExample:
SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi
has been terminated because of "Bad
Link".
:Trillian SQUIT cm22.eng.umd.edu :Server out of control ; message
from Trillian to disconnect
"cm22.eng.umd.edu" from the net
because "Server out of control".The first example drops the tolsun.oulu.fi link for "Bad Link ?". The second one is Trillian dragging cm22.eng.umd.edu off the net for being "Server out of control" 😭 Iconic behaviour from the chaos bestie.
4.2. Channel operations
This group of messages is all about channels 🎀 their properties (channel modes) and their contents (usually users). Race conditions are basically inevitable here. When users on opposite ends of the network send commands that end up clashing, things get messy 🌀 It is also REQUIRED that servers keep a nickname history, so that wherever a <nick> parameter shows up, the server checks its history in case that nickname was changed recently 🕰️
4.2.1 Join message
Command: JOIN
Parameters: <channel>[ %x7 <modes> ]
*( "," <channel>[ %x7 <modes> ] )JOIN is how a client starts listening to a specific channel 👂 Only the local server the client is connected to checks whether that client is allowed to join. Every other server just adds the user to the channel automatically when the command comes in from another server 🤝
Optionally, the user's status on the channel (channel modes 'O', 'o', and 'v') can be tacked onto the channel name, using a control G (^G or ASCII 7) as the separator 🔔 Data like this MUST be ignored if the message didn't come from a server. This format MUST NOT be sent to clients. It's only meant for server-to-server use, and SHOULD be avoided 🙈
The JOIN command MUST be broadcast to all servers, so each server knows where to find the users on the channel. That's what makes delivering PRIVMSG and NOTICE messages to the channel so efficient 🚀
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE
RPL_TOPICExamples:
:WiZ JOIN #Twilight_zone ; JOIN message from WiZWiZ joining #Twilight_zone is literally the whole vibe 🌙
4.2.2 Njoin message
Command: NJOIN
Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
*( "," [ "@@" / "@" ] [ "+" ] <nickname> )NJOIN is strictly server-to-server 🛰️ If a client ever sends one, it MUST be ignored. Servers use it when they connect to each other, to swap lists of channel members for each channel 🫂
You could do the same thing with a whole bunch of JOINs, but this message SHOULD be used instead, because it's more efficient ⚡ The "@@" prefix marks a user as the "channel creator". A lone "@" marks a "channel operator", and "+" marks someone with the voice privilege 🎤
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_ALREADYREGISTREDExamples:
:ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN
message from ircd.stealth.net
announcing users joining the
#Twilight_zone channel: WiZ with
channel operator status, syrk with
voice privilege and avalon with no
privilege.ircd.stealth.net announces that WiZ joins #Twilight_zone as a channel operator, syrk joins with voice, and avalon joins with no privileges at all 🎀
4.2.3 Mode message
The MODE message is a dual-purpose command in IRC 🪄 It lets you change the modes of both users and channels.
When parsing MODE messages, it is RECOMMENDED to parse the entire message first, and then pass on the changes that resulted from it 🧠
It is REQUIRED that servers can change channel modes, so that "channel creator" and "channel operators" can be created 👑
5. Implementation details ✨
At the time of writing, the only current implementation of this protocol is the IRC server, version 2.10 💻 Earlier versions may implement some or all of the commands in this document, with NOTICE messages replacing a lot of the numeric replies. Unfortunately, because of backward compatibility requirements, some parts of this document get implemented differently than what's laid out here. One notable difference is:
- recognition that any LF or CR anywhere in a message marks the end of that message (instead of requiring CR-LF);
The rest of this section deals with issues that matter mostly to people who want to implement a server, though some parts also apply directly to clients 🫶
5.1 Connection 'Liveness' 💖
okay so bestie, to figure out if a connection has ghosted us 👻 or is straight up dead, the server MUST poll each of its connections. The PING command (See "IRC Client Protocol" [IRC-CLIENT]) gets used if the server doesn't hear back from its peer within a given amount of time.
If a connection doesn't respond in time, it gets closed using the appropriate procedures. 🫶
5.2 Accepting a client to server connection ✨
5.2.1 Users
okay this is the moment 🎀 When a server successfully registers a new user connection, it is REQUIRED to send the user messages that are totally unambiguous (no confusion, bestie) saying: the user identifiers it was registered under (RPL_WELCOME), the server name and version (RPL_YOURHOST), the server birth info (RPL_CREATED), and the available user and channel modes (RPL_MYINFO). It MAY also send any intro messages that seem appropriate.
Specifically, the server SHALL send the current user/service/server count (as per the LUSER reply) and then the MOTD (if there is one, as per the MOTD reply). 💅
After registration is handled, the server MUST send to other servers the new user's nickname (NICK message), the other info the user supplied (USER message), and whatever it could figure out (from DNS servers). The server MUST NOT send this info as a pair of NICK and USER messages like they're defined in "IRC Client Protocol" [IRC-CLIENT]. Instead, it MUST take advantage of the extended NICK message from section 4.1.3. 🦋
5.2.2 Services
Once a new service connection registers successfully, the server is subject to the same kind of requirements as for a user. Services are a little different though, so only these replies get sent: RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO. 🧚
After that, the server MUST send to other servers (SERVICE message) the new service's nickname and the info the service supplied itself (SERVICE message), plus anything the server could find out (from DNS servers).
5.3 Establishing a server-server connection. 🌸
Honestly this is lowkey a minefield 💀 Setting up a server-to-server connection is fraught with danger, since there are so many spots where stuff can go wrong, and race conditions are literally the least of it.
After a server has received a connection followed by a PASS/SERVER pair that was recognized as valid, the server SHOULD reply with its own PASS/SERVER info for that connection, plus all the other state info it knows about, as described below.
When the initiating server gets a PASS/SERVER pair, it also checks that the responding server is authenticated properly before accepting the connection as that server. 🔐
5.3.1 Link options
Server links are based on a common protocol (defined by this document), but a particular link MAY set specific options using the PASS message (See Section 4.1.1). ✨
5.3.1.1 Compressed server to server links
If a server wants a compressed link with its peer, it MUST set the 'Z' flag in the options parameter to the PASS message. If both servers request compression and both can initialize the two compressed streams, then the rest of the communication gets compressed. If any server fails to initialize the stream, it will send an uncompressed ERROR message to its peer and close the connection. 📦
The data format used for compression is described by RFC 1950 [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].
5.3.1.2 Anti abuse protections
Most servers have protections against possibly abusive behaviours from non trusted parties (typically users). On some networks these protections are absolutely essential, and on others they're just superfluous. To require that all servers implement and enable these features on a particular network, the 'P' flag is used when two servers connect. If this flag is present, it means the server protections are enabled, and that the server REQUIRES all its server links to enable them as well. 🛡️
Commonly found protections are described in sections 5.7 (Tracking recently used nicknames) and 5.8 (Flood control of clients).
5.3.2 State information exchange when connecting
The order of state info being exchanged between servers is essential 🌈 The REQUIRED order is as follows:
- all known servers;
- all known client information;
- all known channel information.
Info about servers is sent via extra SERVER messages, client info with NICK and SERVICE messages, and channels with NJOIN/MODE messages.
NOTE: channel topics SHOULD NOT be exchanged here, because the TOPIC command overwrites any old topic information, so at best the two sides of the connection would just swap topics. 🙃
By passing the state info about servers first, any collisions with servers that already exist happen before nickname collisions caused by a second server introducing a particular nickname. Since the IRC network can only exist as an acyclic graph, it may be possible that the network has already reconnected in another location. In that case, the place where the server collision occurs shows where the net needs to split. 🧩
5.4 Terminating server-client connections 👋
When a client connection unexpectedly closes, a QUIT message is generated on behalf of the client by the server the client was connected to. No other message is to be generated or used.
5.5 Terminating server-server connections
If a server-server connection is closed, either via a SQUIT command or "natural" causes, the rest of the connected IRC network MUST have its information updated by the server that detected the closure. The terminating server then sends a list of SQUITs (one for each server behind that connection). (See Section 4.1.6 (SQUIT)). 💫
5.6 Tracking nickname changes
All IRC servers are REQUIRED to keep a history of recent nickname changes. This is important so the server has a chance of keeping in touch with things when nick-change race conditions happen with commands that manipulate nicks. Messages which MUST trace nick changes are:
- KILL (the nick being disconnected)
- MODE (+/- o,v on channels)
- KICK (the nick being removed from channel)
No other commands need to check nick changes.
In the above cases, the server is required to first check for the existence of the nickname, then check its history to see who that nick now belongs to (if anyone!). This reduces the chances of race conditions, but they can still occur, with the server ending up affecting the wrong client. When performing a change trace for an above command, it is RECOMMENDED that a time range be given and entries which are too old ignored.
For a reasonable history, a server SHOULD be able to keep the previous nickname for every client it knows about, in case they all decided to change. This size is limited by other factors (such as memory, etc). 🧠
5.7 Tracking recently used nicknames
This mechanism is commonly known as "Nickname Delay". It has been proven to significantly reduce the number of nickname collisions resulting from "network splits"/reconnections, as well as abuse. 🙅♀️
In addition to tracking nickname changes, servers SHOULD keep track of nicknames which were recently used and were released as the result of a "network split" or a KILL message. These nicknames are then unavailable to the server's local clients and cannot be re-used (even though they are not currently in use) for a certain period of time.
The duration for which a nickname remains unavailable SHOULD be set considering many factors, among which are the size (user wise) of the IRC network and the usual duration of "network splits". It SHOULD be uniform on all servers for a given IRC network. ⏳
5.8 Flood control of clients
With a large network of interconnected IRC servers, it's super easy for any single client attached to the network to send a continuous stream of messages. That can flood the network and also degrade the service others get. Rather than require every 'victim' to provide their own protection, flood protection was written into the server and is applied to all clients except services. The current algorithm is as follows:
- check to see if client's `message timer' is less than current time (set to be equal if it is);
- read any data present from the client;
- while the timer is less than ten (10) seconds ahead of the current time, parse any present messages and penalize the client by two (2) seconds for each message;
- additional penalties MAY be used for specific commands which generate a lot of traffic across the network.
This basically means the client may send one (1) message every two (2) seconds without being adversely affected. Services MAY also be subject to this mechanism. 🚦
5.9 Non-blocking lookups
In a real-time environment, it's essential that a server process does as little waiting as possible so all the clients get serviced fairly. This obviously requires non-blocking IO on all network read/write operations. For normal server connections this wasn't too hard, but there are other support operations that may cause the server to block (such as disk reads). Where possible, such activity SHOULD be performed with a short timeout. ⚡
5.9.1 Hostname (DNS) lookups
Using the standard resolver libraries from Berkeley and others meant big delays in some cases where replies timed out. To avoid this, a separate set of DNS routines was written for the current implementation. Routines were set up for non-blocking IO operations with a local cache, and then polled from within the main server IO loop. 🌐
5.9.2 Username (Ident) lookups
There are plenty of ident libraries (implementing the "Identification Protocol" [IDENT]) for use and inclusion in other programs, but these caused problems since they operated in a synchronous manner and caused frequent delays. Again, the solution was to write a set of routines that would cooperate with the rest of the server and work using non-blocking IO. 🔍
6. Current problems 🚧
There are a number of recognized problems with this protocol, all of which are hoped to be solved sometime in the near future during its rewrite. Currently, work is underway to find working solutions to these problems.
6.1 Scalability
It is widely recognized that this protocol doesn't scale well enough when used in a large arena. The main problem comes from the requirement that all servers know about all other servers and clients, and that information regarding them be updated as soon as it changes. It's also desirable to keep the number of servers low, so the path length between any two points stays minimal and the spanning tree is as strongly branched as possible. 📈
6.2 Labels
The current IRC protocol has 4 types of labels: the nickname, the channel name, the server name and the service name. Each of the four types has its own domain, and no duplicates are allowed inside that domain. Right now, users can pick the label for any of the first three, which results in collisions. It's widely recognized that this needs reworking, with a plan for unique names for nicks that don't collide being desirable, as well as a solution allowing a cyclic tree. 🌟
6.2.1 Nicknames ✨
okay so nicknames on IRC are literally so convenient 💖 you use them to talk to each other outside of a channel, but there's only a finite nickname space, and it's not uncommon for several people to want the same nick 😭 if two people pick the same nickname using this protocol, either one won't succeed, or both get removed with a KILL (see Section 3.7.1 of "IRC Client Protocol" [IRC-CLIENT]) 💀
6.2.2 Channels 🌸
the current channel layout means every server has to know about every channel, who's in it, and its properties 👀 which is giving "not scaling well" and also "privacy is a concern" 🙈 and a channel collision gets treated as an inclusive event (people from both nets in a channel with the same name are all considered members of it), not an exclusive one like the way nickname collisions get handled 🦋
this protocol defines "Safe Channels" which are very unlikely to ever be the subject of a channel collision 💅 the other channel types are kept around for backward compatibility 🫶
6.2.3 Servers 🧚
servers are usually few compared to the number of users and channels, but they're still currently REQUIRED to be known globally, either each one separately or hidden behind a mask 🌈
6.3 Algorithms 💜
in some places in the server code it hasn't been possible to avoid N^2 algorithms, like checking the channel list of a set of clients 😩
there are only a few database consistency checks in current server versions 😬 most of the time each server just assumes a neighbouring server is correct 🥺 which opens the door to big problems if a connecting server is buggy or tries to introduce contradictions into the existing net 💀
right now, because there aren't unique internal and global labels, there are a multitude of race conditions 🌪️ these mostly come from the fact that it takes time for messages to traverse the network and take effect 🐢 even switching to unique labels wouldn't fully fix it, since channel-related commands can still get disrupted 🙃
7. Security Considerations 🔐
7.1 Authentication 🗝️
okay this part is a little scary tbh 😭 servers only have two ways to authenticate incoming connections: a plain text password, and DNS lookups 💀 both are weak and widely recognized as unsafe, but their combination has been sufficient in the past, so here's how it's been going:
- public networks typically allow user connections with only a few restrictions, without requiring accurate authentication 🌍
- private networks that operate in a controlled environment often use home-grown authentication mechanisms that aren't available on the internet, like reliable ident servers [IDENT], or other proprietary mechanisms 🏠
the same comments apply to the authentication of IRC Operators 👑
it's also worth noting that even though there's never been real demand over the years for stronger authentication, and no real effort to provide better ways to safely authenticate users, the current protocol offers enough to easily plug in external authentication methods 🔌 based on the information a client can submit to the server on connection: nickname, username, password 🫶
7.2 Integrity 🔒
since the PASS and OPER messages of the IRC protocol are sent in clear text 😱 a stream layer encryption mechanism (like "The TLS Protocol" [TLS]) could be used to protect these transactions 💜
8. Current support and availability 📬
mailing lists for IRC stuff:
General discussion: ircd-users@irc.org
Protocol development: ircd-dev@irc.orgsoftware implementations:
ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/ircnewsgroup: alt.irc 🗞️
9. Acknowledgements 🫶
parts of this document were copied from RFC 1459 [IRC], which first formally documented the IRC Protocol 🙌 it has also benefited from many rounds of review and comments 💖 in particular, these people 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.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 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.
[ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996.
[DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996.
[GZIP] Deutsch, P., "GZIP file format specification version
4.3", RFC 1952, May 1996.
[IDENT] St. Johns, M., "The Identification Protocol", RFC 1413,
February 1993.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
January 1999.11. Author's Address 🎀
Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
USA
EMail: kalt@stealth.net12. Full Copyright Statement ©️
Copyright (C) The Internet Society (2000). All Rights Reserved. 🌸
okay so this document and translations of it may be copied and furnished to others 📄 and derivative works that comment on or otherwise explain it, or help with its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind 🦋 the only condition is 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, like by removing the copyright notice or references to the Internet Society or other Internet organizations 🚫 except as needed for 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 in it 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 💜
📦 where this page comes from
- ietf: rfc2813 2000-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms