The purpose of this web page is to provide a public face to the AustNet Routing Team. The AustNet Routing Team was formed to streamline the server link process. They work individually and as a team to ensure applications are reviewed, and properly handled. The committee is responsible for verifying new applications for correctness, for offering testlinks to qualified and needed servers, and for effecting and supervising those testlinks. Additionally, team members attempt to attract new applications, particularly from large corporate sponsors.
Routing Policies
In this document:
The word ‘IRCD‘ and the phrase ‘IRC DAEMON‘ denote the IRC Server software to be run on the server machine.
The word ‘SERVER‘ denotes the computer indicated by application to run the IRC Daemon.
The word ‘APPLICANT‘ denotes the person applying; The administrator of the server.
The words ‘MUST‘ and ‘WILL‘ denote a requirement that is absolutely mandatory.
The phrases ‘MUST NOT‘ and ‘WILL NOT‘ denote a requirement that is absolutely prohibited.
The words ‘SHOULD‘ and ‘RECOMMENDED‘ denote a specification that would assist the application.
The phrases ‘SHOULD NOT‘ and ‘NOT RECOMMENDED‘ denote a specification that would not assist the application.
Criteria required for application
The server running the IRC Daemon software must be able to run constantly; 24 hours a day, 7 days a week.
The server must be available for at least the next 2 (two) years. If the applicant is aware that the server may not remain on-line this long, please do not apply. Applications must be for the long-term, and must not be temporary.
The server must have at least:
A Family-5 or better processor (on Intel x86/IA32 machines) running at 400MHz or higher.
An Ultra-10 or better for Sun Sparc based machines.
Must be configured to allow a minimum of 2048 file descriptors open per process.
128 Megabytes of RAM minimum (or as appropriate to the operating system and the maximum number of file descriptors given above).
Other platforms should run a comparable, or better system.
The server must have UNIX or a variant as its operating system (FreeBSD, NetBSD, OpenBSD, Linux, Solaris, Digital Unix, BSDi, et cetera). Our IRCD will not run on NT. Alpha, Beta, Development or Pre-Release or similarly specified versions of the operating system must not be used.
The server specifications must be finalised prior to application. Changing specifications or applying with notes about future planned upgrades are not helpful.
The applicant must have ‘root’ access to the server, or an appropriate level of administrative access to change set up parameters of the server.
If the server and/or its connection(s) to the Internet are deemed by AustNet unable or unsuitable to cope with the load generated by IRC traffic, the application will be rejected.
The server must be connected to an internal network by way of a switching repeater (’Network Switch’), or a secured repeater (a repeater which removes packet contents for nodes not authorised to receive the data).
The server must be protected by a suitable firewall to protect it against malicious attacks. However, the firewall must not impede ICMP type 3 code 4 (Fragmentation needed and DF flag set) packets.
The server must be running all current security patches. The applicant must be able to update any software or hardware as required in the future, or be able to make appropriate arrangements for such updates quickly.
The applicant must be fully aware and have read the AustNet Charter, as well as any other rules and regulations that may be ammended from time to time.
The applicant must hold harmless all those involved in the network, including but not limited to AustNet server administrators, AustNet hub administrators, AustNet server application administrators, AustNet Services Department (ASD) staff, AustNet Development Staff and users.
Applicants, Sponsors, Operators (and any other person/organisation associated with the server) must conform and act within the bounds of local and international laws.
The server must be sponsored from a reliable Internet Service Provider (ISP) or an Application Service Provider (ASP). Co-located (hosted) servers or dedicated servers will only be accepted when:
The service has been pre-paid at least 2 years (Proof must be given of this).
The server serves a distinctly defined need to the AustNet network, beyond providing another server in the area or region.
There are only one or two other server operators besides the admin listed
The zone representative makes the determination that the server and its staff are reputable and are not applying simply to become IRC Operators (eg. to achieve a high level of status on the network).
Server applications are only considered if they could be of an advantage to the AustNet network. Average servers or servers that are not better than existing ones in the same geographic location are not an advantage.
Applicants, sponsors, server operators and/or associates who have a reputation from AustNet or other IRC networks in regards to causing trouble, abusing privileges, abusing access, abusing users, not forfilling their duties or any negative reputation to the same or similar effect will result in the server being rejected. If the reputation is of that of an operator, and not the server applicant, the applicant will be given the opportunity to remove the operator in question.
The applicant must have explicit permission from the server owner and network management (not just the owner of the account on which the IRC Daemon is intended to run) prior to application. Objections from the machine owner will automatically result in rejection.
The server must have Network Operations Center (NOC) and/or net-block approval, and/or any other approval appropriate to the applying server’s location prior to application. This will be checked by your zone representative.
The server must not be running any services, processes or daemons which are considered high-traffic, high-load or a security risk, including but not limited to:
Diagnostics and host information services, including ‘echo’, ‘discard’, ‘chargen’, ’systat’, ‘netstat’, ‘rstat’, ‘finger’, ‘nicname’ or similar services.
Remote access services including ‘telnet’, ‘rtelnet’, ‘login’ (rlogin), ‘rje’, ‘rsh’, ‘xdmcp’ or similar services. Note that ’ssh’ is acceptable as long as it is reasonably firewalled and not SSH protocol version 1 (one) which has security issues.
Data/Information access services including ‘ftp’, ‘tftp’, ‘MOX’, ‘gopher’, ’smtp’, ‘pop’ (any version) or similar services. Note that ‘http’ is acceptable as long as it is only used to redirect clients to another server, and not used for serving files itself, or acting as a proxy.
IRC ‘bots’ including ‘eggdrop’ and similar.
Redirection services including proxies (’http’, ’socks’, ‘ftp’ etc), IRC BNCs and similar services.
Database based services such as sql servers (’mysql’), ‘ldap’, and similar.
Game servers such as ‘quakeworld’, any mud (’moo’, ‘mush’, ‘mux’ et cetera), ‘egs’ and similar services.
Open ports will be checked by your zone representative.
The server must not act as a gateway, or any other redirection service.
The server must have its timezone set up to the timezone appropriate to the geographical location of the server.
During the application process, the server must not have any IRC daemons connected to any IRC networks.
The server must not run as a ‘virtual host’, such as running on a non-primary or non-default IP bound to the same ethernet address on the same machine. To do so would be not running a dedicated server.
Applications must not be from public shell/mud/ircd hosting services (or similar hosts) including but not limited to services such as ‘CyberPassport’, ‘Foonet’, ‘GhostWeb’, ‘Grid9′, ‘InterServ’, ‘IRCWeb’, ‘Lomag’, ‘Megalinks’, ‘PHIX-Net’ or ‘ShellServer’. This is to ensure that we do not lose servers if someone forgets to pay their bill, or that the machine is not a source of various malicious behaviour. This is also to ensure the server’s security.
Applicants must not provide a contact e-mail address from any form of free e-mail account including but is not limited to e-mail services provided by ‘hotmail’, ‘yahoo’, ‘altavista’ or similar services provided with free services such as ’sourceforge’, or free shell services.
Bandwidth recommendations
If you are applying from within Australia your connection to the Internet should be at least a 8Mbps (DS2-EUR or similar) multihomed connection.
If you are applying from the US or Canada your connection to the Internet should be at least a 45Mbps (T3/DS3 or similar) connection, preferably also multihomed.
If you are applying elsewhere your connection to the Internet should be at least a 2Mbps (E1 or similar) or 3Mbps (DS1c or similar) connection.
Aggregated connections amounting to the same bandwidth are not recommended.
It is recommended that the server run a DNS caching daemon, such as the latest version of BIND (set up in cache-only mode) or a similar appropriate daemon, which must be configured only to run on the local interface (localhost).
It is recommended that the server be set up to synchronise its system clock using an appropriate method such as ‘xntpd’, or ‘netdate’ in a cron job to maintain an accurate clock as appropriate. If set up as such, the synchronisation source should be reliable, for example a stratum-2 time source.
It is recommended that applications contain the least number of operators (O-lines) possible. AustNet takes into account each operator that appears on your application in great detail.
Conditions for guaranteed rejection:
Fields not filled in correctly and precisely in the application form;
We require all information to be filled out. Some fields may not appear important to you, but they are to us.
Lying about any information;
The administrators thorougly check applying servers before considering them, and they may request access to the server for confirmation.
Mass-applying (for example, applying for a link to other networks at the same time);
This usually results in immediate rejection as it wastes our time, and shows you are desparate.
Applying while connected to any other network(s);
Not only is this disloyal to the other network(s), but gives us the impression that you “network hop” or are desperate for a link.
Failure to meet any of the requirements above;
This wastes our time, and future applications may be ignored.
Too many Operators (O-lines) listed;
This shows us that either you or your operators are not willing to spend much time administering the server, or you are only applying to gain ‘IRC Operator’ status.
Invalid emails on application form;
This wastes our time. AustNet will not chase after the applicant. Instead, the application will be immediately rejected.
Rights during the application process:
AustNet reserves the right to completely discard any complaints or comments which it feels are unjustified or blantant obstructions to the continuation of the application or AustNet.
AustNet’s decision of the server application administrator is final and futher correspondance with the applicant may be halted.
AustNet reserves the right to refuse any application for any reason they see fit, without need for explaination or enquiry.
AustNet may request access to the applying server to confirm aspects of the application or to help assess suitability for a particular region. The applicant has the right to reject this (even though it may hinder the application), or request it be done with supervision of some form.
Application procedure
At any point in the following process the application may be terminated by AustNet with or without explanation.
Applications will be automatically acknowledged and a receipt sent to the applicant, machine owner (including root@server), as notification that AustNet has recieved their server application and it is pending processing. If any of the emails are invalid (except, of course, root@server), the application will be automatically rejected. It is therefore critical that all fields in the application form precisely and correctly
NOC, Net-block, network, service provider administration will be contacted by the appropriate zone representative to confirm permission. They will be informed of the bandwidth usage by the server, and the potential for malicious attacks.
The application will sit for at least 3 (three) days to allow for comments from the public. It will then be verified and thoroughly assessed by the zone representative for accuracy and honesty. Any falsifications will result in immediate rejection.
Assuming the server meets requirements, the application will then be forwarded to the entire routing committee for a vote. A majority must agree to a testlink. If the vote ends inconclusively (for example, a tied vote), the application will not be test-linked.
In the event of a test-link, the applicant will be notified, as will AustNet administration via operators@austnet.org — If the applicant chooses to continue with a test-link, the appropriate arrangements will be made (for example server configuration, latest software, et cetera).
The server will be test-linked for minimum of 30 days, during which complaints and objections will be accepted and the status of the application considered by the network as a whole, decided by a vote open to all on the AustNet vote roll at the end of the test-link period. This time should be used by both the applicant, the server sponsor (if any) and the appropriate AustNet Administration to further assess the appropriateness and suitability of the server on the network.
Note that the The total application process may take up to 2 (two) months or longer before a server is accepted as an official AustNet server.
Application statistics show that only around 3% of all applications are granted a permanent link to AustNet.
