Information Services Division


Use of Private (RFC1918) Address Space in the UCL Internal Network

Version: 1.1
Date: 04/07/07
Author: Bob Lawrence
Document details: N/A
*Last Updated:*21/02/13 

Date Version Author Purpose
4th July 20071.0Bob LawrenceInitial version
7th July 20071.0Bob LawrenceCorrected erroneous network masks for prefixes in
14th March 20081.0Bob LawrenceAmended footnote, page (6)
21st Feb 20131.1Guy MorrellUploaded to wiki with minor format corrections
  • Use of private address space in the UCL internal network

    • Introduction
    • RFC 1918 and private IP addressing
    • Using private IP addressing in the UCL network

Use of private address space in the UCL internal network


This note describes the concept of "private" IP addresses, and their use within the UCL internal network.

Any UCL network administrator contemplating the use of private Internet addressing is urged to read this document to understand how such addresses are used within the College network, and in order to avoid duplication of such addressing and the communication pitfalls that might follow. The administrator is also cautioned to consider the appropriateness of such a choice. If there is any medium to long-term requirement for Internet access for devices using private addressing, e.g. for software updates, or for third-party support, then the use of private IP addressing may not be appropriate.

RFC 1918 and private IP addressing

RFC 1918 describes the use of IP address space deemed private by IANA, the Internet Assigned Numbers Authority (see, for example, RFC1918 - Address Allocation for Private Internets for details). Private address space is available for use by any organisation and is guaranteed to be not routable in the public Internet. What this means in practice is that any host machine which is assigned a private address defined by RFC 1918 cannot be reached "directly" by any other machine not in the hosting organisation's local network. Private addresses can be used for a number of reasons, some of which include,

  • Those instances where a host must be guaranteed to be isolated from the public Internet, for whatever reason.
  • To address public IP address space exhaustion. As more and more machines connect to the Internet, the availability of public IP addresses becomes more and more limited. Where an organisation is not able to augment the public address space it owns, one technique used in mitigation is to allocate private IP addresses internally, and to use a technique called NAT (Network Address Translation) to enable a machine with a private address to communicate with systems beyond the organisation's jurisdiction. What NAT does is to translate the source IP address in outgoing packets to a legitimate public address (or range of addresses) and to manage the housekeeping so that return packets are appropriately translated back to the correct internal addresses. This technique enables a "many-to-one" process in which multiple internal addresses can be translated to a much smaller block of public addresses, thereby conserving valuable public addressing resources PAT or Port Address Translation is an allied technique used essentially for the same purposes, ie. address hiding and conservation. Other than noting that PAT may be used where NAT is cited, it need not be considered further in this note..
  • A variant on the previous case in which, though an organisation may have a sufficiency of public addresses it nevertheless chooses to employ the methodology outlined above in order to enhance its public security posture vis-a-vis the public network. In this case the protected systems are typically connected behind an institutional firewall which performs the NAT function on behalf of the internal systems.

RFC 1918 defines the following address ranges as private,

  • (addresses through inclusive)
  • (addresses through inclusive)
  • (addresses through inclusive)The addresses in these ranges are not routable in the Internet and may be freely used by any organisation for local purposes only.

Note that the address ranges are represented in classless IP addressing notation. For a description of this notation see, for example:

Using private IP addressing in the UCL network

The UCL MAN routers, ie. those which connect the institution to the London MAN, are configured to drop any packet they receive in which an RFC 1918 address appears as either source or destination. There is however some requirement within UCL to route private addresses internally, ie. between different UCL subnets allocated private addresses, or between a public UCL address and a private internal address. Where this requirement is present, the private addressing used must be allocated by the IS Network Group, so as to guarantee both routing and uniqueness of addressing. Address allocation is one of the functions undertaken by the hostadmin role.

The following addresses are allocated by the IS Network Group (through its hostadmin role). They should only be used following formal allocation by hostadmin. These addresses are for use by host administrators who require connectivity between systems configured with private IP addresses and other systems (private or otherwise) connected in the College network. Routing is guaranteed for these address ranges within the core network.

  • (address through inclusive)
  • (addresses through inclusive)
  • (addresses through inclusive)

In practise addresses in (ie. through inclusive) will never be allocated. A number of "out-of-the-box" system configurations use addresses in or Prudence dictates that public allocation of these addresses must be avoided.

Note: there is an exception to this. The School of Pharmacy were using so this prefix is now routed on the backbone.

Note that each prefix represents the lower half of the original prefix from which it is derived, eg. is the lower half of the range represented by following address ranges are guaranteed to be truly private when used within the College network, because the UCL routing infrastructure will drop packets containing any address within these ranges. These addresses may be used by any administrator but on the strict understanding that they will never be made routable in the UCL network.

  • (addresses through inclusive)
  • (addresses through inclusive)
  • (addresses through inclusive)

Note that each prefix represents the upper half of the original prefix from which it is derived, e.g. is the upper half of the range represented by Applications for allocations of private IP addressing for use within the UCL internal network, and general enquiries about RFC 1918, should be directed to: hostadmin.