IPv6 offers data packet security and quality of service – but so does IPv4

Opinion

IPv6 offers data packet security and quality of service – but so does IPv4

One frequently claimed benefit of IPv6 is that it is inherently superior to IPv4 in two areas: quality of service and security. Although true enough when comparing the basic IPv4 protocol to IPv6, the picture this paints is very far from complete.

In its original design, IPv4 undoubtedly lacked any sort of inherent security or encryption features for that matter, it had only the crudest quality of service abilities.

And with TCP/IP's market penetration growing so tremendously in the 1990s, the need for such capabilities rapidly became obvious.

The developers of the IPv6 protocol suite decided to make packet-level encryption and quality of service markings the core elements of their network layer protocol. From this point of view, they were completely successful: IPv6 is certainly superior to IPv4.

If the available IPv4 address space had been quickly exhausted in the 1990s and there had been a resulting speedy move to IPv6, the story would have ended there. But it did not because the address conservation enabled by Network Address Translation (Nat) and Classless Inter-Domain Routing (CIDR) acted to lengthen IPv4's lifetime considerably.

Users were unwilling to wait for IPv6 in order to have IP, quality of service and packet-level encryption. The result has been the wide deployment of IP security (IPSec) and differentiated service for IPv4.

IPSec works in a variety of ways, either by encrypting a packet's header and payload, or by encrypting only the payload. IPSec can then simply transmit those encrypted packets to their destination or encapsulate them in User Datagram Protocol (UDP) for transmission.

IPv4 and IPv6 IPSec are functionally identical. Although there are some slight differences in implementation, the actual authentication and encryption functionality is the same - it is even specified in the same Internet Engineering Task Force request for comments document, RFC 2401.

Although the new header format in IPv6 may make IPSec application development a bit easier (and that is an assumption rather than a known fact), this is hardly an issue that enterprise network managers should concern themselves with. The point is that reliable IPSec clients already exist and are in wide deployment.

Quality of service is handled in a similar manner. Originally, IPv4 quality of service was defined through the use of the type of service and IP precedence bits in the IP header. These bits went largely unused until they were redefined as differentiated service bits, with all eight bits available for quality of service definition instead of being split into two fields.

Differentiated service is now implemented in a greater number of IPv4 networks than in the past because of the increasing penetration of voice over IP (VoIP) and other quality of service-sensitive technologies. In IPv6, a similar IP header field, known as traffic class, is slated to be used in an identical manner to the current differentiated service bits.

Although some IPv6 proponents will note the existence of a new flow label field in the IPv6 header, this field should have little, if any, impact on quality of service functionality. At present, the flow field's utility is unclear and may be utilised on a supplier-by-supplier basis or not used at all.

To sum up the quality of service and security issue: IPv6 will have inherent functionality that was not originally present in IPv4, but current implementations of IPv4 do have these capabilities. In other words, IPv6 is a match for IPv4 rather than an improvement on it.

Another commonly touted advantage of IPv6 is the ability of IPv6 hosts to configure their own IP addresses automatically without the need for a Dynamic Host Configuration Protocol (DHCP) server. Through a process known as IPv6 neighbour discovery, hosts and routers can discover each other on a local area network and exchange information.

In the case of address auto-configuration, the router will inform connected hosts of its IPv6 network address, representing the first 64 bits of the IPv6 address. The hosts, in turn, know the last 64 bits of the address from consulting the hard-wired media access control addresses of their Ethernet adapters. The result is an "automatically assigned" address without the need for a DHCP server.

Unfortunately, there are a few holes in this picture, especially for enterprises.

With IPv6 address auto-assignment, where is the assignment of DNS (Domain Name System) servers and the interaction that can generate DNS update messages to allow hosts to register themselves automatically?

These functions are necessary in a typical large enterprise active directory environment and strongly recommended in other architectures. In fact, proposals exist to extend auto-assignment to include these types of values.

And that leads to an interesting intersection: what is the functional difference between this "auto-assignment" functionality and a DHCP server running on a router?

In fact, the only differences have to do with the mechanisms used to transmit the information from server to host - functionally, they must be equivalent.

Given the time-tested DHCP standard plus the trend to have DNS/DHCP functionality on dedicated IP address management appliances rather than routers, it seems unlikely that IPv6 address auto-configuration will ever gain significant take-up.

For those who choose to move on to IPv6, DHCPv6 offers the same functionality as the IPv4 version while maintaining the same basic mechanisms and largely the same code base.

This article is taken from a paper published by analyst firm Burton Group on the future of IPv6

More information:

www.ipv6.org

The slow march of IPv6

Skill up for IPv6

Comment on this article: computer.weekly@rbi.co.uk

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in January 2007

 

COMMENTS powered by Disqus  //  Commenting policy