Internet Draft C. KaltExpires: 22 Jan 2000 22 Jul 1999Internet Relay Chat: Server Protocoldraft-kalt-irc-server-01.txtStatus of this Memo This document is an Internet-Draft and is in full conformance with all provisions ofSection 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described inRFC 2119 [KEYWORDS].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 ofRFC 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.Kalt [Page 1]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 Table of Contents1. Introduction ...............................................32. Global database ............................................32.1 Servers ................................................32.2 Clients ................................................32.2.1 Users .............................................32.2.2 Services ..........................................42.3 Channels ...............................................43. The IRC Server Specification ...............................53.1 Overview ...............................................53.2 Character codes ........................................53.3 Messages ...............................................53.3.1 Message format in Augmented BNF ...................63.4 Numeric replies ........................................64. Message Details ............................................84.1 Connection Registration ................................84.1.1 Password message ..................................84.1.2 Server message ....................................94.1.3 Nick ..............................................114.1.4 Service message ...................................114.1.5 Quit ..............................................124.1.6 Server quit message ...............................134.2 Channel operations .....................................154.2.1 Join message ......................................154.2.2 Njoin message .....................................164.2.3 Mode message ......................................165. Implementation details ....................................175.1 Connection 'Liveness' ..................................175.2 Accepting a client to server connection ................175.2.1 Users .............................................175.2.2 Services ..........................................185.3 Establishing a server-server connection. ...............185.3.1 Link options ......................................185.3.1.1 Compressed server to server links ............185.3.1.2 Anti abuse protections .......................185.3.2 State information exchange when connecting ........195.4 Terminating server-client connections ..................195.5 Terminating server-server connections ..................195.6 Tracking nickname changes ..............................205.7 Tracking recently used nicknames .......................205.8 Flood control of clients ...............................215.9 Non-blocking lookups ...................................215.9.1 Hostname (DNS) lookups ............................21Kalt [Page 2]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 19995.9.2 Username (Ident) lookups ..........................226. Current problems ...........................................236.1 Scalability ............................................236.2 Labels .................................................236.2.1 Nicknames .........................................236.2.2 Channels ..........................................236.2.3 Servers ...........................................246.3 Algorithms .............................................247. Security Considerations ....................................247.1 Authentication .........................................247.2 Integrity ..............................................258. Current support and availability ...........................259. Acknowledgements ...........................................2510. References ................................................2511. Author's Address ..........................................26Kalt [Page 3]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 19991. Introduction This document is intended for people working on implementing an IRC server but will also be useful to anyone implementing an IRC service. Servers provide the three basic services required for realtime conferencing defined by the "Internet Relay Chat: Architecture" [IRC- ARCH]: client locator (via the client protocol [IRC-CLIENT]), message relaying (via the server protocol defined in this document) and channel hosting and management (following specific rules [IRC-CHAN]).2. Global database Although the IRC Protocol defines a fairly distributed model, each server maintains a "global state database" about the whole IRC network. This database is, in theory, identical on all servers.2.1 Servers Servers are uniquely identified by their name which has a maximum length of sixty three (63) characters. See the protocol grammar rules (section 3.3.1) for what may and may not be used in a server name. Each server is typically known by all other servers, however it is possible to define a "hostmask" to group servers together according to their name. Inside the hostmasked area, all the servers have a name which matches the hostmask, and any other server with a name matching the hostmask SHALL NOT be connected to the IRC network outside the hostmasked area. Servers which are outside the area have no knowledge of the individual servers present inside the area, instead they are presented with a virtual server which has the hostmask for name.2.2 Clients For each client, all servers MUST have the followin information: a netwide unique identifier (whose format depends on the type of client) and the server to which the client is connected.2.2.1 Users Each user is distinguished from other users by a unique nickname having a maximum length of nine (9) characters. See the protocol grammar rules (section 3.3.1) for what may and may not be used in a nickname. In addition to the nickname, all servers MUST have the following information about all users: the name of the host that theKalt [Page 4]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 user is running on, the username of the user on that host, and the server to which the client is connected.2.2.2 Services Each service is distinguished from other services by a service name composed of a nickname and a server name. The nickname has a maximum length of nine (9) characters. See the protocol grammar rules (section 3.3.1) for what may and may not be used in a nickname. The server name used to compose the service name is the name of the server to which the service is connected. In addition to this service name all servers MUST know the service type. Services differ from users by the format of their identifier, but more importantly services and users don't have the same type of access to the server: services can request part or all the global state information that a server maintains, but are not allowed to join channels and have a more restricted set of commands available to them (See "IRC Client Protocol" [IRC-CLIENT] for details on which). Finally services are not usually subject to the "Flood control" mechanism described insection 5.8.2.3 Channels Alike services, channels have a scope [IRC-CHAN] and are not necessarily known to all servers. When a channel existence is known to a server, the server MUST keep track of the channel members, as well as the channel modes.Kalt [Page 5]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 19993. The IRC Server Specification3.1 Overview The protocol as described herein is for use with server to server connections. For client to server connections, see the IRC Client Protocol specification. There are, however, more restrictions on client connections (which are considered to be untrustworthy) than on server connections.3.2 Character codes No specific character set is specified. The protocol is based on a 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. Most communication between servers do not generate any reply, as servers mostly perform routing tasks for the clients. 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. If the prefix is missing from the message, it is assumed to have originated from the connection from which it was received. Clients SHOULD not use a prefix when sending a message from themselves; if they use one, the only valid prefix is the registered nickname associated with the client.Kalt [Page 6]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 When a server receives a message, it MUST identify its source using the (eventually assumed) prefix. If the prefix cannot be found in the server's internal database, it MUST be discarded, and if the prefix indicates the message comes from an (unknown) server, the link from which the message was receveived MUST be dropped. Dropping a link in such circumstances is a little excessive but necessary to maintain the integrity of the network and prevent future problems. Another common error condition is that the prefix is found in the server's internal database identifies a different source (typically a source registered from a different link than from which the message arrived). If the message was received from a server link and the prefix identifies a client, a KILL message MUST be issued for the client and sent to all servers. In other cases, the link from which the message arrived SHOULD be dropped for clients, and MUST be dropped for servers. In all cases, the message MUST be discarded. 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 message lines. Seesection 5 for more details about current implementations.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 <prefix>, <command> and 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 and is only intended for server to client messages in order to provide clients with more useful information about who a message is from without the need for additional queries.3.4 Numeric repliesKalt [Page 7]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 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. The numeric reply MUST be sent as one message consisting of the sender prefix, the three digit numeric, and the target of the reply. A numeric reply is not allowed to originate from a client; any such messages received by a server are silently dropped. In all other respects, a numeric reply is just like a normal message, except that the keyword is made up of 3 numeric digits rather than a string of letters. A list of different replies is supplied in "IRC Client Protocol" [IRC-CLIENT].Kalt [Page 8]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 19994. Message Details All the messages recognized by the IRC server and client are described in the IRC Client Protocol specification. 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. The server to which a client is connected is required to parse the complete message, returning any appropriate errors. If the server encounters a fatal error while parsing a message, an error MUST be sent back to the client and the parsing terminated. A fatal error may follow from incorrect command, a destination which is otherwise unknown to the server (server, client or channel names fit this category), not enough parameters or incorrect privileges. If a full set of parameters is presented, then each MUST be checked for validity and appropriate responses sent back to the client. In the case of messages which use parameter lists using the comma as an item separator, a reply MUST be sent for each item. In the examples below, some messages appear using the full format: :Name COMMAND parameter list Such examples represent a message from "Name" in transit between servers, where it is essential to include the name of the original sender of the message so remote servers may send back a reply along the correct path. The message details for client to server communication are described in the IRC Client Protocol. Some sections in the following pages apply to some of these messages, they are additions to the message specifications which are only relevant to server to server communication, or to the server implementation. The messages which are introduced here are only used for server to server communication.4.1 Connection Registration The commands described here are used to register a connection with another IRC server.4.1.1 Password message Command: PASSParameters: <password> <version> <flags> [<options>]Kalt [Page 9]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 The PASS command is used to set a 'connection password'. The password MUST be set before any attempt to register the connection is made. Currently this means that 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 received from a client (e.g. a user or a service). They are only relevant when received from a server. The <version> parameter is a string of at least four (4) charac¡ ters, and up to fourteen (14) characters. The first four (4) charac¡ ters MUST be digits and indicate the protocol version known by the server issuing the message. The protocol described by this document is version 2.10 which is encoded as "0210". The remaining OPTIONAL characters are implementation dependant and should describe the soft¡ ware version number. The <flags> parameter is a string of up to one hundred (100) char¡ acters. It is composed of two substrings separated by the character ``|'' (%x7C). If present, the first substring SHOULD be the name of the implementation. The second substring is implementation depen¡ dant. Both substrings are OPTIONAL, but the character ``|'' is REQUIRED. The character ``|'' MUST NOT appear in either substring. Finally, the last parameter, <options>, is used for link options. The only options defined by the protocol are link compression (using the character ``Z''), and an abuse protection flag (using the charac¡ ter ``P''). See sections5.3.1.1 (Compressed server to server links) and 5.3.1.2 (Anti abuse protections) respectively for more informa¡ tion on these options. Numeric Replies: ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED Example: PASS moresecretpassword 0210010000 IRC|aBgH$ Z4.1.2 Server message Command: SERVERParameters: <servername> <hopcount> <token> <info> The SERVER command is used to register a new server. A new connec¡ tion introduces itself as a server to its peer. This message is also used to pass server data over whole net. When a new server isKalt [Page 10]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 connected to net, information about it be broadcast to the whole net¡ work. The <info> parameter may contain space characters. <hopcount> is used to give all servers some internal information on how far away each server is. Local peers have a value of 0, and each passed server increments the value. With a full server list, it would be possible to construct a map of the entire server tree, but hostmasks prevent this from being done. The <token> parameter is an unsigned number used by servers as an identifier. This identifier is subsequently used to reference a server in the NICK and SERVICE messages sent between servers. Server tokens only have a meaning for the point-to-point peering they are used and MUST be unique for that connection. They are not global. The SERVER message MUST only be accepted from either (a) a connec¡ tion which is yet to be registered and is attempting 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 occur with the receipt of a SERVER command result in the connection being terminated by the destination host (target SERVER). Because of the severity of such event, error replies are usually sent using the "ERROR" command rather than a numeric. If a SERVER message is parsed and it attempts to introduce a server which is already known to the receiving server, the connec¡ tion, from which that message arrived, MUST be closed (following the correct procedures), since a duplicate route to a server has been formed and the acyclic nature of the IRC tree breaks. In some condi¡ tions, the connection from which the already known server has regis¡ tered MAY be closed instead. It should be noted that this kind of error can also be the result of a second running server, problem which cannot be fixed within the protocol and typically requires human intervention. This type of problem is particularly insidious, as it can quite easily result in part of the IRC network to be iso¡ lated, with one of the two servers connected to each partition there¡ fore making it impossible for the two parts to unite. Numeric Replies: ERR_ALREADYREGISTRED Example:Kalt [Page 11]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999SERVER 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 tol¡ sun.oulu.fi when introducing new users or services connected to csd.bu.edu.4.1.3 Nick Command: NICKParameters: <nickname> <hopcount> <username> <host> <servertoken> <umode> <realname> This form of the NICK message MUST NOT be allowed from user connections. However, it MUST be used instead of the NICK/USER pair to notify other servers of new users joining the IRC network. This message is really the combination of three distinct messages: NICK, USER and MODE [IRC-CLIENT]. The <hopcount> parameter is used by servers to indicate how far away a user is from its home server. A local connection has a hopcount of 0. The hopcount value is incremented by each passed server. The <servertoken> parameter replaces the <servername> parameter of the USER (Seesection 4.1.2 for more information on server tokens). Examples:NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New user with nickname "syrk", user¡ name "kalt", connected from host "mil¡ lennium.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 syrk4.1.4 Service messageKalt [Page 12]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 Command: SERVICEParameters: <servicename> <servertoken> <distribution> <type> <hopcount> <info> The SERVICE command is used to introduce a new service. This form of the SERVICE message SHOULD NOT be allowed from client (unregis¡ tered, or registered) connections. However, it MUST be used between servers to notify other servers of new services joining the IRC net¡ work. The <servertoken> is used to identify the server to which the ser¡ vice is connected. (Seesection 4.1.2 for more information on server tokens). The <hopcount> parameter is used by servers to indicate how far away a service is from its home server. A local connection has a hopcount of 0. The hopcount value is incremented by each passed server. The <distribution> parameter is used to specify the visibility of a service. The service may only be known to servers which have a name matching the distribution. For a matching server to have knowl¡ edge of the service, the network path between that server and the server on which the service is connected MUST be composed of servers whose names all match the mask. Plain ``*'' is used when no restric¡ tion is wished. The <type> parameter is currently reserved for future usage. Numeric Replies: ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS ERR_ERRONEUSNICKNAME RPL_YOURESERVICE RPL_YOURHOST RPL_MYINFO Example:SERVICE dict@irc.fr 9 *.fr 0 1 :French Dictionnary ; New service called "dict@irc.fr" reg¡ istered on server "9" is being announced to another server. This service will only be available on servers whose name matches "*.fr".4.1.5 QuitKalt [Page 13]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 Command: QUITParameters: [<Quit Message>] A client session ends with a quit message. The server MUST close the connection to a client which sends a QUIT message. If a "Quit Message" is given, this will be sent instead of the default message, the nickname or service name. When "netsplit" (SeeSection 4.1.6) occur, the "Quit Message" is composed of the names of two servers involved, separated by a space. The first name is that of the server which is still connected and the second name is either that of the server which has become discon¡ nected or that of the server to which the leaving client was con¡ nected: <Quit Message> = ":" servername space servername Because the "Quit Message" has a special meaning for "netsplits", servers SHOULD NOT allow a client to use a "Quit Message" in the for¡ mat described above. If, for some other reason, a client connection is closed without the client issuing a QUIT command (e.g. client dies and EOF occurs on socket), the server is REQUIRED to fill in the quit message with some sort of message reflecting the nature of the event which caused it to happen. Typically, this is done by reporting a system specific error. Numeric Replies: None. Examples::WiZ QUIT :Gone to have lunch ; Preferred message format.4.1.6 Server quit message Command: SQUITParameters: <server> <comment> The SQUIT message has two distinct uses. The first one (described in "Internet Relay Chat: Client Protocol" [IRC-CLIENT]) allows operators to break a local or remote server link. This form of the message is also eventually used by servers toKalt [Page 14]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 break a remote server link. The second use of this message is needed to inform other servers when a "network split" (also known as "netsplit") occurs, in other words to inform other servers 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, which then closes its connection to the quitting server. The <comment> is filled in by servers which SHOULD place an error or similar message here. Both of the servers which are on either side of the connection being closed are REQUIRED to send out a SQUIT message (to all its other server connections) for all other servers which are considered to be behind that link. Similarly, a QUIT message MAY be sent to the other still connected servers on behalf of all clients behind that quitting link. In addi¡ tion to this, all channel members of a channel which lost a member due to the "split" MUST be sent a QUIT message. Messages to channel members are generated by each client's local server. If a server connection is terminated prematurely (e.g. the server on the other end of the link died), the server which detects this disconnection is REQUIRED to inform the rest of the network that the connection has closed and fill in the comment field with something appropriate. When a client is removed as the result of a SQUIT messsage, the server SHOULD add the nickname to the list of temporarily unavailable nicknames in an attempt to prevent future nickname collisions. Seesection 5.7 (Tracking recently used nicknames) for more information on this procedure. Numeric replies: ERR_NOPRIVILEGES ERR_NOSUCHSERVER ERR_NEEDMOREPARAMS Example:SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has been terminated because of "Bad Link".Kalt [Page 15]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999: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".4.2 Channel operations This group of messages is concerned with manipulating channels, their properties (channel modes), and their contents (typically users). In implementing these, a number of race conditions are inevitable when users at opposing ends of a network send commands which will ultimately clash. It is also REQUIRED that servers keep a nickname history to ensure that wherever a <nick> parameter is given, the server check its history in case it has recently been changed.4.2.1 Join message Command: JOINParameters: <channel>[ %x7 <modes> ] *( "," <channel>[ %x7 <modes> ] ) The JOIN command is used by client to start listening a specific channel. Whether or not a client is allowed to join a channel is checked only by the local server the client is connected to; all other servers automatically add the user to the channel when the com¡ mand is received from other servers. Optionally, the user status (channel modes 'O', 'o', and 'v') on the channel may be appended to the channel name using a control G (^G or ASCII 7) as separator. Such data MUST be ignored if the message wasn't received from a server. This format MUST NOT be sent to clients, it can only be used between servers and SHOULD be avoided. The JOIN command MUST be broadcast to all servers so that each server knows where to find the users who are on the channel. This allows optimal delivery of PRIVMSG and NOTICE messages to the chan¡ nel. Numeric Replies: ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN ERR_INVITEONLYCHAN ERR_BADCHANNELKEY ERR_CHANNELISFULL ERR_BADCHANMASK ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE RPL_TOPIC Examples:Kalt [Page 16]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999:WiZ JOIN #Twilight_zone ; JOIN message from WiZ4.2.2 Njoin message Command: NJOINParameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname> *( "," [ "@@" / "@" ] [ "+" ] <nickname> ) The NJOIN message is used between servers only. If such a message is received from a client, it MUST be ignored. It is used when two servers connect to each other to exchange the list of channel members for each channel. Even though the same function can be performed by using a succes¡ sion of JOIN, this message SHOULD be used instead as it is more effi¡ cient. The prefix "@@" indicates that the user is the "channel cre¡ ator", the character "@" alone indicates a "channel operator", and the character '+' indicates that the user has the voice privilege. Numeric Replies: ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL ERR_ALREADYREGISTRED Examples::ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN message from ircd.stealth.net announcing users joining the #Twi¡ light_zone channel: WiZ with channel operator status, syrk with voice privi¡ lege and avalon with no privilege.4.2.3 Mode message The MODE message is a dual-purpose command in IRC. It allows both usernames and channels to have their mode changed. When parsing MODE messages, it is RECOMMENDED that the entire mes¡ sage be parsed first, and then the changes which resulted then passed on. It is REQUIRED that servers are able to change channel modes so that "channel creator" and "channel operators" may be created.Kalt [Page 17]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 19995. Implementation details A the time of writing, the only current implementation of this protocol is the IRC server, version 2.10. Earlier versions may imple¡ ment some or all of the commands described by this document with NOTICE messages replacing many of the numeric replies. Unfortu¡ nately, due to backward compatibility requirements, the implementa¡ tion of some parts of this document varies with what is laid out. 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 are mostly of importance to those who wish to implement a server but some parts also apply directly to clients as well.5.1 Connection 'Liveness' To detect when a connection has died or become unresponsive, the server MUST poll each of its connections. The PING command (See "IRC Client Protocol" [IRC-CLIENT]) is used if the server doesn't get a response from its peer in a given amount of time. If a connection doesn't respond in time, its connection is closed using the appropriate procedures.5.2 Accepting a client to server connection5.2.1 Users When a server successfully registers a new user connection, it is REQUIRED to send to the user unambiguous messages stating: the user identifiers upon which it was registered (RPL_WELCOME), the server name and version (RPL_YOURHOST), the server birth information (RPL_CREATED), available user and channel modes (RPL_MYINFO), and it MAY send any introductory messages which may be deemed appropriate. In particular the server SHALL send the current user/service/server count (as per the LUSER reply) and finally the MOTD (if any). After dealing with registration, the server MUST then send out to other servers the new user's nickname (NICK message), other informa¡ tion as supplied by itself (USER message) and as the server could discover (from DNS servers). The server MUST NOT send this informa¡ tion out with a pair of NICK and USER messages as defined in "IRC Client Protocol" [IRC-CLIENT], but MUST instead take advantage of the extended NICK message defined insection 4.1.3.Kalt [Page 18]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 19995.2.2 Services Upon successfully registering a new service connection, the server is subject to the same kind of REQUIREMENTS as for a user. Services being somewhat different, only the following replies are sent: RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO. After dealing with this, the server MUST then send out to other servers (SERVICE message) the new service's nickname and other infor¡ mation as supplied by the service (SERVICE message) and as the server could discover (from DNS servers).5.3 Establishing a server-server connection. The process of establishing a server-to-server connection is fraught with danger since there are many possible areas where prob¡ lems can occur - the least of which are race conditions. After a server has received a connection following by a PASS/SERVER pair which were recognized as being valid, the server SHOULD then reply with its own PASS/SERVER information for that con¡ nection as well as all of the other state information it knows about as described below. When the initiating server receives a PASS/SERVER pair, it too then checks that the server responding is authenticated properly before accepting the connection to be that server.5.3.1 Link options Server links are based on a common protocol (defined by this docu¡ ment) but a particular link MAY set specific options using the PASS message (SeeSection 4.1.1).5.3.1.1 Compressed server to server links If a server wishes to establish a compressed link with its peer, it MUST set the 'Z' flag in the options parameter to the PASS mes¡ sage. If both servers request compression and both servers are able to initialize the two compressed streams, then the remainder of the communication is to be 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 the compression is described byRFC 1950 [ZLIB],RFC 1951 [DEFLATE] andRFC 1952 [GZIP].5.3.1.2 Anti abuse protectionsKalt [Page 19]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 Most servers implement various kinds of protections against possi¡ ble abusive behaviours from non trusted parties (typically users). On some networks, such protections are indispensable, on others they are superfluous. To require that all servers implement and enable such features on a particular network, the 'P' flag is used when two servers connect. If this flag is present, it means that 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 sections5.7 (Tracking recently used nicknames) and 5.8 (Flood control of clients).5.3.2 State information exchange when connecting The order of state information being exchanged between servers is essential. The REQUIRED order is as follows: * all known servers; * all known client information; * all known channel information. Information regarding servers is sent via extra SERVER messages, client information 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 exchange topics. By passing the state information about servers first, any colli¡ sions with servers that already exist occur before nickname colli¡ sions caused by a second server introducing a particular nickname. Due to the IRC network only being able to exist as an acyclic graph, it may be possible that the network has already reconnected in another location. In this event, the place where the server colli¡ sion occurs indicating 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 to which the client was connected. 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 SQUITKalt [Page 20]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 command or "natural" causes, the rest of the connected IRC network MUST have its information updated by the server which detected the closure. The terminating server then sends a list of SQUITs (one for each server behind that connection). (SeeSection 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 to allow the server to have a chance of keeping in touch of things when nick-change race conditions occur with commands manipulating them. 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 affect¡ ing 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 previous nickname for every client it knows about if 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 of keeping track of 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 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) ofKalt [Page 21]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 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 is quite easy for any single client attached to the network to supply a con¡ tinuous stream of messages that result in not only flooding the net¡ work, but also degrading the level of service provided to others. Rather than require every 'victim' to be provide their own protec¡ tion, 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 seconds ahead of the current time, parse any present messages and penalize the client by 2 seconds for each message; * additionnal penalties MAY be used for specific commands which generate a lot of traffic across the network. This in essence means that the client may send 1 message every 2 seconds without being adversely affected. Services MAY also be sub¡ ject to this mechanism.5.9 Non-blocking lookups In a real-time environment, it is essential that a server process does as little waiting as possible so that all the clients are ser¡ viced fairly. Obviously this requires non-blocking IO on all network read/write operations. For normal server connections, this was not difficult, 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 has meant large delays in some cases where replies have timed out. To avoid this, a separate set of DNS routines were written for the cur¡ rent implementation. Routines were setup for non-blocking IO opera¡ tions with local cache, and then polled from within the main server IO loop.Kalt [Page 22]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 19995.9.2 Username (Ident) lookups Although there are numerous ident libraries (implementing the "Identification Protocol" [IDENT]) for use and inclusion into other programs, these caused problems since they operated in a synchronous manner and resulted in frequent delays. Again the solution was to write a set of routines which would cooperate with the rest of the server and work using non-blocking IO.Kalt [Page 23]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 19996. 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 does not scale suffi¡ ciently well 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 is also desirable to keep the number of servers low so that the path length between any two points is kept minimal and the spanning tree 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. Currently, it is possible for users to pick the label for any of the first three, resulting in collisions. It is widely recog¡ nized that this needs reworking, with a plan for unique names for nicks that don't collide being desirable as well as a solution allow¡ ing a cyclic tree.6.2.1 Nicknames The idea of the nickname on IRC is very convenient for users to use when talking to each other outside of a channel, but there is only a finite nickname space and being what they are, its not uncom¡ mon for several people to want to use the same nick. If a nickname is chosen by two people using this protocol, either one will not suc¡ ceed or both will removed by use of KILL (4.6.1).6.2.2 Channels The current channel layout requires that all servers know about all channels, their inhabitants and properties. Besides not scaling well, the issue of privacy is also a concern. A collision of chan¡ nels is treated as an inclusive event (people from both nets on chan¡ nel with common name are considered to be members of it) rather than an exclusive one such as used to solve nickname collisions. This protocol defines "Safe Channels" which are very unlikely to be the subject of a channel collision. Other channel types are keptKalt [Page 24]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 for backward compatibility.6.2.3 Servers Although the number of servers is usually small relative to the number of users and channels, they too are currently REQUIRED to be known globally, either each one separately or hidden behind a mask.6.3 Algorithms In some places within the server code, it has not been possible to avoid N^2 algorithms such as checking the channel list of a set of clients. In current server versions, there are only few database consis¡ tency checks, most of the time each server assumes that a neighbour¡ ing server is correct. This opens the door to large problems if a connecting server is buggy or otherwise tries to introduce contradic¡ tions to the existing net. Currently, because of the lack of unique internal and global labels, there are a multitude of race conditions that exist. These race conditions generally arise from the problem of it taking time for messages to traverse and effect the IRC network. Even by chang¡ ing to unique labels, there are problems with channel-related com¡ mands being disrupted.7. Security Considerations7.1 Authentication Servers only have two means of authenticating incoming connec¡ tions: plain text password, and DNS lookups. While these methods are weak and widely recognized as unsafe, their combination has proven to be sufficient in the past: * public networks typically allow user connections with only few restrictions, without requiring accurate authentication. * private networks which operate in a controlled environment often use home-grown authentication mechanisms not available on the internet: reliable ident servers [IDENT], or other proprietary mecha¡ nisms. The same comments apply to the authentication of IRC Operators. It should also be noted that while there has been no real demand over the years for stronger authentication, and no real effort toKalt [Page 25]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999 provide better means to safely authenticate users, the current proto¡ col offers enough to be able to easily plug-in external authentica¡ tion methods based on the information that a client can submit to the server upon 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 Proto¡ col" [TLS]) could be used to protect these transactions.8. Current support and availability Mailing lists for IRC related discussion: General discussion: ircd-users@irc.org Protocol development: ircd-dev@irc.org Software implementations:ftp://ftp.irc.org/irc/serverftp://ftp.funet.fi/pub/unix/ircftp://coombs.anu.edu.au/pub/irc Newsgroup: alt.irc9. Acknowledgements Parts of this document were copied from theRFC 1459 [IRC] which first formally documented the IRC Protocol. It has also benefited from many rounds of review and comments. In particular, the follow¡ ing 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] "Key words for use in RFCs to Indicate Requirement Levels", Network Working GroupRFC 2119, S. Bradner, March 1997.[ABNF] "Augmented BNF for Syntax Specifications: ABNF", Network Working GroupRFC 2234, D. Crocker, P. Overell, November 1997[IRC] "Internet Relay Chat Protocol", Network Working GroupRFC 1459, J. Oikarinen & D. Reed, May 1993Kalt [Page 26]
Internet Draft Internet Relay Chat: Server Protocol 22 Jul 1999[IRC-ARCH] "Internet Relay Chat: Architecture", Work In Progress:draft-kalt-irc-arch-xx.txt[IRC-CLIENT] "Internet Relay Chat: Client Protocol", Work In Progress:draft-kalt-irc-client-xx.txt[IRC-CHAN] "Internet Relay Chat: Channel Management", Work In Progress:draft-kalt-irc-chan-xx-txt[ZLIB] "ZLIB Compressed Data Format Specification version 3.3", Network Working GroupRFC 1950, P. Deutsch & J-L. Gailly, May 1996.[DEFLATE] "DEFLATE Compressed Data Format Specification version 1.3", Network Working GroupRFC 1951, P. Deutsch, May 1996.[GZIP] "GZIP file format specification version 4.3", Network Working GroupRFC 1952, P. Deutsch, May 1996[IDENT] "The Identification Protocol", Network Working GroupRFC 1413, M. St. Johns, February 1993.[TLS] "The TLS Protocol", Network Working GroupRFC 2246, T. Dierks, C. Allen, January 199911. Author's Address Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 USA Email: kalt@stealth.netKalt [Page 27]
Datatracker
draft-kalt-irc-server-01
This is an older version of an Internet-Draft that was ultimately published asRFC 2813.
| Document | Document type | This is an older version of an Internet-Draft that was ultimately published asRFC 2813. | |
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | Christophe Kalt Email authors | ||
| RFC stream |   | ||
| Intended RFC status | Informational | ||
| Other formats |