ViewVC Help
View File | Revision Log | Show Annotations | View Changeset | Root Listing
root/svn/ircd-hybrid/doc/technical/rfc2813.txt
Revision: 32
Committed: Sun Oct 2 20:41:23 2005 UTC (18 years, 5 months ago) by knight
Content type: text/plain
File size: 52701 byte(s)
Log Message:
- svn:keywords

File Contents

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

Properties

Name Value
svn:eol-style native
svn:keywords Revision