Pv4, the current version of IP, supports more than 4 billion addresses. Considering the Internet’s phenomenal growth, however, that represents a relatively meagre allotment.
To extend the reach of the IPv4 address space, companies have turned to using private IPv4 addresses through a public-to-private address translation technique known as network address translation (NAT).
But this method has a number of limitations. So a new technique called Realm-Specific Internet Protocol (RSIP) promises to pick up where NAT leaves off.
NAT works by using the several million private addresses that have been put aside by the Internet Engineering Task Force, turning a public IP address such as 192.156.136.22 into a private address, such as 10.0.0.4, for delivery to a user’s PC. Private IP addresses cannot be “seen” by the Internet, and therefore may be reused by various enterprise networks.
In conjunction with a NAT-enabled gateway or router device, a privately addressed network may hide hundreds or thousands of hosts behind a single public address. The NAT device differentiates among the PCs by translating their port numbers into unique values.
But NAT is limited by applications such as streaming media that transmit IP addresses or port numbers in the payloads of packets. Such applications require that NAT take on application-specific knowledge and perform additional computation.
Worse, because NAT typically resides in a boundary router between private and public networks, it can’t function with IP Security (IPSec), the popular encryption technology for virtual private networks. IPSec requires true end-to-end handshaking in order to set up initial encryption rules. Once encrypted at a client system, IPSec packets cannot be modified-or recognized-by NAT.
Like NAT, RSIP translates between public and private IP addresses. But instead of requiring a boundary router to translate, RSIP uses a simple protocol between a user’s desktop PC and a boundary router to perform preparatory signalling. Through this signalling, the PC is able to prepare each packet in a way that removes the translation burden.
The RSIP protocol works via a simple challenge-response structure, and employs a vocabulary consisting of “parameters” and “messages.”
Operation begins when RSIP client software in a PC signals the RSIP server software in a boundary router or gateway. Through this exchange, the RSIP client requests a public IP address, plus one or more of the router/gateway’s ports.
In reply, the router/gateway’s RSIP server software assigns a public IP address and one or more port numbers, in addition to lease time, tunnel type and other parameters. When the packet hits the RSIP server/ gateway, the packet’s uniqueness is identified by the combination of assigned IP address and port numbers.
As with NAT, the RSIP server uses a reserved IP address, such as 10.0.0.4, for its own internal-enterprise addressing scheme. But unlike NAT, the boundary device gateway does not have to possess the intelligence to perform the translation; instead, the RSIP server/gateway sees the information it needs in the packet header, then consults its RSIP table to determine where the packet should go.
It’s clear that RSIP represents a big improvement over NAT. For instance, with a simple extension, RSIP can support end-to-end IPSec, even though IPSec encrypts port numbers. Still, the two techniques have much in common, and this will work to the advantage of users.
RSIP promises two important advantages. Its close ties with the NAT addressing scheme bring backward compatibility, a benefit to the thousands of NAT users who will prefer to migrate gracefully to RSIP. And because the RSIP protocol employs preparatory signalling, RSIP is suited to policy-driven networking.
(Mike Borella is a senior architect at 3Com. He can be reached at mike borella@3com.com.)
