Private (RFC1918) IP addresses within the University of Cambridge and the CUDN

For the purposes of this document, the term an 'institution of the University of Cambridge', or abbreviated to an 'institution', is to be be understood to mean an organisation whose network is directly connected to the University of Cambridge's data network (CUDN) and whose connection to the global internet is via the CUDN and Janet, whether or not the organisation is formally part of the University.

Introduction

RFC1918 defines a set of IP address ranges which may be used for constructing 'private internets', that is networks which are strictly local to an organisation and whose traffic is not routed over the global internet. Networking within the University of Cambridge is arranged in a hierarchical manner, with the CUDN interlinking the networks of the various institutions within the University and providing a connection to the global internet (via Janet); this hierarchical structure may be replicated within an institution whose own network may be one which interlinks the networks of various subunits and provides a connection to the CUDN. The provisions of RFC1918 are applicable in two distinct ways in the University of Cambridge:

1. providing a private internet across the CUDN - a CUDN-wide private internet
2. providing a private internet within an institution of the University of Cambridge - an institutional private internet.

Furthermore, within an institution, RFC1918 may similarly be applied at two levels: providing a private internet across the institution and providing individual private internets for the subunits within the institution - and so on.

This document defines a partitioning of the RFC1918 address space within the University of Cambridge to accommodate both CUDN-wide private internet and institutional private internets. It is pointless for this document to replicate those parts of the text of RFC1918 which are relevant for this purpose; reference should be made to the RFC for general details and rationale.

This document does not discuss the further partitioning of RFC1918 private addresses to provide both an institution-wide private internet and private internets for the subunits within the institution. This is a matter for the institution itself, within the parameters of this document.

RFC1918 address-space partitions

1. The RFC1918 private address ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16; all other addresses are referred to subsequently as global addresses. The RFC1918 private address ranges are partitioned for use within the CUDN as follows:
   1. 10.128.0.0/9 is a range of addresses which is reserved for the future (as an example, these might be used as private addresses across the EastNet regional academic network - but they have not been reserved specifically for that purpose); it is essential that no use, whether overt or clandestine, of addresses in this range is made within the University or any of the institutions whose networks are connected to the CUDN;
   2. 10.0.0.0/9, 172.31.0.0/16, 192.168.0.0/16 are the address ranges that are entirely private within an institution's network and are routed neither across the CUDN nor to/from Janet; these addresses are referred to subsequently as 'institutional private addresses'.
   3. 172.16.0.0/13, 172.24.0.0/14, 172.28.0.0/15, 172.30.0.0/16 (i.e. addresses 172.16.0.0 to 172.30.255.255) are the address ranges that are routed across the CUDN but are not routed to/from Janet; these address ranges are referred to subsequently as 'CUDN-wide private addresses'.
2. Where possible, CUDN routers are configured so that they do not route institutional private addresses and so that they correctly route CUDN-wide private addresses (in addition, of course, to global IP addresses). This is not possible where the CUDN routers provide proxy-ARP responses to the connected institution for the default route, as is generally the case at present; this is because of limitations in the current CUDN router software. In such cases, the institution needs to provide a firewall or private router to block the relevant ARP requests (and/or responses) before private addresses can be used reliably. This is explained in more detail in the annex, below.
   Institutions should note that they must provide the necessary routing between their private subnets and their global subnets - CUDN routers do not route institutional private addresses at all.
3. Allocation of addresses from the CUDN-wide private address ranges must be made by ip-register in exactly the same way that they are for global IP addresses.
4. Allocation of addresses from the institutional private addresses should be done independent of ip-register who will not be responsible for any clashes of such addresses within an institution. However, an institution should note that use of institutional private addresses does not absolve it of the responsibility to be able to identify a particular device from the traffic that it generates; as use of the internet grows, the number of occasions when such identification is needed is increasing.
5. The Computing Service has set up a private DNS zone, private.cam.ac.uk to hold names associated with CUDN-wide private addresses and operates this in exactly the same way as for global addresses - except, of course, the zone is not visible outside the University.
6. Since the institutional private addresses have no validity other than within the institution itself, the responsibility for running DNS servers for names associated with those addresses must fall to the institution itself.

Example of the use of private addresses within the University

1. An institution may economise on its usage of scarce public IP numbers by assigning private IP numbers to network equipment to which IP access is required only from within Cambridge. For example, ethernet switches and managed hubs might fall into this category.
2. A college might use institutional private addresses for their administrative computing to ensure that those systems cannot be accessed from outside the college.
3. An institution might use institutional private addresses for addressing behind a firewall, with the firewall performing network address translation to CUDN-wide private addresses or global addresses. In this context, the institution needs to maintain a 'trace' of address mappings so that erroneous or malicious behaviour can be tracked to the particular device involved (see also Firewalls and Network Address Translation).

Other considerations

Although the CUDN routers ensure that devices using CUDN-wide or institutional private addresses are not visible from outside the University, there is the possibility that private addresses are promulgated in data outside the CUDN. It is important that those creating data realise that private addresses are not globally unique and that, outside the University, an attempt to reference a device within the University by private address can result in identifying either a different device altogether or no device at all.

Institutions need to bear in mind that their members are likely to make increasing use of institutional facilities from outside the CUDN, e.g. by xDSL, and cable modem facilities provided by external telcos and ISPs. Hosts that use only private addresses are not visible to people accessing the CUDN by such means - although this does not apply to access via the CUDN VPDN Service. This may prove to be a substantial disincentive to the use of private addresses within an institution.

The Computing Service has considered whether there should be any automatic allocation of private address ranges to parallel global address range allocations. It concluded that there would be insufficient benefit in running such a scheme.

The Computing Service has considered a scheme of splitting private address ranges in two so that devices with addresses in one part are allowed access outside Cambridge via proxy servers, whereas devices with addresses in the the other part of the range are not. It concluded that such a scheme, whilst superficially desirable, would be likely to be impractical as it would be difficult to prevent unofficial proxy servers from circumventing the intent of such a scheme.

Annex: The need to block proxy-ARP

Router software generally assumes that an IP address identifies a unique device; this is the case for the commercial routers that are used within the CUDN. Thus, it is not currently possible to configure the CUDN routers such that the institutional private addresses can be assigned to multiple, concurrently active interfaces on the router - this could change if an upgrade to the router software to take private addresses into account becomes available. To prevent traffic for addresses in the institutional private address range being sent to the router's default route, it is necessary to configure the routers to route traffic for institutional private addresses to a 'sink' or 'black hole'.

An ARP request is of the form "to what MAC address should I send traffic for this particular IP address?". If a router sees such a request on an interface where proxy-ARP is enabled, and it has a route (possibly a default route) to the requested address which is not back out of the same interface, it will send a proxy-ARP response of the form "send this traffic to me" (if the route is back out of the same interface, the router will not respond as it will expect the addressed device itself to respond). Where an 'unnatural' address mask is used within an institution's network for efficiency reasons, e.g. where a netmask of 255.255.0.0 is used because an institution has multiple /24 subnets within the same /16 address range, it is essential that the router performs proxy-ARP for those addresses which are included within the subnet mask but are outside the multiple subnets allocated to the institution.

For institutional private addresses, the CUDN router will by definition not have a route except default or, possibly, to a 'sink' ('black-hole'); therefore it will produce a proxy-ARP response, which is liable to conflict with a response from the station that is using the address within the institution. To prevent this, the institution needs to interpose a filtering device, e.g. a private router or a firewall, between its network and the CUDN point of presence.

Current practice in the CUDN is:

1. to have a default route, as this is impossible to avoid in practice;
2. to enable proxy-ARP at interfaces to connected institutions; this is strictly necessary only where the institution uses an unnatural address mask, typically 255.255.0.0, to make local communication more efficient, but it is at present generally in effect for uniformity, simplifying management of the CUDN.