Posted by Nicolas St. Pierre in For the past 10 years, we’ve been hearing about IPv4 address space depletion and I always took it with a slight shrug, believing that there would be ways to manage a punctual migration to IPv6. I was of the opinion that just like the Netware server forgotten in my basement, IPv4 would be with us for the next 20 years (at least!) as the world pursued its migration to IPv6.
But recently I’ve had a change of heart. Carriers have had to deal with a very tight supply of IPv4 space, and some years ago, started to re-use internal (RFC1918) IP space for network element addressing. We’re faced with such a large explosion of mobile device and IP-aware machines that it has become imperative to use Carrier Grade Network Address Translation (CG-NAT) to stave off the lack of IP address resources.
Now, NAT and CG-NAT certainly aren’t that new, but recent standards such as RFC6598 enable service providers to deploy address translation (NAT44, NAT444) within a better established framework.
In NAT44, the carrier can aggregate a logical network node and address its user equipment, or premise equipment with a shared and reusable IP address space block, typically the 100.64/10 network. This space of roughly 4 Million addresses can safely be reused, and will not otherwise interfere with subscriber networks that typically would reside within the private RFC1918 space.
On the public side of the network, the provider can then better utilize its IP address space prefix allocation by overloading the shared IP space, in a many-to-one scenario, to the public range; this is reminiscent of the olden days of Port Address Translation (PAT).
Such CG-NAT is implemented by the hardware vendor through dynamically allocating IP address source port ranges to a public IP. So whereas subscriber A and B may each have their own shared IP address (100.64.100.1 and 100.64.100.2), their public side IP address may be common (24.2.2.2) but the source port of their outbound connections will be assigned to separate and unique ranges, for example: subscriber A to source port range 2001 – 3000, and subscriber B to source port range 3001 – 4000.
One can see why the use of session qualifiers, beyond IP address tuples, becomes a requisite when dealing with subscriber-based systems in a CG-NAT environment; in the shared space, the IP address may be reused in different nodes or parts of the network, and in the public space, the port range must be combined with the public IP address to adequately map to the proper subscriber. This is exactly the type of environment in which the Sandvine platform is deployed today. In order to maintain proper state and subscriber mapping, the PTS and SDE share the IP address and qualifier together, coupling them to ensure appropriate subscriber awareness.
Overall, the use of address translation will grow as available IPv4 prefix depletes, and Sandvine has already answered this network architecture requirement with feature availability. Bookmark this article!
