rfc2811.txt 1 Network Working Group C. Kalt
2 Request for Comments: 2811 April 2000
3 Updates: 1459
4 Category: Informational
5
6 Internet Relay Chat: Channel Management
7
8 Status of this Memo
9
10 This memo provides information for the Internet community. It does
11 not specify an Internet standard of any kind. Distribution of this
12 memo is unlimited.
13
14 Copyright Notice
15
16 Copyright (C) The Internet Society (2000). All Rights Reserved.
17
18 Abstract
19
20 One of the most notable characteristics of the IRC (Internet Relay
21 Chat) protocol is to allow for users to be grouped in forums, called
22 channels, providing a mean for multiple users to communicate
23 together.
24
25 There was originally a unique type of channels, but with the years,
26 new types appeared either as a response to a need, or for
27 experimental purposes.
28
29 This document specifies how channels, their characteristics and
30 properties are managed by IRC servers.
31
32 Table of Contents
33
34 1. Introduction ............................................... 2
35 2. Channel Characteristics .................................... 3
36 2.1 Namespace .............................................. 3
37 2.2 Channel Scope .......................................... 3
38 2.3 Channel Properties ..................................... 4
39 2.4 Privileged Channel Members ............................. 4
40 2.4.1 Channel Operators ................................. 5
41 2.4.2 Channel Creator ................................... 5
42 3. Channel lifetime ........................................... 5
43 3.1 Standard channels ...................................... 5
44 3.2 Safe Channels .......................................... 6
45 4. Channel Modes .............................................. 7
46 4.1 Member Status .......................................... 7
47 4.1.1 "Channel Creator" Status .......................... 7
48
49 4.1.2 Channel Operator Status ........................... 8
50 4.1.3 Voice Privilege ................................... 8
51 4.2 Channel Flags .......................................... 8
52 4.2.1 Anonymous Flag .................................... 8
53 4.2.2 Invite Only Flag .................................. 8
54 4.2.3 Moderated Channel Flag ............................ 9
55 4.2.4 No Messages To Channel From Clients On The Outside 9
56 4.2.5 Quiet Channel ..................................... 9
57 4.2.6 Private and Secret Channels ....................... 9
58 4.2.7 Server Reop Flag .................................. 10
59 4.2.8 Topic ............................................. 10
60 4.2.9 User Limit ........................................ 10
61 4.2.10 Channel Key ...................................... 10
62 4.3 Channel Access Control ................................. 10
63 4.3.1 Channel Ban and Exception ......................... 11
64 4.3.2 Channel Invitation ................................ 11
65 5. Current Implementations .................................... 11
66 5.1 Tracking Recently Used Channels ........................ 11
67 5.2 Safe Channels .......................................... 12
68 5.2.1 Channel Identifier ................................ 12
69 5.2.2 Channel Delay ..................................... 12
70 5.2.3 Abuse Window ...................................... 13
71 5.2.4 Preserving Sanity In The Name Space ............... 13
72 5.2.5 Server Reop Mechanism ............................. 13
73 6. Current problems ........................................... 14
74 6.1 Labels ................................................. 14
75 6.1.1 Channel Delay ..................................... 14
76 6.1.2 Safe Channels ..................................... 15
77 6.2 Mode Propagation Delays ................................ 15
78 6.3 Collisions And Channel Modes ........................... 15
79 6.4 Resource Exhaustion .................................... 16
80 7. Security Considerations .................................... 16
81 7.1 Access Control ......................................... 16
82 7.2 Channel Privacy ........................................ 16
83 7.3 Anonymity ............................................... 17
84 8. Current support and availability ........................... 17
85 9. Acknowledgements ........................................... 17
86 10. References ................................................ 18
87 11. Author's Address .......................................... 18
88 12. Full Copyright Statement ................................... 19
89
90 1. Introduction
91
92 This document defines in detail on how channels are managed by the
93 IRC servers and will be mostly useful to people working on
94 implementing an IRC server.
95
96 While the concepts defined here are an important part of IRC, they
97 remain non essential for implementing clients. While the trend seems
98 to be towards more and more complex and "intelligent" clients which
99 are able to take advantage of knowing the internal workings of
100 channels to provide the users with a more friendly interface, simple
101 clients can be implemented without reading this document.
102
103 Many of the concepts defined here were designed with the IRC
104 architecture [IRC-ARCH] in mind and mostly make sense in this
105 context. However, many others could be applied to other
106 architectures in order to provide forums for a conferencing system.
107
108 Finally, it is to be noted that IRC users may find some of the
109 following sections of interest, in particular sections 2 (Channel
110 Characteristics) and 4 (Channel Modes).
111
112 2. Channel Characteristics
113
114 A channel is a named group of one or more users which will all
115 receive messages addressed to that channel. A channel is
116 characterized by its name, properties and current members.
117
118 2.1 Namespace
119
120 Channels names are strings (beginning with a '&', '#', '+' or '!'
121 character) of length up to fifty (50) characters. Channel names are
122 case insensitive.
123
124 Apart from the the requirement that the first character being either
125 '&', '#', '+' or '!' (hereafter called "channel prefix"). The only
126 restriction on a channel name is that it SHALL NOT contain any spaces
127 (' '), a control G (^G or ASCII 7), a comma (',' which is used as a
128 list item separator by the protocol). Also, a colon (':') is used as
129 a delimiter for the channel mask. The exact syntax of a channel name
130 is defined in "IRC Server Protocol" [IRC-SERVER].
131
132 The use of different prefixes effectively creates four (4) distinct
133 namespaces for channel names. This is important because of the
134 protocol limitations regarding namespaces (in general). See section
135 6.1 (Labels) for more details on these limitations.
136
137 2.2 Channel Scope
138
139 A channel entity is known by one or more servers on the IRC network.
140 A user can only become member of a channel known by the server to
141 which the user is directly connected. The list of servers which know
142
143 of the existence of a particular channel MUST be a contiguous part of
144 the IRC network, in order for the messages addressed to the channel
145 to be sent to all the channel members.
146
147 Channels with '&' as prefix are local to the server where they are
148 created.
149
150 Other channels are known to one (1) or more servers that are
151 connected to the network, depending on the channel mask:
152
153 If there is no channel mask, then the channel is known to all
154 the servers.
155
156 If there is a channel mask, then the channel MUST only be known
157 to servers which has a local user on the channel, and to its
158 neighbours if the mask matches both the local and neighbouring
159 server names. Since other servers have absolutely no knowledge of
160 the existence of such a channel, the area formed by the servers
161 having a name matching the mask has to be contiguous for the
162 channel to be known by all these servers. Channel masks are best
163 used in conjunction with server hostmasking [IRC-SERVER].
164
165 2.3 Channel Properties
166
167 Each channel has its own properties, which are defined by channel
168 modes. Channel modes can be manipulated by the channel members. The
169 modes affect the way servers manage the channels.
170
171 Channels with '+' as prefix do not support channel modes. This means
172 that all the modes are unset, with the exception of the 't' channel
173 flag which is set.
174
175 2.4 Privileged Channel Members
176
177 In order for the channel members to keep some control over a channel,
178 and some kind of sanity, some channel members are privileged. Only
179 these members are allowed to perform the following actions on the
180 channel:
181
182 INVITE - Invite a client to an invite-only channel (mode +i)
183 KICK - Eject a client from the channel
184 MODE - Change the channel's mode, as well as
185 members' privileges
186 PRIVMSG - Sending messages to the channel (mode +n, +m, +v)
187 TOPIC - Change the channel topic in a mode +t channel
188
189 2.4.1 Channel Operators
190
191 The channel operators (also referred to as a "chop" or "chanop") on a
192 given channel are considered to 'own' that channel. Ownership of a
193 channel is shared among channel operators.
194
195 Channel operators are identified by the '@' symbol next to their
196 nickname whenever it is associated with a channel (i.e., replies to
197 the NAMES, WHO and WHOIS commands).
198
199 Since channels starting with the character '+' as prefix do not
200 support channel modes, no member can therefore have the status of
201 channel operator.
202
203 2.4.2 Channel Creator
204
205 A user who creates a channel with the character '!' as prefix is
206 identified as the "channel creator". Upon creation of the channel,
207 this user is also given channel operator status.
208
209 In recognition of this status, the channel creators are endowed with
210 the ability to toggle certain modes of the channel which channel
211 operators may not manipulate.
212
213 A "channel creator" can be distinguished from a channel operator by
214 issuing the proper MODE command. See the "IRC Client Protocol"
215 [IRC-CLIENT] for more information on this topic.
216
217 3. Channel lifetime
218
219 In regard to the lifetime of a channel, there are typically two
220 groups of channels: standard channels which prefix is either '&', '#'
221 or '+', and "safe channels" which prefix is '!'.
222
223 3.1 Standard channels
224
225 These channels are created implicitly when the first user joins it,
226 and cease to exist when the last user leaves it. While the channel
227 exists, any client can reference the channel using the name of the
228 channel.
229
230 The user creating a channel automatically becomes channel operator
231 with the notable exception of channels which name is prefixed by the
232 character '+', see section 4 (Channel modes). See section 2.4.1
233 (Channel Operators) for more details on this title.
234
235 In order to avoid the creation of duplicate channels (typically when
236 the IRC network becomes disjoint because of a split between two
237 servers), channel names SHOULD NOT be allowed to be reused by a user
238 if a channel operator (See Section 2.4.1 (Channel Operators)) has
239 recently left the channel because of a network split. If this
240 happens, the channel name is temporarily unavailable. The duration
241 while a channel remains unavailable should be tuned on a per IRC
242 network basis. It is important to note that this prevents local
243 users from creating a channel using the same name, but does not
244 prevent the channel to be recreated by a remote user. The latter
245 typically happens when the IRC network rejoins. Obviously, this
246 mechanism only makes sense for channels which name begins with the
247 character '#', but MAY be used for channels which name begins with
248 the character '+'. This mechanism is commonly known as "Channel
249 Delay".
250
251 3.2 Safe Channels
252
253 Unlike other channels, "safe channels" are not implicitly created. A
254 user wishing to create such a channel MUST request the creation by
255 sending a special JOIN command to the server in which the channel
256 identifier (then unknown) is replaced by the character '!'. The
257 creation process for this type of channel is strictly controlled.
258 The user only chooses part of the channel name (known as the channel
259 "short name"), the server automatically prepends the user provided
260 name with a channel identifier consisting of five (5) characters.
261 The channel name resulting from the combination of these two elements
262 is unique, making the channel safe from abuses based on network
263 splits.
264
265 The user who creates such a channel automatically becomes "channel
266 creator". See section 2.4.2 (Channel Creator) for more details on
267 this title.
268
269 A server MUST NOT allow the creation of a new channel if another
270 channel with the same short name exists; or if another channel with
271 the same short name existed recently AND any of its member(s) left
272 because of a network split. Such channel ceases to exist after last
273 user leaves AND no other member recently left the channel because of
274 a network split.
275
276 Unlike the mechanism described in section 5.2.2 (Channel Delay), in
277 this case, channel names do not become unavailable: these channels
278 may continue to exist after the last user left. Only the user
279 creating the channel becomes "channel creator", users joining an
280 existing empty channel do not automatically become "channel creator"
281 nor "channel operator".
282
283 To ensure the uniqueness of the channel names, the channel identifier
284 created by the server MUST follow specific rules. For more details
285 on this, see section 5.2.1 (Channel Identifier).
286
287 4. Channel Modes
288
289 The various modes available for channels are as follows:
290
291 O - give "channel creator" status;
292 o - give/take channel operator privilege;
293 v - give/take the voice privilege;
294
295 a - toggle the anonymous channel flag;
296 i - toggle the invite-only channel flag;
297 m - toggle the moderated channel;
298 n - toggle the no messages to channel from clients on the
299 outside;
300 q - toggle the quiet channel flag;
301 p - toggle the private channel flag;
302 s - toggle the secret channel flag;
303 r - toggle the server reop channel flag;
304 t - toggle the topic settable by channel operator only flag;
305
306 k - set/remove the channel key (password);
307 l - set/remove the user limit to channel;
308
309 b - set/remove ban mask to keep users out;
310 e - set/remove an exception mask to override a ban mask;
311 I - set/remove an invitation mask to automatically override
312 the invite-only flag;
313
314 Unless mentioned otherwise below, all these modes can be manipulated
315 by "channel operators" by using the MODE command defined in "IRC
316 Client Protocol" [IRC-CLIENT].
317
318 4.1 Member Status
319
320 The modes in this category take a channel member nickname as argument
321 and affect the privileges given to this user.
322
323 4.1.1 "Channel Creator" Status
324
325 The mode 'O' is only used in conjunction with "safe channels" and
326 SHALL NOT be manipulated by users. Servers use it to give the user
327 creating the channel the status of "channel creator".
328
329 4.1.2 Channel Operator Status
330
331 The mode 'o' is used to toggle the operator status of a channel
332 member.
333
334 4.1.3 Voice Privilege
335
336 The mode 'v' is used to give and take voice privilege to/from a
337 channel member. Users with this privilege can talk on moderated
338 channels. (See section 4.2.3 (Moderated Channel Flag).
339
340 4.2 Channel Flags
341
342 The modes in this category are used to define properties which
343 affects how channels operate.
344
345 4.2.1 Anonymous Flag
346
347 The channel flag 'a' defines an anonymous channel. This means that
348 when a message sent to the channel is sent by the server to users,
349 and the origin is a user, then it MUST be masked. To mask the
350 message, the origin is changed to "anonymous!anonymous@anonymous."
351 (e.g., a user with the nickname "anonymous", the username "anonymous"
352 and from a host called "anonymous."). Because of this, servers MUST
353 forbid users from using the nickname "anonymous". Servers MUST also
354 NOT send QUIT messages for users leaving such channels to the other
355 channel members but generate a PART message instead.
356
357 On channels with the character '&' as prefix, this flag MAY be
358 toggled by channel operators, but on channels with the character '!'
359 as prefix, this flag can be set (but SHALL NOT be unset) by the
360 "channel creator" only. This flag MUST NOT be made available on
361 other types of channels.
362
363 Replies to the WHOIS, WHO and NAMES commands MUST NOT reveal the
364 presence of other users on channels for which the anonymous flag is
365 set.
366
367 4.2.2 Invite Only Flag
368
369 When the channel flag 'i' is set, new members are only accepted if
370 their mask matches Invite-list (See section 4.3.2) or they have been
371 invited by a channel operator. This flag also restricts the usage of
372 the INVITE command (See "IRC Client Protocol" [IRC-CLIENT]) to
373 channel operators.
374
375 4.2.3 Moderated Channel Flag
376
377 The channel flag 'm' is used to control who may speak on a channel.
378 When it is set, only channel operators, and members who have been
379 given the voice privilege may send messages to the channel.
380
381 This flag only affects users.
382
383 4.2.4 No Messages To Channel From Clients On The Outside
384
385 When the channel flag 'n' is set, only channel members MAY send
386 messages to the channel.
387
388 This flag only affects users.
389
390 4.2.5 Quiet Channel
391
392 The channel flag 'q' is for use by servers only. When set, it
393 restricts the type of data sent to users about the channel
394 operations: other user joins, parts and nick changes are not sent.
395 From a user's point of view, the channel contains only one user.
396
397 This is typically used to create special local channels on which the
398 server sends notices related to its operations. This was used as a
399 more efficient and flexible way to replace the user mode 's' defined
400 in RFC 1459 [IRC].
401
402 4.2.6 Private and Secret Channels
403
404 The channel flag 'p' is used to mark a channel "private" and the
405 channel flag 's' to mark a channel "secret". Both properties are
406 similar and conceal the existence of the channel from other users.
407
408 This means that there is no way of getting this channel's name from
409 the server without being a member. In other words, these channels
410 MUST be omitted from replies to queries like the WHOIS command.
411
412 When a channel is "secret", in addition to the restriction above, the
413 server will act as if the channel does not exist for queries like the
414 TOPIC, LIST, NAMES commands. Note that there is one exception to
415 this rule: servers will correctly reply to the MODE command.
416 Finally, secret channels are not accounted for in the reply to the
417 LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC-
418 CLIENT]) when the <mask> parameter is specified.
419
420 The channel flags 'p' and 's' MUST NOT both be set at the same time.
421 If a MODE message originating from a server sets the flag 'p' and the
422 flag 's' is already set for the channel, the change is silently
423 ignored. This should only happen during a split healing phase
424 (mentioned in the "IRC Server Protocol" document [IRC-SERVER]).
425
426 4.2.7 Server Reop Flag
427
428 The channel flag 'r' is only available on channels which name begins
429 with the character '!' and MAY only be toggled by the "channel
430 creator".
431
432 This flag is used to prevent a channel from having no channel
433 operator for an extended period of time. When this flag is set, any
434 channel that has lost all its channel operators for longer than the
435 "reop delay" period triggers a mechanism in servers to reop some or
436 all of the channel inhabitants. This mechanism is described more in
437 detail in section 5.2.4 (Channel Reop Mechanism).
438
439 4.2.8 Topic
440
441 The channel flag 't' is used to restrict the usage of the TOPIC
442 command to channel operators.
443
444 4.2.9 User Limit
445
446 A user limit may be set on channels by using the channel flag 'l'.
447 When the limit is reached, servers MUST forbid their local users to
448 join the channel.
449
450 The value of the limit MUST only be made available to the channel
451 members in the reply sent by the server to a MODE query.
452
453 4.2.10 Channel Key
454
455 When a channel key is set (by using the mode 'k'), servers MUST
456 reject their local users request to join the channel unless this key
457 is given.
458
459 The channel key MUST only be made visible to the channel members in
460 the reply sent by the server to a MODE query.
461
462 4.3 Channel Access Control
463
464 The last category of modes is used to control access to the channel,
465 they take a mask as argument.
466
467 In order to reduce the size of the global database for control access
468 modes set for channels, servers MAY put a maximum limit on the number
469 of such modes set for a particular channel. If such restriction is
470 imposed, it MUST only affect user requests. The limit SHOULD be
471 homogeneous on a per IRC network basis.
472
473 4.3.1 Channel Ban and Exception
474
475 When a user requests to join a channel, his local server checks if
476 the user's address matches any of the ban masks set for the channel.
477 If a match is found, the user request is denied unless the address
478 also matches an exception mask set for the channel.
479
480 Servers MUST NOT allow a channel member who is banned from the
481 channel to speak on the channel, unless this member is a channel
482 operator or has voice privilege. (See Section 4.1.3 (Voice
483 Privilege)).
484
485 A user who is banned from a channel and who carries an invitation
486 sent by a channel operator is allowed to join the channel.
487
488 4.3.2 Channel Invitation
489
490 For channels which have the invite-only flag set (See Section 4.2.2
491 (Invite Only Flag)), users whose address matches an invitation mask
492 set for the channel are allowed to join the channel without any
493 invitation.
494
495 5. Current Implementations
496
497 The only current implementation of these rules as part of the IRC
498 protocol is the IRC server, version 2.10.
499
500 The rest of this section deals with issues that are mostly of
501 importance to those who wish to implement a server but some parts may
502 also be of interest for client writers.
503
504 5.1 Tracking Recently Used Channels
505
506 This mechanism is commonly known as "Channel Delay" and generally
507 only applies to channels which names is prefixed with the character
508 '#' (See Section 3.1 "Standard channels").
509
510 When a network split occurs, servers SHOULD keep track of which
511 channels lost a "channel operator" as the result of the break. These
512 channels are then in a special state which lasts for a certain period
513 of time. In this particular state, the channels cannot cease to
514
515 exist. If all the channel members leave the channel, the channel
516 becomes unavailable: the server local clients cannot join the channel
517 as long as it is empty.
518
519 Once a channel is unavailable, it will become available again either
520 because a remote user has joined the channel (most likely because the
521 network is healing), or because the delay period has expired (in
522 which case the channel ceases to exist and may be re-created).
523
524 The duration for which a channel death is delayed SHOULD be set
525 considering many factors among which are the size (user wise) of the
526 IRC network, and the usual duration of network splits. It SHOULD be
527 uniform on all servers for a given IRC network.
528
529 5.2 Safe Channels
530
531 This document introduces the notion of "safe channels". These
532 channels have a name prefixed with the character '!' and great effort
533 is made to avoid collisions in this name space. Collisions are not
534 impossible, however they are very unlikely.
535
536 5.2.1 Channel Identifier
537
538 The channel identifier is a function of the time. The current time
539 (as defined under UNIX by the number of seconds elapsed since
540 00:00:00 GMT, January 1, 1970) is converted in a string of five (5)
541 characters using the following base:
542 "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890" (each character has a decimal
543 value starting from 0 for 'A' to 35 for '0').
544
545 The channel identifier therefore has a periodicity of 36^5 seconds
546 (about 700 days).
547
548 5.2.2 Channel Delay
549
550 These channels MUST be subject to the "channel delay" mechanism
551 described in section 5.1 (Channel Delay). However, the mechanism is
552 slightly adapted to fit better.
553
554 Servers MUST keep track of all such channels which lose members as
555 the result of a network split, no matter whether the user is a
556 "channel operator" or not.
557
558 However, these channels do NOT ever become unavailable, it is always
559 possible to join them even when they are empty.
560
561 5.2.3 Abuse Window
562
563 Because the periodicity is so long, attacks on a particular channel
564 (name) may only occur once in a very long while. However, with luck
565 and patience, it is still possible for a user to cause a channel
566 collision. In order to avoid this, servers MUST "look in the future"
567 and keep a list of channel names which identifier is about to be used
568 (in the coming few days for example). Such list should remain small,
569 not be a burden for servers to maintain and be used to avoid channel
570 collisions by preventing the re-creation of such channel for a longer
571 period of time than channel delay does.
572
573 Eventually a server MAY choose to extend this procedure to forbid
574 creation of channels with the same shortname only (then ignoring the
575 channel identifier).
576
577 5.2.4 Preserving Sanity In The Name Space
578
579 The combination of the mechanisms described in sections 5.2.2 and
580 5.2.3 makes it quite difficult for a user to create a channel
581 collision. However, another type of abuse consists of creating many
582 channels having the same shortname, but different identifiers. To
583 prevent this from happening, servers MUST forbid the creation of a
584 new channel which has the same shortname of a channel currently
585 existing.
586
587 5.2.5 Server Reop Mechanism
588
589 When a channel has been opless for longer than the "reop delay"
590 period and has the channel flag 'r' set (See Section 4.2.7 (Server
591 Reop Flag)), IRC servers are responsible for giving the channel
592 operator status randomly to some of the members.
593
594 The exact logic used for this mechanism by the current implementation
595 is described below. Servers MAY use a different logic, but that it
596 is strongly RECOMMENDED that all servers use the same logic on a
597 particular IRC network to maintain coherence as well as fairness.
598 For the same reason, the "reop delay" SHOULD be uniform on all
599 servers for a given IRC network. As for the "channel delay", the
600 value of the "reop delay" SHOULD be set considering many factors
601 among which are the size (user wise) of the IRC network, and the
602 usual duration of network splits.
603
604 a) the reop mechanism is triggered after a random time following the
605 expiration of the "reop delay". This should limit the eventuality
606 of the mechanism being triggered at the same time (for the same
607 channel) on two separate servers.
608
609 b) If the channel is small (five (5) users or less), and the "channel
610 delay" for this channel has expired,
611 Then reop all channel members if at least one member is local to
612 the server.
613
614 c) If the channel is small (five (5) users or less), and the "channel
615 delay" for this channel has expired, and the "reop delay" has
616 expired for longer than its value,
617 Then reop all channel members.
618
619 d) For other cases, reop at most one member on the channel, based on
620 some method build into the server. If you don't reop a member, the
621 method should be such that another server will probably op
622 someone. The method SHOULD be the same over the whole network. A
623 good heuristic could be just random reop.
624 (The current implementation actually tries to choose a member
625 local to the server who has not been idle for too long, eventually
626 postponing action, therefore letting other servers have a chance
627 to find a "not too idle" member. This is over complicated due to
628 the fact that servers only know the "idle" time of their local
629 users)
630
631 6. Current problems
632
633 There are a number of recognized problems with the way IRC channels
634 are managed. Some of these can be directly attributed to the rules
635 defined in this document, while others are the result of the
636 underlying "IRC Server Protocol" [IRC-SERVER]. Although derived from
637 RFC 1459 [IRC], this document introduces several novelties in an
638 attempt to solve some of the known problems.
639
640 6.1 Labels
641
642 This document defines one of the many labels used by the IRC
643 protocol. Although there are several distinct namespaces (based on
644 the channel name prefix), duplicates inside each of these are not
645 allowed. Currently, it is possible for users on different servers to
646 pick the label which may result in collisions (with the exception of
647 channels known to only one server where they can be averted).
648
649 6.1.1 Channel Delay
650
651 The channel delay mechanism described in section 5.1 (Tracking
652 Recently Used Channels) and used for channels prefixed with the
653 character '#' is a simple attempt at preventing collisions from
654 happening. Experience has shown that, under normal circumstances, it
655
656 is very efficient; however, it obviously has severe limitations
657 keeping it from being an adequate solution to the problem discussed
658 here.
659
660 6.1.2 Safe Channels
661
662 "Safe channels" described in section 3.2 (Safe Channels) are a better
663 way to prevent collisions from happening as it prevents users from
664 having total control over the label they choose. The obvious
665 drawback for such labels is that they are not user friendly.
666 However, it is fairly trivial for a client program to improve on
667 this.
668
669 6.2 Mode Propagation Delays
670
671 Because of network delays induced by the network, and because each
672 server on the path is REQUIRED to check the validity of mode changes
673 (e.g., user exists and has the right privileges), it is not unusual
674 for a MODE message to only affect part of the network, often creating
675 a discrepancy between servers on the current state of a channel.
676
677 While this may seem easy to fix (by having only the original server
678 check the validity of mode changes), it was decided not to do so for
679 various reasons. One concern is that servers cannot trust each
680 other, and that a misbehaving servers can easily be detected. This
681 way of doing so also stops wave effects on channels which are out of
682 synch when mode changes are issued from different directions.
683
684 6.3 Collisions And Channel Modes
685
686 The "Internet Relay Chat: Server Protocol" document [IRC-SERVER]
687 describes how channel data is exchanged when two servers connect to
688 each other. Channel collisions (either legitimate or not) are
689 treated as inclusive events, meaning that the resulting channel has
690 for members all the users who are members of the channel on either
691 server prior to the connection.
692
693 Similarly, each server sends the channel modes to the other one.
694 Therefore, each server also receives these channel modes. There are
695 three types of modes for a given channel: flags, masks, and data.
696 The first two types are easy to deal with as they are either set or
697 unset. If such a mode is set on one server, it MUST be set on the
698 other server as a result of the connection.
699
700 As topics are not sent as part of this exchange, they are not a
701 problem. However, channel modes 'l' and 'k' are exchanged, and if
702 they are set on both servers prior to the connection, there is no
703 mechanism to decide which of the two values takes precedence. It is
704 left up to the users to fix the resulting discrepancy.
705
706 6.4 Resource Exhaustion
707
708 The mode based on masks defined in section 4.3 make the IRC servers
709 (and network) vulnerable to a simple abuse of the system: a single
710 channel operator can set as many different masks as possible on a
711 particular channel. This can easily cause the server to waste
712 memory, as well as network bandwidth (since the info is propagated to
713 other servers). For this reason it is RECOMMENDED that a limit be
714 put on the number of such masks per channels as mentioned in section
715 4.3.
716
717 Moreover, more complex mechanisms MAY be used to avoid having
718 redundant masks set for the same channel.
719
720 7. Security Considerations
721
722 7.1 Access Control
723
724 One of the main ways to control access to a channel is to use masks
725 which are based on the username and hostname of the user connections.
726 This mechanism can only be efficient and safe if the IRC servers have
727 an accurate way of authenticating user connections, and if users
728 cannot easily get around it. While it is in theory possible to
729 implement such a strict authentication mechanism, most IRC networks
730 (especially public networks) do not have anything like this in place
731 and provide little guaranty about the accuracy of the username and
732 hostname for a particular client connection.
733
734 Another way to control access is to use a channel key, but since this
735 key is sent in plaintext, it is vulnerable to traditional man in the
736 middle attacks.
737
738 7.2 Channel Privacy
739
740 Because channel collisions are treated as inclusive events (See
741 Section 6.3), it is possible for users to join a channel overriding
742 its access control settings. This method has long been used by
743 individuals to "take over" channels by "illegitimately" gaining
744 channel operator status on the channel. The same method can be used
745 to find out the exact list of members of a channel, as well as to
746 eventually receive some of the messages sent to the channel.
747
748 7.3 Anonymity
749
750 The anonymous channel flag (See Section 4.2.1) can be used to render
751 all users on such channel "anonymous" by presenting all messages to
752 the channel as originating from a pseudo user which nickname is
753 "anonymous". This is done at the client-server level, and no
754 anonymity is provided at the server-server level.
755
756 It should be obvious to readers, that the level of anonymity offered
757 is quite poor and insecure, and that clients SHOULD display strong
758 warnings for users joining such channels.
759
760 8. Current support and availability
761
762 Mailing lists for IRC related discussion:
763 General discussion: ircd-users@irc.org
764 Protocol development: ircd-dev@irc.org
765
766 Software implementations:
767 ftp://ftp.irc.org/irc/server
768 ftp://ftp.funet.fi/pub/unix/irc
769 ftp://coombs.anu.edu.au/pub/irc
770
771 Newsgroup: alt.irc
772
773 9. Acknowledgements
774
775 Parts of this document were copied from the RFC 1459 [IRC] which
776 first formally documented the IRC Protocol. It has also benefited
777 from many rounds of review and comments. In particular, the
778 following people have made significant contributions to this
779 document:
780
781 Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
782 Ruokonen, Magnus Tjernstrom, Stefan Zehl.
783
784 10. References
785
786 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
787 Requirement Levels", BCP 14, RFC 2119, March 1997.
788
789 [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
790 Protocol", RFC 1459, May 1993.
791
792 [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
793 April 2000.
794
795 [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
796 2812, April 2000.
797
798 [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
799 2813, April 2000.
800
801 11. Author's Address
802
803 Christophe Kalt
804 99 Teaneck Rd, Apt #117
805 Ridgefield Park, NJ 07660
806 USA
807
808 EMail: kalt@stealth.net
809
810 12. Full Copyright Statement
811
812 Copyright (C) The Internet Society (2000). All Rights Reserved.
813
814 This document and translations of it may be copied and furnished to
815 others, and derivative works that comment on or otherwise explain it
816 or assist in its implementation may be prepared, copied, published
817 and distributed, in whole or in part, without restriction of any
818 kind, provided that the above copyright notice and this paragraph are
819 included on all such copies and derivative works. However, this
820 document itself may not be modified in any way, such as by removing
821 the copyright notice or references to the Internet Society or other
822 Internet organizations, except as needed for the purpose of
823 developing Internet standards in which case the procedures for
824 copyrights defined in the Internet Standards process must be
825 followed, or as required to translate it into languages other than
826 English.
827
828 The limited permissions granted above are perpetual and will not be
829 revoked by the Internet Society or its successors or assigns.
830
831 This document and the information contained herein is provided on an
832 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
833 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
834 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
835 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
836 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
837
838 Acknowledgement
839
840 Funding for the RFC Editor function is currently provided by the
841 Internet Society.