How to request / change / release subnet allocation

Please note that owing to the University having to conserve remaining unallocated IPv4 subnet for new departments, the previously standard procedure of allocating bigger subnets is now severely restricted. Units will likely be expected to accommodate extra client hosts by using technologies such as NAT/PAT.

You should ensure that you are familiar with the University's IPv4 Address Allocation Policy.

As units expand or simply acquire more computers, they may find that their existing IP address ranges become full. As the University's unallocated IPv4 pool shrinks it has become necessary to become stricter with new allocations. The University continues to acquire and create new departments and we have to ensure that these departments are able to receive some addresses. Owing to the shortage we are no longer in a position to allocate subnets bigger than /24 in size.

In general, if a Unit wishes to apply for more address space they must meet the following conditions :

• All printers, switching infrastructure and other devices which do not need Internet access must be migrated to RFC1918
• The existing allocation must be 90% full
• Documentation showing expected future growth must be provided

If we are satisfied that a unit has exhausted the space in its existing IP address range, then we will agree to a move. This has the disadvantage of requiring a complete renumbering of all IP addresses. However it is far preferable in the long term to adding a second subnet to an existing backbone connection, not least because of the problems of internal routing between the two subnets.

In many cases the move will be from an existing 254-address range (for instance 163.1.2.0/255.255.255.0, with valid IP addresses in the range 163.1.2.1 to 163.1.2.254) to a 510-address range (for instance 163.1.14.0/255.255.254.0 with addresses in the range 163.1.14.1 to 163.1.15.254).

We are sometimes asked whether it is possible simply to extend the existing IP address range without having to renumber completely. In general this is not possible owing to the adjacent block of network numbers being in use by another college or department. Even in the cases where it is free, the migration is nontrivial as it requires a "big bang" approach in which the netmask and default gateway of all hosts on the network require changing simultaneously. This has been done, but in general is not to be recommended, especially on large and diverse networks.

Each move takes place over a pre-determined timescale, usually two to three months. Please try to stick to the schedule if at all possible. Avoiding unnecessary fragmentation of our IP address ranges (to allow maximum space for future large subnets) relies upon the prompt return of old subnets. Moreover, there are generally several changes currently in progress, making it hard to keep track of them and to ensure everything runs smoothly.

Upon completion of all the stages in the renumbering process, the networks team will remove IP routing for the old network and make it available for future reallocation.

Before even requesting a subnet change, is a good idea to consider how you expect your IP address needs to change for the forseeable future. For instance a college may have plans to wire up more student rooms, construct a new building or to expand central computing facilities. Departments may be expecting such things as new buildings, expansion in terms of number of students or staff or the introduction of new computing clusters. All of these will create the demand for more IP address space.

With the use of technologies such as VLANs (virtual LANs), it is now possible for annexe networks to be integrated with the network on the main site, despite considerable physical separation. In some cases (especially on networks which are currently shared between colleges or departments) this will require the purchase of additional switching hardware, for which there will be a charge. The use of VLANs can therefore mean that while the subnet used for a remote annexe can be reclaimed, the main network reaches full capacity and requires expansion.

Further planning will be required as to how to distribute IP addresses within the new IP address block: many IT officers like to maintain separate ranges for servers, DHCP-assigned addresses, static addresses, network hardware (hubs & switches), and so forth. If parts of a subnet have been sub-let to other institutions, you must bear them in mind as the change progresses and ensure that they are kept informed of what is happening.

If you operate a firewall within your unit, the firewall rules will need to be amended so that traffic to and from both the old and new subnets can pass through as necessary while the subnet change is in place. Additional configuration changes may be required to access restrictions applying to various servers, for instance tcp_wrappers or departmental intranet web pages.

Routeing firewalls may present an additional problem, in that not all can cope with multiple subnets on the inside. With these, the only option may be to go for a "big-bang" style changeover to the new subnet. Bridging firewalls should in general not suffer from such problems.

Please consider how you will get the work done within the agreed timescale. There may be obstacles such as systems which cannot be reconfigured at certain times (for instance during exams or admissions), or systems for which an IP address change is non-trivial. Please take these into account in your plans and provisionally schedule the necessary work. Many subnet migrations have overrun because critical systems have been left until last and then cannot immediately be changed.

Once you have decided upon your needs, discussed and agreed them with networks@it.ox.ac.uk, it is time to start the procedure. Hostmaster will set up IP routing for the new IP network range and amend the DNS web interface to include your new IP range.

For this section, "static" is taken to mean "not assigned by a DHCP server", despite the fact that a DHCP server may allocate static as well as dynamic IP addresses.

The procedure for changing static IP addresses may be relatively laborious but is fairly straightforward: essentially, all statically-configured machines have their IP addresses (plus default gateway and netmask) changed in turn. Additionally, please ensure that all machines are registered within the DNS following the transition: this is a requirement of connection to the University backbone.

If you are looking for machines to retain the same hostname following the transfer, bear in mind that DNS updates will not necessarily coincide with the time at which the machine is reconfigured. If you are looking for machines to retain the same hostnames post-transition, there may therefore be a period of a few hours in which a machine does not have a valid hostname, leading to temporary problems in accessing some services.

Subnet moves are made much simpler through the use of DHCP, as it frequently means that only a few changes to the server configuration will cause a large number of machines to migrate to the new subnet.

Many networks use large dynamic address pools with addresses of the form dhcp123.misc.ox.ac.uk. When migrating, we recommend that you first register the addresses in the new DHCP pool in the DNS. Since registering large numbers of very similar addresses via the DNS web interface is rather laborious, feel free to contact networks@it.ox.ac.uk and ask for bulk registration of such ranges.

If you make use of the DHCP Service, you will need to contact networks@it.ox.ac.uk to arrange a time to make the DHCP changes. A change to the IP configuration at the router will be necessary at the same time as the changes to the DHCP server configuration, but this should not affect users in any way and is in any case a necessary part of the changeover procedure.

If you have an internal DHCP server, the change to the new IP address range can be made without need to consult OUCS. It is recommended, at least for those using the popular ISC DHCP daemon on Linux/UNIX systems, that the server's IP address be changed at the same time as the DHCP configuration although it is not clear whether this is strictly necessary. We do not currently have the necessary information regarding Novell, Microsoft or other DHCP server implementations.

DHCP clients should pick up their new IP settings from the DHCP server on reboot or on attempt to renew their leases; no other changes should be necessary.

In some cases, clients will be manually configured to use specific servers, either by name or by IP address. In the latter case, client reconfiguration will be needed as the server's IP address changes; in the former it should not, but it may be necessary to request a special DNS update for this purpose. Please contact networks@it.ox.ac.uk a few days in advance to arrange a time to make such changes.

In the case of servers used by clients outside the University network, such as WWW and FTP servers, it may be necessary for the "time to live" (TTL) for the DNS entries for your server to be temporarily lowered to ensure that the changes quickly propagate. Again, this requires consultation with the networks team.

Most modern operating systems permit servers to listen simultaneously on multiple IP addresses, which can be very useful during transitions. A server can therefore listen for requests on both the old and new addresses for a period of time, allowing for DNS updates to be made purely on the usual 8.30am schedule. You will need to refer to your operating system documentation to determine how to do this. The virtual interface on the old IP address will need to be disabled following the DNS change (and global propagation, if appropriate).

Note that if an SMTP or HTTP server exempted at the firewall changes IP address, the firewall rules must be changed accordingly. This must be arranged by contacting networks@it.ox.ac.uk. In the future, firewall blocks may apply to other services.

If you have internal NTP servers, configuration changes are required on the central NTP servers as the access controls are performed by IP address, not hostname. Please contact networks@it.ox.ac.uk to arrange for these to be changed.