Use of RFC1918 addresses in an Internet connected network.

* Executive Summary

The use of RFC1918 addresses in a network which is connected to the Internet at
large is to be discouraged ....

	->	Additional Operational Overhead.

	->	Lack of support for new applications / protocols.

	->	Increased Costs.

* Introduction

RFC1918 address space, also known as Private address space comprises the
following address blocks:
	
	10.0.0.0/8
	172.16.0.0/12
	192.168.0.0/16

These addresses are intended for networks which will not be connected to the
Internet at any point and for whom the requirement for a globally unique address
is not necessary. 

The RIPE policy on IPv4 address allocation (ripe-288) states the where "Internet
connectivity is needed, unique, public addresses should be used."
           
Connecting an RFC1918 network to the Internet severely compromises the design
principles which govern the Internet.
No longer is the hosts address unique and so a variety of work a-rounds have
been developed all of which break the end to end model of the Internet.

The two most common methods used to connect an RFC1918 network to the Internet
are Network Address Translation (NAT) and Application Layer Gateways (proxies).

* Application Layer Gateways

For each application which requires Internet connectivity one or more proxies
are installed. These proxies accept a connection from an application and make
a new connection out onto the Internet. Only your proxy needs to be given a
public address. 

While this seems a good solution there are several issues:

	For each application requiring Internet connectivity a proxy will be
	required. This presents unique challenges in the Education and Research
	space as new or niche applications may not have an application proxy
	available. 
	
	If many applications require Internet access configuring separate
	application proxies for each application.
	
	Each user/host will require each application requiring Internet
	connectivity to be configured to use the proxy.

	An application may not support proxing or may operate in a fashion that
	makes it difficult to proxy. H.323 and FTP are good examples of this
	problem.

	In a large network the proxy servers become choke points limiting the
	growth of the network and can be single points of failure.

* Network Address Translation

Network Address Translation is a method of hiding the IP address of the host 
by editing the packet as it passes out thorough a gateway and by undoing the
changes made as the return packets arrive. To achieve this the NAT device must
dynamically maintain a state table that maps each session back to the appropriate
end host. While NAT appears to offer transparent Internet connectivity there are
several issues.

	NAT is CPU intensive on the gateway device. Rewriting packets and
	updating the state table are complicated tasks.

	The NAT device is a choke point in your network and whose cost will
	increase at a much faster rate compared to router costs as bandwidth is
	upgraded.

	Many protocols are not conducive to having their headers changed since
	end point addresses appear inside the protocol. The only solution to
	this is for the NAT device to look inside all packets, recognise such
	protocols and edit the address within. This is yet another CPU load on
	the NAT device and requires knowledge of each protocol. This can limit
	the deployment of new applications.

	A NAT device will make tracing network problems much more complicated.
	It will mask the true source of the traffic from the network administrator.
	Cases of NAT devices incorrectly rewriting protocol headers/data are
	common in both commercial and open source solutions.

	A NAT device will make tracing security problems much harder since 
	to trace the original source of a report is only possible if the state
	table has been preserved. This is almost impossible to achieve.

	Failure of the NAT device either thorough hardware/software faults or
	from being DOS'd will isolate the network. If the entire network is
	behind one NAT device then many attack mitigation strategies will be
	unavailable.

	By hiding the true address of a host, many of the tools available to
	assist in tracking network misuse (netflow, IDS/Honeynets) will be of
	little use.

	NAT will prohibit the deployment of new services and protocols. 
	Many common NAT devices can not support IP Multicast, SCTP or IPSEC
	for example.

	The deployment of NAT will severely restrict the ability to establish
	projects which are composed of participants from multiple end sites, 
	since hosts can no longer be identified via IP address.


* Security 

Many believe that the use of RFC1918 space provides security benefits. This is
not the case.  As was shown above RFC1918 space can intact limit ones
ability to address security problems. RFC1918 networks are still vulnerable to 
the internal propagation of worms/viruses and machines once infected can still
attempt to infect external hosts in many cases.
The security measures necessary to protect an RFC1918 network are equally
successful on a network with globally unique addresses.

* Conclusion

The use of RFC1918 address on a network which is intended to communicate with
Internet resources imposes significant operational overheads above and beyond
the cost of operating a network with public addresses.