INTERNET-DRAFT Robert M. Hinden
Sun Microsystems, Inc.
October 1994
IP Next Generation Overview
<draft-hinden-ipng-overview-00.txt>
Abstract
This document presents an overview of the protocol which was
recommended as the Next Generation of IP by the IPng Area Directors
of the Internet Engineering Task Force at the Toronto IETF Meeting
on July 25, 1994 [RECM].
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as ``work in
progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ds.internic.net (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim).
This Internet Draft expires on April 1, 1995.
Distribution of this memo is unlimited.
draft-hinden-ipng-overview-00.txt [Page 1]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
1. Introduction
This document presents an overview of the Next Generation Internet
Protocol which was recommended by the IPng Area Directors of the
Internet Engineering Task Force at the Toronto IETF meeting on July 25,
1994 [RECM]. 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).
This overview is is intended to give the reader an overview of the IPng
protocol. For more detailed information the reader should consult the
documents listed in the reference section.
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 IPv4. 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.
This white paper describes the work of IETF IPng working group. Several
individuals deserve specific recognition. These include Steve Deering,
Paul Francis, Bob Gilligan, Dave Crocker, Ran Atkinson, Jim Bound, Ross
Callon, Bill Fink, Ramesh Govindan, Christian Huitema, Erik Nordmark,
Tony Li, Dave Katz, Yakov Rekhter, Bill Simpson, and Sue Thompson.
2. Key Issues for the Next Generation of IP
There are several key issues that should be considered when reviewing
the design of the next generation internet protocol. Some are very
straightforward. For example the new protocol must be able to support
large global internetworks. Others are less obvious. 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. If anything is to be learned from our experience with
IPv4 it is that the addressing and routing must be capable of handling
reasonable scenarios of future growth. It is important that we have an
understanding of the past growth and where the future growth will come
from.
draft-hinden-ipng-overview-00.txt [Page 2]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
Currently IPv4 serves what could be called the computer market. The
computer market has been the driver of the growth of the Internet. 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.
One measure of this is that the number of networks in current Internet
(40,073 as of 10/4/94) is doubling approximately every 12 months. 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. While the computer market will continue to grow at significant
rates due to expansion into other areas such as schools (elementary
through high school) and small businesses, it is doubtful it will
continue to grow at an exponential rate. 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 new markets
are also likely to happen in parallel with one another. It may turn out
that we will look back on the last ten years of Internet growth as the
time when the Internet was small and only doubling every year. The
challenge for an IPng is to provide a solution which solves todays
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 todays 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. This makes them an ideal candidate for
internetworking technology as they will need a common protocol which can
work over a variety of physical networks. These types of devices will
become consumer devices and will replace the current generation of
cellular phones, pagers, and personal digital assistants. 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,
draft-hinden-ipng-overview-00.txt [Page 3]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
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. This is clearly a consumer market.
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. Cost will be the major factor
in the selection of an appropriate technology.
Another market which could use the next generation IP is device control.
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 potential pay-back is that
networked control of devices will result in cost savings which are
extremely large.
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. They will not wait for an IETF solution. If this
should happen it is probable that because of the size and scale of the
new markets the IETF protocol would be supplanted. If the IETF IPng is
not appropriate for use in these markets, it is also probable that they
will each develop their own protocols, perhaps proprietary. These new
protocols would not interoperate with each other. The opportunity for
the IETF is to select an IPng which has a reasonable chance to be used
in these emerging markets. This would have the very desirable outcome
of creating an immense, interoperable, world-wide information
infrastructure created with open protocols. The alternative is a world
of disjoint networks with protocols controlled by individual vendors.
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
draft-hinden-ipng-overview-00.txt [Page 4]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
hierarchies which can be aggregated. The deployment of Classless
Inter-Domain Routing [CIDR] is extending the life time of IPv4 routing
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. There is no question that an IPng is needed, but only a
question of when.
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 address 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 IPng hosts. There
will be IPng-only hosts, just as there will be IPv4-only hosts. The
capability must exist for IPng-only hosts to communicate with IPv4-only
hosts globally while IPv4 addresses are globally unique.
The deployment strategy for an IPng must be as flexible as possible.
The Internet is too large for any kind of controlled rollout to be
successful. The importance of flexibility in an IPng and the need for
interoperability between IPv4 and IPng was well stated in a message to
the sipp mailing list by Bill Fink, who is responsible for a portion of
NASA's operational internet. In his message he said:
"Being a network manager and thereby representing the interests of a
significant number of users, from my perspective it's safe to say
that the transition and interoperation aspects of any IPng is *the*
key first element, without which any other significant advantages
won't be able to be integrated into the user's network environment.
I also don't think it wise to think of the transition as just a
painful phase we'll have to endure en route to a pure IPng
environment, since 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 with IPngng and a new
transition. I might wish it was otherwise but I fear they are facts
of life given the immense installed base.
"Given this situation, and the reality that it won't be feasible to
coordinate all the infrastructure changes even at the national and
regional levels, it is imperative that the transition capabilities
support the ability to deploy the IPng in the piecemeal fashion...
with no requirement to need to coordinate local changes with other
changes elsewhere in the Internet...
"I realize that support for the transition and coexistence
capabilities may be a major part of the IPng effort and may cause
some headaches for the designers and developers, but I think it is a
duty that can't be shirked and the necessary price that must be paid
draft-hinden-ipng-overview-00.txt [Page 5]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
to provide as seamless an environment as possible to the end user
and his basic network services such as e-mail, ftp, gopher, X-Window
clients, etc...
"The bottom line for me is that we must have interoperability during
the extended transition period for the base IPv4 functionality..."
Another way to think about the requirement for compatibility with IPv4
is to look at other product areas. In the product world, backwards
compatability 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.
Operating system vendors go to great lengths to make sure new versions
of their operating systems are binary compatible with their old version.
For example the labels on most PC or MAC software usually indicate that
they require OS version XX or greater. It would be foolish for
Microsoft come out with a new version of Windows which did not run the
applications which ran on the previous version. Microsoft even provides
the ability for windows applications to run on their new OS NT. This is
an important feature. They understand that it was very important to
make sure that the applications which run on Windows also run on NT.
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. History of the IPng 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
draft-hinden-ipng-overview-00.txt [Page 6]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
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 [RECM], includes the following
elements:
o Current address assignment policies are adequate.
o There is no current need to reclaim underutilized assigned network
numbers.
o There is no current need to renumber major portions of the
Internet.
o CIDR-style assignments of parts of unassigned Class A address space
should be considered.
o "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)" [SIPP]
be adopted as the basis for IPng.
o The documents listed in Appendix C be the foundation of the IPng
effort.
o An IPng Working Group be formed, chaired by Steve Deering and Ross
Callon.
o Robert Hinden be the document editor for the IPng effort.
o An IPng Reviewer be appointed and that Dave Clark be the reviewer.
o An Address Autoconfiguration Working Group be formed, chaired by
Dave Katz and Sue Thomson.
o An IPng Transition Working Group be formed, chaired by Bob Gilligan
and TBA.
o The Transition and Coexistence Including Testing Working Group be
chartered.
o Recommendations about the use of non-IPv6 addresses in IPv6
environments and IPv6 addresses in non-IPv6 environments be
developed.
o The IESG commission a review of all IETF standards documents for
IPng implications.
o The IESG task current IETF working groups to take IPng into
account.
o The IESG charter new working groups where needed to revise old
standards documents.
o Informational RFCs be solicited or developed describing a few
draft-hinden-ipng-overview-00.txt [Page 7]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
specific IPng APIs.
o The IPng Area and Area Directorate continue until main documents
are offered as Proposed Standards in late 1994.
o Support for the Authentication Header be required.
o Support for a specific authentication algorithm be required.
o Support for the Privacy Header be required.
o Support for a specific privacy algorithm be required.
o An "IPng framework for firewalls" be developed.
4. IPng Overview
IPng is a new version of the Internet Protocol, designed as a successor
to IP version 4 [IPV4]. IPng is assigned IP version number 6 and is
formally called IPv6 [IPNG].
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:
o 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 scaleability of multicast routing is improved by adding a
"scope" field to multicast addresses.
A new type of address called a "cluster address" is defined, to
identify topological regions rather than individual nodes. The use
of cluster addresses in the IPng source route allows nodes to
control the path which their traffic flows.
o 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.
o Improved Support for Options
Changes in the way IP header options are encoded allows for more
draft-hinden-ipng-overview-00.txt [Page 8]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
efficient forwarding, less stringent limits on the length of
options, and greater flexibility for introducing new options in the
future.
o 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.
o Authentication and Privacy Capabilities
IPng includes the definition of extensions which provide support
for authentication, data integrity, and (optionally)
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 IPng header and IPng
Options.
4.1 IPng Header Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
draft-hinden-ipng-overview-00.txt [Page 9]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
Version 4-bit Internet Protocol version number = 6.
Flow Label 28-bit field. See IPng Quality of Service
section.
Payload Length 16-bit unsigned integer. Length of payload,
i.e., the rest of the packet following the
IPng header, in octets.
Next Header 8-bit selector. Identifies the type of header
immediately following the IPng header. Uses
the same values as the IPv4 Protocol field
[RFC-1340].
Hop Limit 8-bit unsigned integer. Decremented by 1
by each node that forwards the packet.
The packet is discarded if Hop Limit is
decremented to zero.
Source Address 128 bits. An address of the initial sender of
the packet. See [ADDR] for details.
Destination Address 128 bits. An address of the intended recipient
of the packet (possibly not the ultimate
recipient, if an optional Routing Header is
present).
4.2 IPng Options
IPng includes an improved option mechanism over IPv4. IPng options are
placed in separate headers that are located between the IPng header and
the transport-layer header in a packet. Most IPng option 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, IPng options 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.
draft-hinden-ipng-overview-00.txt [Page 10]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
The IPng option headers which are currently defined are:
Option Function
--------------- ---------------------------------------
Routing Extended Routing (like IPv4 loose source
route).
Fragmentation Fragmentation and Reassembly.
Authentication Integrity and Authentication.
Security Encapsulation Confidentiality.
Hop-by-Hop Option Special options which require hop by hop
processing.
End-to-End Options Optional information to be examined by
the destination node.
4.3 IPng Addressing
IPng addresses are 128-bits long and are identifiers for individual
nodes and sets of nodes. There are three types of IPng addresses.
These are unicast, cluster, and multicast. Unicast addresses identify a
single node. Cluster addresses identify a group of nodes, that share a
common address prefix, such that a packet sent to a cluster address will
be delivered to one member of the group. Multicast addresses identify a
group of nodes, such that a packet sent to a multicast address is
delivered to all of the nodes in the group.
IPng supports addresses which are four times the number of bits as IPv4
addresses (128 vs. 32). This is 4 Billion times 4 Billion (2^^96) times
the size of the IPv4 address space (2^^32). 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).
In more practical terms the assignment and routing of addresses requires
the creation of hierarchies which reduces the efficiency of the usage of
the address space. Christian Huitema performed an analysis in [EFFC]
which evaluated the efficiency of other addressing architectures
(including the French telephone system, USA telephone systems, current
internet using IPv4, and IEEE 802 nodes). He concluded that 128bit IPng
addresses could accommodate between 8x10^^17 to 2x10^^33 nodes assuming
efficiency in the same ranges as the other addressing architectures.
Even his most pessimistic estimate this would provide 1,564 for
addresses per square meter of the surface of the planet Earth. The
optimistic estimate would allow for 3,911,873,538,269,506,102 addresses
draft-hinden-ipng-overview-00.txt [Page 11]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
per square meter of the surface of the planet Earth.
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:
Allocation Prefix Fraction of
(binary) Address Space
------------------------------- -------- -------------
Reserved 0000 0000 1/256
Reserved 0000 0001 1/256
NSAP Allocation 0000 001 1/128
IPX Allocation 0000 010 1/128
Reserved 0000 011 1/128
Reserved 0000 100 1/128
Reserved 0000 101 1/128
Reserved 0000 110 1/128
Reserved 0000 111 1/128
Reserved 0001 1/16
Reserved 001 1/8
Provider-Based Unicast Address 010 1/8
Reserved 011 1/8
Reserved for Geographic Addresses 100 1/8
Reserved 101 1/8
Reserved 110 1/8
Reserved 1110 1/16
Reserved 1111 0 1/32
Reserved 1111 10 1/64
Reserved 1111 110 1/128
Local Use Addresses 1111 1110 1/256
Multicast Addresses 1111 1111 1/256
This allocation supports the direct allocation of provider addresses,
NSAP addresses, IPX addresses, local use addresses, and multicast
addresses. Space is reserved for geographic addresses. The remainder
of the address space is reserved for future use. This can be used for
expansion of existing use (e.g. additional provider addresses, IPX
addresses, etc.) or new uses (e.g. separate locators and EID).
Fifteen percent of the address space is initially allocated. The
remaining 85% is reserved for future use.
4.3.1 Unicast Addresses
There are several forms of unicast address assignment in IPv6. These
are global provider hierarchical unicast addresses, geographical
draft-hinden-ipng-overview-00.txt [Page 12]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
hierarchical addresses, NSAP hierarchical addresses, IPX hierarchical
addresses, local-use addresses, and IP-only host addresses. Additional
addresses types can be defined in the future. The assignment plan for
unicast addresses is described in [ALLO] and [ASSN].
4.3.1.1 Provider Based Unicast Addresses
Provider based unicast addresses are used for global communication.
They are similar in function to IPv4 addresses under CIDR. Their format
is:
| 3 | n bits | m bits | p bits | 125-n-m-p |
+-----+--------------+-----------------+-----------+-----------+
| 010 | PROVIDER ID | SUBSCRIBER ID | SUBNET ID | NODE ID |
+-----+--------------+-----------------+-----------+-----------+
The first 3 bits identify the address as a provider-oriented address. A
provider ID is assigned to internet service providers, which then assign
portions of the address space to subscribers. This usage is similar to
assignment of IP addresses under CIDR. The SUBSCRIBER ID distinguishes
among multiple subscribers attached to the provider identified by the
PROVIDER ID. The SUBNET ID identifies a topologically connected group
of nodes within the subscriber network identified by the subscriber
prefix. The NODE ID identifies a single node among the group of nodes
identified by the subnet prefix.
4.3.1.2 Local-Use Address
A local-use address is a unicast address that has only local routability
scope (within the subnet or within a subscriber network), and may have
local or global uniqueness scope. They are intended for use inside of a
site for "plug and play" local communication and for bootstrapping up to
a single global addresses. Their format is:
| 8 |
| bits | n bits | m bits | p bits |
+--------+---------+---------------+------------------------------+
|11111110| 0 | SUBNET ID | NODE ID |
+--------+---------+---------------+------------------------------+
The NODE ID is an identifier which much be unique in the domain in which
it is being used. In most cases these will use a node's IEEE-802 48bit
address. The SUBNET ID identifies a specific subnet in a site. The
combination of the SUBNET ID and the NODE ID to form a local use address
allows a large private internet to be constructed without any other
address allocation.
Local-use addresses allow organizations that are not (yet) connected to
draft-hinden-ipng-overview-00.txt [Page 13]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
the global Internet to operate with out the need to request an address
prefix from the global Internet address space. Local-use addresses can
be used instead. If the organization later connects to the global
Internet, it can use it's SUBNET ID and NODE ID in combination with a
global prefix (e.g. PROVIDER ID + SUBSCRIBER ID) to create a global
address.
4.3.1.3 IPv4-Only Addresses
IPng unicast addresses are assigned to IPv4-only hosts as part of the
SIT scheme for transition from IPv4 to IPng [SIT]. Such addresses have
the following form:
| 80 bits | 16 | 32 bits |
+--------------------------------------+----+---------------------+
|0000..............................0000|XXXX| IP ADDRESS |
+--------------------------------------+----+---------------------+
The high-order 80bits of the address identify the address as an IPv4
address. Bits 80-95 distinguish between an IPv4 only node and an IPng
node.
4.3.2 Cluster Addresses
Cluster addresses are unicast addresses that are used to reach the
"nearest" one (according to unicast routings notion of nearest) of the
set of boundary routers of a cluster of nodes identified by a common
prefix in the IPng unicast routing hierarchy. These are used to
identify a set of nodes. The cluster address, when used as part of an
route sequence, permits a node to select which of several providers it
wants to carry its traffic. A cluster address can only be used as a
destination address. In this example there would be a cluster address
for each provider. This capability is sometimes called "source selected
policies". Cluster addresses have the general form:
| n bits | 128-n bits |
+---------------------------------+-------------------------------+
| CLUSTER PREFIX |0000000000000000000000000000000|
+---------------------------------+-------------------------------+
4.3.3 Multicast Addresses
A IPng multicast address is an identifier for a group of nodes. A node
may belong to any number of multicast groups. Multicast addresses have
the following format:
draft-hinden-ipng-overview-00.txt [Page 14]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
| 8 | 4 | 4 | 112 bits |
+------ -+----+----+---------------------------------------------+
|11111111|FLGS|SCOP| GROUP ID |
+--------+----+----+---------------------------------------------+
Where:
11111111 at the start of the address identifies the address as
being a multicast address.
+-+-+-+-+
FLGS is a set of 4 flags: |0|0|0|T|
+-+-+-+-+
The high-order 3 flags are reserved, and must be initialized to 0.
T = 0 indicates a permanently-assigned ("well-known") multicast
address, assigned by the global internet numbering authority.
T = 1 indicates a non-permanently-assigned ("transient") multicast
address.
SCOP is a 4-bit multicast scope value used to limit the scope of
the multicast group. The values are:
0 reserved 8 intra-organization scope
1 intra-node scope 9 (unassigned)
2 intra-link scope A (unassigned)
3 (unassigned) B intra-community scope
4 (unassigned) C (unassigned)
5 intra-site scope D (unassigned)
6 (unassigned) E global scope
7 (unassigned) F reserved
GROUP ID identifies the multicast group, either permanent or
transient, within the given scope.
4.4 IPng Routing
Routing in IPng is almost identical to IPv4 routing under CIDR except
that the addresses are 128-bit IPng addresses instead of 32-bit IPv4
addresses. With very straightforward extensions, all of IPv4's routing
algorithms (OSPF, RIP, IDRP, ISIS, etc.) can used to route IPng.
IPng also includes simple routing extensions which support powerful new
routing functionality. These capabilities include:
draft-hinden-ipng-overview-00.txt [Page 15]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
Provider Selection (based on policy, performance, cost, etc.)
Host Mobility (route to current location)
Auto-Readdressing (route to new address)
The new routing functionality is obtained by creating sequences of IPng
addresses using the IPng Routing option. The routing option is used by
a IPng source to list one or more intermediate nodes (or topological
clusters) to be "visited" on the way to a packet's destination. This
function is very similar in function to IPv4's Loose Source and Record
Route option.
In order to make address sequences a general function, IPng hosts are
required to reverse routes in a packet it receives containing address
sequences in order to return the packet to its originator. This
approach is taken to make IPng host implementations from the start
support the handling and reversal of source routes. This is the key for
allowing them to work with hosts which implement the new features such
as provider selection or extended addresses.
Three examples show how the address sequences can be used. In these
examples, address sequences are shown by a list of individual addresses
separated by commas. For example:
SRC, I1, I2, I3, DST
Where the first address is the source address, the last address is the
destination address, and the middle addresses are intermediate
addresses.
For these examples assume that two hosts, H1 and H2 wish to communicate.
Assume that H1 and H2's sites are both connected to providers P1 and P2.
A third wireless provider, PR, is connected to both providers P1 and P2.
----- P1 ------
/ | \
/ | \
H1 PR H2
\ | /
\ | /
----- P2 ------
The simplest case (no use of address sequences) is when H1 wants to send
a packet to H2 containing the addresses:
H1, H2
When H2 replied it would reverse the addresses and construct a packet
draft-hinden-ipng-overview-00.txt [Page 16]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
containing the addresses:
H2, H1
In this example either provider could be used, and H1 and H2 would not
be able to select which provider traffic would be sent to and received
from.
If H1 decides that it wants to enforce a policy that all communication
to/from H2 can only use provider P1, it would construct a packet
containing the address sequence:
H1, P1, H2
This ensures that when H2 replies to H1, it will reverse the route and
the reply it would also travel over P1. The addresses in H2's reply
would look like:
H2, P1, H1
If H1 became mobile and moved to provider PR, it could maintain (not
breaking any transport connections) communication with H2, by sending
packets that contain the address sequence:
H1, PR, P1, H2
This would ensure that when H2 replied it would enforce H1's policy of
exclusive use of provider P1 and send the packet to H1 new location on
provider PR. The reversed address sequence would be:
H2, P1, PR, H1
The address sequence facility of IPng can be used for provider
selection, mobility, and readdressing. It is a simple but powerful
capability.
4.5 IPng Quality-of-Service Capabilities
The Flow Label field in the IPng header may be used by a host to label
those packets for which it requests special handling by IPng routers,
such as non-default quality of service or "real-time" service. This
labeling is important in order to support applications which require
some degree of consistent throughput, delay, and/or jitter. The Flow
Label is a 28-bit field, internally structured into two subfields as
follows:
draft-hinden-ipng-overview-00.txt [Page 17]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TCLASS | FLOW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCLASS 4-bit traffic class
FLOW ID 24-bit flow identifier
A flow is a sequence of packets sent from a particular source to a
particular (unicast or multicast) destination for which the source
desires special handling by the intervening routers. The nature of that
special handling might be conveyed to the routers by a control protocol,
such as a resource reservation protocol, or by information within the
flow's packets themselves, e.g., in a hop-by-hop option.
There may be multiple active flows from a source to a destination, as
well as traffic that is not associated with any flow. A flow is
identified by the combination of a Source Address and a non-zero FLOW
ID. Packets that do not belong to a flow carry a FLOW ID of zero.
A FLOW ID is assigned to a flow by the flow's source node. New FLOW IDs
must be chosen (pseudo-)randomly and uniformly from the range 1 to
FFFFFF hex. The purpose of the random allocation is to make any set of
bits within the FLOW ID suitable for use as a hash key by the routers,
for looking up the special-handling state associated with the flow. A
FLOW ID must not be re-used by a source for a new flow while any state
associated with the previous usage still exists in any router.
The TCLASS subfield provides a means separate from the FLOW ID for a
source to identify the desired delivery priority of its packets,
relative to other packets from the same source. The TCLASS values are
divided into two ranges: values 0 through 7 are used to label flow-
controlled packets, e.g., packets that belong to a TCP connection, and
values 8 through 15 are used to label non-flow-controlled packets, e.g.,
"real-time" packets being sent without any flow-control feedback from
the receivers.
For flow-controlled traffic, the following TCLASS values are recommended
for particular application categories:
0 - uncharacterized traffic
1 - "filler" traffic (e.g., netnews)
2 - unattended data transfer (e.g., email)
3 - (reserved)
4 - attended bulk transfer (e.g., FTP, NFS)
5 - (reserved)
6 - interactive traffic (e.g., telnet, X)
7 - internet control traffic (e.g., routing protocols, SNMP)
draft-hinden-ipng-overview-00.txt [Page 18]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
For non-flow-controlled traffic, the lowest TCLASS value (8) should be
used for those packets that the sender is most willing to have discarded
under conditions of congestion (e.g., high-fidelity video traffic), and
the highest value (15) should be used for those packets that the sender
is least willing to have discarded (e.g., low-fidelity audio traffic).
There is no relative ordering implied between the flow-controlled
classes and the non-flow-controlled classes.
4.6 IPng Security
The current Internet has a number of security problems and lacks
effective privacy and authentication mechanisms below the application
layer. IPng remedies these shortcomings by having two integrated
options that provide security services. These two options may be used
singly or together to provide differing levels of security to different
users. This is very important because different user communities have
different security needs.
The first mechanism, called the "IPng Authentication Header", is an
option which provides authentication and integrity (without
confidentiality) to IPng datagrams. While the option is algorithm-
independent and will support many different authentication techniques,
the use of keyed MD5 is proposed to help ensure interoperability within
the worldwide Internet. This can be used to eliminate a significant
class of network attacks, including host masquerading attacks. The use
of the IPng Authentication Header is particularly important when source
routing is used with IPng because of the known risks in IP source
routing. Its placement at the internet layer can help provide host
origin authentication to those upper layer protocols and services that
currently lack meaningful protections. This mechanism should be
exportable by vendors in the United States and other countries with
similar export restrictions because it only provides authentication and
integrity, and specifically does not provide confidentiality. The
exportability of the IPng Authentication Header encourages its
widespread implementation and use.
The second security option provided with IPng is the "IPng Encapsulating
Security Header". This mechanism provides integrity and confidentiality
to IPng datagrams. It is simpler than some similar security protocols
(e.g. SP3D, ISO NLSP) but remains flexible and algorithm-independent.
To achieve interoperability within the global Internet, the use of DES
CBC is being used as the standard algorithm for use with the IPng
Encapsulating Security Header.
draft-hinden-ipng-overview-00.txt [Page 19]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
5. IPng Transition Mechanisms
The key transition objective is to allow IPv6 and IPv4 hosts to
interoperate. A second objective is to allow IPv6 hosts and routers to
be deployed in the Internet in a highly diffuse and incremental fashion,
with few interdependencies. A third objective is that the transition
should be as easy as possible for end-users, system administrators, and
network operators to understand and carry out.
The Simple IP version Six Transition (SIT) is a set of protocol
mechanisms implemented in hosts and routers, along with some operational
guidelines for addressing and deployment, designed to make transitioning
the Internet to IPv6 work with as little disruption as possible [SIT].
SIT provides a number of features, including:
- Incremental upgrade and deployment. Individual IPv4 hosts and
routers may be upgraded to IPv6 one at a time without requiring any
other hosts or routers to be upgraded at the same time. New IPv6
hosts and routers can be installed one by one.
- Minimal upgrade dependencies. The only prerequisite to upgrading
hosts to IPv6 is that the DNS server must first be upgraded to
handle IPv6 address records. There are no pre-requisites to
upgrading routers.
- Easy Addressing. When existing installed IPv4 hosts or routers are
upgraded to IPv6, they may continue to use their existing address.
They do not need to be assigned new addresses. Administrators do
not need to draft new addressing plans.
- Low start-up costs. Little or no preparation work is needed in
order to upgrade existing IPv4 systems to IPv6, or to deploy new
IPv6 systems.
The mechanisms employed by SIT include:
- An IPv6 addressing structure that embeds IPv4 addresses within IPv6
addresses, and encodes other information used by the transition
mechanisms.
- A model of deployment where all hosts and routers upgraded to IPv6
in the early transition phase are "dual" capable (i.e. implement
complete IPv4 and IPv6 protocol stacks).
- The technique of encapsulating IPv6 packets within IPv4 headers to
carry them over segments of the end-to-end path where the routers
have not yet been upgraded to IPv6.
draft-hinden-ipng-overview-00.txt [Page 20]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
- The header translation technique to allow the eventual introduction
of routing topologies that route only IPv6 traffic, and the
deployment of hosts that support only IPv6. Use of this technique
is optional, and would be used in the later phase of transition if
it is used at all.
SIT ensures that IPv6 hosts can interoperate with IPv4 hosts anywhere in
the Internet up until the time when IPv4 addresses run out, and allows
IPv6 and IPv4 hosts within a limited scope to interoperate indefinitely
after that. This feature protects the huge investment users have made
in IPv4. SIT ensures that IPv6 does not render IPv4 obsolete. Hosts
that need only a limited connectivity range (e.g. printers) need never
be upgraded to IPv6.
The incremental upgrade features of SIT allow the host and router
vendors to integrate IPv6 into their product lines at their own pace,
and allows the end users and network operators to deploy IPng on their
own schedules.
6. Why IPng?
There are a number of reasons why IPng is appropriate for the next
generation of the Internet Protocol. It solves the Internet scaling
problem, provides a flexible transition mechanism for the current
Internet, and was designed to meet the needs of new markets such as
nomadic personal computing devices, networked entertainment, and device
control. It does this in a evolutionary way which reduces the risk of
architectural problems.
Ease of transition is a key point in the design of IPng. It is not
something was was added in at the end. IPng is designed to interoperate
with IPv4. Specific mechanisms (embedded IPv4 addresses, pseudo-
checksum rules etc.) were built into IPng to support transition and
compatability with IPv4. It was designed to permit a gradual and
piecemeal deployment with a minimum of dependencies.
IPng supports large hierarchical addresses which will allow the Internet
to continue to grow and provide new routing capabilities not built into
IPv4. It has cluster addresses which can be used for policy route
selection and has scoped multicast addresses which provide improved
scaleability over IPv4 multicast. It also has local use addresses which
provide the ability for "plug and play" installation.
The address structure of IPng was also designed to support carrying the
addresses of other internet protocol suites. Space was allocated in the
addressing plan for IPX and NSAP addresses. This was done to facilitate
migration of these internet protocols to IPng.
draft-hinden-ipng-overview-00.txt [Page 21]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
IPng is designed to have performance better than IPv4 and still work
well in low bandwidth applications like wireless. Its headers are less
expensive to process than IPv4 and its 128-bit addresses are chosen to
be well matched to the new generation of 64bit processors. Its compact
header minimizes bandwidth overhead which makes it appropriate for
wireless use.
IPng provides a platform for new Internet functionality. This includes
support for real-time flows, provider selection, host mobility, end-to-
end security, auto-configuration, and auto-reconfiguration.
In summary, IPng is a new version of IP. It can be installed as a
normal software upgrade in internet devices. It is interoperable with
the current IPv4. 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.
7. Where to Get Additional Information
The documentation listed in the reference sections can be found in one
of the IETF internet draft directories or in the archive site for the
IPng working group. This is located at:
ftp.parc.xerox.com in the /pub/ipng directory.
In addition other material relating to IPng (such as postscript versions
of presentations on IPng) can also be found in the IPng working group
archive.
To join the IPng working group, send an electronic mail message to:
majordomo@sunroof.eng.sun.com
with
subscribe ipng
in the body portion of the message.
An archive of mail sent to this mailing list can be found in the IETF
directories at cnri.reston.va.us.
draft-hinden-ipng-overview-00.txt [Page 22]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
8. Information about the Author
Robert M. Hinden TEL: (415) 336-2082
Manager, Internet Engineering FAX: (415) 336-6016
Sun Microsystems, Inc. EMAIL: hinden@eng.sun.com
MS MTV5-44
2550 Garcia Ave.
Mt. View, CA 94303
USA
draft-hinden-ipng-overview-00.txt [Page 23]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
8. References
[ADDR] R. Hinden, Editor, "IP Next Generation Addressing Architecture",
Internet Draft, draft-hinden-ipng-addr-00.txt, October 1994.
[ASSN] T.Li, P. Lothberg, Y. Rekhter, "IPv6 Provider Unicast Address
Assignment", Internet Draft, In Preparation.
[ALLO] Y. Rekhter, T. Li, "An Architecture for IPv6 Unicast Address
Allocation", Internet Draft, draft-rekhter-ipng-arch-IPv6-addr-
01.txt, October 1994.
[AUTH] R. Atkinson, "IPv6 Authentication Header", Internet Draft,
draft-ietf-sipp-ap-04.txt, August 1994.
[AUTO] D. Katz, S. Thomson, "Automatic Host Address Assignment in
IPv6", Internet Draft, In Perpetration.
[CIDR] V. Fuller, et al, "Supernetting: an Address Assignment and
Aggregation Strategy", RFC 1338.
[COMP] W. Simpson, "IPv6 Header Compression", Internet Draft, draft-
simpson-ipv6-hc-00.txt, September 1994.
[DISC] W. Simpson, "IPv6 Neighbor Discovery -- Processing", Internet
Draft, draft-simpson-ipv6-discov-process-00.txt, October 1994.
[DIS2] W. Simpson, "IPv6 Neighbor Discovery -- ICMP Message Formats",
Internet Draft, draft-simpson-ipv6-discov-formats-00.txt,
September 1994.
[DHCP] S. Thomson, "IPng Extensions to BOOTP/DHCP", Internet Draft, In
Preparation.
[DNS] S. Thomson, C. Huitema, "DNS Extensions to support IP version
6", Internet Draft, <draft-thomson-ipng-dns-00.txt>, October
1994.
[EFFC] C. Huitema, "The H Ratio for Address Assignment Efficiency"
Internet Draft, In Preparation.
[ICMP] S. Deering, A. Conta, "ICMP and IGMP for the Internet Protocol
Version 6 (IPv6)", Internet Draft, In Preparation, October 1994.
[IPNG] R. Hinden, Editor, "Internet Protocol, Version 6 (IPv6)
Specification", Internet Draft, draft-ietf-ipng-ipv6-spec-
01.txt, October 1994.
draft-hinden-ipng-overview-00.txt [Page 24]
INTERNET-DRAFT IP Next Generation Overview Overview 1994
[IPV4] J. Postel, "Internet Protocol", RFC-791, September, 1981.
[RECM] S. Bradner, A. Mankin, "The Recommendation for the IP Next
Generation Protocol", Internet Draft, <draft-ipng-
recommendation-00.txt> September 1994.
[SARC] R. Atkinson, "IPv6 Security Architecture" Internet Draft,
draft-ietf-sipp-sa-03.txt, September 1994.
[SECR] R. Atkinson, "IPng Encapsulating Security Payload (ESP)",
Internet Draft, In Perpetration.
[SIPP] S. Deering, "Simple Internet Protocol Plus (SIPP) Specification
(128-bit address version)", Internet Draft, draft-ietf-sipp-
spec-01.txt, July 1994.
[SIT] R. Gilligan, "Simple IPv6 Transition (SIT) Overview, Internet
Draft, In Perpetration.
draft-hinden-ipng-overview-00.txt [Page 25]