|
|
|
|
|
|
|
Is Realm Specific IP set to take over from today’s address translation technologies to further slow IPv6’s relentless advance? Stuart Mark thinks it is a contender. Realm Specific IP The explosion of the Internet and a growing corporate reliance on standards based LAN applications over the last ten years has seen IPv4 become the protocol of choice for today’s networking infrastructures. So much so, in fact, that the 20 year old protocol’s late flourish has been tempered by grave warnings that the 4 billion+ network addresses provided by its 32 bit address space will soon be exhausted. There are some things in life, though, that seem bent on resisting retirement; The Mini, The Rolling Stones and, thanks to a new address translation protocol being developed by the Internet Engineering Task Force (IETF), the trusty IPv4. Realm Specific Internet Protocol (RSIP), originally developed by 3COM, is being positioned as an evolution of existing Network Address Translation (NAT) technology and, if widely adopted by the industry, could be yet another barrier to the widespread adoption of IPv6. A Natty Trick IPv4 owes much of its longevity to the use of NAT in conjunction with the private IP address space. Autonomous networks that use IP address ranges reserved for private use as per RFC1918 are able to connect to the Internet using one or more publicly assigned IP networks and have the private host addresses translated to addresses from the public range by a NAT router or firewall. The technique can be further refined by Network Address & Port Translation (NAPT) which permits multiple, internal, IP hosts to access the Internet using a single public IP address. This ability to give thousands of hosts a presence on the Internet through only one network number has turned panic into pragmatism and is good news for the enterprise and ISP alike. But we’re talking networking here and things aren’t quite that straight forward. Translation solves a lot of basic Internet connection problems but there are a number of network applications that are known to be disrupted by certain implementations of NAT. This is because NAT works by translating IP addresses - and optionally port numbers - in an IP packet. Some applications require addressing information to be carried in the payloads of packets. NAT cannot translate this data so its use with such applications can invalidate session flows. If you need to transfer files using FTP, send mail with SMTP or resolve a domain name from a DNS server across a NAT device, you might have problems. The same applies if the use of RSVP, SIP, RealAudio or H.323 is a requirement. There is, however, a solution to most application issues across NAT in the form of the Application Layer Gateway (ALG). Most modern proxy firewalls contain some form of ALG which will allow an Internet connection that supports NAT-unfriendly protocols but is usually very CPU intensive and generally expensive to implement. In fact it is the relatively unwieldy nature of ALGs that is cited as one of the driving factors behind the introduction of RSIP but there is another operational issue associated with NAT that is prominent in the minds of almost all network managers and may become RSIP’s champion. That of security. Defence of the Realm Existing NAT technology uses what is called transparent routing. The client has no knowledge of translation carried out on its session and all responsibility for performing such translation is held by the NAT device that links the IP address domains or realms. This means that end to end application layer security encryption algorithms and the IPSec suite of protocols cannot be used because they require that session addresses and ports remain unchanged. It is possible to employ IPSec Tunnel Mode between ALGs, perhaps for VPNs that link two private networks across the Internet or between an ALG and an end station but IPSec AH (Authentication Header), ESP (Encapsulating Security Payload) & IKE (Internet Key Encryption) protocols will not work between end stations when addresses and ports are altered by NAT. RSIP will tackle this by empowering end clients with the ability to perform translation, before they build session packets and will adopt a client server model to enable inter-realm traffic translation. An RSIP server will sit between two IP realms with a connection to both, where a NAT device would be situated in today’s networks. If an IP client in one realm needs to communicate with a node in another it will first register with the RSIP server, informing it of the IP address of the target node and the destination port to be used. The RSIP server will assign a source address (and port if required) from the destination realm and pass that information back to the client. The client will construct IP packets using source and destination addresses and ports from the destination realm, for example public addresses if the destination realm is the Internet. These packets will be tunneled using the client’s own IP address and that of the RSIP server and sent across the client’s realm to the RSIP server which will strip off the outer IP packet and forward the packet to the destination realm. Tunneling will be via an RSIP protocol which is likely to use port 4455 pending approval by the IANA (Internet Assigned Numbers Authority). This translation at source will allow the use of end to end IPSec and other application layer encryption techniques. It will also allow any IP protocol to be used, so negating the requirement for an ALG. It is expected that RSIP servers will run on routers and firewalls and give much better performance than the gateways used at present. It is also expected that RSIP will allow flow policies to be enforced. These will be defined at the RSIP server and will control the addresses and ports a client can use for a particular session. The Next Generation So where does this leave IPv6 or IPng as it has been lovingly called? NAT, RSIP and other technologies such as Classless Inter Domain Routing (CIDR) and Stateful Inspection will stretch the life span of IPv4 but the fact remains that the finite number of addresses offered by the protocol will not last forever. The IANA began the worldwide deployment of IPv6 addresses to the Internet in July last year and in time they will only offer the 128bit addresses, but this doesn’t mean the death of NAT or RSIP. In fact, the first private networks to be assigned IPv6 address space are still likely to be using IPv4 internally and will need the services of RSIP to manage the upgrade. The scope of such upgrades may be enormous and RSIP could become a mandatory requirement for the move to IPv6 but IPv4 will be in use for some time to come and here, RSIP could also have a role to play, replacing the NAT services used today. Additionally, the flurry of mergers and acquisitions in modern business means that there will continue to be cases where private networks may need to connect and RSIP may also be used to overcome address duplication problems when two private realms are using the same private address ranges. So the message is IPv6 is coming, eventually. Technologies like NAT and RSIP are there to make life easier, both in the interim and for the transition to version 6, so make use of them. RSIP has now been officially adopted by the IETF but don’t expect to see many commercially available offerings before the end of the year. www.ietf.org www.iana.org www.3com.com RFC1918 - Address Allocation for Private Internets RFC2663 - IP Network Address Translator (NAT) Terminology and Considerations Summary
|
This site was last updated 04/21/07
