summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2813.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2813.txt')
-rw-r--r--doc/rfc/rfc2813.txt1459
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc2813.txt b/doc/rfc/rfc2813.txt
new file mode 100644
index 0000000..2da3de0
--- /dev/null
+++ b/doc/rfc/rfc2813.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group C. Kalt
+Request for Comments: 2813 April 2000
+Updates: 1459
+Category: Informational
+
+
+ Internet Relay Chat: Server Protocol
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ While based on the client-server model, the IRC (Internet Relay Chat)
+ protocol allows servers to connect to each other effectively forming
+ a network.
+
+ This document defines the protocol used by servers to talk to each
+ other. It was originally a superset of the client protocol but has
+ evolved differently.
+
+ First formally documented in May 1993 as part of RFC 1459 [IRC], most
+ of the changes brought since then can be found in this document as
+ development was focused on making the protocol scale better. Better
+ scalability has allowed existing world-wide networks to keep growing
+ and reach sizes which defy the old specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 1]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+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
+
+
+
+Kalt Informational [Page 2]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ 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 ................................... 26
+
+1. 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.
+
+
+
+
+Kalt Informational [Page 3]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+2.2 Clients
+
+ For each client, all servers MUST have the following 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 the
+ 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 of the global
+ state information that a server maintains, but have a more restricted
+ set of commands available to them (See "IRC Client Protocol" [IRC-
+ CLIENT] for details on which) and are not allowed to join channels.
+ Finally services are not usually subject to the "Flood control"
+ mechanism described in section 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 Informational [Page 4]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+3. The IRC Server Specification
+
+3.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 Informational [Page 5]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ 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 received MUST be dropped. Dropping a link
+ in such circumstances is a little excessive but necessary to maintain
+ the integrity of the network and to prevent future problems. Another
+ common error condition is that the prefix 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. See section 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.
+
+
+
+
+
+
+Kalt Informational [Page 6]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+3.4 Numeric replies
+
+ Most of the messages sent to the server generate a reply of some
+ sort. The most common reply is the numeric reply, used for both
+ errors and normal replies. 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].
+
+4. 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" [IRC-CLIENT]. 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
+
+
+
+Kalt Informational [Page 7]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ 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: PASS
+ Parameters: <password> <version> <flags> [<options>]
+
+ 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) characters,
+ and up to fourteen (14) characters. The first four (4) characters
+ 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 dependent and should describe the
+ software version number.
+
+ The <flags> parameter is a string of up to one hundred (100)
+ characters. It is composed 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, which needs an identifier,
+ then 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.
+
+ 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 character
+
+
+
+
+
+Kalt Informational [Page 8]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ "P"). See sections 5.3.1.1 (Compressed server to server links) and
+ 5.3.1.2 (Anti abuse protections) respectively for more information on
+ these options.
+
+ Numeric Replies:
+
+ ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
+
+ Example:
+
+ PASS moresecretpassword 0210010000 IRC|aBgH$ Z
+
+4.1.2 Server message
+
+ Command: SERVER
+ Parameters: <servername> <hopcount> <token> <info>
+
+ The SERVER command is used to register a new server. A new connection
+ introduces itself as a server to its peer. This message is also used
+ to pass server data over whole net. When a new server is connected
+ to net, information about it MUST be broadcasted to the whole
+ network.
+
+ 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 connection
+ 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.
+
+
+
+
+Kalt Informational [Page 9]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ If a SERVER message is parsed and it attempts to introduce a server
+ which is already known to the receiving server, the connection, 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 conditions, the
+ connection from which the already known server has registered 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 isolated, with one of
+ the two servers connected to each partition therefore making it
+ impossible for the two parts to unite.
+
+ Numeric Replies:
+
+ ERR_ALREADYREGISTRED
+
+ Example:
+
+ 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>
+
+ 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.
+
+
+
+Kalt Informational [Page 10]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ The <servertoken> parameter replaces the <servername> parameter of
+ the USER (See section 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", 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
+ syrk
+
+4.1.4 Service message
+
+ Command: SERVICE
+ Parameters: <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 (unregistered,
+ or registered) connections. However, it MUST be used between servers
+ to notify other servers of new services joining the IRC network.
+
+ The <servertoken> is used to identify the server to which the service
+ is connected. (See section 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 knowledge
+ of the service, the network path between that server and the server
+ to which the service is connected MUST be composed of servers whose
+ names all match the mask. Plain "*" is used when no restriction is
+ wished.
+
+ The <type> parameter is currently reserved for future usage.
+
+
+
+
+
+Kalt Informational [Page 11]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ Numeric Replies:
+
+ ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
+ ERR_ERRONEUSNICKNAME
+ RPL_YOURESERVICE RPL_YOURHOST
+ RPL_MYINFO
+
+ Example:
+
+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".
+
+4.1.5 Quit
+
+ Command: QUIT
+ Parameters: [<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" (See Section 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
+ disconnected or that of the server to which the leaving client was
+ connected:
+
+ <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
+ format 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.
+
+
+
+Kalt Informational [Page 12]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ Examples:
+
+ :WiZ QUIT :Gone to have lunch ; Preferred message format.
+
+4.1.6 Server quit message
+
+ Command: SQUIT
+ Parameters: <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 to
+ 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
+ addition 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 message, the server
+ SHOULD add the nickname to the list of temporarily unavailable
+ nicknames in an attempt to prevent future nickname collisions. See
+
+
+
+
+Kalt Informational [Page 13]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ section 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".
+
+ :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: JOIN
+ Parameters: <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
+ command 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.
+
+
+
+
+
+Kalt Informational [Page 14]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ 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 channel.
+
+ 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:
+
+ :WiZ JOIN #Twilight_zone ; JOIN message from WiZ
+
+4.2.2 Njoin message
+
+ Command: NJOIN
+ Parameters: <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 succession
+ of JOIN, this message SHOULD be used instead as it is more efficient.
+ The prefix "@@" indicates that the user is the "channel creator", 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
+ #Twilight_zone channel: WiZ with
+ channel operator status, syrk with
+ voice privilege and avalon with no
+ privilege.
+
+
+
+Kalt Informational [Page 15]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+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 message
+ be parsed first, and then the changes which resulted passed on.
+
+ It is REQUIRED that servers are able to change channel modes so that
+ "channel creator" and "channel operators" may be created.
+
+5. Implementation details
+
+ A 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 described by this document with
+ NOTICE messages replacing many of the numeric replies. Unfortunately,
+ due to backward compatibility requirements, the implementation 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 connection
+
+5.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.
+
+
+
+Kalt Informational [Page 16]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ In particular the server SHALL send the current user/service/server
+ count (as per the LUSER reply) and finally the MOTD (if any, as per
+ the MOTD reply).
+
+ After dealing with registration, the server MUST then send out to
+ other servers the new user's nickname (NICK message), other
+ information as supplied by itself (USER message) and as the server
+ could discover (from DNS servers). The server MUST NOT send this
+ information 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 in section 4.1.3.
+
+5.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
+ information 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 problems 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 connection 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
+ document) but a particular link MAY set specific options using the
+ PASS message (See Section 4.1.1).
+
+
+
+
+
+
+Kalt Informational [Page 17]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+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 message.
+ 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 by RFC 1950
+ [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].
+
+5.3.1.2 Anti abuse protections
+
+ Most servers implement various kinds of protections against possible
+ 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 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 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.
+
+
+
+
+
+
+Kalt Informational [Page 18]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ By passing the state information about servers first, any collisions
+ with servers that already exist occur before nickname collisions
+ 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 collision occurs
+ indicates 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 SQUIT 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). (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 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
+ 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.
+
+
+
+
+
+
+Kalt Informational [Page 19]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ 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) 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 is quite easy
+ for any single client attached to the network to supply a continuous
+ stream of messages that result in not only flooding the network, but
+ also degrading the level of service provided to others. 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 in essence means that the client may send one (1) message every
+ two (2) seconds without being adversely affected. Services MAY also
+ be subject to this mechanism.
+
+
+
+
+Kalt Informational [Page 20]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+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
+ serviced 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
+ current implementation. Routines were setup for non-blocking IO
+ operations with local cache, and then polled from within the main
+ server IO loop.
+
+5.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.
+
+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 does not scale
+ sufficiently well when used in a large arena. The main problem comes
+ from the requirement that all servers know about all other servers
+ 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.
+
+
+
+
+
+
+
+Kalt Informational [Page 21]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+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
+ 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
+
+ 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, it's not uncommon 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 succeed or
+ both will be removed by use of KILL (See Section 3.7.1 of "IRC Client
+ Protocol" [IRC-CLIENT]).
+
+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
+ channels is treated as an inclusive event (people from both nets on
+ channel 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 kept 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.
+
+
+
+
+
+
+Kalt Informational [Page 22]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ In current server versions, there are only few database consistency
+ checks, most of the time each server assumes that a neighbouring
+ server is correct. This opens the door to large problems if a
+ connecting server is buggy or otherwise tries to introduce
+ contradictions 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 changing to
+ unique labels, there are problems with channel-related commands being
+ disrupted.
+
+7. Security Considerations
+
+7.1 Authentication
+
+ Servers only have two means of authenticating incoming connections:
+ 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
+ mechanisms.
+
+ 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 to provide
+ better means to safely authenticate users, the current protocol
+ offers enough to be able to easily plug-in external authentication
+ 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
+ Protocol" [TLS]) could be used to protect these transactions.
+
+
+
+
+
+
+
+Kalt Informational [Page 23]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+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/server
+ ftp://ftp.funet.fi/pub/unix/irc
+ ftp://coombs.anu.edu.au/pub/irc
+
+ Newsgroup: alt.irc
+
+9. Acknowledgements
+
+ Parts of this document were copied from the RFC 1459 [IRC] which
+ first formally documented the IRC Protocol. It has also benefited
+ from many rounds of review and comments. In particular, the
+ following people have made significant contributions to this
+ document:
+
+ Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
+ Ruokonen, Magnus Tjernstrom, Stefan Zehl.
+
+10. References
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [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.
+
+
+
+
+Kalt Informational [Page 24]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+ [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.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 25]
+
+RFC 2813 Internet Relay Chat: Server Protocol April 2000
+
+
+12. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kalt Informational [Page 26]
+