One of the issues that you will face when designing a network is ensuring that all your devices have an IP address. Each device needs an IP address for sending and receiving traffic, as well as for remote management. With a shortage of public IP addresses for accessing the Internet, this presents a problem for assigning addresses to devices to allow communications. Some type of solution is needed.
One of the problems that the Internet faces is IP address depletion. As a long-term solution, IPv6 is addressing this. However, a lot of manpower and money is required to covert from IPv4 to IPv6. As a short-term solution, IETF defined two standards: RFC 1918 and 1631. These standards set aside a range of public IP addresses and allow anyone to use them; they also translate these addresses to public addresses when they leave a company's network. The following sections discuss these standards.
RFC 1918 sets aside a block of addresses that any network can use, commonly called private addresses. Table 11-1 lists the address class as well as the range of addresses that RFC 1918 sets aside for the class. With this RFC, 1 Class A, 16 Class B, and 256 Class C addresses are set aside for intracompany use. As you can see from this list of addresses, you have more than 17 million at your disposal?more than enough to assign addresses to all your internal devices.
These addresses work fine for intracompany communications, in which one device in a company accesses another device in the same company. However, using private addresses presents problems when two companies want to share information but they are both using the same private address space. Figure 11-1 shows a simple example of this problem. In this example, two companies, A and B, are both using network 10.0.0.0/8. In Company A, an internal user (A) wants to access a server in Company B. You will notice, that in this example, this presents a problem: Both networks are using network 10.0.0.0/8, and both have overlapping addresses: 10.1.1.1. The two networks cannot communicate with each other.
To solve this communication problem, IETF introduced RFC 1631. This RFC defines address translation, translating addressing information in a packet from one number to another. Typically, this is used to translate private addresses to public ones, and vice versa. This translation process commonly is referred to as Network Address Translation (NAT).
You might need to use private IP addresses for these reasons:
Your current ISP assigned you a limited number of public addresses, but not enough to assign to all of your devices.
You currently have enough public addresses, but you are changing ISPs and your new ISP will not support your old public address space.
You need to merge two networks, which, unfortunately, are using the same address space.
You currently are using someone else's assigned public addresses.
You want to set up load balancing by using a single virtual IP address to represent multiple devices.
You want to have better control over traffic entering and leaving your network.
Address translation has both its advantages and disadvantages. Take a look at its advantages first:
You have access to 1 Class A, 16 Class B, and 256 Class C networks, totaling more than 17 million addresses.
If you change ISPs, your work is simplified. You need to change only the address-translation rules on your address-translation device; you do not have to change addresses on specific devices.
Your ISP drops packets with private addresses in them, giving you tighter control over traffic leaving your network. If the private addresses are not translated as they leave your network, your ISP drops these packets.
The internal structure of your network is hidden from outside eyes.
Address translation also has its share of disadvantages, including the following:
When performing address translation, your address-translation device introduces delay in the packet stream. The address-translation device must change addressing information in the packet and recompute checksum information.
The more translations your address translation device needs to support, the greater burden this places on the device. This can create scalability issues in large networks.
It is more difficult to troubleshoot problems because the source and possibly destination are using translated addresses. Therefore, when you look at an IP address in a packet, you cannot necessarily be sure whether this is the address physically assigned to the device or whether it is a translated address.
Even though address translation provides tighter security, it allows people to hide their identities through address translation, making it more difficult to track down the source of an attack.
Some applications embed addressing information in the payload contents. This presents a problem with address-translation devices, which typically translate addressing information only for the IP and, possibly, TCP or UDP headers. If an address-translation device does not translate embedded addressing information, and a device attempts to use the untranslated information, it cannot connect to its destination.
Given the advantages and disadvantages of address translation, you must take care in deciding when you need to use address translation and what it will encompass.