When service providers want to deploy new large-scale services (mobile Internet access, for instance), they're commonly faced with a shortage of public IP addresses. As these are verifiably close to depletion, it's hard to get enough addresses to cover the need for new services.
For example, if you wanted to start offering mobile Internet access to a target group of a million users, you would need between 1,000 and tens of thousands of public IP addresses (depending on whether or not you would bill your customers based on actual airtime). These days, it would be pretty challenging to get such a large address block.
The private address temptation
Faced with the grim reality of address shortage, service providers are tempted to use private IP addresses within their networks. An end user connecting to the Internet through such a network would be assigned a private IP address, and Network Address Translation (NAT) would be used at the network edge to convert a large pool of private IP addresses into a much smaller pool of public IP addresses allocated to the service provider. To conserve the available public address, NAT would usually be configured to use Port Address Translation (PAT), where sessions from different users are mapped into the same IP address and differentiated solely based on TCP or UDP port numbers.
As soon as you start using private addresses and PAT in your network, you lose one of the important security features: accountability. If a rogue user of your network is attacking an outside server, it's close to impossible to identify him. In classic access network designs using public IP addresses, the victim of the attack (or the law enforcement authorities) could provide you with the source IP address of the attacker, and you could use various logs (which are becoming mandatory in many countries worldwide) to figure out who was using that particular IP address at the time of the attack.
In networks using PAT, it's almost impossible to figure out which user was the culprit, since many users are mapped into the same IP address and are differentiated solely on quickly changing port numbers. As the source port numbers are usually not logged by the application servers (Apache, the most popular open-source Web server, does not log port numbers), the victim cannot provide enough information to identify the attacker.
Mapping multiple users into the same IP address has further security implications: Some enterprise networks use strong authentication in combination with the source IP address to allow temporary access from public Internet (for example, using Lock-and-Key functionality available on routers running Cisco IOS). If the service provider used by the remote user deploys PAT, the remote user opens the enterprise network to a very large crowd when the IP address (which is used by a number of others) is allowed to access the enterprise servers.
Note: You should use IP Sec-based Virtual Private Network instead of Lock-and-Key functionality if you're worried about the security implications of PAT.
Private addresses in the network core
To reduce the address usage in the network, the service provider might be tempted to use private IP addresses to address the router-to-router links in the network core. This decision is only inconvenient to your end users. The replies sent by the intermediate routers to the probes of a traceroute command would be sourced from a private IP address. Properly configured firewalls would reject these replies immediately (packets from a private IP address received over a public interface are almost always a sign of an attack), and the address-to-name resolution would almost certainly fail. So it's best to use public IP addresses in your network core to allow your users to troubleshoot any connectivity issues they may have.
The bottom line on Private IP addresses
Private IP addresses offer excellent solutions for enterprise networks, giving them the ability to deploy large-scale IP networks without a large pool of public IP addresses. But they were never meant to deal with the addressing issues of service providers. If you decide to allocate them to your end users, you risk loss of accountability, which could have serious legal implications. Using them in your network core is safer, but it still makes the connectivity troubleshooting more inconvenient for your customers.
About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and Web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. You can read his blog here: http://ioshints.blogspot.com/index.html