Last Updated: 29 December 2004
Last update: 3 August 2009
This document obsoletes all older versions.
****** PLEASE NOTE ********
THE OFFICIAL SITE FOR THESE GUIDELINES IS:
http://www.eu-efnet.com/new-server-guidelines-EU
IF YOU DID NOT GET THIS FROM THE ABOVE LOCATION, PLEASE CHECK TO
MAKE SURE YOU HAVE THE MOST RECENT COPY.
There are many sites that are storing copies of this file that are
not keeping their archive up to date. The first line of this file
is changed every time a modification is made.
***************************
Below are the agreed-upon guidelines for linking new servers to the
European portion of the EFnet. If, after reading these guidelines,
you feel that the EU-EFnet routing committee should consider linking your
server, cut out the application at the bottom, respond to each
of the questions and email it to the EU-EFnet secretary
. If the site you want to link a server from
is in Canada or the US, please contact the admins for your region of
the world.
What the EU-EFnet routing board looks for when considering linking
a new server:
a) The IRC Server must be permitted and supported by the
administration of the machine and network that it
is sitting on.
b) The server administrators must be reasonably knowledgable
about IRC and UNIX. They should be willing and able
to answer most user questions that they encounter
regarding IRC. Additionally, server administrators
should be familiar with general internet topology.
At the minimum, they should know how they normally
reach each of the major backbones.
c) The machine that the server is running on must be dedicated
and adequate for the job.
It should be dedicated for security reasons. It is
never a good idea to run a public ircd on the same
machine that has multiple users. Additionally, it
should be dedicated for performance reasons. Most
of the EFnet IRC Servers run on pentiumII/III/4 running
FreeBSD. 256MB of RAM is a minimum. It is not
uncommon for an ircd to use 80+ MB of RAM not
counting buffered streams data.
In general, the only services that should be running
on the ircd box are core kernel services,
sshd, and ntpdate. It is suggested that the machine not
have inetd running.
For clock synchronization, ntpdate should be ran on a
regular basis (like perhaps at least once a day).
xntpd should be avoided for security reasons.
The machine should be firewalled from outside logins,
protected against common spoofing attacks, and the kernel
must have sufficiently random TCP initial number
generation (this isn't an issue with most of the newer
operating systems). The nameserver that the machine
uses must be the latest ISC BIND 4.9.x or 8.x. The machine
should be protected from ICMP "nuke" attacks -- ICMP
unreachables and redirects should be filtered. The
network admins should be familiar with various Denial
of service attacks such as "smurfing" and should know
how to minimize the effects of it. A detailed paper
on the subject of smurfing can be obtained at
http://www.quadrunner.com/~chuegen/smurf.txt
The machine must have a compiler (gcc suggested) and
debugger (gdb suggested) installed and accessible
by the server admin. If, for some reason or another,
the admin decides to NOT have a compiler and debugger
installed on the machine, s/he should have access
to a compiler and debugger on a similar machine.
The idea here is that the server admin should have
adequate access to be able to compile the ircd source
code when needed and, if there are problems with the
server, the ability to provide information to the
ircd coders obtained through the use of gdb or a similar
debugger.
d) Running a server requires that the rest of the IRC network
put a lot of trust in you. People who are known not to be
trustworthy or who a history of not acting in the best
interests of the IRC networks will typically be denied
server links.
e) New servers will be L:lined - meaning that they cannot link
in other servers until such a time as it is deemed that
the server and its administration are ready for such
a load and the server's network location would provide
a well-placed hub server.
f) These days, a large EFnet client server can utilize
a few hundred kbits/s, which is a large amount of bandwidth
for most small ISPs. Given that we need a few large
client servers and fewer small 'local' servers, this
should definitely be taken into consideration when
a site is deciding whether they even want an EFnet server.
EFnet IRC Servers should be on a network that is
multihomed to with a minimum of two underutilized
OC3s (or STM-1s) to at least two networks. Cooperation
from the uplink providers is an absolute necessity as
EFnet IRC Servers tend to attract frequent Denial
of Service attacks. Some of these attacks can
cripple even the most robust and diverse networks.
Routing on the network on which the IRC Server
resides should allow the server to fully utilize
the multiple links and must not sit in an
address space which would prevent the server from
failing over in the event of circuit problems.
g) The server must have their bots/abuse policies clearly
stated in the motd and contact information must be
stated in the A:lines. The server administration
should be willing to take measures to minimize
clonebotting by the use of connection limits
in the I/Y lines and/or the use of tcms
(monitor bots) or live operators.
h) All new servers must run an ircd approved by the EFnet
routing committee. The three allowed versions on
EU-EFnet are maintained by the team ("hybrid"),
the Ratbox team ("ratbox"), and Chris Behrens ("CS").
Official sites for the above versions are:
ftp://ftp.blackened.com/pub/irc/hybrid
http://www.codestud.com/ircd/
ftp://ftp.blackened.com/pub/irc/ircd-ratbox
All are generally available at ftp.blackened.com but
the +CS code may not be the most current all the time,
although an effort is made to keep it current.
i) Closed I:line servers must have an I:line contact. There
are *very* few sites on the net that can justify
their own private EFnet server. Chances are your
site is not one of them. As a result, you will be
expected to offer service to sites that are close
to you netwise. This is only necessary if you are
limiting your I:lines and intend to run a fairly
closed server. The I:line contact will be someone
who has the ability to modify the ircd.conf to add
I:lines.
j) EU servers are requested to resolve to a name with a ccTLD.
In other words, no EU server can resolve with a name in .net
.com or .org
This is for efficient routing between the US and EU, using
H/L lines.
k) Last, but not least, there must be a need for a server
in your network location.
New server linking notes:
An existing operator on another server may be appointed by
EU-EFnet to help the new administration link their new server.
The new administration must make sure this mentor has access
to the machine and account from which the ircd runs.
The TRIAL period is currently set to 60 days.
During the TRIAL period the server/staff will NOT be allowed to:
o Participate in votes or admin-level tasks on EFnet.
o Be subscribed to eu-admins@.
o Add spoofed I-lines for non-operators (operators on other EU-EFnet
servers excluded).
o route/connect servers other than relinking their own to the network.
o Exchange C/Ns with hidden HUBs.
During the first 30 days of the TRIAL the newly introduced staff
members will not be able to:
o /kill clients on remote servers.
o Participate in GLINE votes (i.e. staff isn't permitted to hold the
G O-line flag).
After 30 days have passed the administrator is free to enable them
both for the previously blocked staff members.
Existing EFnet operators who are given O-lines on the new server are
exceptions to the /kill and GLINE rules.
About a week before the TRIAL period comes to an end the secretary
will announce this and people are free to discuss anything about the
server. Unless something major surfaces surrounding the server that
would cause someone to call a vote for delink or extended TRIAL, the
server will pass into a permanent state. When the server gets
permanently linked the TRIAL limitations will be removed.
If a server is removed after its TRIAL, or is voted down during the
application phase, it will not be permitted to reapply until 6 months
have passed.
After gaining access to IRC operators related mailing lists (and/or
channels), IRC operators must not divulge any sensitive information
transpiring on those, to non operators. This particularly concerns
naming other servers or persons, without express authorisation.
These guidelines have been agreed upon by all of the EU-EFnet
hub admins. By submitting this application, you indirectly agree
to follow this set of rules, as well as any additional rule that
may have been voted upon (see
http://voting.efnet.net/pastvotes/index.shtml ). Contravening may
lead to sanctions, up to permanent server unlinking.
Once completing this application, mail it to secretary (a) irc.pp.se
---------- CUT
1. Contact Info
1a. Server Admin Name:
1b. Server Admin Nick:
1c. Server Admin Phone:
1d. Server Admin Email:
1e. Relationship to server hardware and network (ie: employee, co-lo,
customer, student account, etc):
1f. Sysadmin Contact:
1g. Network Admin Contact:
1h. Server Name:
2. Connectivity
Please describe your connectivity to your uplinks, and any
additional significant peering. Please also include an IP address of
the server or at least a machine on the same hub/switch:
3. Machine Info
3a. Processor:
3b. OS and Version:
3c. RAM:
3d. Who has access to run processes on the machine:
3e. Describe how ICMP unreachables and redirects are filtered:
3f. Please list nameservers that will be in resolv.conf,
and specify the version of BIND that each runs:
3g. What other services are running on the machine (ftp, www,
smtp, pop3, imap, etc):
3h. How will you ensure the server's IP address will not be hijacked?
4. IRCD Info
4a. IRCD type and version:
4b. Site IRCD obtained from:
4c. Person resposible for compiling and upgrading ircd:
5. Bot and Abuse Policies
Please detail your policies on Bots and Abusive users, and how you plan
to implement these policies:
6. Initial Opers
Please list: name, common irc nicks, and a personal, detailed,
introduction of the people who will have global O: lines on you server
when it goes online.
7. The Essay Question
How will EFnet benefit from your server being linked?
8. Starting date
Please state the date starting from which the server will be ready to link
to EFnet.
In the case of a notification of link acceptance less than 2 weeks before
the date you have stated, you will be expected to link 2 weeks after that
notification.
Failure to meet the linking date will result in a cancellation of the link
acceptance.
9. Traceroutes
Please include the output of traceroutes to the following sites. Note
that many EFnet servers filter ICMP and UDP packets. Run the
traceroutes as far as you can and make a note that they stopped
before reaching the destination.
a) irc.ac.za
b) irc.inet.tele.dk
c) irc.efnet.pl
d) irc.swepipe.se
e) irc.du.se
f) irc.efnet.ru
g) irc.inter.net.il
h) irc.banetele.no
i) efnet.cs.hut.fi
j) irc.homelien.no
k) irc.efnet.nl
l) efnet.xs4all.nl
m) efnet.port80.se
------ CUT