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