Network Address Translation (NAT) is a technique which may be used in a routing device to convert between a "public" and a "private" address. Packet headers are rewritten as necessary; for some protocols it may be necessary to rewrite addresses embedded within the packet body for correct operation.
- Basic NAT: in this model there is a one-to-one mapping between the addresses on the internal and external interfaces, and each system has a unique public IP address. Port numbers for protocols that use them (eg TCP, UDP) remain unchanged.
- Port Address Translation (PAT): also called Network Address Port Translation (NAPT), this is in fact what many people mean when they say "NAT". In this scenario, the one-to-one mapping between internal and external addresses is lost; typically all internal addresses will map to one external address (though sometimes more than one may be used). Because multiple internal addresses may be using the same port numbers, the routing device must remap port numbers between the internal and external interfaces.
NAT has been widely used in commercial environments for some time. With the advent of domestic broadband routers it is now commonly seen in homes to allow multiple systems to share a single IP address assigned by the ISP; this generally works fairly well. In recent years, NAT solutions have been increasingly implemented within the University, but this is not without problems. There are many factors to be considered which are simply not an issue in a typical corporate or domestic environment, in part brought on by the distributed nature of IT support within the University.
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; OUCS 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 implentations may be a hybrid of the types defined). Without going into detail, symmetric NAT is generally considered the most restrictrive 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.
Any rewriting of packet headers has the potential to cause problems. With NAT, problems are most likely to occur with those protocols in which the IP address is embedded within the packets, or with those where there is a need for a remote host to initiate a connection to the host behind the NAT. With many such protocols, there may be legitimate uses of them, particularly within the university environment.
Some application-level gateways can introduce their own problems, through bugs, security issues and the difficulty of debugging problems where they are involved. Indeed, some application gateways have achieved considerable notoriety, such were the problems caused.
As with stateful firewalls, issues with TCP timeouts can arise with many protocols. Idle TCP connections may be kept open through the use of keep-alives, but if the interval between sending keep-alives is longer than the lifetime of a connection in the state table of a firewall or NAT drive, idle connections are liable to be broken. This may be annoying for some applications, for instance logins to remote systems, especially if users have a need to log into several simultaneously. Keeping state table entries for too long may risk the table filling, but the keep-alive interval can often be adjusted in applications to reduce the risk of unwanted disconnects.
One of the biggest problems with NAT is that individual systems no longer have a unique identifier on the public side of the gateway. This poses considerable problems when it comes to network abuse, such as security incidents or copyright violations, as there is no longer any means of isolating a particular host at the level of the backbone network, nor can OUCS's central logs identify the individual host concerned.
The requirement for traceability is described in detail within the OxCERT documentation on Logging of network usage, and has a section on NAT. Please read this and ensure that you are able to comply with OxCERT's expectations. Bear in mind that even if you are logging all necessary information, OxCERT will in general have no immediate access to your logs or to any means of restricting network access for an individual system within your network. Severe threats may require immediate action, including a complete IP block against your NAT gateway. Also worth bearing in mind is the type of NAT traversal i.e. "cone" or "symmetric" NAT as defined in RFC3489. Use of "cone" NAT traversal could adversley affect traceability on busy networks as inbound traffic may be incorrectly associated with a given internal host.
To avoid your NAT gateway being mistaken for a standard host, OUCS strongly
recommend that you give it a distinctive name in the DNS, for example
student-nat.unit.ox.ac.uk. High traffic levels or usage patterns
which would be abnormal for a single host might reasonably be expected of
NAT gateways. In the past, the lack of distinct labelling has caused blocks
to be placed NAT gateways as a result of relatively mild security problems
or copyright infringements. This may be standard practice for a single
host, but where there may be considerable collateral damage against
unaffected hosts, this will be taken into account before imposing a block
against a NAT gateway. Immediate blocks against known NAT gateways will
only be imposed in those cases where the immediate risks to others outweighs
the disruption caused by cutting off network access to all hosts behind
In conclusion, neither shortage of address space nor security should be considered strong reasons to migrate large numbers of systems behind NAT. Similar or better firewalling capabilities are offered on by many appliances or software applications without the need for NAT, while IP address space shortages are less severe than some may perceive.
OUCS are by no means looking to ban the use of NAT within the university but do ask that units understand the implications and ensure that they can fulfil OUCS's expectations of them. It is vital that the need for decent logging be appreciated by anyone who has implemented, or is looking to implement, NAT within their network.