--- irc3-20000415.txt Sat Apr 15 14:01:55 2000 +++ irc3-20010711.txt Wed Jul 11 23:49:57 2001 @@ -1,5 +1,5 @@ Network Working Group A. Church -Request For Comments: nnnn April, 2000 +Request For Comments: nnnn July, 2001 Obsoletes: 1459 Category: Experimental @@ -47,15 +47,17 @@ 1.5 Unicode 1.6 Communication 1.6.1 The shortest-path algorithm - 1.6.2 One-to-one messages - 1.6.2.1 Inter-network messages - 1.6.3 One-to-many messages + 1.6.2 Network topology changes + 1.6.3 One-to-one messages + 1.6.3.1 Inter-network messages + 1.6.4 One-to-many messages 2. The IRC specification 2.1 Strings 2.2 Messages 2.2.1 Client messages (commands) 2.2.2 Server messages 2.2.3 Replies + 2.2.4 Acknowledgements and acknowledgement requests 2.3 Summary of message flag bits 2.4 Time values 3. Message details @@ -180,35 +182,11 @@ less than six variant protocols, none of which are compatible with each other or with the original RFC 1459 [1] specification. - Hence, this document uses a number of terms to indicate which - elements of the protocol are required and which are merely suggested. - Whenever these words are used in this sense, they are capitalized. - For a more complete description of the use of these terms, see RFC - 2119 [4]. - - MUST indicates that the capability or functionality described is - an absolute requirement. An implementation that does not include - this capability does not conform to the protocol. - - SHOULD indicates that, while the capability or functionality - described is strongly recommended for inclusion in any - implementation, it is not required for compliance with the protocol. - However, any implementation designer should carefully weigh the - potential benefits and liabilities before deciding not to include - this capability or functionality. - - MAY indicates that the capability or functionality described is - truly optional. One implementation may include it, and another may - not, for any reason whatsoever. Both are compliant with the - protocol. - - SHOULD NOT is the opposite of SHOULD; implementation designers - are discouraged from including the capability or functionality - described in an implementation of the protocol, though there may - exist valid reasons to do so. - - MUST NOT is the opposite of MUST; implementations are prohibited - from including the capability or functionality described. + Hence, this document uses the terms "MUST", "SHOULD", "MAY", "SHOULD + NOT", and "MUST NOT" to indicate elements of the protocol are + required and which are merely suggested. Whenever these words are + used in this sense, they are capitalized. These terms are to be + interpreted as defined in RFC 2119 [4]. Additionally, the terms "old protocol" and "original protocol" refer to the IRC protocol described in RFC 1459 [1]. The word "iff" (as @@ -327,7 +305,7 @@ population, it is considered sufficient for the foreseeable future. Furthermore, should it be necessary to split clients among two or more networks, those clients can still communicate with each other - via inter-network messages (see section 1.6.2.1). + via inter-network messages (see section 1.6.3.1). When a client registers its connection, it gives a "nickname" by which it will be known to all other clients. This allows a @@ -487,19 +465,19 @@ 1.6.1 The shortest-path algorithm For any message from or to a directly connected client, the shortest - path is obvious; however, in order for a message between servers or + path is obvious; however, in order for a message between servers (or from a server to a remote client) to traverse the IRC network, the - servers need to know what path to send it along. Servers may use + servers need to know what path to send it along. Servers MAY use any method they choose to calculate the shortest path to other servers; a description of Dijkstra's algorithm, an algorithm for finding the shortest path from one node in a graph to all others, is presented in Appendix A. Typically, all links will be assigned equal - weight. In some circumstances it may be preferable to assign a - larger weight to a server on a slow link, or to assign weights based - on round-trip packet times; however, every server on a network MUST - use the same method for computing weights, so that all servers - compute the same shortest paths. (Otherwise, some messages may be - sent in cycles and ultimately discarded without reaching their + weight, although in some circumstances, it may be preferable to + assign a larger weight to a server on a slow link, or to assign + weights based on round-trip packet times. However, every server on a + network MUST use the same method for computing weights, so that all + servers compute the same shortest paths. (Otherwise, some messages + may be sent in cycles and ultimately discarded without reaching their destinations.) When sending a message to another server, the sender MUST append its @@ -538,7 +516,59 @@ Server 4 may send the message either to server 5 or to server 7; whichever it chooses will then forward the message to server 11. -1.6.2 One-to-one messages +1.6.2 Network topology changes + + Over the course of time, the topology of an IRC network will change. + New servers may join the network, servers may leave the network, + routing faults between servers may disrupt connections between + servers. In these situations, servers must adjust their routing + tables to compensate for the new or removed servers. + + One important effect of such network topology changes is that they + may change the route taken by messages from one server to another. + Consider, for example, the simple network shown in Figure 2: + + 1 3 + \ / + \ / + 2 + + [Figure 2: Small network with no cycles] + + In this network, messages from server 1 to server 3 are passed + through server 2. Now suppose that server 1 decides to establish a + direct connection to server 3, resulting in the network shown in + Figure 3: + + 1-----3 + \ / + \ / + 2 + + [Figure 3: Small network with a cycle] + + If server 1 then immediately sends a message over the direct + connection to server 3, that message may reach server 3 before a + message sent earlier via server 2. Alternatively, in the state shown + in Figure 3, the connection between servers 1 and 3 may be broken, + either deliberately or as the result of network problems; in this + case, any messages in transit between servers 1 and 3 at that instant + would have to be retransmitted via server 2. + + In order to ensure that all information is properly transmitted, all + servers MUST retain a copy of each message in local storage until all + recipients of the message have acknowledged it; MUST request an + acknowledgement (see section 2.2.4) from any server for which a + direct connection has been established, before sending any messages + over the connection, and for which a direct connection has been + terminated, through the remaining shortest path; and MUST retransmit + (via the new shortest route) any messages the remote server indicates + it has not received. + + *** FIXME: this is basically redoing TCP, can we do any better + without requiring a fully interconnected network? + +1.6.3 One-to-one messages There are three types of one-to-one messages: client-to-server, server-to-client, and server-to-server. Messages travel from the @@ -554,7 +584,7 @@ - Server-to-client, server-to-server: Ping messages to determine whether an inactive link is still connected. -1.6.2.1 Inter-network messages +1.6.3.1 Inter-network messages A special subset of one-to-one messages are messages sent between a server on one IRC network and a server on another IRC network. This @@ -564,7 +594,7 @@ This inter-network communication is accomplished through "border servers" which connect to other networks and identify themselves as - such. In Figure 2, below, servers A4 and B1 are border servers for + such. In Figure 4, below, servers A4 and B1 are border servers for networks A and B, respectively. Network C is currently isolated from the other networks. @@ -576,7 +606,7 @@ | / | / | A2----A4------------B1 C2----C4 - [Figure 2: Three IRC Networks with Border Servers] + [Figure 4: Three IRC Networks with Border Servers] To identify networks, a simple arbitrary string, obeying the same restrictions as for server names (see section 1.1), is used, since @@ -591,7 +621,7 @@ rest of the servers on their own networks identifying themselves as border servers (see section 3.1.5). - If server B3 in Figure 2 were now to make a connection as a remote + If server B3 in Figure 4 were now to make a connection as a remote server to server C1, then it would inform all servers on network B of the new connection; likewise, server C1 would inform all servers on network C of the connection to network B. However, note that server @@ -621,7 +651,7 @@ identification numbers and might otherwise be confused with the client on network B. -1.6.3 One-to-many messages +1.6.4 One-to-many messages There are two types of one-to-many messages: server-to-clients and server-to-servers. The former includes all messages sent to a @@ -642,7 +672,7 @@ employed similar to TCP [5] sequence numbers. See section 2.2.2 for detailed information on this component of a message. - The following examples, which use Figure 3 below, should help make + The following examples, which use Figure 5 below, should help make this more clear. Note that those examples begin from a client action which causes servers to generate this type of message. @@ -662,7 +692,7 @@ #otherchannel: B, D, F, G #secret: C, D - [Figure 3: Small IRC Network with Clients and Channels] + [Figure 5: Small IRC Network with Clients and Channels] Example: Message from client A to channel #mychannel. In this example, there are clients in the destination channel on @@ -753,7 +783,9 @@ Both message formats begin with an 8-bit start-of-message indicator, followed by a 16-bit flag parameter, followed by a 32-bit value - containing the length of the remaining data in the message in octets. + containing the length of the remaining data in the message in octets + (except for acknowledgement and acknowledgement request messages; see + section 2.2.4). The start-of-message indicator is an octet with decimal value 253. If the first octet of a supposed message does not have this value, @@ -906,8 +938,8 @@ others, all state change messages (including client connections and disconnections and channel joins and parts) are transmitted to all servers. Should this situation occur, it could be resolved by - breaking the connection between the two servers (if one existed) and - establishing a new connection. + breaking all connections between the two servers and establishing a + new connection. Note also that this algorithm assumes that all data is transmitted in sequence along all paths. Without this assumption, it is possible @@ -915,11 +947,9 @@ to be inappropriately discarded. For this reason, IRC servers MUST use a transport protocol that guarantees in-order delivery of data, such as TCP [5], or explicitly implement such a protocol on top of an - existing transport protocol. - - As described in detail in section 5.5, cyclic networks present - additional difficulties with respect to message passing. - *** FIXME: update this when section 5.5's FIXME is resolved + existing transport protocol. (Note that out-of-order message arrival + caused by establishment of a redundant connection is discussed in + section 1.6.2.) All server-to-server messages also include a "trace" of hops (servers) the message has already passed through. When a server @@ -927,7 +957,7 @@ inserts its own server ID as the sole element in the hop list. When forwarding a message from a server to another server, the forwarding server increments the length of the hop list by 1 and inserts its - server ID as the first element in the hop list. See section 1.6.3 + server ID as the first element in the hop list. See section 1.6.4 for more discussion of the hop list and server-to-server messages. The original sender of the message is always included, and both the @@ -994,14 +1024,58 @@ reply = flag length code sendername [string] +2.2.4 Acknowledgements and acknowledgement requests + + Acknowledgment messages are used to allow servers to determine which + messages have been properly received by other servers. + Acknowledgements and acknowledgement requests are sent only by + servers and only to other servers; an acknowledgement or + acknowledgement request received from a client MUST be discarded. + Servers SHOULD send an acknowledgement periodically, such as after a + certain number of messages have been received, and this period SHOULD + be configurable by the server administrator; however, at minimum, + servers MUST send an acknowledgement immediately upon receiving an + acknowledgement request. Additionally, servers SHOULD send an + acknowledgement request when the number of unacknowledged messages + exceeds a certain amount, which SHOULD be configurable by the server + administrator. + + In order to reduce the network bandwidth used by acknowledgements, a + special format is used, which does not include a length or message + code. The augmented BNF description of acknowledgements and + acknowledgement requests is: + + ack = flag serverid serverid seqnum + ; first serverid is source, + ; second is destination + ack-request = flag serverid serverid + + To differentiate these messages from others which do have a length + and message code, bit 10 of the flag parameter (indicating a reply) + is set to 1, while bit 14 (indicating a message from a server) is set + to zero, an otherwise illegal combination. Bit 11 is set to 0 for + acknowledgements and 1 for acknowledgement requests. + + The flag parameter is followed immediately by the 16-bit server ID of + the server sending the message, followed by the server ID of the + destination server. In the case of an acknowledgement, these + parameters are followed by the 32-bit sequence number of the last + message from the destination server which the source server (the + server generating the message) has received. + 2.3 Summary of message flag bits Bit 15: Reserved, set to 0. - 14: 1 if the message is from a server, else 0. + 14: 1 if the message is from a server and is not an + acknowledgement or acknowledgement request, else 0. 13: Reserved, set to 0. 12: Reserved, set to 0. - 11: 1 if the message includes a sender address field, else 0. - 10: 1 if the message is a reply, else 0. + 11: For acknowledgements and acknowledgement requests, 1 if the + message is an acknowledgement request, 0 if it is an + acknowledgement. For other messages, 1 if the message + includes a sender address field, else 0. + 10: 1 if the message is a reply, acknowledgement, or + acknowledgement request, else 0. 9: Reserved, set to 0. 8: 1 if the message includes a timestamp, else 0. 7-6: Reserved for experimental or local use; values undefined. @@ -1083,26 +1157,36 @@ some, or all of those replies to be sent. Note that this list only includes server-to-client messages which fall under the "replies" category (section 2.2.3); they do not include "command" messages - (section 2.2.1) sent back to the client. The reply code - ERR_NOT_REGISTERED is not listed; see section 3.9 for conditions - under which it is to be generated. - - Note that in general, servers are not permitted to reject messages - from other servers on permission or other grounds; for example, while - a channel join message (see section 3.3.1) sent by a client directly - connected to a server indicates a request by the client to join the - channel, and may be rejected by the server for various reasons, the - same message coming from another server indicates an event that has + (section 2.2.1) sent back to the client. Conditions under which each + reply is to be sent are in general not listed for each individual + command; if not otherwise specified, the conditions listed for the + reply in the reply's definition (section 4) are to be used. The + reply code ERR_NOT_REGISTERED is not listed; see section 3.9 for + conditions under which it is to be generated. + + Note that in general, servers MUST NOT reject messages from other + servers on permission or other grounds; for example, while a channel + join message (see section 3.3.1) sent by a client directly connected + to a server indicates a request by the client to join the channel, + and may be rejected by the server for various reasons, the same + message coming from another server indicates an event that has _already happened_, and if the server were to reject the message, its copy of the network state would become desynchronized from the rest of the servers on the network, quite likely resulting in total chaos. + Where a server is permitted to reject a message from another server, + this is explicitly stated. Servers MAY generate messages to nullify + the effect of another message--for example, generating a kick message + (section 3.3.7) to nullify the effect of a join message--if they do + not wish to permit a certain action to occur; however, this does not + nullify any requirement to pass (forward) the original message on to + other servers, where such a requirement exists. Where a description refers to "forwarding" a message received by a server and is not otherwise qualified, the term refers to the server sending, to all other servers on the network, a server-server message containing the same message code and parameters as the original message. In any message including a target, the message MUST be sent - to that target as described under section 1.5 unless otherwise noted. + to that target as described under section 1.6 unless otherwise noted. "Wildcards" in a string refer to the characters "*" (asterisk, ASCII 0x2A) and "?" (question mark, ASCII 0x3F). The former matches any @@ -1111,7 +1195,7 @@ shells, VAX/VMS, and MS-DOS, among others. Except as otherwise specified, all implementations MUST implement - the messages below with exactly the behavior listed. Message codes, + all messages below with exactly the behavior listed. Message codes, parameters, or bits in parameters listed as reserved for experimentation have undefined behavior for the purpose of the protocol definition. @@ -1328,7 +1412,8 @@ Unlike all other messages between servers except the remote server message (see section 3.1.4 below), this message, when used to register a server connection, is sent in client-server message - format. + format. This message may be rejected by the receiving server when + used to register a connection. Examples: @@ -1363,10 +1448,10 @@ outside network. Such a server will, if the connection is allowed, then be able to pass messages from its own network to the network to which it is connecting, and will receive messages from that network - destined for its own network. See section 1.6.2.1 for more + destined for its own network. See section 1.6.3.1 for more information on inter-network messages. The network-name parameter is a string containing the name of the network, as described in section - 1.6.2.1. The other parameters are as described for the normal server + 1.6.3.1. The other parameters are as described for the normal server registration message in section 3.1.3. Note that servers MUST NOT send state information to remote networks. @@ -1376,7 +1461,9 @@ invalid server or network names with ERR_INVALID_NAME. Unlike all other messages between servers except the server message, - this message is sent in client-server message format. + this message is sent in client-server message format. This message + may be rejected by the receiving server when used to register a + connection. Examples: @@ -1429,13 +1516,14 @@ may cause a server to forcibly close a client's connection. Such circumstances SHOULD be limited to a "ping timeout", as described in section 3.6.2; a kill message, as described in section 3.4.5; a - nickname collision, as described in section 5.2.1; and an operating + nickname collision, as described in section 5.2.1; an operating system error which prevents the server from reading data from the - client's connection. When a server forcibly closes a connection, it - MUST generate a quit message on the client's behalf, it MUST include - a "reason" describing why the connection was closed, and it MUST send - that quit message to the client whose connection is being closed (if - possible). + client's connection; and administrative restrictions on client + connections (such as host address, connection length, or idle time). + When a server forcibly closes a connection, it MUST generate a quit + message on the client's behalf, it MUST include a "reason" describing + why the connection was closed, and it MUST send that quit message to + the client whose connection is being closed (if possible). Any server receiving a quit message, whether from a directly-connected client or from another server, MUST send that @@ -3157,7 +3245,7 @@ The ping message is designed to test the integrity of a client or server connection. A client or server which receives a ping message - MUST reply by sending a pong message (see section 3.7.2) to the + MUST reply by sending a pong message (see section 3.7.3) to the sender as soon as possible. If the optional text parameter is included in the ping message, an identical text parameter MUST be sent with the corresponding pong message. @@ -3692,59 +3780,6 @@ not be sent to all servers, so some servers will see "gaps" in sequence numbers between messages. - As described in section 2.2.2, this algorithm will only function - properly in an environment where data is guaranteed to be received in - the same order it was sent. For this reason, servers MUST use a - reliable transport protocol which preserves order, such as TCP [5], - or explicitly implement such a protocol on top of an existing - transport protocol. - - *** FIXME: This breaks when servers create redundant connections. - Take the following simple network: - - A----B----C - - Suppose both the A<->B and B<->C links are very slow, but that a - direct connection between A and C would be much faster. If A - sends a message with ID 1 destined for server C, it will first - go to B and from there to C. But suppose that right after - sending that message, A connects to C and sends another message - to it, with ID 2. C could receive message 2 first, and when it - later receives message 1 from B, it will inappropriately discard - it. This problem could be mitigated by inserting a "delay" - before making use of any new routes, but this is only a kludge, - not a solution. - - One solution might be to have the server actually sending the - message (i.e. forwarders too, not just originators) set the - message sequence number field to its own next sequence number. - This would appear to solve the problem, but could still result in - desynchs from one message overtaking another. To resolve this - would seem to require sending a copy of the entire state over the - new connection, despite the fact that the remote server already - has that information. - - Another possibility is to have a server P, when connecting to - another server Q, to check whether Q is already in the network, - and to send Q's last seen sequence number in the server - registration message if so. Q will then send to P any messages - it has not yet seen. The sequence number processing will filter - out the duplicates. However, this breaks when many servers are - involved. Suppose a server D is connected to C in the network - above; how do we ensure that D's messages arrive in order? Does - solving this problem require sending information on _every_ - server's last seen sequence number? - - Note that we can't just rely on waiting for the last sequence - number plus one (or some other calculable number), like we do - with TCP sequence numbers, because not all messages go to all - servers. We could supposedly have individual sequence numbers - for every connection to every server, but then we still have the - problem where C sees message 2 before message 1, and C can't know - that B still has something to send it. - - Maybe this needs a completely different tack? - When a server sends a message (whether generated or forwarded) to another server, it inserts itself at the head of the server hop list in the message. Servers never forward messages to servers @@ -3781,6 +3816,13 @@ Client: 0x419FC82D834960017D2A9AB540FF1683E7 (regular commands and replies follow) + Since this procedure is only effective if the client cannot predict + the series of octets sent by the server, servers implementing this + procedure MUST ensure that the generated series of octets is truly + random, or at least as unpredictable as possible without consuming + undue processing time (to avoid resource consumption attacks caused + by a client repeatedly connecting to the server). + 6.2 DNS spoofing Another way in which malicious users may try to exploit trust systems @@ -3841,37 +3883,51 @@ names, and so on) creates the potential for attacks against clients. While servers would be unlikely to encounter problems with any particular character occurring in a name, since no processing of - names processing of names is performed, interactive clients in - particular may suffer from certain types of attacks. For example, an - an attacker may choose a nickname containing unprintable characters - or other characters which a user was unable to input; although this - protocol provides a method for clients to filter messages from other - clients (see section 3.4.3), the user would be unable to take - advantage of this feature and would be at the attacker's mercy. Some - clients also have features which rely on text representations of user - information (for example, the "@" between a user's username and - hostname), and it may be possible for attackers to choose names which - cause these features to malfunction; even without such features, - attackers can cause confusion to users who view the resulting text. - - For this reason, servers SHOULD disallow at least the following - characters, as well as any others determined by the server - administrator to pose a potential danger. - ASCII control characters (ASCII 0x00..0x1F) + names is performed, interactive clients in particular may suffer from + certain types of attacks. For example, an attacker may choose a + nickname containing unprintable characters or other characters which + a user was unable to input; although this protocol provides a method + for clients to filter messages from other clients (see section + 3.4.3), the user would be unable to take advantage of this feature + and would be at the attacker's mercy. Some clients also have + features which rely on text representations of user information (for + example, the "@" between a user's username and hostname), and it may + be possible for attackers to choose names which cause these features + to malfunction; even without such features, attackers can cause + confusion to users who view the resulting text. + + For this reason, servers SHOULD disallow any characters which may + cause problems with servers, clients, or users on the network. At + present, the following characters are considered potentially + dangerous; however, this is not intended to be a complete list, and + implementors and administrators should feel free to add or remove + characters as necessary. + + Null character (ASCII 0x00) + May cause names to be incorrectly displayed by clients or + misinterpreted by servers (0x00 is used as a string terminator + in some programming languages). + + ASCII control characters (ASCII 0x01..0x1F) May cause unintended display side effects. However, servers - MAY permit ESC (ASCII 0x1B) or other characters when those - characters are in common use; for example, the Japanese JIS - character (ISO-2022-JP) set uses the ESC character, and many - IRC clients use control characters for bold, underline, or - other display effects. + MAY permit certain characters when those characters are in + common use; for example, many IRC clients use control + characters for bold, underline, or other display effects. + + " " (ASCII 0x20) + May be misinterpreted by clients as a parameter separator. + "!" (ASCII 0x21) In nicknames, may cause old-protocol clients to consider the "!" as a nickname-username separator. + "#" (ASCII 0x23), "&" (ASCII 0x26) At the beginning of nicknames and server names, may cause clients to misinterpret the name as a channel name. + "*" (ASCII 0x2A), "?" (ASCII 0x3F) May be interpreted as wildcards when entered by a user. + "@" (ASCII 0x40) In nicknames and server names, may cause unintended meaning when a user attempts to send a message to the name (for @@ -3879,6 +3935,10 @@ In usernames, may cause confusion when combined with the hostname. + 0xA0 + On some systems, this is displayed as a space (ASCII 0x20) and + may cause confusion. + 7. AUTHOR'S ADDRESS @@ -3919,7 +3979,7 @@ [8] http://www.undernet.org/documents/ctcpinfo.txt - [9] http://achurch.org/services/ + [9] http://www.ircservices.za.net/ [10] Mills, David L., "Network Time Protocol (Version 3)", RFC 1305, March, 1992. @@ -3927,7 +3987,7 @@ 9. Copyright notice - This document is copyright (c) 2000 Andrew Church. This document may + This document is copyright (c) 2001 Andrew Church. This document may be freely distributed as-is, and may be excerpted as-is provided that the excerpt includes an attribution to the author. This document may be modified, but modified versions may not be distributed unless this @@ -3966,6 +4026,10 @@ Appendix B. Alphabetical list of message and reply elements + ack = flag serverid serverid seqnum + ; first serverid is source, + ; second is destination + ack-request = flag serverid serverid addr-octet = addr-string = length * "@" * @@ -4100,7 +4164,8 @@ *D: Keep in mind that the new protocol distinguishes between messages/notices to a channel (public) and messages/notices to a - client (private). + single client (private). Also, multiple recipients may not be + specified for a single message. *E: The SUMMON and USERS commands were deliberately left out of this protocol definition, as their functionality is considered