IPv4 address allocation policy

The University's reserves of IPv4 addresses are low. When this policy was originally implemented it was calculated that at the then rate of assignment, approximately two years' supply remained. The Internet Exhaustion Group (IEG), now a sub-group of the Network Advisory Group, was setup to manage the remaining address space and has stabilised the depletion rate. However, as IPv6 implementation has now been delayed, IEG been tasked (NAG 98, Nov'2019) to manage the reserves for another 10 years.

1. IPv6 is not the only answer - systems will require access to IPv4-only services for the foreseeable future
2. There is almost no possibility of acquiring additional IPv4 address space, certainly not without paying
3. We are unlikely to be able to recover significant amounts of address space from existing allocations - most cannot easily be relinquished
4. We cannot afford to run out entirely and so reserves must be retained for future expansion of the University
5. Future IPv4 allocations will be limited to a maximum of 256 addresses (ie a /24 subnet). An extremely strong justification must be made to the IEG for any exception to this
6. The future is considerably more NAT. However this is implemented, it will bring its own challenges and incur significant (direct and indirect) costs for the University

1. NO further allocation of public IPv4 subnets will be made to any unit/sub-unit which already has an existing allocation, baring exceptional circumstances (see 1.5 above).

2. Any new Unit that joins the University will only be given a /24 allocation and will have to use RFC 1918 ranges of 192.168/16 &/or 10.128/9 2internally to the Unit.

Note: in addition existing users are encouraged, as opportunity permits, to migrate users onto the above two RFC 1918 ranges to avoid long term unexpected interaction with the other RFC 1918 ranges, which are being routed over the core network (Odin).

3. The existing policy RFC1918 Address Space Usage will now say use of the 172.16/12 range must be avoided ³.

4. This means that everyone will now have to use NAT/PAT to satisfy any requirements that do not fit into their existing allocation. All instances of NAT/PAT systems must comply with the Logging requirements to aid traceability set out by IT Services/InfoSec.

5. Centrally provided data centre server hosting. Where servers are provided on the data centre network the DC team will provide IP addresses. This does not apply for Campus Network connections where the Unit will provide addresses from their existing allocation.

1. Temporary additional allocations. These may be made available provided that over an agreed timescale, normally not exceeding 3 months, either the subnet itself or an equivalent subnet are returned back to the pool. Example: a building move. Provide a new /24 to ease a move and then return either of the /24's (new or old one) back to the pool.
2. Linknets ⁴: we will allocate a public /30 (or a /29) for routing firewalls and VPN termination. These will normally be agreed by a subset of IEG (Head of Networks & Data Centres and the Network Support and Development Manager), subject to reasonable use/demand and reviewed, post factum, by the full IEG.
3. Geographical exigencies. In these cases and subject to 1.5 above IEG, or its sub-group, will consider providing a linknet-type allocation.

Main outline agreed OUCS/SMG (04/12/12) and NAG 23/01/2013. Revised: NAG 07/11/2019.

1. As defined by University organisation structure. We use the designation Unit to cover Sub-Unit where more appropriate. The exact boundary is ill defined. IT Services will endeavour to be as fair as practical to both the group directly concerned and the University as a whole.

2. We are allowing only 10.128/9 because LIN already uses 10.0.0.0/12 & 10.16.0.0/12. This avoids clashes when routing some RFC 1918 through the core network.

3. Primarily the imminent large-scale projects eg Integrated Communications and the TONE Projects.

4. Normally network addresses which are not destination addresses in and of themselves.