IP Addressing And Understanding IPv6 Concepts

1.  Introduction
2.  Key Issues
3.  History of the IPng Effort
4.  IPng Overview
5.  IPng Header Format
6.  IPng Extensions
7.  IPng Addressing

IPv6 or IPng (IP Next generation):
IPv6 is short for "Internet Protocol Version 6". IPv6 is the "next generation" protocol designed by the IETF (The Internet Engineering Task Force) to replace the current version Internet Protocol, IP Version 4 ("IPv4"). The IP v 6 specifications are in rfc2460.

Most of today's Internet uses IPv4, which is now nearly twenty years old. IPv4 has been remarkably resilient in spite of its age, but it is beginning to have problems. Most importantly, there is a growing shortage of IPv4 addresses, which are needed by all new machines added to the Internet.

IPv6 fixes a number of problems in IPv4, such as the limited number of available IPv4 addresses. It also adds many improvements to IPv4 in areas such as routing and network auto configuration. IPv6 is expected to gradually replace IPv4, with the two coexisting for a number of years during a transition period.

1. Introduction

IPng was recommended by the IPng Area Directors of the Internet Engineering Task Force at the Toronto IETF meeting on July 25, 1994, and documented in RFC 1752, "The Recommendation for the IP Next Generation Protocol" [1]. The recommendation was approved by the Internet Engineering Steering Group on November 17, 1994 and made a Proposed Standard.

The formal name of this protocol is IPv6 (where the "6" refers to it being assigned version number 6). The current version of the Internet Protocol is version 4 (referred to as IPv4).

IPng is a new version of IP which is designed to be an evolutionary step from IPv4. It is a natural increment to IPv4. It can be installed as a normal software upgrade in Internet devices and is interoperable with the current lPv4. Its deployment strategy was designed to not have any "flag" days. IPng is designed to run well on high performance networks (e.g., ATM) and at the same time is still efficient for low bandwidth networks (e.g., wireless). In addition, it provides a platform for new Internet functionality that will be required in the near future.

2.0 Key Issues

There are several key issues that should be considered when reviewing the design of the next generation internet protocol.

For example the new protocol must be able to support large global internetworks. There must be a clear way to transition the current large installed base of IPv4 systems. It doesn't matter how good a new protocol is if there isn't a practical way to transition the current operational systems running IPv4 to the new protocol.

2.1 Growth
Growth is the basic issue which caused there to be a need for a next generation IP. It is that the addressing and routing must be capable of handling reasonable scenarios of future growth. Currently IPv4 serves what could be called the computer market. It comprises the current Internet and countless other smaller internets which are not connected to the Internet. Its focus is to connect computers together in the large business, government, and university education markets. This market has been growing at an exponential rate. The computers which are used at the endpoints of internet communications range from PC's to Supercomputers. Most are attached to Local Area Networks (LANs) and the vast majority are not mobile.

The next phase of growth will probably not be driven by the computer market. What is likely to happen is that other kinds of markets will develop. These markets will fall into several areas. They all have the characteristic that they are extremely large. They also bring with them a new set of requirements which were not as evident in the early stages of IPv4 deployment.

The challenge for an IPng is to provide a solution which solves today's problems and is attractive in these emerging markets.

Nomadic personal computing devices seem certain to become ubiquitous as their prices drop and their capabilities increase. A key capability is that they will be networked. Unlike the majority of today's networked computers they will support a variety of types of network attachments. When disconnected they will use RF wireless networks, when used in networked facilities they will use infrared attachment, and when docked they will use physical wires. In addition to the obvious requirement of an internet protocol which can support large scale routing and addressing, they will require an internet protocol which imposes a low overhead and supports auto configuration and mobility as a basic element. The nature of nomadic computing requires an internet protocol to have built in authentication and confidentiality. It also goes without saying that these devices will need to communicate with the current generation of computers. The requirement for low overhead comes from the wireless media.

Unlike LAN's which will be very high speed, the wireless media will be several orders of magnitude slower due to constraints on available frequencies, spectrum allocation, error rates, and power consumption.

Another market is networked entertainment. The first signs of this emerging market are the proposals being discussed for 500 channels of television, video on demand, etc. The possibility is that every television set will become an Internet host. As the world of digital high definition television approaches, the differences between a computer and a television will diminish. As in the previous market, this market will require an Internet protocol which supports large scale routing and addressing, and auto configuration. This market also requires a protocol suite which imposes the minimum overhead to get the job done.

Another market which could use the next generation IP is device control for example, smart home. This consists of the control of everyday devices such as lighting equipment, heating and cooling equipment, motors, and other types of equipment which are currently controlled via analog switches and in aggregate consume considerable amounts of electrical power. The size of this market is enormous and requires solutions which are simple, robust, easy to use, and very low cost.

The challenge the IETF faced in the selection of an IPng is to pick a protocol which meets today's requirements and also matches the requirements of these emerging markets. These markets will happen with or without an IETF IPng. If the IETF IPng is a good match for these new markets it is likely to be used. If not, these markets will develop something else.

2.2 Transition
At some point in the next three to seven years the Internet will require a deployed new version of the Internet protocol. Two factors are driving this: routing and addressing. Global internet routing based on the on 32-bit addresses of IPv4 is becoming increasingly strained. IPv4 address do not provide enough flexibility to construct efficient hierarchies which can be aggregated. The deployment of Classless Inter- Domain Routing [2] is extending the life time of IPv4 routing by a number of years, the effort to manage the routing will continue to increase. Even if the IPv4 routing can be scaled to support a full IPv4 Internet, the Internet will eventually run out of network numbers.

The challenge for an IPng is for its transition to be complete before IPv4 routing and addressing break. The transition will be much easier if IPv4 addresses are still globally unique. The two transition requirements which are the most important are flexibility of deployment and the ability for IPv4 hosts to communicate with lPng hosts. There will be IPng- only hosts, just as there will be IPv4-only hosts. The capability must exist for lPng-only hosts to communicate with IPv4-only hosts globally while IPv4 addresses are globally unique.

Another way to think about the requirement for compatibility with IPv4 is to look at other product areas. In the product world, backwards compatibility is very important. Vendors who do not provide backward compatibility for their customers usually find they do not have many customers left. For example, chip makers put considerable effort into making sure that new versions of their processor always run all of the software that ran on the previous model. It is unlikely that Intel would develop a new processor in the X86 family that did not run DOS and the tens of thousands of applications which run on the current versions of X86's.

The same requirement is also true for IPng. The Internet has a large installed base. Features need to be designed into an IPng to make the transition as easy as possible. As with processors and operating systems, it must be backwards compatible with IPv4. Other protocols have tried to replace TCP/IP, for example XTP and OSI. One element in their failure to reach widespread acceptance was that neither had any transition strategy other than running in parallel (sometimes called dual stack). New features alone are not adequate to motivate users to deploy new protocols. IPng must have a great transition strategy and new features.

3.0 History of the lPng Effort

The IPng protocol represents the evolution of many different IETF proposals and working groups focused on developing an IPng.

It represents over three years of effort focused on this topic. A brief history follows:

By the Winter of 1992 the Internet community had developed four separate proposals for IPng. These were "CNAT", "IP Encaps", "Nimrod", and "Simple CLNP". By December 1992 three more proposals followed; "The P Internet Protocol" (PIP), "The Simple Internet Protocol" (SIP) and "TP/IX". In the Spring of 1992 the "Simple CLNP" evolved into "TCP and UDP with Bigger Addresses" (TUBA) and "IP Encaps" evolved into "IP Address Encapsulation" (IPAE).

By the fall of 1993, IPAE merged with SIP while still maintaining the name SIP. This group later merged with PIP and the resulting working group called themselves "Simple Internet Protocol Plus" (SIPP). At about the same time the TP/IX Working Group changed its name to "Common Architecture for the Internet" (CATNIP).

The IPng area directors made a recommendation for an IPng in July of 1994. This recommendation, from [1], includes the following elements:
•    Current address assignment policies are adequate.
•    There is no current need to reclaim underutilized assigned network numbers.
•    There is no current need to renumber major portions of the Internet.
•    CIDR-style assignments of parts of unassigned Class A address space should beconsidered.
•    "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)" [3] be adopted as the basis for IPng.
•    Other related documents also are used as the foundation of the IPng effort.
•    An IPng Working Group be formed, chaired by Steve Deering and Ross Callon.
•    Robert Hinden be the document editor for the IPng effort.
•    An IPng Reviewer be appointed and that Dave Clark be the reviewer.
•    An Address Autoconfiguration Working Group be formed, chaired by Dave Katz and Sue Thomson.
•    An IPng Transition Working Group be formed, chaired by Bob Gilligan and TBA.
•    The Transition and Coexistence Including Testing Working Group be chartered.
•    Recommendations about the use of non-IPv6 addresses in IPv6 environments and IPv6 addresses in non-IPv6 environments be developed.
•    The IESG commission a review of all IETF standards documents for IPng implications.
•    The IESG task current IETF working groups to take IPng into account.
•    The IESG charter new working groups where needed to revise old standards documents.
•    Informational RFCs be solicited or developed describing a few specific IPng APIs.
•    The IPng Area and Area Directorate continue until main documents are offered as Proposed Standards in late 1994.
•    Support for the Authentication Header be required.
•    Support for a specific authentication algorithm be required.
•    Support for the Privacy Header be required.
•    Support for a specific privacy algorithm be required.
•    An "IPng framework for firewalls" be developed.

4.0 IPng Overview

IPng is a new version of the Internet Protocol, designed as a successor to IP version 4 [4]. IPng is assigned IP version number 6 and is formally called IPv6 [5].

IPng was designed to take an evolutionary step from IPv4. It was not a design goal to take a radical step away from IPv4.

Functions which work in IPv4 were kept in IPng. Functions which didn't work were removed. The changes from IPv4 to IPng fall primarily into the following categories:
•    Expanded Routing and Addressing Capabilities IPng increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy and a much greater number of addressable nodes, and simpler auto-configuration of addresses.
The scalability of multicast routing is improved by adding a "scope" field to multicast addresses.
•    A new type of address called a anycast address is defined, to identify sets of nodes where a packet sent to an
anycast address is delivered to one of the nodes. The use of anycast addresses in the IPng source route allows nodes to control the path which their traffic flows.
•    Header Format Simplification Some IPv4 header fields have been dropped or made optional, to reduce the common¬case processing cost of packet handling and to keep the bandwidth cost of the IPng header as low as possible despite the increased size of the addresses. Even though the IPng addresses are four time longer than the IPv4 addresses, the IPng header is only twice the size of the IPv4 header.
•    Improved Support for Options Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future.
•    Quality-of-Service Capabilities A new capability is added to enable the labeling of packets belonging to particular traffic "flows" for which the sender requests special handling, such as non-default quality of service or "real- time" service.
•    Authentication and Privacy Capabilities IPng includes the definition of extensions which provide support for authentication, data integrity, and confidentiality.

This is included as a basic element of IPng and will be included in all implementations.
The IPng protocol consists of two parts, the basic lPng header and lPng extension headers. 5.0

5.0 lPng Header Format

6.0 lPng Extensions

IPng includes an improved option mechanism over IPv4. IPng options are placed in separate extension headers that are located between the IPng header and the transport-layer header in a packet. Most IPng extension headers are not examined or processed by any router along a packet's delivery path until it arrives at its final destination. This facilitates a major improvement in router performance for packets containing options. In IPv4 the presence of any options requires the router to examine all options.

The other improvement is that unlike IPv4 options, IPng extension headers can be of arbitrary length and the total amount of options carried in a packet is not limited to 40 bytes. This feature plus the manner in which they are processed, permits IPng options to be used for functions which were not practical in IPv4. A good example of this is the IPng Authentication and Security Encapsulation options.

In order to improve the performance when handling subsequent option headers and the transport protocol which follows, IPng options are always an integer multiple of 8 octets long, in order to retain this alignment for subsequent headers.
The IPng extension headers which are currently defined are:

7.0 IPng Addressing

IPng addresses are 128-bits long and are identifiers for individual interfaces and sets of interfaces. IPng Addresses of all types are assigned to interfaces, not nodes. Since each interface belongs to a single node, any of that node's interfaces' unicast addresses may be used as an identifier for the node. A single interface may be assigned multiple IPv6 addresses of any type.

There are three types of IPng addresses. These are unicast, anycast, and multicast. Unicast addresses identify a single interface. Anycast addresses identify a set of interfaces such that a packet sent to a anycast address will be delivered to one member of the set. Multicast addresses identify a group of interfaces, such that a packet sent to a multicast address is delivered to all of the interfaces in the group. There are no broadcast addresses in IM, their function being superseded by multicast addresses.

IPng supports addresses which are four times the number of bits as IPv4 addresses (128 vs. 32). This is 4 Billion times 4 Billion times 4 Billion (2128) times the size of the IPv4 address space (232). This works out to be:

340,282,366,920,938,463,463,374,607,431,768,211,456

This is an extremely large address space. In a theoretical sense this is approximately 665,570,793,348,866,943,898,599 addresses per square meter of the surface of the planet Earth (assuming the earth surface is 511,263,971,197,990 square meters).

The specific type of IPng address is indicated by the leading bits in the address. The variable¬length field comprising these leading bits is called the Format Prefix (FP). The initial allocation of these prefixes is as follows: