All Undernet server applications must be accompanied by authorization
to run the server.This authorization must come from the NOC (Network
Operations Center) or Network Administration of the HOSTING network.
Such authorization may not be from the Domain administrative, technical,
or billing contact, as in many cases these are not the individuals
responsible for the site or the associated network. Rather, the responsible
party must be the administrative/technical contact for the AUTONOMOUS SYSTEM. Please note that a route and autonomous system object must be present in the RADB routing registry!
The NOC contact provided on the server link application will be contacted
by the Routing Committee. The contact will then have 14 days to reply to
the request for authorization. If verifyable authorization is received during
that time, the application will be processed and reviewed by the Routing
Committee. If the NOC contact fails to respond within 14 days,the application
will be automatically declined.
Form of authorization and Bandwidth Requirements
The following is an extract from the text of the NOC contact authorization request:
We would request verification from you that you approve of the
proposal for an Undernet IRC server to be run from your site
(should the application be approved by the routing committee) and
that you are aware of the potential network consequences involved
in hosting an Undernet server.
Please note that the Undernet being one of the largest IRC
Networks in the world, the servers are often targets of large
scale Distributed Denial of Service (DDoS) attacks, which can
usually last several hours or even days with peak bandwidth usage
of *multiple gigabits per second* and *tens of thousands of packets per second*.
Indeed, it is guaranteed that the server will become a target of
a DoS attack at some point. DDoS mitigation technologies should
be considered (on your network or at the upstream level) as good
steps to help prevent these attacks from harming your network and
Following are the current AVERAGE bandwidth figures for Undernet servers. (if
approved, the proposed server would be a Client-Leaf server).
Bandwidth measurements shown are taken from a two week period in October 2000, and averaged
||Number and Type of Connections
||Average Nominal Operational Bandwidth
||Average Burst/High-Traffic Bandwidth
||4 Leaf Connections ||1.042 Mbps
||2.476 Mbps |
||1 Hub Uplink 4000 Clients ||3.148 Mbps
To this end, only sites with a total aggregate transit bandwidth
greater than 100 Mbps will be considered. For the purposes of
this document, transit is defined as bandwidth which is globally
accessible. It is the globally accessible "international"
bandwidth which counts as transit, for this purpose.
If you are fully aware of the implications of such a server, and
approve of this server being potentially hosted by your site
please respond to this message withing 14 days indicating your approval.
The bandwidth consumption averages shown are based on ONLY
Undernet traffic. This does not include traffic and bandwidth
usage for the hosting site's normal business operations. This
factor should be born in mind when determining whether a site has
available resources to host an Undernet server. Generally, any
site which consumes 70% or more of their available bandwidth for
their general business operations will not be well suited to running an Undernet server.
All Undernet servers must meet certain minimum hardware standards
in order to efficiently operate on the Undernet IRC Network. The
bare minimum standards are as follows: Minimum 512MB RAM (1 GB or
higher highly recommended)
For for x86-based machines, a minumum of 600MHz is required. for
Sparc, the machine should be a Ultra-10 or better. Other
platforms should run a comparable, or better, system. The
Operating System kernel must be configured to allow a minimum of
4096 open file descriptors per process, and must support at least
4000 undernet user connections.
Server must be a DEDICATED machine to serve as an IRC server.
IRCU should be listening on (at least) port 6667.
No other services open to the Internet (as in "0.0.0.0/0") may be
run on such a machine.
Servers MUST NOT be running useless services for an IRC server like :
inetd, rpc.statd, apache, telnetd, webmin, ftpd, etc...
Any service running on the server other than ircu and sshd like
snmpd, sendmail/postfix, zebra/quagga or even syslogd must be
filtered or listening on localhost or your out of band network only.
This being said, it is also quite obvious that the SSH service
should be firewalled or listening only on your out of band
network. We recommend that you use a firewall on the machine and
even at any upstream level so that you can limit access and to a
certain extent, some attacks on the machine.
Further it is required that the server run a NTP daemon for time
synchronisation. New client servers will have one week from the
beginning of their test link to properly configure ntpd on their
server, since they will not have the proper IP addresses prior to
the approval of their application. Until they have ntpd running
and synchronized with at least one Undernet hub, they must leave
RELIABLE_CLOCK turned off. If more than one week is required, the
test link admin must contact the Routing Committee secretary, who
may, at his or her discretion, extend the time for fulfillment of
this requirement. However, the server must have ntpd properly
configured prior to the vote for full link status.
When a user connects to undernet, a DNS reverse lookup request is
made. Since these kind of lookups are quite time hungry,
optimizing their speed is necessary for any middle-sized server
(2000-8000 clients). It is recommended that the server run the
latest version of any cache-only name server
(bind8/bind9/djbdns/...) and accept requests from ONLY localhost.
The admin of the prospective server must have at least a general competence with Unix and
the running of an IRC server, to include at least a basic understanding of the server
configuration file, and use of the C compiler and associated utilities for the particular
platform in use. The Routing Committee will offer general guidance in the configuration
of the server, but will not "hand-hold" an admin on every detail.
Undernet Routing Committee
Technical Requirements Document
Undernet Routing Committee Secretary