IPv6 - IP Next Generation [2004]

Introduction

At the moment, almost all educational institutes, Governments and businesses have been allocated internet address ranges and could quite happily continue to function under IPv4 for quite some time. However, there is huge growth in new non-computing markets that will soon call for a next generation protocol to accommodate them. These new markets include; nomadic (mobile) devices such as PDAs and mobile telecommunications; entertainment streaming devices; and embedded technologies the likes of environmental and security control. It is now becoming a case of individuals and businesses requiring multiple IP address.

Not only will these new technologies necessitate more addresses, they will also have a wider variety of network connection options. Any new protocol must be efficient in high bandwidth environments, the likes of ATM or 10 Gigabit Ethernet, as well as coping with slower connections, like wireless. If the next generation protocol does not adequately accommodate these requirements, then a number of proprietary alternatives will be developed; which would be a less than satisfactory situation.

The most important aspect when considering a next generation protocol is that it is capable of being implemented alongside IPv4 and coexists with it seamlessly. It would be unreasonable and impossible to roll out a complete replacement protocol quickly, without serious detrimental effect.

Hence; IP Next Generation, also known as IPng or IPv6, has been developed as a successor to IPv4.

So, what happened to IPv5? Late in the 1970’s a protocol called ST (The Internet Stream Protocol) was developed for transmitting data such as voice and video. ST, in its various forms, was a connection oriented protocol (unlike IPv4) that also guaranteed quality of service. It was this particular protocol that became known as IPv5.

History

The need for a next generation protocol was identified back in the late 1980’s. The urgency may have been somewhat overstated at the time, but by the end of 1992 there were seven separate proposals for IPng.  These were (in no particular order):

Mergers and amalgamations between some of the above proposals over the next year or so resulted in a formal list of recommendations being proposed in July 1994.

Some of the more important recommendations included:

The Advantages of IPv6

Expanded Addressing

IPv4 is definitely running out of addresses. Currently, under IPv4, with its 32 bit addressing length, there is a theoretical maximum of approximately four billion addresses. This is obviously greatly reduced due to address range allotment for specific tasking and reserved addresses. IPv6 has a 128 bit addressing length, giving trillions of addresses. This works out to be billions of addresses for every square metre of the Earth’s surface.

IPv6 addresses are assigned to interfaces, not nodes. Each interface can be assigned more than one IP address. There are three types of IPv6 addresses:

1. Unicast addresses identify a single interface and send packets to just that interface.

2. Anycast addresses identify a set of interfaces and can send a packet to a single interface in a set, usually the one with the shortest path. Anycast addresses are allocated from the Unicast range and are syntactically identical.

3. Multicast addresses identify groups of interfaces and can send a packet to all interfaces in a group. An interface can belong to any number of Multicast groups.

The IPv6 address range is divided into the following:

The new address notation for IPv6 comprises of eight groups of four hexadecimal numbers:

8000:0023:4321:ffab:0000:0000:0000:2e5a

Leading zeros within a group may be omitted and groups of all zeros can be replaced with a pair of colons:

8000:23:4321:ffab::2e5a

IPv4 addresses are written as a pair of colons and the old style of dotted decimal:

::192.168.50.25

Simplified Headers

There are now only 8 segments in a standard IPv6 packet, including the version segment. This compares favourably with 13 segments in an Ipv4 packet. As a result, router processing, which translates into throughput, is improved. IPv6 has also dispensed with the Checksum field. This has been made redundant due to the development of Data and Transport layer checksums.

The new header structure:

header

Version: Simply identifies the packet as an IPv6 packet.

Traffic Class (Priority): Basically this identifies packets that can be flow-controlled. A value of 1 to 7 indicates lower priority packets. These packets can be slowed in case of congestion. A value of 8 to 15 would represent that the packet requires real-time processing (video, voice, etc.) and needs a constant rate of throughput.

Flow Label: This allows the labelling of packets that belong to a particular “flow”. The main benefit is that the flow can be identified as requiring special handling; e.g. non-default QoS (Quality of Service).

This is important for processing such flows as multimedia (or “real-time”) streaming data that require consistent throughput.

Payload Length: Used to be called “Total Length” in IPv4. It represents the entire length of the packet, including the length of any extension headers (see below) after the standard IPv6 header.

Next Header: This segment identifies the extension header that immediately follows the IPv6 header. There are six optional extension headers available (see below). This simplifies the header structure of IPv6 over the older IPv4 structure. If there is no optional extension header required, this segment will contain the name of the transport protocol handler.

Hop Limit: Replaces the TTL (Time to Live) segment of IPv4. The Hop Limit decrements by one at each router segment (node).

Source Address: Address of the originator of the packet.

Destination Address: Address of the intended recipient. If a routing header is present, this address may not be the final destination address of the packet.

Better Optional Extension Header Support

IPv6 is a long-term solution that can evolve as required yet still maintain compatibility with IPv4 options. Only relevant options from IPv4 have been retained, however, routers can ignore options that are not meant for them. This significantly speeds up packet forwarding. The option support allows for future additions.

The new Extension Header options are:

HBH      Hop-By-Hop Option
DH        Destination Header Option
RH        Routing Header
FH        Fragment Header
AH        Authentication Header
ESP       Encapsulating Security Payload Header

Hop-by-Hop contains information that must be processed by every node on the packet’s journey – including the source and destination nodes. The Hop-by-Hop option must immediately follow the IPv6 header and is indicated by a 0 in the Next Header field of the IPv6 header. It supports “Jumbograms”, which are datagrams larger than 64Kb. The payload must be larger than 65,535 bytes.

Destination header contains information specifically for the destination node to process. This header is indicated by a value of 60 in the Next Header field of the preceding header.

Routing header contains data that specifies specific nodes which the packet must pass through on its way to a destination. It is similar to the IPv4 Loose Source and record Route option. This header is indicated by a value of 43 in the Next Header field of the preceding header.

Fragment header contains information regarding packets that are larger than the MTU of the path. Under IPv6, fragmentation is performed only by the source node (not by routers, as in IPv4). The source node may decide to divide up a large packet into fragments for reassembly at the destination. This header is indicated by a value of 44 in the Next Header field of the preceding header.

Authentication header is used to provide delivery integrity without confidentiality of IPv6 datagrams. The destination can be sure of the source of the packet. This extension is algorithm independent and is capable of supporting a number of authentication techniques.

Encapsulation Security header provides integrity and confidentiality of payloads utilising encrypted security extensions. It is flexible in that it is independent of specific algorithms.

Transition and Adoption

Initially, IPv6 was scheduled to be rolled out in 1996. It is quite obvious that this has not been the case. It is the advent of NAT (Network Address Translation) that is responsible for postponing the urgency. NAT or CIDR (Classless Inter-Domain Routing) masks larger networks by sharing a single Internet-facing IP address. Businesses, Governments and educational institutes haven’t needed to consider the implementation of a next generation protocol; at least, not as a priority.

At the time of writing, IPv6 has not been adopted in any significant fashion. Nevertheless, organisations such as 6bone have been set up as a test bed for the technology. There exists a need for more pervasive acceptance and support in order to promote IPv6. It is not unfeasible to suggest that there are many businesses unaware of the need and/or existence of a next generation protocol.

However, in March 2004, a group of industry leaders conducted tests on a new IPv6 backbone which stretches across North America from New Hampshire to California. The group comprised of the North American IPv6 Taskforce, the University of New Hampshire Interoperability Lab, Internet2 and the US Department of Defense. The trials, which involved a number of service providers, were conducted over a two week period and tested such areas as routing, security and transition mechanisms.

Real world traffic applications were also introduced to test the traffic priority (flow control) capabilities of IPv6, the Taskforce also ran media streaming, video and normal file transfer tests. Even over wireless connections, the results were encouraging.

Because of the booming Chinese economy (A projected per capita GDP of $US3,000 in 2020) they are also conducting serious IPv6 trials to accommodate the information infrastructure. Their trial, dubbed CNGI (Chinese Next Generation Internet) is strongly backed by their Government. Currently, with 270 million mobile subscribers in China, if only 10% of them subscribed to data services, IPv4 would be unable to cope.

The US military have mandated that, as of 2005, all new network equipment must be IPv6 compliant. Their schedule to adopt IPv6 is 2008. This will be a significant factor in the commercial uptake of IPv6. It was the Pentagon that drove the approval of TCP/IP a number of decades ago. Once they started using it, confidence and acceptance grew rapidly.

Larger corporations will already have similar directives as the US military. They will start to replace equipment with IPv6 compliant components as old equipment fails or as part of their routine upgrade strategy. Because IPv6 is backwardly compatible, this transition will be relatively painless and should minimise overall costs. As IPv6 is somewhat more complex to implement, the only considerable cost will be obtaining trained personnel for administration and management.

Part of the IPng Transition Mechanism is to ensure that the upgrade of any single piece of equipment is not co-dependant on other devices.

Once IPv6 is implemented, it has been identified that one of the main issues will be the upgrade of DNS (Domain Name Service) servers. Hence; part of the March 2003 tests in the US included a wide area network pilot named Moon6 by the North American IPv6 Taskforce. They successfully tested DNS on such platforms as Linux, Microsoft, Sun and other UNIX variants. Most of the other components of a transitional network will work happily with a mixture of IPv6 as well as IPv4 traffic.

One of the benefits of moving to IPv6 is the ability to develop a more structured network. IPv4 currently does not provide enough flexibility to build efficient network hierarchies that can be aggregated.

It is pertinent to mention that IPv6 needs to be successfully introduced before the existing protocol addressing system breaks.

It has been said by many industry pundits that IPv6 may never be fully implemented. To sum it up, Bill Fink, part of NASA’s operational internet team once posted, “…the transition/coexistence period undoubtedly will last at least a decade and may very well continue for the entire lifetime of IPng, until it’s replaced by IPngng and a new transition. I might wish it was otherwise but I fear they are facts of life given the immense installed base.”

Conclusion

From my research, I have concluded that IPv6 was initially developed, in most part, as a response to addressing issues; although there are many other built-in benefits. While IPng was being developed, Network Address Translation (Classless Inter-Domain Routing) became popular, which conserved IP addresses and offered a degree of security for internet-connected networks. The ubiquitous use of IPv4 equipment and the decelerated need for more addresses made it difficult for equipment manufacturers to justify producing IPv6 equipment. This flowed on to prevent network designers from buying and implementing IPv6 networks; a Catch-22 situation.

The transitional period will be quite lengthy. New, compliant equipment will only be introduced through natural attrition; only replacing failed equipment or due to normal upgrades.

A push by technology developers (mainly in Asia) has spurred the US into some serious testing of IPv6 backbone technologies. Once the huge US and Chinese markets adopt the new technology it will ripple out, exponentially, across the rest of the world.

With the US military adopting a firm policy on employing IPv6, this will be a major driving force in its widespread acceptance within the commercial arena. Many service providers will be forced to upgrade or be left behind.

The rapid adoption of mobile technologies will also be a driving force behind the need for more addressing and a better protocol for wireless media technologies.

This will create a circular development form; as IPv6 is implemented, technology development will accelerate and the process of adoption will accelerate.

References:

S. Bradner, A. Mankin, RFC 1752, "The Recommendation for the IP Next Generation Protocol", January 1995.
S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", Internet Draft, March 1995.
R. Hinden, "IP Version 6 Addressing Architecture", Internet Draft, April 1995.
R. M. Hinden, “INET-IPng Paper”, May 1995
S. Thomson, "IPv6 Address Autoconfiguration", Internet Draft, February 1995.

http://www.ietf.org/
http://www.ipv6forum.com/
http://playground.sun.com/pub/ipng/html/ipng-main.html
http://www.6bone.net/
http://weblogs.oreillynet.com/
http://research.microsoft.com/msripv6/msripv6.htm
http://hs247.com/