This information is intended for people who are about to acquire (or have acquired) a computer or other device supporting TCP/IP, and who wish to connect this to the Cambridge University Data Network on an already established ethernet. You MUST get a properly issued IP address BEFORE connecting any IP equipment to the CUDN. To do otherwise risks disrupting the network and seriously inconveniencing other users, and may lead to the Information Services Committee (ISC) placing sanctions on the offender.
In particular, it is necessary to read the conditions under which IP addresses are issued.
If at all possible, apply for an IP address well before you need it. Although simple simple cases can normally be dealt very quickly, seasonal loads such as start of term, absence of appropriate staff or any unforeseen complication can spin the process out much longer.
In the vast majority of cases you will need to apply to the local managers of the network segment to which you wish to connect, that is to to your local College or Departmental computing or network staff. However, you will still need to present the information cited below, so read on. Even where it is necessary or possible to apply directly to the UIS you would still be well advised to consult any local or departmental computing officer since there are often local factors to consider. If you are unable to find out who manages your local network please get in touch with the UIS Service Desk.
Nearly all IP-addresses issued by the UIS are IPv4 addresses. It is possible to have IPv6 addresses but this depends upon local circumstances and you will need to consult with your institution's network or computer staff. Institutions also have their own policies as to whether a global or private (CUDN only) IP address is issued.
First of all, find out who are your local computing or networking staff, and consult them. If local procedures are in force, follow them. If you can find none, or if you discover that in this case addresses are issued directly by the Computing Service, communicate by email to firstname.lastname@example.org.
When the equipment to be connected is an ordinary workstation computer or similarly common-or-garden device, with a single network interface, and when the ethernet is already in place and has other IP nodes on it, it will normally be necessary and sufficient to specify
- What you want, i.e. that a name and address are requested.
- The location at which the equipment will be connected, including sufficient detail to find the machine and identify the ethernet. Typically room number and building name are used.
- A brief (~5 word) description of the system, e.g. SPARCstation 5, DEC Alpha (VMS), Windows PC, Linux PC, MacPro.
- The identity of the department or institution and group under whose auspices this machine is operated, and, if known, the corresponding domain name.
- A suggested name for the machine, distinctive within the department or group.
- The identities and standings of the following and the means of contacting them, preferably email addresses and telephone extensions.
- The owner of the equipment: whoever it is that has ultimate responsibility for it and the say-so about it's disposal, perhaps an individual, perhaps the department/college, whoever or whatever. Generally, if you did not buy the equipment out of your own pocket then it it is probably owned by the institution.
- The individual(s) chiefly using the equipment, if any such. This is mainly applicable to personal workstations. Generic titles such as "Head Porter" may be appropriate.
- The system administrator, the person charged with technical management of the system, citing either a named individual or something like "Dept. Computer Officer" where appropriate.
- Any known complications.
Notice especially that a name is required for the machine. IP addresses are not issued without names to attach them to in the DNS (Domain Name System). The proposed name should normally be four or more characters long, begin with a letter, and contain only lower case letters and digits and "-". Some departments and colleges enforce further constraints. The appropriate departmental or group tag will be added to make a fully qualified domain name. Please note that the complete name denotes affiliation, NOT physical location.
If dealing directly with the UIS and all is in order, a formal notification of an address and name will be emailed back. This notification contains important other information. Please read it fully.
A sample application
This is a request for global IP name & address for a new Unix workstation. The details are:
Location: Room 123 in the main building of the Department of Immaterial Affairs (NB not Important Studies) on the East Cambridge site, on the only ethernet there.
Equipment: Sparcstation 100000 running Solaris 99
Dept: Important Studies, impstud.cam.ac.uk. NB not Immaterial Affairs
Owner: Dr Proud Owner, p.owner@impstud, ext 000000
User: Fred Sidekick, f.sidekick@impstud ext 111111
Sysadmin: Departmental Computer Officer, computing@impstud
Name: "erudite" if possible, please.
Complications: The machine is likely to be moved to a new location a few months hence. The initial location is in temporary loaned premises.
Complications: some advice to Institutions' Computing and Network Staff
The vast majority of applications are straight-forward and can be dealt with quickly, but difficulties can arise and can be extremely frustrating for the unfortunate few. It would be wildly impractical to explain all the possible difficulties here, but a brief tour of the commoner problems may provide useful forewarning.
The DNS allows for the possibility of alias host names, in fact of two distinct types. However there are limits on the total number of aliases that can be used by any one institution, and there may be local conventions about the style of alias name. There are also complications involving global and private names. Any such request should be dealt with by your local network or Computing staff,
Departmental or Group name tag
If the request is the first such request from a particular department, the chances are that no departmental network name suffix ("domain name") has yet been agreed, and agreeing a tag for a department is a bigger issue than might be expected. The tag has to stand for the department in ALL networking contexts, not just IP, is highly visible, has to be unique and appropriate amid around a hundred other departments and institutions in Cambridge, and has to stand for all time. It is also subject to severe technical constraints. The UIS (on behalf of the ISC) requires that the department in question formally agrees to it, with a letter signed by the Head of Department or immediate deputy. The negotiation can take some time, particularly when the department as a whole does not share the urgency or enthusiasm of the individual with the workstation. Requests for new domain names should be made to email@example.com.
Similar and only slightly less ferocious considerations apply to group tags within a department. These are normally discouraged.
You must not (unless you are given special permission which is not normally granted) allow a system to be advertised as a mail host, either by headers (such as the "From:" field) in any email, or by MX RR or by any other formal or informal means. Neither may you emit mail except via some mail server established for the purpose. CUDN routers enforce some restrictions. Although many systems come configured as mail hosts by suppliers, the configurations are almost invariably utterly unsuitable, and although they may in some degree appear to work they will in all probability be causing much trouble elsewhere which will result in much trouble visiting you.
Individual workstations requiring network mail facilities normally shelter behind some departmental or group mail server. Where such a server is already established there is usually no problem about adding another client workstation, provided of course that it has suitable software. Establishing such a server is however a complicated matter, and certain to take substantial time, both initial and ongoing.
Those without departmental mail facilities have the option of using the central "hermes" mail server, which can be accessed remotely by client programs such as Mail or Outlook running on your workstation. No special negotiation is needed, other than the acquisition of an account on hermes. If you want to use mail via your workstation and you don't understand the technical restrictions alluded to above then this is perhaps the option to investigate first.
Establishment or Connection of an ethernet
The fact that some ethernet or other piece of the CUDN runs somewhere near is no guarantee whatever that a new ethernet segment can be straight-forwardly connected. The establishment of a new ethernet segment is a major matter, usually involving substantial bills, and must be arranged first by separate application to the UIS Network Division, email firstname.lastname@example.org, phone extension 34691. It is not possible to issue IP addresses until the nature of the connection is settled, since IP addresses encode network configuration.
It sometimes appears attractive to have a local subnetwork linked to the main (CUDN-connected) ethernet via some locally administered machine acting as an IP router or gateway. A common scenario is someone noticing that a second ethernet interface in some existing server or workstation might provide a cheap network extension. Sometimes there are poorly conceived notions of privacy or performance benefit. It must be understood however that such arrangements entail cost and complexity in the main routing network, sometimes vastly outweighing any local advantage, and it should not be presumed that such an arrangement is available. Advance consultation and agreement must be sought before embarking on any such scheme, and in general good reasons for it will be required, especially where there are alternative means of achieving the underlying objectives.
This site contains the bulk of the information available from the UIS.
IP address notifications include an injunction to read and heed Conditions of issue of IP addresses
The network is evolving. Yesterday's wisdom can be today's rubbish, and it is not always (not often) possible to keep everyone abreast of things at all times. Please be tolerant of apparently conflicting advice, and be suspicious of any that is not fresh from authoritative sources.