Network Working Group: R. Hinden
Request for Comments: 1710 Sun Microsystems
Category: Informational October 1994
Simple Internet Protocol Plus White Paper
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be
submitted to the author and/or the sipp@sunroof.eng.sun.com mailing
list.
This white paper presents an overview of the Simple Internet Protocol
plus (SIPP) which is one of the candidates being considered in the
Internet Engineering Task Force (IETF) for the next version of the
Internet Protocol (the current version is usually referred to as
IPv4). This white paper is not intended to be a detailed
presentation of all of the features and motivation for SIPP, but is
intended to give the reader an overview of the proposal. It is also
not intended that this be an implementation specification, but given
the simplicity of the central core of SIPP, an implementor familiar
with IPv4 could probably construct a basic working SIPP
implementation from reading this overview.
SIPP 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. SIPP 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 SIPP working group.
Several individuals deserve specific recognition. These include
Steve Deering, Paul Francis, Dave Crocker, Bob Gilligan, Bill
Hinden [Page 1]
RFC 1710 SIPP IPng White Paper October 1994
Simpson, Ran Atkinson, Bill Fink, Erik Nordmark, Christian Huitema,
Sue Thompson, and Ramesh Govindan.
There are several key issues that should be used in the evaluation of
any 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 installed base of IP
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.
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.
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 (23,494 as of 1/28/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 other. 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
Hinden [Page 2]
RFC 1710 SIPP IPng White Paper October 1994
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, 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 a technology to use.
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 power. The size of
this market is enormous and requires solutions which are simple,
robust, easy to use, and very low cost.
Hinden [Page 3]
RFC 1710 SIPP IPng White Paper October 1994
The challenge for the IETF 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.
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 [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
Hinden [Page 4]
RFC 1710 SIPP IPng White Paper October 1994
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 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
Hinden [Page 5]
RFC 1710 SIPP IPng White Paper October 1994
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.
The SIPP working group represents the evolution of three different
IETF working groups focused on developing an IPng. The first was
called IP Address Encapsulation (IPAE) and was chaired by Dave
Crocker and Robert Hinden. It proposed extensions to IPv4 which
would carry larger addresses. Much of its work was focused on
developing transition mechanisms.
Somewhat later Steve Deering proposed a new protocol evolved from
IPv4 called the Simple Internet Protocol (SIP). A working group was
formed to work on this proposal which was chaired by Steve Deering
and Christian Huitema. SIP had 64-bit addresses, a simplified
header, and options in separate extension headers. After lengthly
interaction between the two working groups and the realization that
IPAE and SIP had a number of common elements and the transition
mechanisms developed for IPAE would apply to SIP, the groups decided
to merge and concentrate their efforts. The chairs of the new SIP
working group were Steve Deering and Robert Hinden.
In parallel to SIP, Paul Francis (formerly Paul Tsuchiya) had founded
a working group to develop the "P" Internet Protocol (Pip). Pip was
a new internet protocol based on a new architecture. The motivation
behind Pip was that the opportunity for introducing a new internet
protocol does not come very often and given that opportunity
important new features should be introduced. Pip supported variable
length addressing in 16-bit units, separation of addresses from
identifiers, support for provider selection, mobility, and efficient
Hinden [Page 6]
RFC 1710 SIPP IPng White Paper October 1994
forwarding. It included a transition scheme similar to IPAE.
After considerable discussion among the leaders of the Pip and SIP
working groups, they came to realize that the advanced features in
Pip could be accomplished in SIP without changing the base SIP
protocol as well as keeping the IPAE transition mechanisms. In
essence it was possible to keep the best features of each protocol.
Based on this the groups decided to merge their efforts. The new
protocol was called Simple Internet Protocol Plus (SIPP). The chairs
of the merged working group are Steve Deering, Paul Francis, and
Robert Hinden.
SIPP is a new version of the Internet Protocol, designed as a
successor to IP version 4 [IPV4]. SIPP is assigned IP version number
6.
SIPP 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 SIPP. Functions which didn't work were
removed. The changes from IPv4 to SIPP fall primarily into the
following categories:
o Expanded Routing and Addressing Capabilities
SIPP increases the IP address size from 32 bits to 64 bits, to
support more levels of addressing hierarchy and a much greater
number of addressable nodes. SIPP addressing can be further
extended, in units of 64 bits, by a facility equivalent to
IPv4's Loose Source and Record Route option, in combination
with a new address type called "cluster addresses" which
identify topological regions rather than individual nodes.
The scaleability of multicast routing is improved by adding
a "scope" field to multicast addresses.
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 SIPP header almost as low as that
of IPv4, despite the increased size of the addresses. The basic
SIPP header is only four bytes longer than IPv4.
Hinden [Page 7]
RFC 1710 SIPP IPng White Paper October 1994
o Improved Support for Options
Changes in the way IP header options are encoded allows for more
efficient forwarding, less stringent limits on the length of
options, and greater flexibility for introducing new options in
the future.
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
SIPP includes the definition of extensions which provide support
for authentication, data integrity, and confidentiality. This
is included as a basic element of SIPP.
The SIPP protocol consists of two parts, the basic SIPP header and
SIPP Options.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Payload Type | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version 4-bit Internet Protocol version number = 6.
Flow Label 28-bit field. See SIPP Quality of Service
section.
Payload Length 16-bit unsigned integer. Length of payload,
i.e., the rest of the packet following the
SIPP header, in octets.
Hinden [Page 8]
RFC 1710 SIPP IPng White Paper October 1994
Payload Type 8-bit selector. Identifies the type of
header immediately following the SIPP
header. Uses the same values as the IPv4
Protocol field [STD 2, RFC 1700].
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 64 bits. An address of the initial sender of
the packet. See [ROUT] for details.
Destination Address 64 bits. An address of the intended
recipient of the packet (possibly not the
ultimate recipient, if an optional Routing
Header is present).
SIPP includes an improved option mechanism over IPv4. SIPP options
are placed in separate headers that are located between the SIPP
header and the transport-layer header in a packet. Most SIPP 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, SIPP 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 SIPP options to
be used for functions which were not practical in IPv4. A good
example of this is the SIPP Authentication and Security Encapsulation
options.
In order to improve the performance when handling subsequent option
headers and the transport protocol which follows, SIPP options are
always an integer multiple of 8 octets long, in order to retain this
alignment for subsequent headers.
Hinden [Page 9]
RFC 1710 SIPP IPng White Paper October 1994
The SIPP 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
SIPP addresses are 64-bits long and are identifiers for individual
nodes and sets of nodes. There are three types of SIPP 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.
SIPP supports addresses which are twice the number of bits as IPv4
addresses. These addresses support an address space which is four
billion (2^^32) times the size of IPv4 addresses (2^^32). Another
way to say this is that SIPP supports four billion internets each the
size of the maximum IPv4 internet. That is enough to allow each
person on the planet to have their own internet. Even with several
layers of hierarchy (with assignment utilization similar to IPv4)
this would allow for each person on the planet to have their own
internet each holding several thousand hosts.
In addition, SIPP supports extended addresses using the routing
option. This capability allows the address space to grow to 128-
bits, 192-bits (or even larger) while still keeping the address units
in manageable 64-bit units. This permits the addresses to grow while
keeping the routing algorithms efficient because they continue to
operate using 64- bit units.
There are several forms of unicast address assignment in SIPP. These
are global hierarchical unicast addresses, local-use addresses, and
IPv4- only host addresses. The assignment plan for unicast addresses
is described in [ADDR].
Hinden [Page 10]
RFC 1710 SIPP IPng White Paper October 1994
Global unicast addresses are used for global communication. They are
the most common SIPP address and are similar in function to IPv4
addresses. Their format is:
|1| n bits | m bits | p bits | 63-n-m-p|
+-+-------------------+---------------------+-----------+---------+
|C| PROVIDER ID | SUBSCRIBER ID | SUBNET ID | NODE ID |
+-+-------------------+---------------------+-----------+---------+
The first bit is the IPv4 compatibility bit, or C-bit. It indicates
whether the node represented by the address is IPv4 or SIPP. SIPP
addresses are provider-oriented. That is, the high-order part of the
address is assigned to internet service providers, which then assign
portions of the address space to subscribers, etc. 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.
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, for
bootstrapping up to a single global addresses, and as part of an
address sequence for global communication. Their format is:
| 4 |
|bits| 12 bits | 48 bits |
+----+---------------+--------------------------------------------+
|0110| 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 have two primary benefits. First, for sites or
organizations that are not (yet) connected to the global Internet,
there is no need to request an address prefix from the global
Hinden [Page 11]
RFC 1710 SIPP IPng White Paper October 1994
Internet address space. Local-use addresses can be used instead. If
the organization connects to the global Internet, it can use it's
local use addresses to communicate with a server (e.g., using the
Dynamic Host Configuration Protocol [DHCP]) to have a global address
automatically assigned.
The second benefit of local-use addresses is that they can hold much
larger NODE IDs, which makes possible a very simple form of auto-
configuration of addresses. In particular, a node may discover a
SUBNET ID by listening to a Router Advertisement messages on its
attached link(s), and then fabricating a SIPP address for itself by
using its link-level address as the NODE ID on that subnet.
An auto-configured local-use address may be used by a node as its own
identification for communication within the local domain, possibly
including communication with a local address server to obtain a
global SIPP address. The details of host auto-configuration are
described in [DHCP].
SIPP unicast addresses are assigned to IPv4-only hosts as part of the
IPAE scheme for transition from IPv4 to SIPP. Such addresses have
the following form:
|1| 31 bits | 32 bits |
+-+------------------------------+--------------------------------+
|1| HIGHER-ORDER SIPP PREFIX | IPv4 ADDRESS |
+-+------------------------------+--------------------------------+
The highest-order bit of a SIPP address is called the IPv4
compatibility bit or the C bit. A C bit value of 1 identifies an
address as belonging to an IPv4-only node.
The IPv4 node's 32-bit IPv4 address is carried in the low-order 32
bits of the SIPP address. The remaining 31 bits are used to carry
HIGHER- ORDER SIPP PREFIX, such as a service-provider ID.
Cluster addresses are unicast addresses that are used to reach the
"nearest" one (according to unicast routing's notion of nearest) of
the set of boundary routers of a cluster of nodes identified by a
common prefix in the SIPP unicast routing hierarchy. These are used
to identify a set of nodes. The cluster address, when used as part
of an address 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
Hinden [Page 12]
RFC 1710 SIPP IPng White Paper October 1994
cluster address for each provider. This capability is sometimes
called "source selected policies". Cluster addresses have the
general form:
| n bits | 64-n bits |
+---------------------------------+-------------------------------+