rfc2813.txt 1 Network Working Group C. Kalt
2 Request for Comments: 2813 April 2000
3 Updates: 1459
4 Category: Informational
5
6 Internet Relay Chat: Server Protocol
7
8 Status of this Memo
9
10 This memo provides information for the Internet community. It does
11 not specify an Internet standard of any kind. Distribution of this
12 memo is unlimited.
13
14 Copyright Notice
15
16 Copyright (C) The Internet Society (2000). All Rights Reserved.
17
18 Abstract
19
20 While based on the client-server model, the IRC (Internet Relay Chat)
21 protocol allows servers to connect to each other effectively forming
22 a network.
23
24 This document defines the protocol used by servers to talk to each
25 other. It was originally a superset of the client protocol but has
26 evolved differently.
27
28 First formally documented in May 1993 as part of RFC 1459 [IRC], most
29 of the changes brought since then can be found in this document as
30 development was focused on making the protocol scale better. Better
31 scalability has allowed existing world-wide networks to keep growing
32 and reach sizes which defy the old specification.
33
34 Table of Contents
35
36 1. Introduction ............................................... 3
37 2. Global database ............................................ 3
38 2.1 Servers ................................................ 3
39 2.2 Clients ................................................ 4
40 2.2.1 Users ............................................. 4
41 2.2.2 Services .......................................... 4
42 2.3 Channels ............................................... 4
43 3. The IRC Server Specification ............................... 5
44 3.1 Overview ............................................... 5
45 3.2 Character codes ........................................ 5
46 3.3 Messages ............................................... 5
47 3.3.1 Message format in Augmented BNF ................... 6
48 3.4 Numeric replies ........................................ 7
49 4. Message Details ............................................ 7
50 4.1 Connection Registration ................................ 8
51 4.1.1 Password message .................................. 8
52 4.1.2 Server message .................................... 9
53 4.1.3 Nick .............................................. 10
54 4.1.4 Service message ................................... 11
55 4.1.5 Quit .............................................. 12
56 4.1.6 Server quit message ............................... 13
57 4.2 Channel operations ..................................... 14
58 4.2.1 Join message ...................................... 14
59 4.2.2 Njoin message ..................................... 15
60 4.2.3 Mode message ...................................... 16
61 5. Implementation details .................................... 16
62 5.1 Connection 'Liveness' .................................. 16
63 5.2 Accepting a client to server connection ................ 16
64 5.2.1 Users ............................................. 16
65 5.2.2 Services .......................................... 17
66 5.3 Establishing a server-server connection. ............... 17
67 5.3.1 Link options ...................................... 17
68 5.3.1.1 Compressed server to server links ............ 18
69 5.3.1.2 Anti abuse protections ....................... 18
70 5.3.2 State information exchange when connecting ........ 18
71 5.4 Terminating server-client connections .................. 19
72 5.5 Terminating server-server connections .................. 19
73 5.6 Tracking nickname changes .............................. 19
74 5.7 Tracking recently used nicknames ....................... 20
75 5.8 Flood control of clients ............................... 20
76 5.9 Non-blocking lookups ................................... 21
77 5.9.1 Hostname (DNS) lookups ............................ 21
78 5.9.2 Username (Ident) lookups .......................... 21
79 6. Current problems ........................................... 21
80 6.1 Scalability ............................................ 21
81 6.2 Labels ................................................. 22
82
83 6.2.1 Nicknames ......................................... 22
84 6.2.2 Channels .......................................... 22
85 6.2.3 Servers ........................................... 22
86 6.3 Algorithms ............................................. 22
87 7. Security Considerations .................................... 23
88 7.1 Authentication ......................................... 23
89 7.2 Integrity .............................................. 23
90 8. Current support and availability ........................... 24
91 9. Acknowledgements ........................................... 24
92 10. References ................................................ 24
93 11. Author's Address .......................................... 25
94 12. Full Copyright Statement ................................... 26
95
96 1. Introduction
97
98 This document is intended for people working on implementing an IRC
99 server but will also be useful to anyone implementing an IRC service.
100
101 Servers provide the three basic services required for realtime
102 conferencing defined by the "Internet Relay Chat: Architecture"
103 [IRC-ARCH]: client locator (via the client protocol [IRC-CLIENT]),
104 message relaying (via the server protocol defined in this document)
105 and channel hosting and management (following specific rules [IRC-
106 CHAN]).
107
108 2. Global database
109
110 Although the IRC Protocol defines a fairly distributed model, each
111 server maintains a "global state database" about the whole IRC
112 network. This database is, in theory, identical on all servers.
113
114 2.1 Servers
115
116 Servers are uniquely identified by their name which has a maximum
117 length of sixty three (63) characters. See the protocol grammar
118 rules (section 3.3.1) for what may and may not be used in a server
119 name.
120
121 Each server is typically known by all other servers, however it is
122 possible to define a "hostmask" to group servers together according
123 to their name. Inside the hostmasked area, all the servers have a
124 name which matches the hostmask, and any other server with a name
125 matching the hostmask SHALL NOT be connected to the IRC network
126 outside the hostmasked area. Servers which are outside the area have
127 no knowledge of the individual servers present inside the area,
128 instead they are presented with a virtual server which has the
129 hostmask for name.
130
131 2.2 Clients
132
133 For each client, all servers MUST have the following information: a
134 netwide unique identifier (whose format depends on the type of
135 client) and the server to which the client is connected.
136
137 2.2.1 Users
138
139 Each user is distinguished from other users by a unique nickname
140 having a maximum length of nine (9) characters. See the protocol
141 grammar rules (section 3.3.1) for what may and may not be used in a
142 nickname. In addition to the nickname, all servers MUST have the
143 following information about all users: the name of the host that the
144 user is running on, the username of the user on that host, and the
145 server to which the client is connected.
146
147 2.2.2 Services
148
149 Each service is distinguished from other services by a service name
150 composed of a nickname and a server name. The nickname has a maximum
151 length of nine (9) characters. See the protocol grammar rules
152 (section 3.3.1) for what may and may not be used in a nickname. The
153 server name used to compose the service name is the name of the
154 server to which the service is connected. In addition to this
155 service name all servers MUST know the service type.
156
157 Services differ from users by the format of their identifier, but
158 more importantly services and users don't have the same type of
159 access to the server: services can request part or all of the global
160 state information that a server maintains, but have a more restricted
161 set of commands available to them (See "IRC Client Protocol" [IRC-
162 CLIENT] for details on which) and are not allowed to join channels.
163 Finally services are not usually subject to the "Flood control"
164 mechanism described in section 5.8.
165
166 2.3 Channels
167
168 Alike services, channels have a scope [IRC-CHAN] and are not
169 necessarily known to all servers. When a channel existence is known
170 to a server, the server MUST keep track of the channel members, as
171 well as the channel modes.
172
173 3. The IRC Server Specification
174
175 3.1 Overview
176
177 The protocol as described herein is for use with server to server
178 connections. For client to server connections, see the IRC Client
179 Protocol specification.
180
181 There are, however, more restrictions on client connections (which
182 are considered to be untrustworthy) than on server connections.
183
184 3.2 Character codes
185
186 No specific character set is specified. The protocol is based on a a
187 set of codes which are composed of eight (8) bits, making up an
188 octet. Each message may be composed of any number of these octets;
189 however, some octet values are used for control codes which act as
190 message delimiters.
191
192 Regardless of being an 8-bit protocol, the delimiters and keywords
193 are such that protocol is mostly usable from US-ASCII terminal and a
194 telnet connection.
195
196 Because of IRC's Scandinavian origin, the characters {}|^ are
197 considered to be the lower case equivalents of the characters []\~,
198 respectively. This is a critical issue when determining the
199 equivalence of two nicknames, or channel names.
200
201 3.3 Messages
202
203 Servers and clients send each other messages which may or may not
204 generate a reply. Most communication between servers do not generate
205 any reply, as servers mostly perform routing tasks for the clients.
206
207 Each IRC message may consist of up to three main parts: the prefix
208 (OPTIONAL), the command, and the command parameters (maximum of
209 fifteen (15)). The prefix, command, and all parameters are separated
210 by one ASCII space character (0x20) each.
211
212 The presence of a prefix is indicated with a single leading ASCII
213 colon character (':', 0x3b), which MUST be the first character of the
214 message itself. There MUST be NO gap (whitespace) between the colon
215 and the prefix. The prefix is used by servers to indicate the true
216 origin of the message. If the prefix is missing from the message, it
217 is assumed to have originated from the connection from which it was
218 received. Clients SHOULD not use a prefix when sending a message
219 from themselves; if they use one, the only valid prefix is the
220 registered nickname associated with the client.
221
222 When a server receives a message, it MUST identify its source using
223 the (eventually assumed) prefix. If the prefix cannot be found in
224 the server's internal database, it MUST be discarded, and if the
225 prefix indicates the message comes from an (unknown) server, the link
226 from which the message was received MUST be dropped. Dropping a link
227 in such circumstances is a little excessive but necessary to maintain
228 the integrity of the network and to prevent future problems. Another
229 common error condition is that the prefix found in the server's
230 internal database identifies a different source (typically a source
231 registered from a different link than from which the message
232 arrived). If the message was received from a server link and the
233 prefix identifies a client, a KILL message MUST be issued for the
234 client and sent to all servers. In other cases, the link from which
235 the message arrived SHOULD be dropped for clients, and MUST be
236 dropped for servers. In all cases, the message MUST be discarded.
237
238 The command MUST either be a valid IRC command or a three (3) digit
239 number represented in ASCII text.
240
241 IRC messages are always lines of characters terminated with a CR-LF
242 (Carriage Return - Line Feed) pair, and these messages SHALL NOT
243 exceed 512 characters in length, counting all characters including
244 the trailing CR-LF. Thus, there are 510 characters maximum allowed
245 for the command and its parameters. There is no provision for
246 continuation message lines. See section 5 for more details about
247 current implementations.
248
249 3.3.1 Message format in Augmented BNF
250
251 The protocol messages must be extracted from the contiguous stream of
252 octets. The current solution is to designate two characters, CR and
253 LF, as message separators. Empty messages are silently ignored,
254 which permits use of the sequence CR-LF between messages without
255 extra problems.
256
257 The extracted message is parsed into the components <prefix>,
258 <command> and list of parameters (<params>).
259
260 The Augmented BNF representation for this is found in "IRC Client
261 Protocol" [IRC-CLIENT].
262
263 The extended prefix (["!" user "@" host ]) MUST NOT be used in server
264 to server communications and is only intended for server to client
265 messages in order to provide clients with more useful information
266 about who a message is from without the need for additional queries.
267
268 3.4 Numeric replies
269
270 Most of the messages sent to the server generate a reply of some
271 sort. The most common reply is the numeric reply, used for both
272 errors and normal replies. The numeric reply MUST be sent as one
273 message consisting of the sender prefix, the three digit numeric, and
274 the target of the reply. A numeric reply is not allowed to originate
275 from a client; any such messages received by a server are silently
276 dropped. In all other respects, a numeric reply is just like a normal
277 message, except that the keyword is made up of 3 numeric digits
278 rather than a string of letters. A list of different replies is
279 supplied in "IRC Client Protocol" [IRC-CLIENT].
280
281 4. Message Details
282
283 All the messages recognized by the IRC server and client are
284 described in the IRC Client Protocol specification.
285
286 Where the reply ERR_NOSUCHSERVER is returned, it means that the
287 target of the message could not be found. The server MUST NOT send
288 any other replies after this error for that command.
289
290 The server to which a client is connected is required to parse the
291 complete message, returning any appropriate errors. If the server
292 encounters a fatal error while parsing a message, an error MUST be
293 sent back to the client and the parsing terminated. A fatal error
294 may follow from incorrect command, a destination which is otherwise
295 unknown to the server (server, client or channel names fit this
296 category), not enough parameters or incorrect privileges.
297
298 If a full set of parameters is presented, then each MUST be checked
299 for validity and appropriate responses sent back to the client. In
300 the case of messages which use parameter lists using the comma as an
301 item separator, a reply MUST be sent for each item.
302
303 In the examples below, some messages appear using the full format:
304
305 :Name COMMAND parameter list
306
307 Such examples represent a message from "Name" in transit between
308 servers, where it is essential to include the name of the original
309 sender of the message so remote servers may send back a reply along
310 the correct path.
311
312 The message details for client to server communication are described
313 in the "IRC Client Protocol" [IRC-CLIENT]. Some sections in the
314 following pages apply to some of these messages, they are additions
315 to the message specifications which are only relevant to server to
316
317 server communication, or to the server implementation. The messages
318 which are introduced here are only used for server to server
319 communication.
320
321 4.1 Connection Registration
322
323 The commands described here are used to register a connection with
324 another IRC server.
325
326 4.1.1 Password message
327
328 Command: PASS
329 Parameters: <password> <version> <flags> [<options>]
330
331 The PASS command is used to set a 'connection password'. The
332 password MUST be set before any attempt to register the connection is
333 made. Currently this means that servers MUST send a PASS command
334 before any SERVER command. Only one (1) PASS command SHALL be
335 accepted from a connection.
336
337 The last three (3) parameters MUST be ignored if received from a
338 client (e.g. a user or a service). They are only relevant when
339 received from a server.
340
341 The <version> parameter is a string of at least four (4) characters,
342 and up to fourteen (14) characters. The first four (4) characters
343 MUST be digits and indicate the protocol version known by the server
344 issuing the message. The protocol described by this document is
345 version 2.10 which is encoded as "0210". The remaining OPTIONAL
346 characters are implementation dependent and should describe the
347 software version number.
348
349 The <flags> parameter is a string of up to one hundred (100)
350 characters. It is composed of two substrings separated by the
351 character "|" (%x7C). If present, the first substring MUST be the
352 name of the implementation. The reference implementation (See
353 Section 8, "Current support and availability") uses the string "IRC".
354 If a different implementation is written, which needs an identifier,
355 then that identifier should be registered through publication of an
356 RFC. The second substring is implementation dependent. Both
357 substrings are OPTIONAL, but the character "|" is REQUIRED. The
358 character "|" MUST NOT appear in either substring.
359
360 Finally, the last parameter, <options>, is used for link options.
361 The only options defined by the protocol are link compression (using
362 the character "Z"), and an abuse protection flag (using the character
363
364 "P"). See sections 5.3.1.1 (Compressed server to server links) and
365 5.3.1.2 (Anti abuse protections) respectively for more information on
366 these options.
367
368 Numeric Replies:
369
370 ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
371
372 Example:
373
374 PASS moresecretpassword 0210010000 IRC|aBgH$ Z
375
376 4.1.2 Server message
377
378 Command: SERVER
379 Parameters: <servername> <hopcount> <token> <info>
380
381 The SERVER command is used to register a new server. A new connection
382 introduces itself as a server to its peer. This message is also used
383 to pass server data over whole net. When a new server is connected
384 to net, information about it MUST be broadcasted to the whole
385 network.
386
387 The <info> parameter may contain space characters.
388
389 <hopcount> is used to give all servers some internal information on
390 how far away each server is. Local peers have a value of 0, and each
391 passed server increments the value. With a full server list, it
392 would be possible to construct a map of the entire server tree, but
393 hostmasks prevent this from being done.
394
395 The <token> parameter is an unsigned number used by servers as an
396 identifier. This identifier is subsequently used to reference a
397 server in the NICK and SERVICE messages sent between servers. Server
398 tokens only have a meaning for the point-to-point peering they are
399 used and MUST be unique for that connection. They are not global.
400
401 The SERVER message MUST only be accepted from either (a) a connection
402 which is yet to be registered and is attempting to register as a
403 server, or (b) an existing connection to another server, in which
404 case the SERVER message is introducing a new server behind that
405 server.
406
407 Most errors that occur with the receipt of a SERVER command result in
408 the connection being terminated by the destination host (target
409 SERVER). Because of the severity of such event, error replies are
410 usually sent using the "ERROR" command rather than a numeric.
411
412 If a SERVER message is parsed and it attempts to introduce a server
413 which is already known to the receiving server, the connection, from
414 which that message arrived, MUST be closed (following the correct
415 procedures), since a duplicate route to a server has been formed and
416 the acyclic nature of the IRC tree breaks. In some conditions, the
417 connection from which the already known server has registered MAY be
418 closed instead. It should be noted that this kind of error can also
419 be the result of a second running server, problem which cannot be
420 fixed within the protocol and typically requires human intervention.
421 This type of problem is particularly insidious, as it can quite
422 easily result in part of the IRC network to be isolated, with one of
423 the two servers connected to each partition therefore making it
424 impossible for the two parts to unite.
425
426 Numeric Replies:
427
428 ERR_ALREADYREGISTRED
429
430 Example:
431
432 SERVER test.oulu.fi 1 1 :Experimental server ; New server
433 test.oulu.fi introducing itself and
434 attempting to register.
435
436 :tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server
437 tolsun.oulu.fi is our uplink for
438 csd.bu.edu which is 5 hops away. The
439 token "34" will be used by
440 tolsun.oulu.fi when introducing new
441 users or services connected to
442 csd.bu.edu.
443
444 4.1.3 Nick
445
446 Command: NICK
447 Parameters: <nickname> <hopcount> <username> <host> <servertoken>
448 <umode> <realname>
449
450 This form of the NICK message MUST NOT be allowed from user
451 connections. However, it MUST be used instead of the NICK/USER pair
452 to notify other servers of new users joining the IRC network.
453
454 This message is really the combination of three distinct messages:
455 NICK, USER and MODE [IRC-CLIENT].
456
457 The <hopcount> parameter is used by servers to indicate how far away
458 a user is from its home server. A local connection has a hopcount of
459 0. The hopcount value is incremented by each passed server.
460
461 The <servertoken> parameter replaces the <servername> parameter of
462 the USER (See section 4.1.2 for more information on server tokens).
463
464 Examples:
465
466 NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New
467 user with nickname "syrk", username
468 "kalt", connected from host
469 "millennium.stealth.net" to server
470 "34" ("csd.bu.edu" according to the
471 previous example).
472
473 :krys NICK syrk ; The other form of the NICK message,
474 as defined in "IRC Client Protocol"
475 [IRC-CLIENT] and used between
476 servers: krys changed his nickname to
477 syrk
478
479 4.1.4 Service message
480
481 Command: SERVICE
482 Parameters: <servicename> <servertoken> <distribution> <type>
483 <hopcount> <info>
484
485 The SERVICE command is used to introduce a new service. This form of
486 the SERVICE message SHOULD NOT be allowed from client (unregistered,
487 or registered) connections. However, it MUST be used between servers
488 to notify other servers of new services joining the IRC network.
489
490 The <servertoken> is used to identify the server to which the service
491 is connected. (See section 4.1.2 for more information on server
492 tokens).
493
494 The <hopcount> parameter is used by servers to indicate how far away
495 a service is from its home server. A local connection has a hopcount
496 of 0. The hopcount value is incremented by each passed server.
497
498 The <distribution> parameter is used to specify the visibility of a
499 service. The service may only be known to servers which have a name
500 matching the distribution. For a matching server to have knowledge
501 of the service, the network path between that server and the server
502 to which the service is connected MUST be composed of servers whose
503 names all match the mask. Plain "*" is used when no restriction is
504 wished.
505
506 The <type> parameter is currently reserved for future usage.
507
508 Numeric Replies:
509
510 ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
511 ERR_ERRONEUSNICKNAME
512 RPL_YOURESERVICE RPL_YOURHOST
513 RPL_MYINFO
514
515 Example:
516
517 SERVICE dict@irc.fr 9 *.fr 0 1 :French Dictionary r" registered on
518 server "9" is being announced to
519 another server. This service will
520 only be available on servers whose
521 name matches "*.fr".
522
523 4.1.5 Quit
524
525 Command: QUIT
526 Parameters: [<Quit Message>]
527
528 A client session ends with a quit message. The server MUST close the
529 connection to a client which sends a QUIT message. If a "Quit
530 Message" is given, this will be sent instead of the default message,
531 the nickname or service name.
532
533 When "netsplit" (See Section 4.1.6) occur, the "Quit Message" is
534 composed of the names of two servers involved, separated by a space.
535 The first name is that of the server which is still connected and the
536 second name is either that of the server which has become
537 disconnected or that of the server to which the leaving client was
538 connected:
539
540 <Quit Message> = ":" servername SPACE servername
541
542 Because the "Quit Message" has a special meaning for "netsplits",
543 servers SHOULD NOT allow a client to use a <Quit Message> in the
544 format described above.
545
546 If, for some other reason, a client connection is closed without the
547 client issuing a QUIT command (e.g. client dies and EOF occurs on
548 socket), the server is REQUIRED to fill in the quit message with some
549 sort of message reflecting the nature of the event which caused it to
550 happen. Typically, this is done by reporting a system specific
551 error.
552
553 Numeric Replies:
554
555 None.
556
557 Examples:
558
559 :WiZ QUIT :Gone to have lunch ; Preferred message format.
560
561 4.1.6 Server quit message
562
563 Command: SQUIT
564 Parameters: <server> <comment>
565
566 The SQUIT message has two distinct uses.
567
568 The first one (described in "Internet Relay Chat: Client Protocol"
569 [IRC-CLIENT]) allows operators to break a local or remote server
570 link. This form of the message is also eventually used by servers to
571 break a remote server link.
572
573 The second use of this message is needed to inform other servers when
574 a "network split" (also known as "netsplit") occurs, in other words
575 to inform other servers about quitting or dead servers. If a server
576 wishes to break the connection to another server it MUST send a SQUIT
577 message to the other server, using the name of the other server as
578 the server parameter, which then closes its connection to the
579 quitting server.
580
581 The <comment> is filled in by servers which SHOULD place an error or
582 similar message here.
583
584 Both of the servers which are on either side of the connection being
585 closed are REQUIRED to send out a SQUIT message (to all its other
586 server connections) for all other servers which are considered to be
587 behind that link.
588
589 Similarly, a QUIT message MAY be sent to the other still connected
590 servers on behalf of all clients behind that quitting link. In
591 addition to this, all channel members of a channel which lost a
592 member due to the "split" MUST be sent a QUIT message. Messages to
593 channel members are generated by each client's local server.
594
595 If a server connection is terminated prematurely (e.g., the server on
596 the other end of the link died), the server which detects this
597 disconnection is REQUIRED to inform the rest of the network that the
598 connection has closed and fill in the comment field with something
599 appropriate.
600
601 When a client is removed as the result of a SQUIT message, the server
602 SHOULD add the nickname to the list of temporarily unavailable
603 nicknames in an attempt to prevent future nickname collisions. See
604
605 section 5.7 (Tracking recently used nicknames) for more information
606 on this procedure.
607
608 Numeric replies:
609
610 ERR_NOPRIVILEGES ERR_NOSUCHSERVER
611 ERR_NEEDMOREPARAMS
612
613 Example:
614
615 SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi
616 has been terminated because of "Bad
617 Link".
618
619 :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; message
620 from Trillian to disconnect
621 "cm22.eng.umd.edu" from the net
622 because "Server out of control".
623
624 4.2 Channel operations
625
626 This group of messages is concerned with manipulating channels, their
627 properties (channel modes), and their contents (typically users). In
628 implementing these, a number of race conditions are inevitable when
629 users at opposing ends of a network send commands which will
630 ultimately clash. It is also REQUIRED that servers keep a nickname
631 history to ensure that wherever a <nick> parameter is given, the
632 server check its history in case it has recently been changed.
633
634 4.2.1 Join message
635
636 Command: JOIN
637 Parameters: <channel>[ %x7 <modes> ]
638 *( "," <channel>[ %x7 <modes> ] )
639
640 The JOIN command is used by client to start listening a specific
641 channel. Whether or not a client is allowed to join a channel is
642 checked only by the local server the client is connected to; all
643 other servers automatically add the user to the channel when the
644 command is received from other servers.
645
646 Optionally, the user status (channel modes 'O', 'o', and 'v') on the
647 channel may be appended to the channel name using a control G (^G or
648 ASCII 7) as separator. Such data MUST be ignored if the message
649 wasn't received from a server. This format MUST NOT be sent to
650 clients, it can only be used between servers and SHOULD be avoided.
651
652 The JOIN command MUST be broadcast to all servers so that each server
653 knows where to find the users who are on the channel. This allows
654 optimal delivery of PRIVMSG and NOTICE messages to the channel.
655
656 Numeric Replies:
657
658 ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
659 ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
660 ERR_CHANNELISFULL ERR_BADCHANMASK
661 ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
662 ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE
663 RPL_TOPIC
664
665 Examples:
666
667 :WiZ JOIN #Twilight_zone ; JOIN message from WiZ
668
669 4.2.2 Njoin message
670
671 Command: NJOIN
672 Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
673 *( "," [ "@@" / "@" ] [ "+" ] <nickname> )
674
675 The NJOIN message is used between servers only. If such a message is
676 received from a client, it MUST be ignored. It is used when two
677 servers connect to each other to exchange the list of channel members
678 for each channel.
679
680 Even though the same function can be performed by using a succession
681 of JOIN, this message SHOULD be used instead as it is more efficient.
682 The prefix "@@" indicates that the user is the "channel creator", the
683 character "@" alone indicates a "channel operator", and the character
684 '+' indicates that the user has the voice privilege.
685
686 Numeric Replies:
687
688 ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
689 ERR_ALREADYREGISTRED
690
691 Examples:
692
693 :ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN
694 message from ircd.stealth.net
695 announcing users joining the
696 #Twilight_zone channel: WiZ with
697 channel operator status, syrk with
698 voice privilege and avalon with no
699 privilege.
700
701 4.2.3 Mode message
702
703 The MODE message is a dual-purpose command in IRC. It allows both
704 usernames and channels to have their mode changed.
705
706 When parsing MODE messages, it is RECOMMENDED that the entire message
707 be parsed first, and then the changes which resulted passed on.
708
709 It is REQUIRED that servers are able to change channel modes so that
710 "channel creator" and "channel operators" may be created.
711
712 5. Implementation details
713
714 A the time of writing, the only current implementation of this
715 protocol is the IRC server, version 2.10. Earlier versions may
716 implement some or all of the commands described by this document with
717 NOTICE messages replacing many of the numeric replies. Unfortunately,
718 due to backward compatibility requirements, the implementation of
719 some parts of this document varies with what is laid out. One
720 notable difference is:
721
722 * recognition that any LF or CR anywhere in a message marks
723 the end of that message (instead of requiring CR-LF);
724
725 The rest of this section deals with issues that are mostly of
726 importance to those who wish to implement a server but some parts
727 also apply directly to clients as well.
728
729 5.1 Connection 'Liveness'
730
731 To detect when a connection has died or become unresponsive, the
732 server MUST poll each of its connections. The PING command (See "IRC
733 Client Protocol" [IRC-CLIENT]) is used if the server doesn't get a
734 response from its peer in a given amount of time.
735
736 If a connection doesn't respond in time, its connection is closed
737 using the appropriate procedures.
738
739 5.2 Accepting a client to server connection
740
741 5.2.1 Users
742
743 When a server successfully registers a new user connection, it is
744 REQUIRED to send to the user unambiguous messages stating: the user
745 identifiers upon which it was registered (RPL_WELCOME), the server
746 name and version (RPL_YOURHOST), the server birth information
747 (RPL_CREATED), available user and channel modes (RPL_MYINFO), and it
748 MAY send any introductory messages which may be deemed appropriate.
749
750 In particular the server SHALL send the current user/service/server
751 count (as per the LUSER reply) and finally the MOTD (if any, as per
752 the MOTD reply).
753
754 After dealing with registration, the server MUST then send out to
755 other servers the new user's nickname (NICK message), other
756 information as supplied by itself (USER message) and as the server
757 could discover (from DNS servers). The server MUST NOT send this
758 information out with a pair of NICK and USER messages as defined in
759 "IRC Client Protocol" [IRC-CLIENT], but MUST instead take advantage
760 of the extended NICK message defined in section 4.1.3.
761
762 5.2.2 Services
763
764 Upon successfully registering a new service connection, the server is
765 subject to the same kind of REQUIREMENTS as for a user. Services
766 being somewhat different, only the following replies are sent:
767 RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO.
768
769 After dealing with this, the server MUST then send out to other
770 servers (SERVICE message) the new service's nickname and other
771 information as supplied by the service (SERVICE message) and as the
772 server could discover (from DNS servers).
773
774 5.3 Establishing a server-server connection.
775
776 The process of establishing a server-to-server connection is fraught
777 with danger since there are many possible areas where problems can
778 occur - the least of which are race conditions.
779
780 After a server has received a connection following by a PASS/SERVER
781 pair which were recognized as being valid, the server SHOULD then
782 reply with its own PASS/SERVER information for that connection as
783 well as all of the other state information it knows about as
784 described below.
785
786 When the initiating server receives a PASS/SERVER pair, it too then
787 checks that the server responding is authenticated properly before
788 accepting the connection to be that server.
789
790 5.3.1 Link options
791
792 Server links are based on a common protocol (defined by this
793 document) but a particular link MAY set specific options using the
794 PASS message (See Section 4.1.1).
795
796 5.3.1.1 Compressed server to server links
797
798 If a server wishes to establish a compressed link with its peer, it
799 MUST set the 'Z' flag in the options parameter to the PASS message.
800 If both servers request compression and both servers are able to
801 initialize the two compressed streams, then the remainder of the
802 communication is to be compressed. If any server fails to initialize
803 the stream, it will send an uncompressed ERROR message to its peer
804 and close the connection.
805
806 The data format used for the compression is described by RFC 1950
807 [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].
808
809 5.3.1.2 Anti abuse protections
810
811 Most servers implement various kinds of protections against possible
812 abusive behaviours from non trusted parties (typically users). On
813 some networks, such protections are indispensable, on others they are
814 superfluous. To require that all servers implement and enable such
815 features on a particular network, the 'P' flag is used when two
816 servers connect. If this flag is present, it means that the server
817 protections are enabled, and that the server REQUIRES all its server
818 links to enable them as well.
819
820 Commonly found protections are described in sections 5.7 (Tracking
821 recently used nicknames) and 5.8 (Flood control of clients).
822
823 5.3.2 State information exchange when connecting
824
825 The order of state information being exchanged between servers is
826 essential. The REQUIRED order is as follows:
827
828 * all known servers;
829
830 * all known client information;
831
832 * all known channel information.
833
834 Information regarding servers is sent via extra SERVER messages,
835 client information with NICK and SERVICE messages and channels with
836 NJOIN/MODE messages.
837
838 NOTE: channel topics SHOULD NOT be exchanged here because the TOPIC
839 command overwrites any old topic information, so at best, the two
840 sides of the connection would exchange topics.
841
842 By passing the state information about servers first, any collisions
843 with servers that already exist occur before nickname collisions
844 caused by a second server introducing a particular nickname. Due to
845 the IRC network only being able to exist as an acyclic graph, it may
846 be possible that the network has already reconnected in another
847 location. In this event, the place where the server collision occurs
848 indicates where the net needs to split.
849
850 5.4 Terminating server-client connections
851
852 When a client connection unexpectedly closes, a QUIT message is
853 generated on behalf of the client by the server to which the client
854 was connected. No other message is to be generated or used.
855
856 5.5 Terminating server-server connections
857
858 If a server-server connection is closed, either via a SQUIT command
859 or "natural" causes, the rest of the connected IRC network MUST have
860 its information updated by the server which detected the closure.
861 The terminating server then sends a list of SQUITs (one for each
862 server behind that connection). (See Section 4.1.6 (SQUIT)).
863
864 5.6 Tracking nickname changes
865
866 All IRC servers are REQUIRED to keep a history of recent nickname
867 changes. This is important to allow the server to have a chance of
868 keeping in touch of things when nick-change race conditions occur
869 with commands manipulating them. Messages which MUST trace nick
870 changes are:
871
872 * KILL (the nick being disconnected)
873
874 * MODE (+/- o,v on channels)
875
876 * KICK (the nick being removed from channel)
877
878 No other commands need to check nick changes.
879
880 In the above cases, the server is required to first check for the
881 existence of the nickname, then check its history to see who that
882 nick now belongs to (if anyone!). This reduces the chances of race
883 conditions but they can still occur with the server ending up
884 affecting the wrong client. When performing a change trace for an
885 above command it is RECOMMENDED that a time range be given and
886 entries which are too old ignored.
887
888 For a reasonable history, a server SHOULD be able to keep previous
889 nickname for every client it knows about if they all decided to
890 change. This size is limited by other factors (such as memory, etc).
891
892 5.7 Tracking recently used nicknames
893
894 This mechanism is commonly known as "Nickname Delay", it has been
895 proven to significantly reduce the number of nickname collisions
896 resulting from "network splits"/reconnections as well as abuse.
897
898 In addition of keeping track of nickname changes, servers SHOULD keep
899 track of nicknames which were recently used and were released as the
900 result of a "network split" or a KILL message. These nicknames are
901 then unavailable to the server local clients and cannot be re-used
902 (even though they are not currently in use) for a certain period of
903 time.
904
905 The duration for which a nickname remains unavailable SHOULD be set
906 considering many factors among which are the size (user wise) of the
907 IRC network, and the usual duration of "network splits". It SHOULD
908 be uniform on all servers for a given IRC network.
909
910 5.8 Flood control of clients
911
912 With a large network of interconnected IRC servers, it is quite easy
913 for any single client attached to the network to supply a continuous
914 stream of messages that result in not only flooding the network, but
915 also degrading the level of service provided to others. Rather than
916 require every 'victim' to provide their own protection, flood
917 protection was written into the server and is applied to all clients
918 except services. The current algorithm is as follows:
919
920 * check to see if client's `message timer' is less than current time
921 (set to be equal if it is);
922
923 * read any data present from the client;
924
925 * while the timer is less than ten (10) seconds ahead of the current
926 time, parse any present messages and penalize the client by two (2)
927 seconds for each message;
928
929 * additional penalties MAY be used for specific commands which
930 generate a lot of traffic across the network.
931
932 This in essence means that the client may send one (1) message every
933 two (2) seconds without being adversely affected. Services MAY also
934 be subject to this mechanism.
935
936 5.9 Non-blocking lookups
937
938 In a real-time environment, it is essential that a server process
939 does as little waiting as possible so that all the clients are
940 serviced fairly. Obviously this requires non-blocking IO on all
941 network read/write operations. For normal server connections, this
942 was not difficult, but there are other support operations that may
943 cause the server to block (such as disk reads). Where possible, such
944 activity SHOULD be performed with a short timeout.
945
946 5.9.1 Hostname (DNS) lookups
947
948 Using the standard resolver libraries from Berkeley and others has
949 meant large delays in some cases where replies have timed out. To
950 avoid this, a separate set of DNS routines were written for the
951 current implementation. Routines were setup for non-blocking IO
952 operations with local cache, and then polled from within the main
953 server IO loop.
954
955 5.9.2 Username (Ident) lookups
956
957 Although there are numerous ident libraries (implementing the
958 "Identification Protocol" [IDENT]) for use and inclusion into other
959 programs, these caused problems since they operated in a synchronous
960 manner and resulted in frequent delays. Again the solution was to
961 write a set of routines which would cooperate with the rest of the
962 server and work using non-blocking IO.
963
964 6. Current problems
965
966 There are a number of recognized problems with this protocol, all of
967 which are hoped to be solved sometime in the near future during its
968 rewrite. Currently, work is underway to find working solutions to
969 these problems.
970
971 6.1 Scalability
972
973 It is widely recognized that this protocol does not scale
974 sufficiently well when used in a large arena. The main problem comes
975 from the requirement that all servers know about all other servers
976 and clients and that information regarding them be updated as soon as
977 it changes. It is also desirable to keep the number of servers low
978 so that the path length between any two points is kept minimal and
979 the spanning tree as strongly branched as possible.
980
981 6.2 Labels
982
983 The current IRC protocol has 4 types of labels: the nickname, the
984 channel name, the server name and the service name. Each of the four
985 types has its own domain and no duplicates are allowed inside that
986 domain. Currently, it is possible for users to pick the label for
987 any of the first three, resulting in collisions. It is widely
988 recognized that this needs reworking, with a plan for unique names
989 for nicks that don't collide being desirable as well as a solution
990 allowing a cyclic tree.
991
992 6.2.1 Nicknames
993
994 The idea of the nickname on IRC is very convenient for users to use
995 when talking to each other outside of a channel, but there is only a
996 finite nickname space and being what they are, it's not uncommon for
997 several people to want to use the same nick. If a nickname is chosen
998 by two people using this protocol, either one will not succeed or
999 both will be removed by use of KILL (See Section 3.7.1 of "IRC Client
1000 Protocol" [IRC-CLIENT]).
1001
1002 6.2.2 Channels
1003
1004 The current channel layout requires that all servers know about all
1005 channels, their inhabitants and properties. Besides not scaling
1006 well, the issue of privacy is also a concern. A collision of
1007 channels is treated as an inclusive event (people from both nets on
1008 channel with common name are considered to be members of it) rather
1009 than an exclusive one such as used to solve nickname collisions.
1010
1011 This protocol defines "Safe Channels" which are very unlikely to be
1012 the subject of a channel collision. Other channel types are kept for
1013 backward compatibility.
1014
1015 6.2.3 Servers
1016
1017 Although the number of servers is usually small relative to the
1018 number of users and channels, they too are currently REQUIRED to be
1019 known globally, either each one separately or hidden behind a mask.
1020
1021 6.3 Algorithms
1022
1023 In some places within the server code, it has not been possible to
1024 avoid N^2 algorithms such as checking the channel list of a set of
1025 clients.
1026
1027 In current server versions, there are only few database consistency
1028 checks, most of the time each server assumes that a neighbouring
1029 server is correct. This opens the door to large problems if a
1030 connecting server is buggy or otherwise tries to introduce
1031 contradictions to the existing net.
1032
1033 Currently, because of the lack of unique internal and global labels,
1034 there are a multitude of race conditions that exist. These race
1035 conditions generally arise from the problem of it taking time for
1036 messages to traverse and effect the IRC network. Even by changing to
1037 unique labels, there are problems with channel-related commands being
1038 disrupted.
1039
1040 7. Security Considerations
1041
1042 7.1 Authentication
1043
1044 Servers only have two means of authenticating incoming connections:
1045 plain text password, and DNS lookups. While these methods are weak
1046 and widely recognized as unsafe, their combination has proven to be
1047 sufficient in the past:
1048
1049 * public networks typically allow user connections with only few
1050 restrictions, without requiring accurate authentication.
1051
1052 * private networks which operate in a controlled environment often
1053 use home-grown authentication mechanisms not available on the
1054 internet: reliable ident servers [IDENT], or other proprietary
1055 mechanisms.
1056
1057 The same comments apply to the authentication of IRC Operators.
1058
1059 It should also be noted that while there has been no real demand over
1060 the years for stronger authentication, and no real effort to provide
1061 better means to safely authenticate users, the current protocol
1062 offers enough to be able to easily plug-in external authentication
1063 methods based on the information that a client can submit to the
1064 server upon connection: nickname, username, password.
1065
1066 7.2 Integrity
1067
1068 Since the PASS and OPER messages of the IRC protocol are sent in
1069 clear text, a stream layer encryption mechanism (like "The TLS
1070 Protocol" [TLS]) could be used to protect these transactions.
1071
1072 8. Current support and availability
1073
1074 Mailing lists for IRC related discussion:
1075 General discussion: ircd-users@irc.org
1076 Protocol development: ircd-dev@irc.org
1077
1078 Software implementations:
1079 ftp://ftp.irc.org/irc/server
1080 ftp://ftp.funet.fi/pub/unix/irc
1081 ftp://coombs.anu.edu.au/pub/irc
1082
1083 Newsgroup: alt.irc
1084
1085 9. Acknowledgements
1086
1087 Parts of this document were copied from the RFC 1459 [IRC] which
1088 first formally documented the IRC Protocol. It has also benefited
1089 from many rounds of review and comments. In particular, the
1090 following people have made significant contributions to this
1091 document:
1092
1093 Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
1094 Ruokonen, Magnus Tjernstrom, Stefan Zehl.
1095
1096 10. References
1097
1098 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
1099 Requirement Levels", BCP 14, RFC 2119, March 1997.
1100
1101 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
1102 Specifications: ABNF", RFC 2234, November 1997.
1103
1104 [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
1105 Protocol", RFC 1459, May 1993.
1106
1107 [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
1108 April 2000.
1109
1110 [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
1111 2812, April 2000.
1112
1113 [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
1114 2811, April 2000.
1115
1116 [ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
1117 Format Specification version 3.3", RFC 1950, May 1996.
1118
1119 [DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format
1120 Specification version 1.3", RFC 1951, May 1996.
1121
1122 [GZIP] Deutsch, P., "GZIP file format specification version
1123 4.3", RFC 1952, May 1996.
1124
1125 [IDENT] St. Johns, M., "The Identification Protocol", RFC 1413,
1126 February 1993.
1127
1128 [TLS] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
1129 January 1999.
1130
1131 11. Author's Address
1132
1133 Christophe Kalt
1134 99 Teaneck Rd, Apt #117
1135 Ridgefield Park, NJ 07660
1136 USA
1137
1138 EMail: kalt@stealth.net
1139
1140 12. Full Copyright Statement
1141
1142 Copyright (C) The Internet Society (2000). All Rights Reserved.
1143
1144 This document and translations of it may be copied and furnished to
1145 others, and derivative works that comment on or otherwise explain it
1146 or assist in its implementation may be prepared, copied, published
1147 and distributed, in whole or in part, without restriction of any
1148 kind, provided that the above copyright notice and this paragraph are
1149 included on all such copies and derivative works. However, this
1150 document itself may not be modified in any way, such as by removing
1151 the copyright notice or references to the Internet Society or other
1152 Internet organizations, except as needed for the purpose of
1153 developing Internet standards in which case the procedures for
1154 copyrights defined in the Internet Standards process must be
1155 followed, or as required to translate it into languages other than
1156 English.
1157
1158 The limited permissions granted above are perpetual and will not be
1159 revoked by the Internet Society or its successors or assigns.
1160
1161 This document and the information contained herein is provided on an
1162 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1163 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1164 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1165 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1166 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1167
1168 Acknowledgement
1169
1170 Funding for the RFC Editor function is currently provided by the
1171 Internet Society.
1172