/* * Piotr `Beeth' Kucharski * uniqueID.txt, ver 0.4 * ctime: Thu Aug 06 16:16:51 MET 1998 * mtime: Wed Jul 22 19:12:26 MET 2003 */ Nowodays we have a large number of nick collision KILLs. These are abused by kids enjoying destruction, who in their goal to take channels over for fun do not hesitate to break network using depletable smurf attacks, nukes and other evil toys. As protocol now is vulnerable to such attacks, there should be ongoing effort to change it to protect innocents. The most important thing in new protocol should be preventing abusive nick collisions. I thought about it a while and shared it with other opers, who provided substantial criticism and now I think I am ready to present main ideas about it. To make nick collisions impossible, servers should identify clients not by nicks, but by uniqueIDs, which would be guaranteed to be globally (among all servers) unique. How to accomplish this task? My idea is, that each server will have its own (also globally unique) server ID (sID) and it will assign unique (server-wide) client ID (cID) to clients connecting to it. Unique ID would be then combination of sID and cID. Alphabet of sID and cID is 36-base, [A-Z0-9], case insensitive. This allows us to have, with a restriction of first char of sID being a digit, a sID range from 0AAA to 9999 (theoretically allowing 466560 servers on the network), each having clients with cID range from AAAAA to 99999 (theoretically allowing 60466176 clients on each server). For easy maintenance, sID would have to be distributed among the network admins. Small networks would not probably care, but IRCnet will have pools of sIDs, one pool for each country. Such a pool would be constructed from ISO-3166 list of 3-digit country codes (f.e. Poland is 616), leaving one char for country coord to assign to servers. That makes the restriction of 36 servers per country, but if any country ever needs more, it should not be a problem to assign them another 3-digit pool (however, this time without ISO list). Such a design allows very easy maintenance of the network. The next important issue: a method of dealing with nick collision. Splits happen and we can do almost nothing about it. But how servers deal with net joins can be modified. Just to clarify the matter: when net joins and servers from both sides introduce the same nick, KILL is being issued and propagated. That is what we call nick collision. But it doesn't have to be that way. If each client would be distinguished by globally unique ID, servers could force clients to change their nicks or even change that nick for themselves. But, some may ask, to what nick? How to avoid another nick collision? Here comes uniqueID. Imagine, that instead of KILLing nick in case of collision, server changes client's nick to client's uniqueID. As this ID is globally unique, no client will have such nick. "Anyone can change their nick to that uniqueID number!" one might doubt. But that's not true. Those unique IDs are built from sID and cID and sID always begins with digit (yes, that's why I've chosen that range). If you check RFC, first char of nick must not be a digit. Noone can take such a nick himself. So if server changes someone's nick to his uniqueID, this uniqueID will be safe from further collisions. Of course he can change his nick to whatever he wants. Another change would be with server to server communication. Instead of using 'nick' as a target (or source) of command, they would use uniqueIDs. We could guarantee this way, that MODEs and PRIVMSGs always reach the one, who it was meant for. Note, that old versions of commands must also be understood by new protocol. Here's hypothetical transmission between two old servers, when they merge: PASS xxx 0209040000 AaEFHiIKMpRtuZ SERVER some.ser.ver 1 :free text NICK Wiz 1 ~user host.some.where 1 +i :ircname comment NICK Kilroy 1 ~blah ppp.host.why.not 1 +i :another cool comment :Wiz JOIN :#foo^Go :Kilroy JOIN :#bar :Wiz NICK :Angel :Angel PRIVMSG Kilroy :hello :Angel MODE Angel :+i :Kilroy JOIN :#foo :Angel MODE #foo +o Kilroy :Kilroy QUIT :Ping timeout And the same using new protocol: PASS xxx 0211000100 AaEFHiIKMpRtuZ SERVER some.ser.ver 1 616E :free text UNICK WiZ 616EAAAAA ~user host.some.where 10.0.0.1 +i :ircname comment UNICK Kilroy 616EAAAAB ~blah ppp.host.why.not 192.168.0.1 +i :another cool comment :616EAAAAA NJOIN :@#foo :616EAAAAB JOIN :#bar :616EAAAAA NICK :Angel :616EAAAAA PRIVMSG 616EAAAAB :hello :616EAAAAA MODE 616EAAAAA :+i :616EAAAAB JOIN :#foo :616EAAAAA MODE #foo +o 616EAAAAB :616EAAAAB QUIT :Ping timeout Users do not notice the difference, as it is only server-to-server protocol, and all users see is... as it was before. What about mixed net? Unfortunately, old rules apply, along with collisions. Hence the transition period should be as short as possible. What happens, when there are two same nicks introduced? Let's have a look. Old version first: PASS ... SERVER ... NICK Wiz ... (here we see another Wiz) KILL Wiz (some.server <- another.server) New version: PASS ... SERVER ... UNICK WiZ 616EAAAAA ... (here we see another WiZ) :WiZ NICK :616EAAAAA (change nick instead of kill) So server instead of killing client, simply changes his nick. Yes, server changes client's nick. It seems easier and more stable than forcing client to change their nick, as client might not be present at the time to change nick. Remember, that no PRIVMSG, no MODE change is lost, as every server to server command uses UID as identifiers, not nicks. As I assumed server changes client's nick to their uniqueIDs, uniqueIDs cannot be longer than 9 chars and must start with digit, but you have figured that out already, haven't you? :-) END