archive- Random tools & helpful resources for IRC |
git clone git://git.acid.vegas/archive.git |
Log | Files | Refs | Archive |
rfc2813.txt (56681B)
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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