Services implemented by people already, not in the specs:

    ({
        (string) "beep",
        (int)    5,
        (string) originator_mudname,
        (string) originator_username,
        (string) target_mudname,
        (string) target_username,
        (string) visname,
    })

This just beeps a user and writes a messages to them, or just writes a message, depending on how the MUD is set up, and if the user has settings to make it not do the actual sound part. (This was taken from Diku muds such as Alsherok and Thirteen Chronicles which are already using this. Thanks Nicholas@Thirteen Chronicles for beeping me one day to show me exactly what it sent.) (The router doesn't need to do anything special for that, by the way)

Additions done on Samson's router:
(Alsherok Forums has an Intermud-3 forum that describes this stuff.)
(Mine will also eventually do most of the same things.)
(update... he wrote about his I3 stuff here, and also released his own router too.)
(even more updated... he removed that)

    ({
        (string) "chan-adminlist",
        (int)    5,
        (string) originator_mudname, // your mud
        (string) originator_username, // your user name, or 0 if automated
        (string) target_mudname, // the router
        (string) 0,
        (string) channel_name,
    })
    ({
        (string) "chan-adminlist-reply",
        (int)    5,
        (string) originator_mudname, // the router
        (string) 0,
        (string) target_mudname, // your mud
        (string) target_username, // your user name, or 0 if automated
        (string) channel_name,
	(string *) listed_muds
    })

I have implemented this on my own router
(Description taken from Samson's I3 forum) chan-adminlist - packet to request an administrative list from the channel. If you are the host mud it will reply back with a chan-adminlist-reply packet detailing the muds which are either invited or banned. This is not a supported feature on the "official" main router, but it's been something I wanted to have available for some time.

    ({
        (string)   "router-shutdown",
        (int)      5,
        (string)   originator_mudname, // router
        (string)   0,
        (string)   target_mudname,     // connected mud name
        (string)   0,
        (int)      delay_value         // 0 for shutdown, any other value for reboot
    })

On my own router, I have it set up to do a router-shutdown with 10 seconds every time that the router gets destroyed. I haven't made a scheduled shutdown type of thing yet, so every time I update it'll just act like it's gonna be down 10 seconds. It takes about 5 seconds to finish the startup sequence, but I'm telling the muds it'll be 10 seconds anyway.
(Description taken from Samson's I3 forum) router-shutdown should be sent by the router in the event of a known shutdown. Specifying 0 for the delay value indicates a shutdown state. The router will not be back up again in a known timeframe. Properly configured clients should treat this as a complete shutdown of the network and close their connections without attempting to reconnect, or should cycle ahead to another router if they have them configured. Specifying any other delay value should be treated as a reboot condition and properly configured clients should attempt to reconnect at their chosen intervals.

Proposed I3 additions:

I3 additions which I have implimented myself:

    ({
        (string) "chan-groups-reply",
        (int)    5,
        (string) originator_mudname, // the router
	(string) 0,
        (string) target_mudname,
        (string) 0,
        (string *) groups_your_mud_is_in,
        (string *) groups_your_mud_is_not_in,
    })

This will be sent with the full list right after logging onto the router, and then updates will be sent as they happen. A MUD should have it work similar to chanlist-reply and treat this as an update instead of clearing the entire list. This doesn't use any ID's to keep track of which ones you already knew about, it simply sends the entire list on login, but you should still code your client to treat it as an update. Just in case I decide to change this later, treat it like an update so it'll be easier on you to update yours later on too.

NOTES:
Filtered channels:

The main router doesn't handle filtered channels, it treats them exactly like selective allow channels.
My router handles filtered channels.
Samson's does as well

Mud lists:

If you are trying out routers and switching between them, delete your I3 data file, because each router won't know to tell you that all the old muds you knew about are gone on this router. Some of them will look like they're online and connected even, if your client works right.
The main router sends the entire mud list in sets of 10, then one mudlist packet with yourself in it.
My router sends the updated (according to the old_mudlist_id sent in your startup-req) parts of the mud list in sets of 10, and then one packet with yourself in it.
Mine has a #define for SEND_WHOLE_MUDLIST, so I can make it act like the main router if I wanted to.
Samson's does the same as the main router, but with sets of 9.
The main router has muds expire after a while. I think it's 7 days. Samson says his is 30 days, and mine doesn't do expiring yet.

Channel lists:

If you are trying out routers and switching between them, delete your I3 data file, because each router won't know to tell you that all the old channels you knew about are gone on this router. If your MUD's I3 client works right, some of them will look like they exist when they don't exist, because the new router doesn't know which ones to tell you to forget about.
The main router sends the entire channel list when you connect.
My router sends the updated channels according to the old_chanlist_id sent in your startup-req, or else sends the whole list if I #define for SEND_WHOLE_CHANLIST... so I can make it act like the main router if I wanted to.
I turned on debugging and then reconnected to Samson's and didn't see any chanlist-reply's. I added a separate messaging thing to message me when a chanlist-reply comes in, and it apparently only displays when I don't have debugging on :P His sends it, it's just my MUD isn't writing all the debug stuff it should I guess

How to see what other muds are on a channel's allow or ban list:

On the main router, no way to know... when you update it, keep track on your own.
On Samson's router, can use the chan-adminlist described earlier
On mine, I got it to act like Samson's

Error as a result from a channel-listen on a channel you can't listen to:

The main router has an error that looks like:

({
  "error",
  5,
  "*gjs",
  0,
  "TimMUD",
  0,
  "not-allowed",
  "you are not allowed on that channel",
  ({
    "channel-listen",
    5,
    "TimMUD",
    0,
    "*gjs",
    0,
    "diku_dev",
    1
  })
})

Mine looks the same as the main router's except it says "Banned from ___" or "Not in allow list for ___". Samson's is similar and says "___ is a private channel your mud has not been invited to"
Basically, with all 3 routers, you can attempt to listen to all the channels at once, and then have an error handler to look at the error_packet and then know that the listen failed, because they all send the error_packet. NOTE: If you make your own router, make sure to keep the original packet for the error, so that muds can easily know what channel they failed to listen to.
On mine, I have chan-groups-reply support, so if you handle that, then your mud might know not to even bother trying to listen to it. On mine and Samson's, you get an error that includes the name of the channel in the error_message if you wanna read the error_message's, while on all three, you get the error_packet which includes the name of the channel. (The main router simply calls it "this channel" in the error_message, so you have to look at the error_packet, if you tried to listen to multiple ones at the same time)

User cache broadcasts:

Mine and the main router both broadcast ucache to everybody, while Samson's only sends it to muds that have ucache in their service list. (Which means if you don't handle ucache, you won't get sent useless info, and if you broadcast a ucache, nobody is gonna send you a reply that says "error: my mud doesn't understand what you just now sent me")
If for some reason you support ucache and don't have it in your service list, go ahead and put it in your service list. Do it even if you're on my router and the main router, because people are just curious.
Remember that other muds sending a ucache-update have no way of doing a selective broadcast to only MUDs with ucache in their service list. If your mud doesn't support it, just drop the packets, don't whine because they can't control who it goes to. When sending error packets back to a mud, you might want to avoid sending errors back when you get broadcast, and only do it when they send it directly to you.

Creating and deleting channels:

The main router doesn't respond at all when you create a channel. That's a bug. It will create the channel, and tell all the other muds about it, but it won't tell your own mud about it. If you make a channel, just log off and on with I3 so that it'll tell you when you log back on.
Samson's will act right and send you (and everyone else) a chanlist update with just that channel in it.
Mine acts like Samson's

Non-standard packets in general:

Mine and the original router allow them as far as I know, except for channel messages are processed. Samson's avoids sending ucache updates to muds that don't have ucache, and I assume might do similar for the other services like locate, but I don't know. If you're writing a client, list what services you have, there's no reason not to.
If you're writing your own client, assume that you'll get packets that you don't understand. If you're writing your own router, then be aware that if you decide to analyze ALL of them instead of just looking at channel packets and blindly forwarding the others, then make sure to either watch what people are trying to do, or else forward all the packets that you don't recognize.
If you do write your own router, then keep in mind that there's already some commonly-used packets that aren't in the specs. (Look at the top of this page)
The specs say "To efficiently implement the routing, the routers will route based entirely on the originator/target fields of the packet. Knowledge of the packet types will not be required. This provides flexibility for extensions and, most likely, increased routing speed." To me, this sounds like it says that if somebody wants to send out their own types of packets, they should be allowed to, and knowledge of the packet type isn't even required by the router. If somebody wanted to use encrypted messages, and have their packet be called "secret", doesn't sound like the router should mind :P If you're going to do broadcasts though, then let people know about it. I'd like to add info about packets onto this page for other coders, and people might even help you out. (Get sick of seeing errors from other muds when you do some new packet you thought up? Let me or Samson know to only send it to people who support it!)

Routers:

The main router is at 198.144.203.194 (us-1.i3.intermud.org) port 9000 with the name "*gjs"
Samson's router is at 66.116.74.116 (i3.arthmoor.com) port 9900 with the name "*arthmoor"
My router isn't on the internet right now, just on my LAN.
None of the 3 routers support any of the router-to-router stuff, so they're all just on their own. There have been other router(s) written, but none are running that I know of. OuterSpace's Intermud Protocols page mentions GoT Intermud which isn't running nor is it's code available anywhere I know of.

Code for my router

Nice things I haven't planned too much on:
Some way to add comments onto a channel (url for rules, for example) Policies, url, etc

Packets for an out of band service that emulates in-band service, and uses a pre-determined key similar to how auth works. This wouldn't be for channels and such, but would only work on services that the router would normally send directly to one target mud, such as tells and emoteto's. This could then be used to send tells to a target mud when the router is down.
Unlike auth, it would use 2 or 3 numbers instead of one, and would be valid longer than 10 minutes, I'm thinking 2 weeks maybe, since normally you won't expect the router to be down that long. Your mud will pick the numbers before the mud anticipates that they might be needed, and then through the router it will tell my mud what numbers you plan to use to talk to me, and thus there will constantly be a key which I can use to connect to your mud. Or else, your mud could directly connect to me on it's own, and tell me your new key. This way, my mud can connect on the OOB port and send you tells even if the router suddenly went down without warning.
There could be a mapping in the extra_info field that tells what services that your mud allows OOB with (which ideally should be everything except for channels and locates and ucache since they are meant for broadcasts).

An extra_info field called something like "router_info" to tell the router if there's anything special you'd like for your mud. It could have things like "enforce-password" which would be used on a MUD that has other users on the same machine. Currently, if you log in from the same IP, it allows you to log onto the router without the password, but since alot of people are on mud hosts with multiple muds on the same machine, this would be very good.

Also, was thinking it'd be cool to have the opposite of what I mentioned earlier... A packet that goes in-band and emulates out-of-band services. This could be useful for muds that have a limited number of listening ports available. If you were to have the mud running the router log on to the router, then it could even be possible to update the code for the router from an admin mud. I could set up a mud on my LAN, then tell the router that my LAN mud is in charge... could run the whole router without even needing to telnet onto it. I could even run the router with a single listen port, in that case. Could log onto my own mud and then just upload files via an in-band file service thing to the router, and restart the router. Right now I'm content with having a router that is part of a mud and I have to telnet onto the mud to control it, but it'd be nice to have it be remotely controllable.

A packet that tells another mud to connect to you. That way, if they can't listen on a OOB port but you can, then you can still do OOB with them.

Packets for remote administration of the router. (Banning IP's, etc.)

Support for router-to-router communication! There's not enough in the specifications to do this yourself though, so this'll take some brainstorming to do right.