When IP was first envisaged back in the 1970s, just over 4 billion unique IP addresses were allocated. However, the overwhelming international adoption of the internet with a world population of more than 8 billion people has demonstrated there are simply not enough IP addresses to go around.

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 3.4 × 1038 unique IP addresses, or approximately 4.2 × 1028 addresses for every person on Earth. Hopefully, this should be enough.

Although IPv6 was first implemented experimentally into Linux kernel V2.1.8 in 1998, and fully adopted into Linux kernel version V2.6.12 in 2006, its take-up hasn’t been spectacular: Google reports that approximately only 37% of users accessing its services currently do so over 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 process 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 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.

A NAT maintains a translation table containing IP addresses and UDP or TCP port numbers. The combination of an IP address and UDP or TCP port number provides a unique mapping entry within the NAT 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 console’s packet is streamed through the NAT router to its destination, the NAT will change the source IP address and UDP port number 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 degree of isolation because the private IP addresses of the broadcast equipment are hidden from the public network.

Port Address Translation

Modern NAT systems normally operate using a method often referred to as Port Address Translation (PAT), and sometimes also called Network Address and Port Translation (NAPT). This allows many devices within a private network to share a single public IPv4 address simultaneously while still maintaining independent network connections.

The public IP address alone is not sufficient to distinguish one device from another because multiple devices may all communicate through the same NAT router at the same time. The router therefore uses the UDP or TCP source port number to create a unique mapping for each active communication flow.

For example, several devices within a broadcast facility may all be sending traffic through the same internet connection. A stagebox may be transmitting audio streams, a monitoring workstation may be accessing cloud-based control systems, and an engineering laptop may be connected through a VPN. Although all of these devices may share the same public IP address, the NAT router allocates different public-side port numbers to maintain separation between each traffic flow.

This approach works extremely well for conventional IT systems because most network traffic is initiated from inside the private network. The NAT router creates a temporary translation entry when the outgoing connection is first established and automatically removes the entry after the communication session ends or becomes inactive.

However, this behavior can introduce operational complexity for live media systems. Many professional broadcast protocols rely on deterministic network configuration and fixed addressing relationships between devices. If UDP or TCP port numbers are modified dynamically by the NAT router, then receiving equipment may require additional configuration to correctly identify the incoming stream. For this reason, engineers often use static NAT mappings or port-forwarding rules when deploying professional media systems across public networks.

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 creates a challenge because IPsec authentication mechanisms validate parts of the packet that may subsequently be modified by the NAT process. If a NAT changes the source IP address or UDP/TCP port numbers after IPsec processing has taken place, the receiving IPsec endpoint may determine that the packet has been altered and reject it.

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 requires higher-layer security protocols to become aware of lower-layer address translation behavior. RFC 3947 defines NAT-Traversal (NAT-T), one of the primary mechanisms used to allow IPsec to operate across NAT devices.

In summary, NAT-Traversal relies on the IPsec packet being encapsulated inside an additional UDP packet 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 and 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.