NAT permits many hundreds of systems to be hidden behind a single public IP address space. For some units this may eliminate the need for a time-consuming subnet change.
Both global and University IP address spaces are finite resources, and may eventually run out. The long-term solution will be to migrate from using 32-bit IPv4 addresses to 128-bit IPv6 addresses, but at the time of writing this is still some time away.
Moving to a larger subnet assignment does require some work, although the procedure is described in some detail in our subnet change guide. With a little preparation, a well-maintained network can be migrated within a few days with minimal disruption, or as a one-day "big bang" changeover. There should rarely be a need for the procedure to drag on for months. A subnet change should not be perceived as a significantly greater challenge than moving large numbers of systems behind a single NAT IP address.
Please note that requirements must be considered "reasonable". We will expect efficient usage of existing address space prior to granting additional IP addresses and may require a breakdown of requirements. In particular, colleges should note that in addition to their requirements for servers, staff, public areas and infrastructure, more than one IP address per student cannot be guaranteed for residential accommodation.
In general, pressure on IP address space should not be seen as a reason for units to move to NAT; IT Services will do their best to accommodate your requirements although shortage of unallocated IPv4 addresses means that larger subnets can no longer be offered. Some limited usage of private (RFC1918) address space may be appropriate for devices which do not need to be externally-addressable (for instance network infrastructure), or for large compute clusters. Note that you can run both public and private subnets in parallel on the same network segment. To communicate between the two, you will require either an internal router or routing table entries on the individual machines that need to talk to both networks (for instance, the IT officers' computers).
Some people perceive NAT as making their network more secure. There are definite security benefits over leaving systems directly connected to the internet, as it should not be possible (without specific exceptions on the NAT device) for external systems to initiate connections to systems behind NAT.
In practice, a NAT will generally not prevent all external connections because of the mechanism used to permit traffic to pass to and from internal hosts. RFC3489 defines four basic types of NAT, which can be divided into two categories, "cone" and "symmetric" NATs (note that some NAT implementations may be a hybrid of the types defined). Without going into detail, symmetric NAT is generally considered the most restrictive type and is that found on most "enterprise" NAT solutions - the STUN mechanism for NAT traversal defined in the RFC will not work through symmetric NATs. Consumer NAT devices tend to be less restrictive, not least because for home users it may be more important that software such as file-sharing and voice-over-IP applications function correctly than that all possible attacks are prevented.
NAT traversal is significantly easier with UDP than with TCP, and TCP connections may often be tunnelled: for instance TCP connections over VPN may use UDP as a transport mechanism, while Microsoft's Teredo protocol tunnels IPv6 over IPv4 UDP packets. However, studies have shown that direct TCP NAT traversal is still possible.
To summarise, NAT offers considerable security benefits over nothing, but offers no security benefit over a good firewall - in principle an inbound default-deny policy on a stateful firewall should offer the same protection as a symmetric NAT setup.