IRC.org / IRC 2.9 & 2.10

As of the the version 2.9.1 of the IRC server, a client can see all the KILLs occuring on the network by joining the &kills channel. There are various reasons which can trigger a KILL, and the notice sent is the only way to find it.

This document assumes that you already have knowledge of the IRC protocol and that you understand it.

General notice format

:local.server.name NOTICE &KILLS :Received KILL message for <target>. From <source> Path: <kill path> (<description>)

Field short description:

target: Which nickname is being killed.
source: Who issued the kill (IRC operator nickname, or server name).
path: Where the kill comes from.
Example: ircd.stealth.net!*.fi[unknown@ircd.funet.fi]!*.hu[unknown@irc.bme.hu]!irc.bme.hu
In this example, we can follow the path took by the KILL to reach us:
1. the kill was issued on irc.bme.hu.
2. It was then received on the next server from *.hu (unknown@irc.bme.hu identifies the *.hu connection as network link with the host irc.bme.hu which didn't reply to the ident lookup).
3. The next server to received the kill got it from *.fi (unknown@ircd.funet.fi identifies the *.fi connection as network link with the host ircd.funet.fi which didn't reply to the ident lookup).
4. Finally, the server who sent the notice to &KILLS had received it from ircd.stealth.net
description:
- IRC Operator kill: reason given by the operator when s/he issued the kill.
- Server kill: see below.

Understanding server kills

You will find all description formats below with a short explanation. Unless otherwise noted, the point of view of the following is the server issuing the kill.

nickname[server1] != server2
This is commonly known as a Fake Prefix error condition. nickname has been introduced by server1 but server2 is sending data claiming it comes from nickname (which is impossible since nickname is behind server1 and not behind server2).
Both server1 and server2 are local connections.
server1 <- server2
server2 is a new server being introduced on the network, but its name is currently being used by another client as a nickname (this client was introduced by server1). This is a Server/nick collision.
server1 != server2[server2 hostname]
The nickname being killed is being introduced by server2 and is supposed to be a client using server1. It is impossible because server1 is not behind server2.
server <- nickname!user@hostname

server is propagating an illegal nickname change for nickname!user@hostname.
server1 <- local connection name
This is a Nick/Server collision, the local connection is a server which introduced a nickname using the same name as a server behind server1.
(user1@host1)server1 <- (user2@host2)server2
This is a ``classic'' nickname collision. The nickname being killed was known from server1 but server2 introduced it again. user2@host2 identifies the new user which was being introduced, and user1@host1 the user which got collided.
server1 <- server2(nick2)
server1(nick1) <- server2
This is a ``nickname change'' collision. Both nick1 and nick2 are registered clients. The server issuing the kill does so because nick2 tried to change its name to nick1 (which is already taken).
In theory this shouldn't happen. However, large networks are commonly affected by ``lag'' (delays) which makes this kind of situation possible.

Christophe Kalt <kalt@stealth.net>

$Id: kills.html,v 1.5 2000/05/03 16:13:03 kalt Exp $