IPv6 or IPng (IP
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
autoconfiguration. IPv6 is expected
to gradually replace IPv4, with the
two coexisting for a number of years
during a transition period.
2 Key Issues
3 History of the
4 IPng Overview
5 IPng Header Format
6 IPng Extensions
7 IPng Addressing
8 IPng Routing
9 IPng Quality-of-Service
10. IPng Security
11. IPng Transition
12. Why IPng?
This paper presents an overview of the
Next Generation Internet Protocol (IPng).
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"
. 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). This overview
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 paper describes the work of
IETF IPng working group. Several individuals
deserve specific recognition. These
include 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.0 Key Issues
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
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
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, spectrum
allocation, error rates, and power
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 he job done. Cost will be the
major factor in the selection of an
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 hierarchies which
can be aggregated. The deployment of
Classless Inter- Domain Routing 
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. There is no question
that an IPng is needed, but only a question
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 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 roll out 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 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 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
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
3.0 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
By the Winter of
1992 the Internet community had developed
four separate proposals for IPng.
These were "CNAT", "IP
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"
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"
The IPng area directors made a recommendation
for an IPng in July of 1994. This
recommendation, from , includes
the following elements:
- Current address assignment policies
- 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 be considered.
- "Simple Internet Protocol
Plus (SIPP) Spec. (128 bit ver)"
 be adopted as the basis for
- The documents listed in Appendix
C be the foundation of the IPng
- An IPng Working Group be formed,
chaired by Steve Deering and Ross
- 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
- The Transition and Coexistence
Including Testing Working Group
- Recommendations about the use
of non-IPv6 addresses in IPv6 environments
and IPv6 addresses in non-IPv6 environments
- The IESG commission a review of
all IETF standards documents for
- The IESG task current IETF working
groups to take IPng into account.
- The IESG charter new working groups
where needed to revise old standards
- Informational RFCs be solicited
or developed describing a few specific
- The IPng Area and Area Directorate
continue until main documents are
offered as Proposed Standards in
- Support for the Authentication
Header be required.
- Support for a specific authentication
algorithm be required.
- Support for the Privacy Header
- Support for a specific privacy
algorithm be required.
- An "IPng framework for firewalls"
4.0 IPng Overview
IPng is a new version of the Internet
Protocol, designed as a successor to
IP version 4 . IPng is assigned IP
version number 6 and is formally called
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
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
- 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
- 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
- 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"
- 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 IPng header and IPng
5.0 IPng Header Format
4-bit Internet Protocol version
number = 6.
4-bit Priority value. See IPng Priority
24-bit field. See IPng Quality of
16-bit unsigned integer. Length
of payload, i.e., the rest of the
packet following the IPng header,
8-bit selector. Identifies
the type of header immediately following
the IPng header. Uses the same values
as the IPv4 Protocol field .
8-bit unsigned integer.
Decremented by 1 by each node that
forwards the packet. The packet
is discarded if Hop Limit is decremented
128 bits. The address of
the initial sender of the packet.
See  for details.
128 bits. The address of
the intended recipient of the packet
(possibly not the ultimate recipient,
if an optional Routing Header is
6.0 IPng 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
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
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
The IPng extension headers which
are currently defined are:
7.0 IPng Addressing
- Routing Extended
Routing (like IPv4 loose source
- Fragmentation Fragmentation
- Authentication Integrity
and Authentication. Security
- Encapsulation Confidentiality.
- Hop-by-Hop Option Special
options which require hop by hop
- Destination Options Optional
information to be examined by the
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.
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
IPv6, 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
(2^^96) times the size of the IPv4
address space (2^^32). This works
out to be:
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
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  which
evaluated the efficiency of other
addressing architecture's (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 architecture's.
Even his most pessimistic estimate
this would provide 1,564 addresses
for each square meter of the surface
of the planet Earth. The optimistic
estimate would allow for 3,911,873,538,269,506,102
addresses for each 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
Allocation Prefix(binary) Fraction of Address Space
Reserved 0000 0000 1/256
Unassigned 0000 0001 1/256
Reserved for NSAP Allocation 0000 001 1/128
Reserved for IPX Allocation 0000 010 1/128
Unassigned 0000 011 1/128
Unassigned 0000 1 1/32
Unassigned 0001 1/16
Unassigned 001 1/8
Provider-Based Unicast Address 010 1/8
Unassigned 011 1/8
Unicast Addresses 100 1/8
Unassigned 101 1/8
Unassigned 110 1/8
Unassigned 1110 1/16
Unassigned 1111 0 1/32
Unassigned 1111 10 1/64
Unassigned 1111 110 1/128
Unassigned 1111 1110 0 1/512
Link Local Use Addresses 1111 1110 10 1/1024
Site Local Use Addresses 1111 1110 11 1/1024
Multicast Addresses 1111 1111 1/256
This allocation supports the direct
allocation of provider addresses,
local use addresses, and multicast
addresses. Space is reserved for NSAP
addresses, IPX addresses, and neutral-interconnect
addresses. The remainder of the address
space is unassigned for future use.
This can be used for expansion of
existing use (e.g., additional provider
addresses, etc.) or new uses (e.g.,
separate locators and identifiers).
Note that Anycast addresses are not
shown here because they are allocated
out of the unicast address space.
Approximately fifteen percent of
the address space is initially allocated.
The remaining 85% is reserved for
7.1 Unicast Addresses There
are several forms of unicast address
assignment in IPv6. These are the global
provider based unicast address, the
neutral-interconnect unicast address,
the NSAP address, the IPX hierarchical
address, the site-local-use address,
the link-local-use address, and the
IPv4-capable host address. Additional
address types can be defined in the
7.2 Provider Based Unicast Addresses Provider based unicast addresses
are used for global communication. They
are similar in function to IPv4 addresses
under CIDR. The assignment plan for
unicast addresses is described in 
and . Their format is:
| 3 | n bits | m bits | o bits | p bits | o-p bits |
|010|REGISTRY ID|PROVIDER ID|SUBSCRIBER ID|SUBNET ID| INTF. ID |
The first 3 bits identify the address
as a provider- oriented unicast address.
The next field (REGISTRY ID) identifies
the internet address registry which
assigns provider identifiers (PROVIDER
ID) 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 internet service provider
identified by the PROVIDER ID. The
SUBNET ID identifies a specific physical
link. There can be multiple subnets
on the same physical link. A specific
subnet can not span multiple physical
links. The INTERFACE ID identifies
a single interface among the group
of interfaces identified by the subnet
7.3 Local-Use Addresses 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 the use of global
There are two types
of local-use unicast addresses defined.
These are Link-Local and Site-Local.
The Link-Local-Use is for use on a
single link and the Site-Local-Use
is for use in a single site. Link-Local-
Use addresses have the following format:
| 10 |
| bits | n bits | 118-n bits |
|1111111010| 0 | INTERFACE ID |
Link-Local-Use addresses are designed
to be used for addressing on a single
link for purposes such as auto-address
Site-Local-Use addresses have the
| 10 |
| bits | n bits | m bits | 118-n-m bits |
|1111111011| 0 | SUBNET ID | INTERFACE ID |
For both types of local use addresses
the INTERFACE 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 INTERFACE
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 the
global Internet to operate without
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
its SUBNET ID and INTERFACE ID in
combination with a global prefix (e.g.,
REGISTRY ID + PROVIDER ID + SUBSCRIBER
ID) to create a global address. This
is a significant improvement over
IPv4 which requires sites which use
private (non-global) IPv4 address
to manually renumber when they connect
to the Internet. IPng does the renumbering
7.4 IPv6 Addresses with Embedded
IPV4 Addresses The IPv6 transition
mechanisms include a technique for hosts
and routers to dynamically tunnel IPv6
packets over IPv4 routing infrastructure.
IPv6 nodes that utilize this technique
are assigned special IPv6 unicast addresses
that carry an IPv4 address in the low-order
32-bits. This type of address is termed
an "IPv4-compatible IPv6 address"
and has the format:
| 80 bits | 16 | 32 bits |
|0000..............................0000|0000| IPV4 ADDRESS |
A second type of IPv6 address which
holds an embedded IPv4 address is
also defined. This address is used
to represent the addresses of IPv4-
only nodes (those that *do not* support
IPv6) as IPv6 addresses. This type
of address is termed an "IPv4-mapped
IPv6 address" and has the format:
| 80 bits | 16 | 32 bits |
|0000..............................0000|FFFF| IPV4 ADDRESS |
7.5 Anycast Addresses
An IPv6 anycast address is
an address that is assigned to more
than one interfaces (typically belonging
to different nodes), with the property
that a packet sent to an anycast address
is routed to the "nearest"
interface having that address, according
to the routing protocols' measure of
Anycast addresses, when used as part
of an route sequence, permits a node
to select which of several internet
service providers it wants to carry
its traffic. This capability is sometimes
called "source selected policies".
This would be implemented by configuring
anycast addresses to identify the
set of routers belonging to internet
service providers (e.g., one anycast
address per internet service provider).
These anycast addresses can be used
as intermediate addresses in an IPv6
routing header, to cause a packet
to be delivered via a particular provider
or sequence of providers. Other possible
uses of anycast addresses are to identify
the set of routers attached to a particular
subnet, or the set of routers providing
entry into a particular routing domain.
Anycast addresses are allocated from
the unicast address space, using any
of the defined unicast address formats.
Thus, anycast addresses are syntactically
indistinguishable from unicast addresses.
When a unicast address is assigned
to more than one interface, thus turning
it into an anycast address, the nodes
to which the address is assigned must
be explicitly configured to know that
it is an anycast address.
7.6 Multicast Addresses A IPng multicast address is an identifier
for a group of interfaces. A interface
may belong to any number of multicast
groups. Multicast addresses have the
| 8 | 4 | 4 | 112 bits |
|11111111|FLGS|SCOP| GROUP ID |
11111111 at the start of the address
identifies the address as being a
+-+-+-+-+ FLGS is a set of 4 flags:
The high-order 3 flags are reserved,
and must be initialized to 0.
T=0 indicates a permanently assigned
address, assigned by the global internet
T=1 indicates a non-permanently assigned
SCOP is a 4-bit multicast scope value
used to limit the scope of the multicast
group. The values are:
0 Reserved 8 Organization-local scope
1 Node-local scope 9 (unassigned)
2 Link-local scope A (unassigned)
3 (unassigned) B (unassigned) 4 (unassigned)
C (unassigned) 5 Site-local 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.
8.0 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 also includes simple routing
extensions which support powerful
new routing functionality. These capabilities
- Provider Selection (based on policy,
performance, cost, etc.)
- Host Mobility (route to current
- Auto-Readdressing (route to new
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
group) 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
In order to make address sequences
a general function, IPng hosts are
required in most cases to reverse
routes in a packet it receives (if
the packet was successfully authenticated
using the IPng Authentication Header)
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
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
----- 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,
When H2 replied it would reverse
the addresses and construct a packet
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.
9.0 IPng Quality-of-Service
The Flow Label and the Priority
fields in the IPng header may be used
by a host to identify those packets
for which it requests special handling
by IPng routers, such as non-default
quality of service or "real-time"
service. This capability is important
in order to support applications which
require some degree of consistent throughput,
delay, and/or jitter. These type of
applications are commonly described
as "multi- media" or "real-time"
9.1 Flow Labels The
24-bit Flow Label field in the IPv6
header may be used by a source to label
those packets for which it requests
special handling by the IPv6 routers,
such as non-default quality of service
or "real-time" service.
aspect of IPv6 is, at the time of
writing, still experimental and subject
to change as the requirements for
flow support in the Internet become
clearer. Hosts or routers that do
not support the functions of the Flow
Label field are required to set the
field to zero when originating a packet,
pass the field on unchanged when forwarding
a packet, and ignore the field when
receiving a packet.
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 uniquely
identified by the combination of a
source address and a non- zero flow
label. Packets that do not belong
to a flow carry a flow label of zero.
A flow label is assigned to a flow
by the flow's source node. New flow
labels 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 Label field suitable
for use as a hash key by routers,
for looking up the state associated
with the flow.
All packets belonging to the same
flow must be sent with the same source
address, same destination address,
and same non-zero flow label. If any
of those packets includes a Hop-by-Hop
Options header, then they all must
be originated with the same Hop-by-Hop
Options header contents (excluding
the Next Header field of the Hop-by-Hop
Options header). If any of those packets
includes a Routing header, then they
all must be originated with the same
contents in all extension headers
up to and including the Routing header
(excluding the Next Header field in
the Routing header). The routers or
destinations are permitted, but not
required, to verify that these conditions
are satisfied. If a violation is detected,
it should be reported to the source
by an ICMP Parameter Problem message,
Code 0, pointing to the high-order
octet of the Flow Label field (i.e.,
offset 1 within the IPv6 packet) .
Routers are free to "opportunistically"
set up flow- handling state for any
flow, even when no explicit flow establishment
information has been provided to them
via a control protocol, a hop-by-hop
option, or other means. For example,
upon receiving a packet from a particular
source with an unknown, non-zero flow
label, a router may process its IPv6
header and any necessary extension
headers as if the flow label were
zero. That processing would include
determining the next-hop interface,
and possibly other actions, such as
updating a hop-by-hop option, advancing
the pointer and addresses in a Routing
header, or deciding on how to queue
the packet based on its Priority field.
The router may then choose to "remember"
the results of those processing steps
and cache that information, using
the source address plus the flow label
as the cache key. Subsequent packets
with the same source address and flow
label may then be handled by referring
to the cached information rather than
examining all those fields that, according
to the requirements of the previous
paragraph, can be assumed unchanged
from the first packet seen in the
9.2 Priority The 4-bit
Priority field in the IPv6 header enables
a source to identify the desired delivery
priority of its packets, relative to
other packets from the same source.
The Priority values are divided into
two ranges: Values 0 through 7 are used
to specify the priority of traffic for
which the source is providing congestion
control, i.e., traffic that "backs
off" in response to congestion,
such as TCP traffic. Values 8 through
15 are used to specify the priority
of traffic that does not back off in
response to congestion, e.g., "real-time"
packets being sent at a constant rate.
congestion-controlled traffic, the
following Priority values are recommended
for particular application categories:
- 0 Uncharacterized
- 1 "Filler"
traffic (e.g., netnews)
- 2 Unattended data
transfer (e.g., email)
- 3 (Reserved)
- 4 Attended bulk transfer
(e.g., FTP, HTTP, NFS)
- 5 (Reserved)
- 6 Interactive traffic
(e.g., telnet, X)
- 7 Internet control
traffic (e.g., routing protocols,
For non-congestion-controlled traffic,
the lowest Priority 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 congestion-controlled
priorities and the non-congestion-controlled
10. 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
The first mechanism, called
the "IPng Authentication Header",
is an extension header which provides
authentication and integrity (without
confidentiality) to IPng datagrams
. While the extension 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 deployment
The second security extension header
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
11. IPng Transition
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 IPng transition mechanisms are
a set of protocol mechanisms implemented
in hosts and routers, along with some
operational guidelines for addressing
and deployment, designed to make transition
the Internet to IPv6 work with as
little disruption as possible .
The IPng transition mechanisms 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
- 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 the IPng
transition mechanisms 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
- 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.
- 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.
The IPng transition mechanisms 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 and 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 the IPng transition mechanisms
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.
12. 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
Ease of transition is a
key point in the design of IPng. It
is not something 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 compatibility 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 anycast addresses which
can be used for policy route selection
and has scoped multicast addresses
which provide improved scalability
over IPv4 multicast. It also has local
use address mechanisms which provide
the ability for "plug and play"
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.
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,
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.
How often do you use your printer? If you are constantly running out of printer
ink, sign online. By purchasing your printer
ink cartridges online, you are saving yourself time and money. Have your printer
ink delivered right to your door when you need it!
Want to learn a skill that will help you with your future
career? Computer training is
an important task to learn. From IT certification to A+
Certification, there are many programs to learn. If you are
interested in A+
Certification, sign online to explore training courses. Computer
training is training you don't want to delay!