Articles in this series:

One method to solve this was the introduction of IPv6 with an address space of 128 bits, as opposed to 32 bits for IPv4, providing a massive 340 trillion, trillion, trillion unique IP addresses (2^128), or just over 42,000 trillion, trillion unique addresses for every person in the world. Hopefully, this should be enough.

Although IPv6 was first implemented experimentally into Linux V2.1.8 in 1998, and then fully adopted into version V2.6.12 in 2006, its take-up hasn’t been spectacular: Google reports that only 37% of the internet currently uses IPv6.

Expanding Address Space

Another work-around for the limited IPv4 address space, and one that is widely used today, is that of Network Address Translation, or NAT. This assumes that a limited number of public IP addresses are available for a user, but within their network, they have many more private IP addresses available.

In a home, the ISP usually allocates one public IPv4 address for the router. A private network is provided on the home side of the router with IP addresses for each device. Only when a device tries to communicate with the internet does it undergo a NAT process to effectively change the source IP address.

Similarly, but on a much larger scale, the same method occurs within a broadcast facility. Most of the time the broadcast equipment, such as cameras, microphones, monitors, etc., will exchange data packets over the private IP network. It’s only when the devices need to send data outside of the network across a public network, such as the internet, will the source IP address change.

In effect, NAT creates a many-to-one mapping, when looking from the private network to the public. Or a one-to-many mapping when looking from the public network to the private network.

Unique Tuple Identification

A NAT is a list of IP addresses, and UDP or TCP port numbers. The unique tuple of an IP source address and port number provides the entry for a specific device in the NAT routing table. For example, if a sound console at a stadium has private IP address 10.0.100.1 and is using UDP port 4001, then the NAT will allocate a tuple of the public IP address with a unique port number. For example 86.24.250.33 and port 2010, to provide a mapping of 10.0.100.1 port 4001 to 86.24.250.33 port 2010 in the NAT table (see figure 1). When the sound consoles packet is streamed through the NAT router to its destination, the NAT will change the source IP and UDP address of the sound console’s packet.

The receiver device, such as a studio sound console, will only see the modified source IP address and port number that was set by the NAT and not the original IP address and port number. However, if the studio console needs to send data packets back to the stadium console, then the stadium router’s NAT will identify the unique IP address and port number and change it back to the private network allocation. Figure 1 shows how this happens in practice.

Figure 1 shows the flow of packets from the stadium to the studio and how the source addresses and UDP/TCP port numbers are changed in the packets. If packets flow from the studio to the stadium, then the reverse mapping occurs. Mapping from the public IP address space to the private space provides a good level of security protection as the IP addresses to the sensitive broadcast equipment are blind to a hacker: the mappings are kept secret within each NAT router.

Complete System Knowledge

There is no easy way of advertising the mappings of each NAT router as they are kept private within the routers thus improving security. However, the network engineer must have knowledge of the public IP addresses and UDP/TCP port number combinations at both the stadium and the studio to allow configuration of the system. For example, when streaming audio from the stadium to the studio console, the network engineer must know the public IP address and UDP/TCP port number combination of the studio console so that it can be programmed into the destination IP address and UDP/TCP port numbers of the stagebox or console at the stadium.

Although NAT works well and solves the initial problem, there are not enough IPv4 network addresses for every device to have its own unique address. It does have some challenges for security as the data in the packet payload is still in the clear, so anybody sniffing the packets will have access to the data. One solution to this is to use VPNs or IPsec as discussed in Part 3.

IPsec encrypts the data payload and validates the packet header. This causes a challenge in combination with a NAT as the source address and port numbers are changed during translation to the public network. As the IPsec encryption and authentication processing takes place prior to the NAT on the IP header containing the IP addresses, any IPsec-receiving equipment will find the source IP address in the IP packet header and port number of the UDP/TCP header to be different to the calculated values, causing the packet to be dropped.

Due to the speed with which IP and its associated protocols have been specified and released over the years, the interaction of a NAT with IPsec creates a direct contradiction as IP addresses are changed in the process.

Introducing NAT-Traversal

The good news is that there is a workaround. It’s not elegant as it implies a breach of the OSI seven-layer model, but it does work. RFC3947, through NAT-Traversal, is one of the solutions available but some of the detail is not as well defined as it could be and often relies on proprietary solutions to make it work.

In summary, NAT-Traversal relies on the IPsec packet being encapsulated by another IP/UDP datagram with the IP source address and port number specified by the NAT router and entered in its look-up table.

In the next article we delve into the NAT-Traversal protocol, how it operates with the IKE (Internet Key Exchange) to facilitate IPsec over NAT and provide a secure and reliable network for sending high-value media over the internet.