--- irc3-19990929.txt Wed Sep 29 22:57:55 1999 +++ irc3-19991002.txt Sat Oct 2 08:08:34 1999 @@ -1,5 +1,5 @@ Network Working Group A. Church -Request For Comments: nnnn September, 1999 +Request For Comments: nnnn October, 1999 Obsoletes: 1459 Category: Experimental @@ -57,6 +57,7 @@ 2.2.2 Server messages 2.2.3 Replies 2.3 Summary of message flag bits + 2.4 Time values 3. Message details 3.1 Connection registration and cancellation 3.1.1 Password message @@ -92,7 +93,7 @@ 3.4.5 Operator message 3.4.6 Kill message 3.4.7 Server ban message - 3.4.7 Network ban message + 3.4.8 Network ban message 3.5 Server control messages 3.5.1 Connect message 3.5.2 Disconnect message @@ -140,6 +141,7 @@ 6.1 IP spoofing 6.2 DNS spoofing 6.3 Network sniffing + 6.4 Time overflow 7. Author's address 8. References and notes 9. Copyright notice @@ -974,15 +976,13 @@ indicates when the original message was sent. Servers MUST include a timestamp for the user registration (section 3.1.2) and nickname change (section 3.4.1) messages. If a timestamp is included, bit 8 - of the flag parameter MUST be set. The timestamp value is the number - of seconds since 1 January 1970, 00:00 UTC (Universal Coordinated - Time, or Greenwich Mean Time); this is the same as the Unix time(2) - value. + of the flag parameter MUST be set. See section 2.4 for information + on timestamps, including the reasons for using a 64-bit integer. In augmented BNF, the server message format is as follows: - server-message = flag length seqnum hop-list code source dest [time] - * + server-message = flag length seqnum hop-list code source dest + [timestamp] * seqnum = longint hop-list = hop-count *32767 hop-count = shortint ;number of servers in hop-list @@ -990,7 +990,7 @@ serverid = shortint clientid = shortint dest = [network] serverid clientid - time = longint ;seconds since 1970/1/1 0:00 UTC + timestamp = <64-bit integer> 2.2.3 Replies @@ -1031,6 +1031,27 @@ 1-0: Identify the destination of a message with destination client ID equal to zero; see section 2.2.2. +2.4 Timestamps + + A number of messages require timestamps to be sent. All servers on + a network MUST assign the same meaning to this time value; servers + SHOULD use the current Unix standard (seconds since 1 January 1970 + 00:00 GMT), to reduce difficulties for clients in determining what + timestamp system is in use. + + Since servers that use the time system described above will run into + problems beginning in January 2038 if a 32-bit signed integer is + used to store the time, and 32 bits is a considerable restriction on + the range of times representable in many other conceivable time + systems (such as systems using milliseconds as the base unit), all + timestamps, when sent in binary format, MUST be sent using 64 bits. + + Clients and servers MUST be prepared to properly handle any + timestamp value, including values outside the range of a 32-bit + integer. Additionally, clients which process decimal time values + (particularly in response to query messages; see section 3.6) MUST + be prepared to handle values outside the range of a 32-bit integer. + 3. MESSAGE DETAILS @@ -1038,7 +1059,8 @@ defined for this protocol. Unless otherwise noted, all of the messages described below MUST be implemented by all servers. Note that messages are also called "commands", particularly when referring - to the act of a client sending a message to a server. + to the act of a client sending a message to a server to request a + certain action on the part of the server. Parameters are listed below in the following format: tag (type) where "tag" is a text string describing the parameter and "type" is @@ -1137,7 +1159,7 @@ Code: 0x0001 Parameters: version-id (shortint), nickname (string), username (user-string), real-name (string) - Server-only parameters: time (longint) + Server-only parameters: time (timestamp) longint = <32-bit value> user-string = * @@ -1167,10 +1189,6 @@ The time parameter is added to the message by the server to which the client connected before the message is broadcast to other servers. - All servers MUST assign the same meaning to this time value; servers - SHOULD use the current Unix standard (seconds since 1 January 1970 - 0:00 GMT), to reduce difficulties for clients in determining what - timestamp system is in use. If the nickname given by the client is already in use, the server MUST return ERR_NICKNAME_IN_USE and ignore the message. @@ -2587,7 +2605,7 @@ Parameters: nickname (string), [target-server (string)] nickname (string), userhost (string), name (string), servername (string), - serverdesc (string), signon (time), + serverdesc (string), signon (timestamp), idle (longint), status (bits-16), [away (string)] @@ -2632,7 +2650,7 @@ Parameters: nickname, [target-server (string)] nickname (string), userhost (string), name (string), servername (string), - signoff (time) + signoff (timestamp) Requests information on previous users of a nickname. One reply is returned for each user, starting from the most recent. The number @@ -2860,8 +2878,6 @@ * The format of remote addresses in statistics information is implementation- and server-dependent, but addresses MUST NOT contain the comma character (ASCII 0x2C). - * Absolute time values MUST be given as the number of seconds since - 1 January 1970, 00:00 UTC. * All numeric values MUST be represented as decimal values using the characters "0" through "9" (ASCII 0x30 through 0x39), except where otherwise specified; hexadecimal values MUST be represented using @@ -2877,8 +2893,8 @@ wildcards). * Nickname to which the ban applies (possibly including wildcards). - * Absolute time at which the ban expires, or "0" if the - ban does not expire. + * Timestamp at which the ban expires, or "0" if the ban + does not expire. 0x63: Server connection information Requests a list of what servers the server will attempt to @@ -2924,12 +2940,13 @@ * Absolute time at which the connection was established. 0x6D: Message statistics - Requests information on message use, including: + Requests usage information for each message code supported by + the server, including: * Message code, represented as a 4-digit hexadecimal number. * Number of times the message has been received. * Total number of octets included in all received instances of the message. - Servers MAY omit messages which have never been received. + Servers MAY omit message codes which have never been received. 0x6F: Operator restrictions Requests information on restrictions on clients becoming IRC @@ -2993,11 +3010,10 @@ other characters to indicate special types of connections, and MAY use the space character. - The time (in seconds since 1 January 1970 00:00 UTC) when the - connection was acknowledged by the server. + The timestamp when the connection was established. - The time (in seconds since 1 January 1970 00:00 UTC) when data was - most recently received from the remote end of the connection. + The timestamp when data was most recently received from the remote + end of the connection. The number of octets of data which have been scheduled to be sent to the remote host but have not yet been passed to the transport @@ -3066,9 +3082,8 @@ Requests the server's current time. The server MUST send a RPL_TIME reply with a descriptive string containing only the server's idea of - the current time expressed as the number of seconds since 1 January - 1970, 00:00 UTC, represented in decimal using the characters "0" - through "9" (ASCII 0x30 through 0x39). + the current time expressed as a timestamp, represented in decimal + using the characters "0" through "9" (ASCII 0x30 through 0x39). Examples: See section 3.6.8. @@ -3625,7 +3640,6 @@ 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. @@ -3647,13 +3661,14 @@ 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 calculatable number), like we do + 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 - from every server to every server; would this be feasible or - eat up a huge amount of memory and CPU time? I haven't given - this option much thought yet, so I'm not sure whether it's - workable. + 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 @@ -3722,6 +3737,29 @@ For this reason, networks may wish to investigate external encryption methods, such as encrypted IP tunnels. +6.4 Timekeeping and timestamp overflows + + Section 5.3 discusses the necessity of maintaining synchronized + clocks among all servers on a network; a server with an incorrect + clock may, among other things, allow users to deliberately + disconnect other users or improperly take over control of channels. + + Furthermore, it is important that implementors be aware of the + possibility of timestamp overflows; no matter what time system is + used, there are only a finite number of instants of time + representable by a timestamp, and if that range is exceeded, + unpredictable results similar to the case of a server with an + incorrect clock will result. Therefore, implementors SHOULD take + appropriate steps to reduce the likelihood of an overflow and/or + handle the case of an overflow specially. As a concrete example, + implementors using the C language and the "time_t" type defined on + Unix (and other) systems should be aware that in many cases the + "time_t" type is a 32-bit signed integer, and will overflow in + January 2038; such implementors SHOULD explicitly use a 64-bit + integer type (or, when such a type is not available, two 32-bit + integers) rather than the predefined "time_t" type for handling + timestamps. + 7. AUTHOR'S ADDRESS @@ -3852,7 +3890,7 @@ string = string16 / string32 string16 = length16 *32767 string32 = length32 *2147483647 - time = longint ;seconds since 1970/1/1 0:00 UTC + timestamp = <64-bit integer> user-string = length * @@ -3973,7 +4011,7 @@ REQ: Bit 8 of the flag parameter MUST be set if a timestamp is included in the message. (2.2.2) REC: Servers SHOULD NOT include descriptive strings when sending - replies to other servers. + replies to other servers. (2.2.3) REQ: Every server on a network MUST use the same method for computing link weights for shortest-path determination. (1.6.1) @@ -4022,7 +4060,17 @@ REQ: If a server receives a string in a reply, it MUST pass that string along unmodified. (2.2.3) REC: Clients SHOULD display a default description if one is not sent - with the reply. + with the reply. (2.2.3) + + REQ: All servers on a network MUST assign the same meaning to the + value of a timestamp. (2.4) + REQ: Timestamps, when sent in binary format, MUST be sent using 64 + bits. (2.4) + REQ: Clients and servers MUST be prepared to properly handle any + timestamp value, including values outside the range of a 32-bit + integer. (2.4) + REQ: Clients which process decimal time values MUST be prepared to + handle values outside the range of a 32-bit integer. (2.4) C.6 Messages @@ -4380,7 +4428,7 @@ | JOIN | 0x0200,0x0280 | E | | KICK | 0x0206 | | | KILL | 0x0305 | | - | LINKS | 0x050C | | + | LINKS | 0x050C,0x058C | | | LIST | 0x0502 | | | LUSERS | 0x0506 | | | MODE | 0x0303,0x0202, | C |