This document obsoletes any older versions of all EFnet server applications. Below are the agreed-upon guidelines for linking new servers to EFnet. If after reading these guidelines you feel that EFnet should consider linking your server, cut out the application at the bottom and respond to each of the questions. To submit it, contact an administrator of a current EFnet server to forward the application for you. What the EFnet admin body is looking 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. Uplink support is required prior to applying for an EFnet link. The contact address for an individual at the hosting entity must be given when applying to verify IRC approval and uplink support. b) The server administrators must be reasonably knowledgeable 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 hardware and adequate for the job. The machine should be reasonably modern, and at least 1GB of total RAM is recommended. 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. In general, the only services that should be running on the IRCd machine are core kernel services, SSHd, and clock synchronization such as ntpdate. Services such as inetd, ftpd, telnetd, httpd and so on should not be running on an EFnet IRC server. For clock synchronization, ntpd or ntpdate or similar must be run, the TS protocol requires that clocks be kept accurate. If running ntpd, the service should be restricted to the local system and ideally syncing to a non-public NTP server. The machine must be firewalled from outside logins and protected against common spoofing attacks. The network admins should be familiar with various Denial of Service attacks and should know how to minimize the effects of it. The nameserver that the machine should be running must use a secure current version. Information on the latest version of BIND can be found at http://www.isc.org. All vulnerabilities in your IRC server's OS should be patched and updated. Likewise, if a vulnerability arises in any of the running daemons such as SSHd or IRCd, those should be updated as soon as possible. d) Running a server requires the IRC network and community placing a lot of trust in you. People who are known not to be trustworthy or who have a history of not acting in the best interests of IRC networks or its community will typically be denied server links. e) New servers will be defined as a Leaf - 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) New servers may not be compiled in debug mode and all their operators are not to be given global /kill, gline access or remote squit/connect access during the trial period. g) These days, a large EFnet client server can utilize several mbits/s, which is a large amount of bandwidth for most small ISPs. Given that large client servers are more desirable than small 'local' servers, this will be taken into consideration when reviewing the application. New servers must be on a multi-homed network. This multi-homed network should have a minimum of 20 Gbit to at least two different ASN's. We must also be able to verify that your server is on a multi-homed network, via BGP announcements. Routing on the network on which the IRC Server resides should allow the server to fully utilize the multiple links. The server must be protected from attacks resulting from ARP hijacking. One way to accomplish this is by utilizing static arp addressing on your router. In addition to static arp addressing, an EFnet server should be on its own IP subnet and VLAN. h) EFnet IRC Servers tend to attract frequent Distributed Denial of Service (DDoS) attacks and hack attempts. DDoS attacks can reach 50Gbps and higher, with several million packets per second. Often times these attacks are also not targeted at the servers directly, but at neighboring routers or machines. These attacks can often times cripple even the most robust and diverse networks. New applicants must be aware of this, and not only be ready to deal with it, but must be versed in methods of combating and protecting your server from DDoS attacks. i) The server must have their bots/abuse policies clearly stated in the MOTD and contact information must be stated in the Admin block. The server administration should be willing to take measures to minimize clone-botting by the use of connection limits in the Class/Auth blocks and/or the use of monitoring bots (oomon, tcm, etc.) and live operators. j) All new servers must run an IRCd approved by the EFnet admin body. The current approved IRCd is: ircd-ratbox - http://www.ircd-ratbox.org/ k) Servers that intend to be 'closed' servers either by means of the Auth block, of network announcements, or by any other means must state this intent at the time the server application is submitted. Very few servers are able to justify being a 'closed' EFnet server. Servers that intend to only hold a couple of hundred clients due to Auth block limits or closed announcements are typically denied a trial or full link. l) Any server downtime or period of absence must be announced to the admins list prior to going down (if applicable). If there is an unforeseen incident that renders your server absent, notice must be sent to the admins list as soon as possible. m) Failure to comply or meet one or more of these guidelines may end with the denial or termination of your link to EFnet. n) 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 EFnet to help the new administration link their new server, an admin defined as a Mentor. If a Mentor is appointed to you, 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 45 days. During the TRIAL period the server and ALL its opers will NOT be allowed to: Participate in votes or admin-level tasks on EFnet. Be subscribed to admins@ or opers@ lists. Add spoofs for non-operators (existing operators on other EFnet servers excluded). Route/Connect servers other than relinking their own server to the network. /kill clients on remote servers. Participate in GLINE votes (i.e. staff isn't permitted to hold Global flag options). At the end of this 45 day trial period, a vote may be called by any admin to determine whether to delink your server or to extend your server's trial period. If no questions or votes are called at the end of your trial period, then you will be considered a full linked server and eligible to all rights that it includes. 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 (six) 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 authorization. ---------- CUT ---------- 1. Contact Info 1a. Server Admin Full Name: 1b. Server Admin Nick (include previous Nicks): 1c. Server Admin Phone: 1d. Server Admin Email: 1e. Relationship to server hardware and network (ie: employee, colocation, student, etc): 1f. Sysadmin Contact: 1g. Network Admin Contact: 1h. Server Name: 2. Network Info 2a. Connectivity Please list the connectivity your network has to various other uplinks and providers, and this size of the connection to them. Please also include the IP address of the IRC server, or an IP address close to it for testing purposes. Any additional relevant information may also be included: 2b. Does this server utilize static ARP addressing?: 2c. Is this server on its own IP subnet and/or VLAN?: 2d. Do you have uplink network support?: 2e. Hosting networks ASN: 2f. Please describe how (D)DoS attacks will be handled: 3. Machine Info 3a. Processor: 3b. OS and Version: 3c. RAM: 3d. Who has access to run processes on the machine: 3e. What other services are running on the machine (ftp, www, smtp, pop3, imap, etc): 3f. Describe how ICMP unreachables and redirects are filtered: 3g. Please list nameservers that will be in resolv.conf, and specify the version of BIND that each runs: 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 responsible for compiling and upgrading IRCd: 4d. Will this server be a "closed" server (via Auth block, network announcements, etc.) after the completion of the trial period?: 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: full names, common IRC nicks (including any previous nicks), e-mail addresses and a personal detailed introduction of all people who will be operators on your 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 is less than 2 weeks before the date you have stated, you will be expected to link within 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.choopa.net b) irc.colosolutions.net c) irc.du.se d) irc.efnet.pl e) irc.homelien.no f) irc.inet.tele.dk g) irc.mzima.net h) efnet.port80.se i) irc.prison.net j) irc.servercentral.net k) irc.teksavvy.ca l) irc.umich.edu m) irc.underworld.no 10. All information provided will be validated before any application will be considered. We reserve the right to reject an application for any reason.