Limitations of IPv4 | Understanding Ipv6

The current version of IP (known as version 4 or IPv4) has not changed substantially since RFC 791, which was published in 1981. IPv4 has proven to be robust, and easily implemented and interoperable. It has stood up to the test of scaling an internetwork to a global utility the size of today's Internet. This is a tribute to its initial design.

However, the initial design of IPv4 did not anticipate:

The recent exponential growth of the Internet and the impending exhaustion of the IPv4 address space
Although the 32-bit address space of IPv4 allows for 4,294,967,296 addresses, previous and current allocation practices limit the number of public IP addresses to a few hundred million. As a result, IPv4 addresses have become relatively scarce, forcing some organizations to use a Network Address Translator (NAT) to map a single public IP address to multiple private IP addresses. Although NATs promote reuse of the private address space, they create performance and application bottlenecks.

Additionally, the rising prominence of Internet-connected devices and appliances ensures that the public IPv4 address space will eventually be depleted.
The growth of the Internet and the ability of Internet backbone routers to maintain large routing tables
Because of the way that IPv4 network IDs have been (and are currently) allocated, there are routinely over 85,000 routes in the routing tables of Internet backbone routers today. The current IPv4 Internet routing infrastructure is a combination of both flat and hierarchical routing.
The need for simpler configuration
Most current IPv4 implementations must be either manually configured or use a stateful address configuration protocol such as Dynamic Host Configuration Protocol (DHCP). With more computers and devices using IP, there is a need for a simpler and more automatic configuration of addresses and other configuration settings that do not rely on the administration of a DHCP infrastructure.
The requirement for security at the IP level
Private communication over a public medium like the Internet requires cryptographic services that protect the data being sent from being viewed or modified in transit. Although a standard now exists for providing security for IPv4 packets (known as Internet Protocol Security, or IPSec), this standard is optional for IPv4 and proprietary security solutions are prevalent.
The need for better support for real-time delivery of data—also called quality of service (QoS)
Although standards for QoS exist for IPv4, real-time traffic support relies on the 8 bits of the historical IPv4 Type of Service (TOS) field and the identification of the payload, typically using a User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) port. Unfortunately, the IPv4 TOS field has limited functionality and, over time, has been redefined and locally interpreted. Additionally, payload identification that uses a TCP or UDP port is not possible when the IPv4 packet payload is encrypted.

To address these and other concerns, the Internet Engineering Task Force (IETF) has developed a suite of protocols and standards known as IP version 6 (IPv6). This new version, previously called IP-The Next Generation (IPng), incorporates the concepts of many proposed methods for updating the IPv4 protocol. IPv6 is designed intentionally to have minimal impact on upper- and lower-layer protocols and avoids the random addition of new features.

Consequences of the Limited IPv4 Address Space

Due to the relative scarcity of public IPv4 addresses, NATs are being deployed to reuse the IPv4 private address space. In areas of the world where public IP addresses are scarce, there are multiple levels of NATs between the client computer and the Internet. Although NATs do allow more clients to connect to the Internet, they also act as traffic bottlenecks and barriers to some types of communications. Let's examine the operation of a NAT to illustrate why network address translation is a non-scalable, stopgap solution that impairs end-to-end communication.

For example, a small business uses the 192.168.0.0/24 IPv4 private network ID for its intranet and has been granted the public address of 131.107.47.119 by its Internet service provider (ISP). The NAT deployed at the edge of this network maps all private addresses on 192.168.0.0/24 to the public address of 131.107.47.119. To distinguish one intranet location from another, the NAT uses dynamically chosen TCP and UDP ports. Figure 1-1 shows this example configuration.

Figure 1-1. A NAT example

If a private host using the private IPv4 address 192.168.0.10 uses a Web browser to connect to the Web server at 157.60.13.9, the private host creates an IPv4 packet with the following:

Destination address: 157.60.13.9
Source address: 192.168.0.10
Destination TCP port: 80
Source TCP port: 1025

This IPv4 packet is then forwarded to the NAT, which translates the source address and source TCP port of the outgoing packet to the following:

Destination address: 157.60.13.9
Source address: 131.107.47.119
Destination TCP port: 80
Source TCP port: 5000

The NAT keeps the mapping of {192.168.0.10, TCP 1025} to {131.107.47.119, TCP 5000} in a local translation table for future reference.

The translated IPv4 packet is sent over the Internet. The response is sent back by the Web server and received by the NAT. When received, the packet contains the following:

Destination address: 131.107.47.119
Source address: 157.60.13.9
Destination TCP port: 5000
Source TCP port: 80

The NAT checks its translation table, translates the destination address and destination TCP port and forwards the packet to the host at 192.168.0.10. The forwarded packet contains the following:

Destination address: 192.168.0.10
Source address: 157.60.13.9
Destination TCP port: 1025
Source TCP port: 80

For outgoing packets from the NAT, the source IPv4 address (a private address) is mapped to the ISP-allocated address (a public address), and the source TCP/UDP port numbers are mapped to a different TCP/UDP port number. For incoming packets to the NAT, the destination IPv4 address (a public address) is mapped to the original intranet address (a private address), and the destination TCP/UDP port numbers are mapped back to their original TCP/UDP port numbers.

Normal network address translation relies on the following:

Address translation
Translation of the IPv4 addresses in the IPv4 header.
Port translation
Translation of the TCP port numbers in the TCP header or of the UDP port numbers in the UDP header.

Address and port translation lowers the forwarding performance of the NAT due to the additional operations that must be performed on each packet. As a result, NATs are typically not deployed in large-scale environments.

To make modifications to the IPv4 packet beyond address or port translation requires additional processing and software components on the NAT called NAT editors. HyperText Transfer Protocol (HTTP) traffic on the World Wide Web does not require a NAT editor because all HTTP traffic requires only address and TCP port translation. However, NAT editors are required in the following situations:

An IPv4 address, TCP port, or UDP port is stored elsewhere in the payload.
For example, File Transfer Protocol (FTP) stores the dotted decimal representation of IPv4 addresses in the FTP header for the FTP PORT command. If the NAT does not properly translate the IPv4 address within the FTP header for the FTP PORT command and adjust the TCP sequence numbers in the data stream, connectivity and data transfer problems will occur.
TCP or UDP is not used to identify the data stream.
For example, Point-to-Point Tunneling Protocol (PPTP) tunneled data does not use a TCP or UDP header. Instead, a Generic Routing Encapsulation (GRE) header is used and the Call ID field of the GRE header identifies the data stream. If the NAT does not properly translate the Call ID field within the GRE header, connectivity problems will occur.

Most traffic can traverse a NAT because either the packets require only address or port translation, or a NAT editor is present to modify the payload appropriately. However, some traffic cannot traverse a NAT. If the data requiring translation is in an encrypted part of the packet, translation is not possible. For IPSec packets, address and port translation invalidates the packet's integrity.

An additional problem with NATs is their effect on peer-to-peer applications. In the peer-to-peer communication model, peers can act as either the client or the server and communicate by sending packets directly to each other. If a peer is behind a NAT, there are two addresses associated with it, one of which is known to the peer behind the NAT (the private address) and one of which is known in front of the NAT (the public address). Let's examine a simple configuration in which NATs can cause problems for peer-to-peer applications. Figure 1-2 shows an intranet with a NAT at its edge.

Figure 1-2. NATs and peer-to-peer applications

For a peer-to-peer application running on all hosts, Host A can initiate a session with Host B (directly reachable on its link) and with Host C. However, Host A cannot inform Host C of the public address of Host B because Host A does not know it. Also, Host C cannot initiate a session with either Host A or Host B without manual configuration of the NAT with a static translation table entry to translate the inbound connection request packets to Host A's private address and port. Even with the static entry, Host C cannot initiate a session with both Host A and Host B because both hosts are known by the same public IPv4 address and application port number.

To make matters worse, it is a more common situation to have each Internet peer behind a NAT. To solve these problems, the peer-to-peer or multiple-party applications must be modified to be NAT-aware, resulting in additional complexity on the NAT and the application.

NATs are a makeshift measure to extend the life of the IPv4 public address space, and are not a solution to the IPv4 public address space problem. NATs work best for reusing the private address space for client computers. Most server computers still need unambiguous public addresses. A server can be placed behind a NAT; however, the NAT must be configured manually with a static translation table entry to translate the inbound connection request packets to the server's private address and port. In peer-to-peer communications, each end acts as both client and server and, therefore, peers separated by NATs might not operate correctly and must be modified for NAT awareness.