As per Relevance of the word internet, we have this rfc below:
Network Working Group C.
Request for Comments: 2813 April 2000
Updates: 1459
Category:
Internet Relay Chat: Server
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
While based on the client-server model, the IRC (Internet Relay Chat
protocol allows servers to connect to each other effectively
a network
This document defines the protocol used by servers to talk to
other. It was originally a superset of the client protocol but
evolved differently
First formally documented in May 1993 as part of RFC 1459 [IRC],
of the changes brought since then can be found in this document
development was focused on making the protocol scale better.
scalability has allowed existing world-wide networks to keep
and reach sizes which defy the old specification
Kalt Informational [Page 1]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
Table of
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.
This document is intended for people working on implementing an
server but will also be useful to anyone implementing an IRC service
Servers provide the three basic services required for
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
Although the IRC Protocol defines a fairly distributed model,
server maintains a "global state database" about the whole
network. This database is, in theory, identical on all servers
2.1
Servers are uniquely identified by their name which has a
length of sixty three (63) characters. See the protocol
rules (section 3.3.1) for what may and may not be used in a
name
Each server is typically known by all other servers, however it
possible to define a "hostmask" to group servers together
to their name. Inside the hostmasked area, all the servers have
name which matches the hostmask, and any other server with a
matching the hostmask SHALL NOT be connected to the IRC
outside the hostmasked area. Servers which are outside the area
no knowledge of the individual servers present inside the area
instead they are presented with a virtual server which has
hostmask for name
Kalt Informational [Page 3]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
2.2
For each client, all servers MUST have the following information:
netwide unique identifier (whose format depends on the type
client) and the server to which the client is connected
2.2.1
Each user is distinguished from other users by a unique
having a maximum length of nine (9) characters. See the
grammar rules (section 3.3.1) for what may and may not be used in
nickname. In addition to the nickname, all servers MUST have
following information about all users: the name of the host that
user is running on, the username of the user on that host, and
server to which the client is connected
2.2.2
Each service is distinguished from other services by a service
composed of a nickname and a server name. The nickname has a
length of nine (9) characters. See the protocol grammar
(section 3.3.1) for what may and may not be used in a nickname.
server name used to compose the service name is the name of
server to which the service is connected. In addition to
service name all servers MUST know the service type
Services differ from users by the format of their identifier,
more importantly services and users don't have the same type
access to the server: services can request part or all of the
state information that a server maintains, but have a more
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
Alike services, channels have a scope [IRC-CHAN] and are
necessarily known to all servers. When a channel existence is
to a server, the server MUST keep track of the channel members,
well as the channel modes
Kalt Informational [Page 4]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
3. The IRC Server
3.1
The protocol as described herein is for use with server to
connections. For client to server connections, see the IRC
Protocol specification
There are, however, more restrictions on client connections (
are considered to be untrustworthy) than on server connections
3.2 Character
No specific character set is specified. The protocol is based on a
set of codes which are composed of eight (8) bits, making up
octet. Each message may be composed of any number of these octets
however, some octet values are used for control codes which act
message delimiters
Regardless of being an 8-bit protocol, the delimiters and
are such that protocol is mostly usable from US-ASCII terminal and
telnet connection
Because of IRC's Scandinavian origin, the characters {}|^
considered to be the lower case equivalents of the characters []\~,
respectively. This is a critical issue when determining
equivalence of two nicknames, or channel names
3.3
Servers and clients send each other messages which may or may
generate a reply. Most communication between servers do not
any reply, as servers mostly perform routing tasks for the clients
Each IRC message may consist of up to three main parts: the
(OPTIONAL), the command, and the command parameters (maximum
fifteen (15)). The prefix, command, and all parameters are
by one ASCII space character (0x20) each
The presence of a prefix is indicated with a single leading
colon character (':', 0x3b), which MUST be the first character of
message itself. There MUST be NO gap (whitespace) between the
and the prefix. The prefix is used by servers to indicate the
origin of the message. If the prefix is missing from the message,
is assumed to have originated from the connection from which it
received. Clients SHOULD not use a prefix when sending a
from themselves; if they use one, the only valid prefix is
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
the (eventually assumed) prefix. If the prefix cannot be found
the server's internal database, it MUST be discarded, and if
prefix indicates the message comes from an (unknown) server, the
from which the message was received MUST be dropped. Dropping a
in such circumstances is a little excessive but necessary to
the integrity of the network and to prevent future problems.
common error condition is that the prefix found in the server'
internal database identifies a different source (typically a
registered from a different link than from which the
arrived). If the message was received from a server link and
prefix identifies a client, a KILL message MUST be issued for
client and sent to all servers. In other cases, the link from
the message arrived SHOULD be dropped for clients, and MUST
dropped for servers. In all cases, the message MUST be discarded
The command MUST either be a valid IRC command or a three (3)
number represented in ASCII text
IRC messages are always lines of characters terminated with a CR-
(Carriage Return - Line Feed) pair, and these messages SHALL
exceed 512 characters in length, counting all characters
the trailing CR-LF. Thus, there are 510 characters maximum
for the command and its parameters. There is no provision
continuation message lines. See section 5 for more details
current implementations
3.3.1 Message format in Augmented
The protocol messages must be extracted from the contiguous stream
octets. The current solution is to designate two characters, CR
LF, as message separators. Empty messages are silently ignored
which permits use of the sequence CR-LF between messages
extra problems
The extracted message is parsed into the components ,
and list of parameters ().
The Augmented BNF representation for this is found in "IRC
Protocol" [IRC-CLIENT].
The extended prefix (["!" user "@" host ]) MUST NOT be used in
to server communications and is only intended for server to
messages in order to provide clients with more useful
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
Most of the messages sent to the server generate a reply of
sort. The most common reply is the numeric reply, used for
errors and normal replies. The numeric reply MUST be sent as
message consisting of the sender prefix, the three digit numeric,
the target of the reply. A numeric reply is not allowed to
from a client; any such messages received by a server are
dropped. In all other respects, a numeric reply is just like a
message, except that the keyword is made up of 3 numeric
rather than a string of letters. A list of different replies
supplied in "IRC Client Protocol" [IRC-CLIENT].
4. Message
All the messages recognized by the IRC server and client
described in the IRC Client Protocol specification
Where the reply ERR_NOSUCHSERVER is returned, it means that
target of the message could not be found. The server MUST NOT
any other replies after this error for that command
The server to which a client is connected is required to parse
complete message, returning any appropriate errors. If the
encounters a fatal error while parsing a message, an error MUST
sent back to the client and the parsing terminated. A fatal
may follow from incorrect command, a destination which is
unknown to the server (server, client or channel names fit
category), not enough parameters or incorrect privileges
If a full set of parameters is presented, then each MUST be
for validity and appropriate responses sent back to the client.
the case of messages which use parameter lists using the comma as
item separator, a reply MUST be sent for each item
In the examples below, some messages appear using the full format
:Name COMMAND parameter
Such examples represent a message from "Name" in transit
servers, where it is essential to include the name of the
sender of the message so remote servers may send back a reply
the correct path
The message details for client to server communication are
in the "IRC Client Protocol" [IRC-CLIENT]. Some sections in
following pages apply to some of these messages, they are
to the message specifications which are only relevant to server
Kalt Informational [Page 7]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
server communication, or to the server implementation. The
which are introduced here are only used for server to
communication
4.1 Connection
The commands described here are used to register a connection
another IRC server
4.1.1 Password
Command:
Parameters: <password> []
The PASS command is used to set a 'connection password'.
password MUST be set before any attempt to register the connection
made. Currently this means that servers MUST send a PASS
before any SERVER command. Only one (1) PASS command SHALL
accepted from a connection
The last three (3) parameters MUST be ignored if received from
client (e.g. a user or a service). They are only relevant
received from a server
The parameter is a string of at least four (4) characters
and up to fourteen (14) characters. The first four (4)
MUST be digits and indicate the protocol version known by the
issuing the message. The protocol described by this document
version 2.10 which is encoded as "0210". The remaining
characters are implementation dependent and should describe
software version number
The parameter is a string of up to one hundred (100)
characters. It is composed of two substrings separated by
character "|" (%x7C). If present, the first substring MUST be
name of the implementation. The reference implementation (
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
RFC. The second substring is implementation dependent.
substrings are OPTIONAL, but the character "|" is REQUIRED.
character "|" MUST NOT appear in either substring
Finally, the last parameter, , is used for link options
The only options defined by the protocol are link compression (
the character "Z"), and an abuse protection flag (using the
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)
5.3.1.2 (Anti abuse protections) respectively for more information
these options
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
Example
PASS moresecretpassword 0210010000 IRC|aBgH$
4.1.2 Server
Command:
Parameters:
The SERVER command is used to register a new server. A new
introduces itself as a server to its peer. This message is also
to pass server data over whole net. When a new server is
to net, information about it MUST be broadcasted to the
network
The parameter may contain space characters
is used to give all servers some internal information
how far away each server is. Local peers have a value of 0, and
passed server increments the value. With a full server list,
would be possible to construct a map of the entire server tree,
hostmasks prevent this from being done
The parameter is an unsigned number used by servers as
identifier. This identifier is subsequently used to reference
server in the NICK and SERVICE messages sent between servers.
tokens only have a meaning for the point-to-point peering they
used and MUST be unique for that connection. They are not global
The SERVER message MUST only be accepted from either (a) a
which is yet to be registered and is attempting to register as
server, or (b) an existing connection to another server, in
case the SERVER message is introducing a new server behind
server
Most errors that occur with the receipt of a SERVER command result
the connection being terminated by the destination host (
SERVER). Because of the severity of such event, error replies
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
which is already known to the receiving server, the connection,
which that message arrived, MUST be closed (following the
procedures), since a duplicate route to a server has been formed
the acyclic nature of the IRC tree breaks. In some conditions,
connection from which the already known server has registered MAY
closed instead. It should be noted that this kind of error can
be the result of a second running server, problem which cannot
fixed within the protocol and typically requires human intervention
This type of problem is particularly insidious, as it can
easily result in part of the IRC network to be isolated, with one
the two servers connected to each partition therefore making
impossible for the two parts to unite
Numeric Replies
ERR_
Example
SERVER test.oulu.fi 1 1 :Experimental server ; New
test.oulu.fi introducing itself
attempting to register
:tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ;
tolsun.oulu.fi is our uplink
csd.bu.edu which is 5 hops away.
token "34" will be used
tolsun.oulu.fi when introducing
users or services connected
csd.bu.edu
4.1.3
Command:
Parameters: <nickname> <username>
This form of the NICK message MUST NOT be allowed from
connections. However, it MUST be used instead of the NICK/USER
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 parameter is used by servers to indicate how far
a user is from its home server. A local connection has a hopcount
0. The hopcount value is incremented by each passed server
Kalt Informational [Page 10]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
The parameter replaces the parameter
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 ;
user with nickname "syrk",
"kalt", connected from
"millennium.stealth.net" to
"34" ("csd.bu.edu" according to
previous example).
:krys NICK syrk ; The other form of the NICK message
as defined in "IRC Client Protocol
[IRC-CLIENT] and used
servers: krys changed his nickname
4.1.4 Service
Command:
Parameters: <distribution>
The SERVICE command is used to introduce a new service. This form
the SERVICE message SHOULD NOT be allowed from client (unregistered
or registered) connections. However, it MUST be used between
to notify other servers of new services joining the IRC network
The is used to identify the server to which the
is connected. (See section 4.1.2 for more information on
tokens).
The parameter is used by servers to indicate how far
a service is from its home server. A local connection has a
of 0. The hopcount value is incremented by each passed server
The <distribution> parameter is used to specify the visibility of
service. The service may only be known to servers which have a
matching the distribution. For a matching server to have
of the service, the network path between that server and the
to which the service is connected MUST be composed of servers
names all match the mask. Plain "*" is used when no restriction
wished
The 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_
ERR_
RPL_YOURESERVICE RPL_
RPL_
Example
SERVICE dict@irc.fr 9 *.fr 0 1 :French Dictionary r" registered
server "9" is being announced
another server. This service
only be available on servers
name matches "*.fr".
4.1.5
Command:
Parameters: []
A client session ends with a quit message. The server MUST close
connection to a client which sends a QUIT message. If a "
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"
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
second name is either that of the server which has
disconnected or that of the server to which the leaving client
connected
= ":" servername SPACE
Because the "Quit Message" has a special meaning for "netsplits",
servers SHOULD NOT allow a client to use a in
format described above
If, for some other reason, a client connection is closed without
client issuing a QUIT command (e.g. client dies and EOF occurs
socket), the server is REQUIRED to fill in the quit message with
sort of message reflecting the nature of the event which caused it
happen. Typically, this is done by reporting a system
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
Command:
Parameters:
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
link. This form of the message is also eventually used by servers
break a remote server link
The second use of this message is needed to inform other servers
a "network split" (also known as "netsplit") occurs, in other
to inform other servers about quitting or dead servers. If a
wishes to break the connection to another server it MUST send a
message to the other server, using the name of the other server
the server parameter, which then closes its connection to
quitting server
The is filled in by servers which SHOULD place an error
similar message here
Both of the servers which are on either side of the connection
closed are REQUIRED to send out a SQUIT message (to all its
server connections) for all other servers which are considered to
behind that link
Similarly, a QUIT message MAY be sent to the other still
servers on behalf of all clients behind that quitting link.
addition to this, all channel members of a channel which lost
member due to the "split" MUST be sent a QUIT message. Messages
channel members are generated by each client's local server
If a server connection is terminated prematurely (e.g., the server
the other end of the link died), the server which detects
disconnection is REQUIRED to inform the rest of the network that
connection has closed and fill in the comment field with
appropriate
When a client is removed as the result of a SQUIT message, the
SHOULD add the nickname to the list of temporarily
nicknames in an attempt to prevent future nickname collisions.
Kalt Informational [Page 13]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
section 5.7 (Tracking recently used nicknames) for more
on this procedure
Numeric replies
ERR_NOPRIVILEGES ERR_
ERR_
Example
SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.
has been terminated because of "
Link".
:Trillian SQUIT cm22.eng.umd.edu :Server out of control ;
from Trillian to
"cm22.eng.umd.edu" from the
because "Server out of control".
4.2 Channel
This group of messages is concerned with manipulating channels,
properties (channel modes), and their contents (typically users).
implementing these, a number of race conditions are inevitable
users at opposing ends of a network send commands which
ultimately clash. It is also REQUIRED that servers keep a
history to ensure that wherever a parameter is given,
server check its history in case it has recently been changed
4.2.1 Join
Command:
Parameters: [ %x7 ]
*( "," [ %x7 ] )
The JOIN command is used by client to start listening a
channel. Whether or not a client is allowed to join a channel
checked only by the local server the client is connected to;
other servers automatically add the user to the channel when
command is received from other servers
Optionally, the user status (channel modes 'O', 'o', and 'v') on
channel may be appended to the channel name using a control G (^G
ASCII 7) as separator. Such data MUST be ignored if the
wasn't received from a server. This format MUST NOT be sent
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
knows where to find the users who are on the channel. This
optimal delivery of PRIVMSG and NOTICE messages to the channel
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
ERR_INVITEONLYCHAN ERR_
ERR_CHANNELISFULL ERR_
ERR_NOSUCHCHANNEL ERR_
ERR_TOOMANYTARGETS ERR_
RPL_
Examples
:WiZ JOIN #Twilight_zone ; JOIN message from
4.2.2 Njoin
Command:
Parameters: [ "@@" / "@" ] [ "+" ] <nickname
*( "," [ "@@" / "@" ] [ "+" ] <nickname> )
The NJOIN message is used between servers only. If such a message
received from a client, it MUST be ignored. It is used when
servers connect to each other to exchange the list of channel
for each channel
Even though the same function can be performed by using a
of JOIN, this message SHOULD be used instead as it is more efficient
The prefix "@@" indicates that the user is the "channel creator",
character "@" alone indicates a "channel operator", and the
'+' indicates that the user has the voice privilege
Numeric Replies
ERR_NEEDMOREPARAMS ERR_
ERR_
Examples
:ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ;
message from ircd.stealth.
announcing users joining
#Twilight_zone channel: WiZ
channel operator status, syrk
voice privilege and avalon with
privilege
Kalt Informational [Page 15]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
4.2.3 Mode
The MODE message is a dual-purpose command in IRC. It allows
usernames and channels to have their mode changed
When parsing MODE messages, it is RECOMMENDED that the entire
be parsed first, and then the changes which resulted passed on
It is REQUIRED that servers are able to change channel modes so
"channel creator" and "channel operators" may be created
5. Implementation
A the time of writing, the only current implementation of
protocol is the IRC server, version 2.10. Earlier versions
implement some or all of the commands described by this document
NOTICE messages replacing many of the numeric replies. Unfortunately
due to backward compatibility requirements, the implementation
some parts of this document varies with what is laid out.
notable difference is
* recognition that any LF or CR anywhere in a message
the end of that message (instead of requiring CR-LF);
The rest of this section deals with issues that are mostly
importance to those who wish to implement a server but some
also apply directly to clients as well
5.1 Connection 'Liveness
To detect when a connection has died or become unresponsive,
server MUST poll each of its connections. The PING command (See "
Client Protocol" [IRC-CLIENT]) is used if the server doesn't get
response from its peer in a given amount of time
If a connection doesn't respond in time, its connection is
using the appropriate procedures
5.2 Accepting a client to server
5.2.1
When a server successfully registers a new user connection, it
REQUIRED to send to the user unambiguous messages stating: the
identifiers upon which it was registered (RPL_WELCOME), the
name and version (RPL_YOURHOST), the server birth
(RPL_CREATED), available user and channel modes (RPL_MYINFO), and
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/
count (as per the LUSER reply) and finally the MOTD (if any, as
the MOTD reply).
After dealing with registration, the server MUST then send out
other servers the new user's nickname (NICK message),
information as supplied by itself (USER message) and as the
could discover (from DNS servers). The server MUST NOT send
information out with a pair of NICK and USER messages as defined
"IRC Client Protocol" [IRC-CLIENT], but MUST instead take
of the extended NICK message defined in section 4.1.3.
5.2.2
Upon successfully registering a new service connection, the server
subject to the same kind of REQUIREMENTS as for a user.
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
servers (SERVICE message) the new service's nickname and
information as supplied by the service (SERVICE message) and as
server could discover (from DNS servers).
5.3 Establishing a server-server connection
The process of establishing a server-to-server connection is
with danger since there are many possible areas where problems
occur - the least of which are race conditions
After a server has received a connection following by a PASS/
pair which were recognized as being valid, the server SHOULD
reply with its own PASS/SERVER information for that connection
well as all of the other state information it knows about
described below
When the initiating server receives a PASS/SERVER pair, it too
checks that the server responding is authenticated properly
accepting the connection to be that server
5.3.1 Link
Server links are based on a common protocol (defined by
document) but a particular link MAY set specific options using
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
If a server wishes to establish a compressed link with its peer,
MUST set the 'Z' flag in the options parameter to the PASS message
If both servers request compression and both servers are able
initialize the two compressed streams, then the remainder of
communication is to be compressed. If any server fails to
the stream, it will send an uncompressed ERROR message to its
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
Most servers implement various kinds of protections against
abusive behaviours from non trusted parties (typically users).
some networks, such protections are indispensable, on others they
superfluous. To require that all servers implement and enable
features on a particular network, the 'P' flag is used when
servers connect. If this flag is present, it means that the
protections are enabled, and that the server REQUIRES all its
links to enable them as well
Commonly found protections are described in sections 5.7 (
recently used nicknames) and 5.8 (Flood control of clients).
5.3.2 State information exchange when
The order of state information being exchanged between servers
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
NJOIN/MODE messages
NOTE: channel topics SHOULD NOT be exchanged here because the
command overwrites any old topic information, so at best, the
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
with servers that already exist occur before nickname
caused by a second server introducing a particular nickname. Due
the IRC network only being able to exist as an acyclic graph, it
be possible that the network has already reconnected in
location. In this event, the place where the server collision
indicates where the net needs to split
5.4 Terminating server-client
When a client connection unexpectedly closes, a QUIT message
generated on behalf of the client by the server to which the
was connected. No other message is to be generated or used
5.5 Terminating server-server
If a server-server connection is closed, either via a SQUIT
or "natural" causes, the rest of the connected IRC network MUST
its information updated by the server which detected the closure
The terminating server then sends a list of SQUITs (one for
server behind that connection). (See Section 4.1.6 (SQUIT)).
5.6 Tracking nickname
All IRC servers are REQUIRED to keep a history of recent
changes. This is important to allow the server to have a chance
keeping in touch of things when nick-change race conditions
with commands manipulating them. Messages which MUST trace
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
existence of the nickname, then check its history to see who
nick now belongs to (if anyone!). This reduces the chances of
conditions but they can still occur with the server ending
affecting the wrong client. When performing a change trace for
above command it is RECOMMENDED that a time range be given
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
nickname for every client it knows about if they all decided
change. This size is limited by other factors (such as memory, etc).
5.7 Tracking recently used
This mechanism is commonly known as "Nickname Delay", it has
proven to significantly reduce the number of nickname
resulting from "network splits"/reconnections as well as abuse
In addition of keeping track of nickname changes, servers SHOULD
track of nicknames which were recently used and were released as
result of a "network split" or a KILL message. These nicknames
then unavailable to the server local clients and cannot be re-
(even though they are not currently in use) for a certain period
time
The duration for which a nickname remains unavailable SHOULD be
considering many factors among which are the size (user wise) of
IRC network, and the usual duration of "network splits". It
be uniform on all servers for a given IRC network
5.8 Flood control of
With a large network of interconnected IRC servers, it is quite
for any single client attached to the network to supply a
stream of messages that result in not only flooding the network,
also degrading the level of service provided to others. Rather
require every 'victim' to provide their own protection,
protection was written into the server and is applied to all
except services. The current algorithm is as follows
* check to see if client's `message timer' is less than current
(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
time, parse any present messages and penalize the client by two (2)
seconds for each message
* additional penalties MAY be used for specific commands
generate a lot of traffic across the network
This in essence means that the client may send one (1) message
two (2) seconds without being adversely affected. Services MAY
be subject to this mechanism
Kalt Informational [Page 20]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
5.9 Non-blocking
In a real-time environment, it is essential that a server
does as little waiting as possible so that all the clients
serviced fairly. Obviously this requires non-blocking IO on
network read/write operations. For normal server connections,
was not difficult, but there are other support operations that
cause the server to block (such as disk reads). Where possible,
activity SHOULD be performed with a short timeout
5.9.1 Hostname (DNS)
Using the standard resolver libraries from Berkeley and others
meant large delays in some cases where replies have timed out.
avoid this, a separate set of DNS routines were written for
current implementation. Routines were setup for non-blocking
operations with local cache, and then polled from within the
server IO loop
5.9.2 Username (Ident)
Although there are numerous ident libraries (implementing
"Identification Protocol" [IDENT]) for use and inclusion into
programs, these caused problems since they operated in a
manner and resulted in frequent delays. Again the solution was
write a set of routines which would cooperate with the rest of
server and work using non-blocking IO
6. Current
There are a number of recognized problems with this protocol, all
which are hoped to be solved sometime in the near future during
rewrite. Currently, work is underway to find working solutions
these problems
6.1
It is widely recognized that this protocol does not
sufficiently well when used in a large arena. The main problem
from the requirement that all servers know about all other
and clients and that information regarding them be updated as soon
it changes. It is also desirable to keep the number of servers
so that the path length between any two points is kept minimal
the spanning tree as strongly branched as possible
Kalt Informational [Page 21]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
6.2
The current IRC protocol has 4 types of labels: the nickname,
channel name, the server name and the service name. Each of the
types has its own domain and no duplicates are allowed inside
domain. Currently, it is possible for users to pick the label
any of the first three, resulting in collisions. It is
recognized that this needs reworking, with a plan for unique
for nicks that don't collide being desirable as well as a
allowing a cyclic tree
6.2.1
The idea of the nickname on IRC is very convenient for users to
when talking to each other outside of a channel, but there is only
finite nickname space and being what they are, it's not uncommon
several people to want to use the same nick. If a nickname is
by two people using this protocol, either one will not succeed
both will be removed by use of KILL (See Section 3.7.1 of "IRC
Protocol" [IRC-CLIENT]).
6.2.2
The current channel layout requires that all servers know about
channels, their inhabitants and properties. Besides not
well, the issue of privacy is also a concern. A collision
channels is treated as an inclusive event (people from both nets
channel with common name are considered to be members of it)
than an exclusive one such as used to solve nickname collisions
This protocol defines "Safe Channels" which are very unlikely to
the subject of a channel collision. Other channel types are kept
backward compatibility
6.2.3
Although the number of servers is usually small relative to
number of users and channels, they too are currently REQUIRED to
known globally, either each one separately or hidden behind a mask
6.3
In some places within the server code, it has not been possible
avoid N^2 algorithms such as checking the channel list of a set
clients
Kalt Informational [Page 22]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
In current server versions, there are only few database
checks, most of the time each server assumes that a
server is correct. This opens the door to large problems if
connecting server is buggy or otherwise tries to
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
conditions generally arise from the problem of it taking time
messages to traverse and effect the IRC network. Even by changing
unique labels, there are problems with channel-related commands
disrupted
7. Security
7.1
Servers only have two means of authenticating incoming connections
plain text password, and DNS lookups. While these methods are
and widely recognized as unsafe, their combination has proven to
sufficient in the past
* public networks typically allow user connections with only
restrictions, without requiring accurate authentication
* private networks which operate in a controlled environment
use home-grown authentication mechanisms not available on
internet: reliable ident servers [IDENT], or other
mechanisms
The same comments apply to the authentication of IRC Operators
It should also be noted that while there has been no real demand
the years for stronger authentication, and no real effort to
better means to safely authenticate users, the current
offers enough to be able to easily plug-in external
methods based on the information that a client can submit to
server upon connection: nickname, username, password
7.2
Since the PASS and OPER messages of the IRC protocol are sent
clear text, a stream layer encryption mechanism (like "The
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
Mailing lists for IRC related discussion
General discussion: ircd-users@irc.
Protocol development: ircd-dev@irc.
Software implementations
ftp://ftp.irc.org/irc/
ftp://ftp.funet.fi/pub/unix/
ftp://coombs.anu.edu.au/pub/
Newsgroup: alt.
9.
Parts of this document were copied from the RFC 1459 [IRC]
first formally documented the IRC Protocol. It has also
from many rounds of review and comments. In particular,
following people have made significant contributions to
document
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx,
Ruokonen, Magnus Tjernstrom, Stefan Zehl
10.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
[IRC] Oikarinen, J. and D. Reed, "Internet Relay
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",
2812, April 2000.
[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management",
2811, April 2000.
[ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed
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
Specification version 1.3", RFC 1951, May 1996.
[GZIP] Deutsch, P., "GZIP file format specification
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
Christophe
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
EMail: kalt@stealth.
Kalt Informational [Page 25]
RFC 2813 Internet Relay Chat: Server Protocol April 2000
12. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Kalt Informational [Page 26]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
