
IPv6's importance to the end-to-end model comes from its increased address space and support for multiple addresses per interface, along with mandatory IPSec (IP Security). Since IP addresses are both system identifiers and routing tags, address uniqueness is an a priori requirement for the end-to-end model. Companies today are faced with situations where two clients from different companies have the same address, or worse yet, the client and server have the same address. Both of these require address translation and/or application-level gateways for mediation. With IPv6, not only is the address availability solved, but the multiple address per interface offers a solution to multiple network connections, letting business traffic run over a private network while general traffic runs over the Internet.
Without IPv6, we are grasping for solutions. The attention has centered on what engineering gymnastics we can do at the corporate gateways. The tools are multiplying: NAT, pNAT (Port level NAT), DNSlg (DNS level gateway)--some really extreme DNS games to get resolution working through double NATed situations--and dNAT (distributed NAT), where the "NATing" is done at the host, not the gateway. These are but a sampling of the acronyms and configuration nightmares being pushed on businesses. We know that given an architectural deficiency, the engineers can whip up a patch, but is this the best usage of our limited networking resources?
Addressing Immediate Needs Some of the early work that led to IPv6 examined how we might use our 32-bit address space more efficiently. Much of this work considered a 32-bit address large enough, but we were using them inefficiently (remember RIP, which uses 256 addresses for each WAN link?) and routing them ineffectively. This led to a scarcely remembered architecture referred to as "map'n'encap." The premise was to move away from global routing of addresses while maintaining global uniqueness of addresses. The tools for accomplishing this were address translation and packet-tunneling. We have learned through our NAT experiences that address translation is a bad choice--it requires constant fiddling, and every new process that comes along has to work without a reliable host identifier. Packet tunneling is a much cleaner technology because it's transparent to end systems and applications.
A substantial portion of the IPv4 address space is still unallocated (more than 1.6 billion addresses). Much of this address space might be allocated to businesses that need global addresses for interbusiness connectivity, with no expectation that it will ever be routed outside the business' network. Interbusiness data movement would occur via IPSec or RFC2003 tunnels.
Our Internet architects need to sit down and develop a cohesive plan that will sew together the patchwork of technological hacks. Just because a technology can be developed does not mean it is architecturally sound. Sound design principles must be applied before everything grinds to a halt. IPv6 will happen, but business can no longer afford to wait. Reasonable approaches are possible while maintaining our IPv4 network and continuing our efforts to deliver IPv6.
Robert Moskowitz is a senior technical director at the International Computer Security Association and a member of the Internet Architecture Board. Send comments on this column to him at rgm@htt-consult.com.
|