As per Relevance of the word addresses, we have this rfc below:
Network Working Group: R.
Request for Comments: 1710 Sun
Category: Informational October 1994
Simple Internet Protocol Plus White
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document was submitted to the IETF IPng area in response to
1550. Publication of this document does not imply acceptance by
IPng area of any ideas expressed within. Comments should
submitted to the author and/or the sipp@sunroof.eng.sun.com
list
1.
This white paper presents an overview of the Simple Internet
plus (SIPP) which is one of the candidates being considered in
Internet Engineering Task Force (IETF) for the next version of
Internet Protocol (the current version is usually referred to
IPv4). This white paper is not intended to be a
presentation of all of the features and motivation for SIPP, but
intended to give the reader an overview of the proposal. It is
not intended that this be an implementation specification, but
the simplicity of the central core of SIPP, an implementor
with IPv4 could probably construct a basic working
implementation from reading this overview
SIPP is a new version of IP which is designed to be an
step from IPv4. It is a natural increment to IPv4. It can
installed as a normal software upgrade in internet devices and
interoperable with the current IPv4. Its deployment strategy
designed to not have any "flag" days. SIPP is designed to run
on high performance networks (e.g., ATM) and at the same time
still efficient for low bandwidth networks (e.g., wireless).
addition, it provides a platform for new internet functionality
will be required in the near future
This white paper describes the work of IETF SIPP working group
Several individuals deserve specific recognition. These
Steve Deering, Paul Francis, Dave Crocker, Bob Gilligan,
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
2. Key Issues for the Next Generation of
There are several key issues that should be used in the evaluation
any next generation internet protocol. Some are
straightforward. For example the new protocol must be able
support large global internetworks. Others are less obvious.
must be a clear way to transition the current installed base of
systems. It doesn't matter how good a new protocol is if there isn'
a practical way to transition the current operational systems
IPv4 to the new protocol
2.1
Growth is the basic issue which caused there to be a need for a
generation IP. If anything is to be learned from our experience
IPv4 it is that the addressing and routing must be capable
handling reasonable scenarios of future growth. It is important
we have an understanding of the past growth and where the
growth will come from
Currently IPv4 serves what could be called the computer market.
computer market has been the driver of the growth of the Internet
It comprises the current Internet and countless other
internets which are not connected to the Internet. Its focus is
connect computers together in the large business, government,
university education markets. This market has been growing at
exponential rate. One measure of this is that the number of
in current Internet (23,494 as of 1/28/94) is doubling
every 12 months. The computers which are used at the endpoints
internet communications range from PC's to Supercomputers. Most
attached to Local Area Networks (LANs) and the vast majority are
mobile
The next phase of growth will probably not be driven by the
market. While the computer market will continue to grow
significant rates due to expansion into other areas such as
(elementary through high school) and small businesses, it is
it will continue to grow at an exponential rate. What is likely
happen is that other kinds of markets will develop. These
will fall into several areas. They all have the characteristic
they are extremely large. They also bring with them a new set
requirements which were not as evident in the early stages of IPv
deployment. The new markets are also likely to happen in
with other. It may turn out that we will look back on the last
years of Internet growth as the time when the Internet was small
Hinden [Page 2]
RFC 1710 SIPP IPng White Paper October 1994
only doubling every year. The challenge for an IPng is to provide
solution which solves todays problems and is attractive in
emerging markets
Nomadic personal computing devices seem certain to become
as their prices drop and their capabilities increase. A
capability is that they will be networked. Unlike the majority
todays networked computers they will support a variety of types
network attachments. When disconnected they will use RF
networks, when used in networked facilities they will use
attachment, and when docked they will use physical wires. This
them an ideal candidate for internetworking technology as they
need a common protocol which can work over a variety of
networks. These types of devices will become consumer devices
will replace the current generation of cellular phones, pagers,
personal digital assistants. In addition to the obvious
of an internet protocol which can support large scale routing
addressing, they will require an internet protocol which imposes
low overhead and supports auto configuration and mobility as a
element. The nature of nomadic computing requires an
protocol to have built in authentication and confidentiality.
also goes without saying that these devices will need to
with the current generation of computers. The requirement for
overhead comes from the wireless media. Unlike LAN's which will
very high speed, the wireless media will be several orders
magnitude slower due to constraints on available frequencies
spectrum allocation, and power consumption
Another market is networked entertainment. The first signs of
emerging market are the proposals being discussed for 500 channels
television, video on demand, etc. This is clearly a consumer market
The possibility is that every television set will become an
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
protocol which supports large scale routing and addressing, and
configuration. This market also requires a protocol suite
imposes the minimum overhead to get the job done. Cost will be
major factor in the selection of a technology to use
Another market which could use the next generation IP is
control. This consists of the control of everyday devices such
lighting equipment, heating and cooling equipment, motors, and
types of equipment which are currently controlled via analog
and in aggregate consume considerable amounts of power. The size
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
protocol which meets today's requirements and also matches
requirements of these emerging markets. These markets will
with or without an IETF IPng. If the IETF IPng is a good match
these new markets it is likely to be used. If not, these
will develop something else. They will not wait for an
solution. If this should happen it is probable that because of
size and scale of the new markets the IETF protocol would
supplanted. If the IETF IPng is not appropriate for use in
markets, it is also probable that they will each develop their
protocols, perhaps proprietary. These new protocols would
interoperate with each other. The opportunity for the IETF is
select an IPng which has a reasonable chance to be used in
emerging markets. This would have the very desirable outcome
creating an immense, interoperable, world-wide
infrastructure created with open protocols. The alternative is
world of disjoint networks with protocols controlled by
vendors
2.2.
At some point in the next three to seven years the Internet
require a deployed new version of the Internet protocol. Two
are driving this: routing and addressing. Global internet
based on the on 32-bit addresses of IPv4 is becoming
strained. IPv4 address do not provide enough flexibility
construct efficient hierarchies which can be aggregated.
deployment of Classless Inter-Domain Routing [CIDR] is extending
life time of IPv4 routing routing by a number of years, the effort
manage the routing will continue to increase. Even if the IPv
routing can be scaled to support a full IPv4 Internet, the
will eventually run out of network numbers. There is no
that an IPng is needed, but only a question of when
The challenge for an IPng is for its transition to be complete
IPv4 routing and addressing break. The transition will be
easier if IPv4 address are still globally unique. The two
requirements which are the most important are flexibility
deployment and the ability for IPv4 hosts to communicate with
hosts. There will be IPng-only hosts, just as there will be IPv4-
only hosts. The capability must exist for IPng-only hosts
communicate with IPv4-only hosts globally while IPv4 addresses
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
successful. The importance of flexibility in an IPng and the
for interoperability between IPv4 and IPng was well stated in
Hinden [Page 4]
RFC 1710 SIPP IPng White Paper October 1994
message to the sipp mailing list by Bill Fink, who is responsible
a portion of NASA's operational internet. In his message he said
"Being a network manager and thereby representing the interests
a significant number of users, from my perspective it's safe
say that the transition and interoperation aspects of any IPng
*the* key first element, without which any other
advantages won't be able to be integrated into the user's
environment. I also don't think it wise to think of
transition as just a painful phase we'll have to endure en
to a pure IPng environment, since the transition/
period undoubtedly will last at least a decade and may very
continue for the entire lifetime of IPng, until it's replaced
IPngng and a new transition. I might wish it was otherwise but
fear they are facts of life given the immense installed base
"Given this situation, and the reality that it won't be
to coordinate all the infrastructure changes even at the
and regional levels, it is imperative that the
capabilities support the ability to deploy the IPng in
piecemeal fashion... with no requirement to need to
local changes with other changes elsewhere in the Internet...
"I realize that support for the transition and
capabilities may be a major part of the IPng effort and may
some headaches for the designers and developers, but I think it
a duty that can't be shirked and the necessary price that must
paid to provide as seamless an environment as possible to the
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
during the extended transition period for the base IPv
functionality..."
Another way to think about the requirement for compatibility
IPv4 is to look at other product areas. In the product world
backwards compatability is very important. Vendors who do
provide backward compatibility for their customers usually find
do not have many customers left. For example, chip makers
considerable effort into making sure that new versions of
processor always run all of the software that ran on the
model. It is unlikely that Intel would develop a new processor
the X86 family that did not run DOS and the tens of thousands
applications which run on the current versions of X86's
Operating system vendors go to great lengths to make sure
versions of their operating systems are binary compatible with
Hinden [Page 5]
RFC 1710 SIPP IPng White Paper October 1994
old version. For example the labels on most PC or MAC
usually indicate that they require OS version XX or greater.
would be foolish for Microsoft come out with a new version of
which did not run the applications which ran on the previous version
Microsoft even provides the ability for windows applications to
on their new OS NT. This is an important feature. They
that it was very important to make sure that the applications
run on Windows also run on NT
The same requirement is also true for IPng. The Internet has a
installed base. Features need to be designed into an IPng to
the transition as easy as possible. As with processors and
systems, it must be backwards compatible with IPv4. Other
have tried to replace TCP/IP, for example XTP and OSI. One
in their failure to reach widespread acceptance was that neither
any transition strategy other than running in parallel (
called dual stack). New features alone are not adequate to
users to deploy new protocols. IPng must have a great
strategy and new features
3. History of the SIPP
The SIPP working group represents the evolution of three
IETF working groups focused on developing an IPng. The first
called IP Address Encapsulation (IPAE) and was chaired by
Crocker and Robert Hinden. It proposed extensions to IPv4
would carry larger addresses. Much of its work was focused
developing transition mechanisms
Somewhat later Steve Deering proposed a new protocol evolved
IPv4 called the Simple Internet Protocol (SIP). A working group
formed to work on this proposal which was chaired by Steve
and Christian Huitema. SIP had 64-bit addresses, a
header, and options in separate extension headers. After
interaction between the two working groups and the realization
IPAE and SIP had a number of common elements and the
mechanisms developed for IPAE would apply to SIP, the groups
to merge and concentrate their efforts. The chairs of the new
working group were Steve Deering and Robert Hinden
In parallel to SIP, Paul Francis (formerly Paul Tsuchiya) had
a working group to develop the "P" Internet Protocol (Pip). Pip
a new internet protocol based on a new architecture. The
behind Pip was that the opportunity for introducing a new
protocol does not come very often and given that
important new features should be introduced. Pip supported
length addressing in 16-bit units, separation of addresses
identifiers, support for provider selection, mobility, and
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
working groups, they came to realize that the advanced features
Pip could be accomplished in SIP without changing the base
protocol as well as keeping the IPAE transition mechanisms.
essence it was possible to keep the best features of each protocol
Based on this the groups decided to merge their efforts. The
protocol was called Simple Internet Protocol Plus (SIPP). The
of the merged working group are Steve Deering, Paul Francis,
Robert Hinden
4. SIPP
SIPP is a new version of the Internet Protocol, designed as
successor to IP version 4 [IPV4]. SIPP is assigned IP version
6.
SIPP was designed to take an evolutionary step from IPv4. It was
a design goal to take a radical step away from IPv4. Functions
work in IPv4 were kept in SIPP. Functions which didn't work
removed. The changes from IPv4 to SIPP fall primarily into
following categories
o Expanded Routing and Addressing
SIPP increases the IP address size from 32 bits to 64 bits,
support more levels of addressing hierarchy and a much
number of addressable nodes. SIPP addressing can be
extended, in units of 64 bits, by a facility equivalent
IPv4's Loose Source and Record Route option, in
with a new address type called "cluster addresses"
identify topological regions rather than individual nodes
The scaleability of multicast routing is improved by
a "scope" field to multicast addresses
o Header Format
Some IPv4 header fields have been dropped or made optional,
reduce the common-case processing cost of packet handling and
keep the bandwidth cost of the SIPP header almost as low as
of IPv4, despite the increased size of the addresses. The
SIPP header is only four bytes longer than IPv4.
Hinden [Page 7]
RFC 1710 SIPP IPng White Paper October 1994
o Improved Support for
Changes in the way IP header options are encoded allows for
efficient forwarding, less stringent limits on the length
options, and greater flexibility for introducing new options
the future
o Quality-of-Service
A new capability is added to enable the labeling of
belonging to particular traffic "flows" for which the
requests special handling, such as non-default quality
service or "real-time" service
o Authentication and Privacy
SIPP includes the definition of extensions which provide
for authentication, data integrity, and confidentiality.
is included as a basic element of SIPP
The SIPP protocol consists of two parts, the basic SIPP header
SIPP Options
4.1 SIPP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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
section
Payload Length 16-bit unsigned integer. Length of payload
i.e., the rest of the packet following
SIPP header, in octets
Hinden [Page 8]
RFC 1710 SIPP IPng White Paper October 1994
Payload Type 8-bit selector. Identifies the type
header immediately following the
header. Uses the same values as the IPv
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
decremented to zero
Source Address 64 bits. An address of the initial sender
the packet. See [ROUT] for details
Destination Address 64 bits. An address of the
recipient of the packet (possibly not
ultimate recipient, if an optional
Header is present).
4.2 SIPP
SIPP includes an improved option mechanism over IPv4. SIPP
are placed in separate headers that are located between the
header and the transport-layer header in a packet. Most SIPP
headers are not examined or processed by any router along a packet'
delivery path until it arrives at its final destination.
facilitates a major improvement in router performance for
containing options. In IPv4 the presence of any options requires
router to examine all options. The other improvement is that
IPv4, SIPP options can be of arbitrary length and the total amount
options carried in a packet is not limited to 40 bytes. This
plus the manner in which they are processed, permits SIPP options
be used for functions which were not practical in IPv4. A
example of this is the SIPP Authentication and Security
options
In order to improve the performance when handling subsequent
headers and the transport protocol which follows, SIPP options
always an integer multiple of 8 octets long, in order to retain
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
--------------- ---------------------------------------
Routing Extended Routing (like IPv4 loose
route
Fragmentation Fragmentation and
Authentication Integrity and
Security Encapsulation
Hop-by-Hop Option Special options which require hop by
4.3 SIPP
SIPP addresses are 64-bits long and are identifiers for
nodes and sets of nodes. There are three types of SIPP addresses
These are unicast, cluster, and multicast. Unicast
identify a single node. Cluster addresses identify a group of nodes
that share a common address prefix, such that a packet sent to
cluster address will be delivered to one member of the group
Multicast addresses identify a group of nodes, such that a
sent to a multicast address is delivered to all of the nodes in
group
SIPP supports addresses which are twice the number of bits as IPv
addresses. These addresses support an address space which is
billion (2^^32) times the size of IPv4 addresses (2^^32).
way to say this is that SIPP supports four billion internets each
size of the maximum IPv4 internet. That is enough to allow
person on the planet to have their own internet. Even with
layers of hierarchy (with assignment utilization similar to IPv4)
this would allow for each person on the planet to have their
internet each holding several thousand hosts
In addition, SIPP supports extended addresses using the
option. This capability allows the address space to grow to 128-
bits, 192-bits (or even larger) while still keeping the address
in manageable 64-bit units. This permits the addresses to grow
keeping the routing algorithms efficient because they continue
operate using 64- bit units
4.3.1 Unicast
There are several forms of unicast address assignment in SIPP.
are global hierarchical unicast addresses, local-use addresses,
IPv4- only host addresses. The assignment plan for unicast
is described in [ADDR].
Hinden [Page 10]
RFC 1710 SIPP IPng White Paper October 1994
4.3.1.1 Global Unicast
Global unicast addresses are used for global communication. They
the most common SIPP address and are similar in function to IPv
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
whether the node represented by the address is IPv4 or SIPP.
addresses are provider-oriented. That is, the high-order part of
address is assigned to internet service providers, which then
portions of the address space to subscribers, etc. This usage
similar to assignment of IP addresses under CIDR. The SUBSCRIBER
distinguishes among multiple subscribers attached to the
identified by the PROVIDER ID. The SUBNET ID identifies
topologically connected group of nodes within the subscriber
identified by the subscriber prefix. The NODE ID identifies a
node among the group of nodes identified by the subnet prefix
4.3.1.2 Local-Use
A local-use address is a unicast address that has only
routability scope (within the subnet or within a subscriber network),
and may have local or global uniqueness scope. They are intended
use inside of a site for "plug and play" local communication,
bootstrapping up to a single global addresses, and as part of
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
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
site. The combination of the SUBNET ID and the NODE ID to form
local use address allows a large private internet to be
without any other address allocation
Local-use addresses have two primary benefits. First, for sites
organizations that are not (yet) connected to the global Internet
there is no need to request an address prefix from the
Hinden [Page 11]
RFC 1710 SIPP IPng White Paper October 1994
Internet address space. Local-use addresses can be used instead.
the organization connects to the global Internet, it can use it'
local use addresses to communicate with a server (e.g., using
Dynamic Host Configuration Protocol [DHCP]) to have a global
automatically assigned
The second benefit of local-use addresses is that they can hold
larger NODE IDs, which makes possible a very simple form of auto
configuration of addresses. In particular, a node may discover
SUBNET ID by listening to a Router Advertisement messages on
attached link(s), and then fabricating a SIPP address for itself
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
identification for communication within the local domain,
including communication with a local address server to obtain
global SIPP address. The details of host auto-configuration
described in [DHCP].
4.3.1.3 IPv4-Only
SIPP unicast addresses are assigned to IPv4-only hosts as part of
IPAE scheme for transition from IPv4 to SIPP. Such addresses
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 IPv
compatibility bit or the C bit. A C bit value of 1 identifies
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
HIGHER- ORDER SIPP PREFIX, such as a service-provider ID
4.3.2 Cluster
Cluster addresses are unicast addresses that are used to reach
"nearest" one (according to unicast routing's notion of nearest)
the set of boundary routers of a cluster of nodes identified by
common prefix in the SIPP unicast routing hierarchy. These are
to identify a set of nodes. The cluster address, when used as
of an address sequence, permits a node to select which of
providers it wants to carry its traffic. A cluster address can
be used as a destination address. In this example there would be
Hinden [Page 12]
RFC 1710 SIPP IPng White Paper October 1994
cluster address for each provider. This capability is
called "source selected policies". Cluster addresses have
general form
| n bits | 64-n bits |
+---------------------------------+-------------------------------+
| CLUSTER PREFIX |0000000000000000000000000000000|
+---------------------------------+-------------------------------+
4.3.3 Multicast
A SIPP multicast address is an identifier for a group of nodes.
node may belong to any number of multicast groups.
addresses have the following format
|1| 7 | 4 | 4 | 48 bits |
+-+-------+----+----+---------------------------------------------+
|C|1111111|FLGS|SCOP| GROUP ID |
+-+-------+----+----+---------------------------------------------+
Where
C = IPv4 compatibility bit
1111111 in the rest of the first octet identifies the address
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")
address, assigned by the global internet numbering authority
T = 1 indicates a non-permanently-assigned ("transient")
address
SCOP is a 4-bit multicast scope value used to limit the scope
the multicast group. The values are
0 reserved 8 intra-organization
1 intra-node scope 9 (unassigned
2 intra-link scope 10 (unassigned
3 (unassigned) 11 intra-community
4 (unassigned) 12 (unassigned
Hinden [Page 13]
RFC 1710 SIPP IPng White Paper October 1994
5 intra-site scope 13 (unassigned
6 (unassigned) 14 global
7 (unassigned) 15
GROUP ID identifies the multicast group, either permanent
transient, within the given scope
4.4 SIPP
Routing in SIPP is almost identical to IPv4 routing under CIDR
that the addresses are 64-bit SIPP addresses instead of 32-bit IPv
addresses. This is true even when extended addresses are being used
With very straightforward extensions, all of IPv4's
algorithms (OSPF, BGP, RIP, IDRP, etc.) can used to route SIPP [OSPF
[RIP2] [IDRP].
SIPP also includes simple routing extensions which support
new routing functionality. These capabilities include
Provider Selection (based on policy, performance, cost, etc.)
Host Mobility (route to current location
Auto-Readdressing (route to new address
Extended Addressing (route to "sub-cloud")
The new routing functionality is obtained by creating sequences
SIPP addresses using the SIPP Routing option. The routing option
used by a SIPP source to list one or more intermediate nodes (
topological clusters) to be "visited" on the way to a packet'
destination. This function is very similar in function to IPv4'
Loose Source and Record Route option. A node would publish
address sequence in the Domain Name System [DNS].
The identification of a specific transport connection is done by
using the first (source) and last (destination) address in
sequence. These identifying addresses (i.e., first and
addresses of a route sequence) are required to be unique within
scope over which they are used. This permits the middle addresses
the address sequence to change (in the cases of mobility,
changes, site readdressing, etc.) without disrupting the
connection
In order to make address sequences a general function, SIPP hosts
required to reverse routes in a packet it receives containing
sequences in order to return the packet to its originator.
approach is taken to make SIPP host implementations from the
support the handling and reversal of source routes. This is the
for allowing them to work with hosts which implement the new
such as provider selection or extended addresses
Hinden [Page 14]
RFC 1710 SIPP IPng White Paper October 1994
Three examples show how the extended addressing can be used.
these examples, address sequences are shown by a list of
addresses separated by commas. For example
SRC, I1, I2, I3,
Where the first address is the source address, the last address
the destination address, and the middle addresses are
addresses
For these examples assume that two hosts, H1 and H2 wish
communicate. Assume that H1 and H2's sites are both connected
providers P1 and P2. A third wireless provider, PR, is connected
both providers P1 and P2.
----- P1 ------
/ | \
/ | \
H1 PR H
\ | /
\ | /
----- P2 ------
The simplest case (no use of address sequences) is when H1 wants
send a packet to H2 containing the addresses
H1, H
When H2 replied it would reverse the addresses and construct a
containing the addresses
H2, H
In this example either provider could be used, and H1 and H2
not be able to select which provider traffic would be sent to
received from
If H1 decides that it wants to enforce a policy that
communication to/from H2 can only use provider P1, it would
a packet containing the address sequence
H1, P1, H
This ensures that when H2 replies to H1, it will reverse the
and the reply it would also travel over P1. The addresses in H2'
reply would look like
H2, P1, H
Hinden [Page 15]
RFC 1710 SIPP IPng White Paper October 1994
If H1 became mobile and moved to provider PR, it could maintain (
breaking any transport connections) communication with H2, by
packets that contain the address sequence
H1, PR, P1, H
This would ensure that when H2 replied it would enforce H1's
of exclusive use of provider P1 and send the packet to H1
location on provider PR. The reversed address sequence would be
H2, P1, PR, H
The address extension facility of SIPP can be used for
selection, mobility, readdressing, and extended addressing. It is
simple but powerful capability
4.5 SIPP Quality-of-Service
The Flow Label field in the SIPP header may be used by a host
label those packets for which it requests special handling by
routers, such as non-default quality of service or "real-time
service. This labeling is important in order to support
which require some degree of consistent throughput, delay, and/
jitter. The Flow Label is a 28-bit field, internally structured
three subfields as follows
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| DP | Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (Reserved) 1-bit subfield. Initialized to zero
transmission; Ignored on reception
DP (Drop Priority) 3-bit unsigned integer. Specifies
priority of the packet, relative to
packets from the same source, for
discarded by a router under conditions
congestion. Larger values indicates
greater willingness by the sender to
the packet to be discarded
Flow ID 24-bit subfield used to identify
specific flow
A flow is a sequence of packets sent from a particular source to
particular (unicast or multicast) destination for which the
desires special handling by the intervening routers. There may
multiple active flows from a source to a destination, as well
Hinden [Page 16]
RFC 1710 SIPP IPng White Paper October 1994
traffic that is not associated with any flow. A flow is
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
IDs must be chosen (pseudo-)randomly and uniformly from the range 1
to FFFFFF hex. The purpose of the random allocation is to make
set of bits within the Flow ID suitable for use as a hash key by
routers, for looking up the special-handling state associated
the flow. A Flow ID must not be re-used by a source for a new
while any state associated with the previous usage still exists
any router
The Drop Priority subfield provides a means separate from the Flow
for distinguishing among packets from the same source, to allow
source to specify which of its packets are to be discarded
preference to others when a router cannot forward them all. This
useful for applications like video where it is preferable to
packets carrying screen updates rather than the packets carrying
video synchronization information
4.6 SIPP
The current Internet has a number of security problems and
effective privacy and authentication mechanisms below the
layer. SIPP remedies these shortcomings by having two
options that provide security services. These two options may
used singly or together to provide differing levels of security
different users. This is very important because different
communities have different security needs
The first mechanism, called the "SIPP Authentication Header", is
option which provides authentication and integrity (
confidentiality) to SIPP datagrams. While the option is algorithm
independent and will support many different
techniques, the use of keyed MD5 is proposed to help
interoperability within the worldwide Internet. This can be used
eliminate a significant class of network attacks, including
masquerading attacks. The use of the SIPP Authentication Header
particularly important when source routing is used with SIPP
of the known risks in IP source routing. Its placement at
internet layer can help provide host origin authentication to
upper layer protocols and services that currently lack
protections. This mechanism should be exportable by vendors in
United States and other countries with similar export
because it only provides authentication and integrity,
specifically does not provide confidentiality. The exportability
the SIPP Authentication Header encourages its
Hinden [Page 17]
RFC 1710 SIPP IPng White Paper October 1994
implementation and use
The second security option provided with SIPP is the "
Encapsulating Security Header". This mechanism provides
and confidentiality to SIPP datagrams. It is simpler than
similar security protocols (e.g., SP3D, ISO NLSP) but
flexible and algorithm-independent. To achieve
within the global Internet, the use of DES CBC is proposed as
standard algorithm for use with the SIPP Encapsulating
Header
5. SIPP Transition
The two key motivations in the SIPP transition mechanisms are
provide direct interoperability between IPv4 and SIPP hosts and
allow the user population to adopt SIPP in an a highly
fashion. The transition must be incremental, with few or no
interdependencies, if it is to succeed. The SIPP transition
the users to upgrade their hosts to SIPP, and the network
to deploy SIPP in routers, with very little coordination between
two
The mechanisms and policies of the SIPP transition are called "IPAE".
Having a separate term serves to highlight those features
specifically for transition. Once an acronym for an
technique to facilitate transition, the term "IPAE" now is
historical
The IPAE transition is based on five key elements
1) A 64-bit SIPP addressing plan that encompasses the
32-bit IPv4 addressing plan. The 64-bit plan will be used
assign addresses for both SIPP and IPv4 nodes at the
of the transition. Existing IPv4 nodes will not need to
their addresses, and IPv4 hosts being upgraded to SIPP keep
existing IPv4 addresses as the low-order 32 bits of their
addresses. Since the SIPP addressing plan is a superset of
existing IPv4 plan, SIPP hosts are assigned only a single 64-
address, which can be used to communicate with both SIPP and IPv
hosts
2) A mechanism for encapsulating SIPP traffic within IPv4 packets
that the IPv4 infrastructure can be leveraged early in
transition. Most of the "SIPP within IPv4 tunnels" can
automatically configured
Hinden [Page 18]
RFC 1710 SIPP IPng White Paper October 1994
3) Algorithms in SIPP hosts that allow them to directly
with IPv4 hosts located on the same subnet and elsewhere in
Internet
4) A mechanism for translating between IPv4 and SIPP headers
allow SIPP-only hosts to communicate with IPv4-only hosts and
facilitate IPv4 hosts communicating over over a SIPP-
backbone
5) An optional mechanism for mapping IPv4 addresses to SIPP
to allow improved scaling of IPv4 routing. At the present
given the success of CIDR, this does not look like it will
needed in a transition to SIPP. If Internet growth
continue beyond what CIDR can handle, it is available as
optional mechanism
IPAE ensures that SIPP hosts can interoperate with IPv4
anywhere in the Internet up until the time when IPv4 addresses
out, and afterward allows SIPP and IPv4 hosts within a limited
to interoperate indefinitely. This feature protects for a very
time the huge investment users have made in IPv4. Hosts that
only a limited connectivity range (e.g., printers) need never
upgraded to SIPP. This feature also allows SIPP-only hosts
interoperate with IPv4-only hosts
The incremental upgrade features of IPAE allow the host and
vendors to integrate SIPP into their product lines at their own pace
and allows the end users and network operators to deploy SIPP
their own schedules
The interoperability between SIPP and IPv4 provided by IPAE also
the benefit of extending the lifetime of IPv4 hosts. Given the
installed base of IPv4, changes to IPv4 in hosts are
impossible. Once an IPng is chosen, most of the new
development will be done on IPng. New features in IPng will
the incentives to adopt and deploy it
6. Why SIPP
There are a number of reasons why SIPP should be selected as
IETF's IPng. It solves the Internet scaling problem, provides
flexible transition mechanism for the current Internet, and
designed to meet the needs of new markets such as nomadic
computing devices, networked entertainment, and device control.
does this in a evolutionary way which reduces the risk
architectural problems
Hinden [Page 19]
RFC 1710 SIPP IPng White Paper October 1994
Ease of transition is a key point in the design of SIPP. It is
something was was added in at the end. SIPP is designed
interoperate with IPv4. Specific mechanisms (C-bit, embedded IPv
addresses, etc.) were built into SIPP to support transition
compatability with IPv4. It was designed to permit a gradual
piecemeal deployment without any dependencies
SIPP supports large hierarchical addresses which will allow
Internet to continue to grow and provide new routing capabilities
built into IPv4. It has cluster addresses which can be used
policy route selection and has scoped multicast addresses
provide improved scaleability over IPv4 multicast. It also has
use addresses which provide the ability for "plug and play
installation
SIPP is designed to have performance better than IPv4 and work
in low bandwidth applications like wireless. Its headers are
expensive to process than IPv4 and its 64-bit addresses are chosen
be well matched to the new generation of 64bit processors.
compact header minimizes bandwidth overhead which makes it ideal
wireless use
SIPP provides a platform for new Internet functionality.
includes support for real-time flows, provider selection,
mobility, end-to- end security, auto-configuration, and auto
reconfiguration
In summary, SIPP is a new version of IP. It can be installed as
normal software upgrade in internet devices. It is
with the current IPv4. Its deployment strategy was designed to
have any "flag" days. SIPP is designed to run well on
performance networks (e.g., ATM) and at the same time is
efficient for low bandwidth networks (e.g., wireless). In addition
it provides a platform for new internet functionality that will
required in the near future
Hinden [Page 20]
RFC 1710 SIPP IPng White Paper October 1994
7. Status of SIPP
There are many active participants in the SIPP working group.
making active contributions include
Group
--------------------- ----------------------------------------
Beame & Whiteside Implementation (PC
Bellcore Implementation (SunOS), DNS and ICMP specs
Digital Equipment Corp. Implementation (Alpha/OSF, Open VMS
INRIA Implementation (BSD, BIND), DNS & OSPF specs
INESC Implementation (BSD/Mach/x-kernel
Intercon Implementation (MAC
MCI Phone
Merit IDRP for SIPP
Naval Research Lab. Implementation (BSD) Security
Network General Implementation (Sniffer
SGI Implementation (IRIX, NetVisulizer
Sun Implementation (Solaris 2.x, Snoop
TGV Implementation (Open VMS
Xerox PARC Protocol
Bill Simpson Implementation (KA9Q
As of the time this paper was written there were a number of SIPP
IPAE implementations. These include
Implementation
-------------- ------------------------------------
BSD/Mach Completed (telnet, NFS, AFS, UDP
BSD/Net/2 In
Bind Code
DOS &Windows Completed (telnet, ftp, tftp, ping
IRIX In progress (ping
KA9Q In progress (ping, TCP
Mac OS Completed (telnet, ftp, finger, ping
NetVisualizer Completed (SIP & IPAE
Open VMS Completed (telnet, ftp), In
OSF/1 In Progress (ping, ICMP
Sniffer Completed (SIP & IPAE
Snoop Completed (SIP & IPAE
Solaris Completed (telnet, ftp, tftp, ping
Sun OS In
Hinden [Page 21]
RFC 1710 SIPP IPng White Paper October 1994
8. Where to Get Additional
The documentation listed in the reference sections can be found
one of the IETF internet draft directories or in the archive site
the SIPP working group. This is located at
ftp.parc.xerox.com in the /pub/sipp directory
In addition other material relating to SIPP (such as
versions of presentations on SIPP) can also be found in the
working group archive
To join the SIPP working group, send electronic mail
sipp-request@sunroof.eng.sun.
An archive of mail sent to this mailing list can be found in the
directories at cnri.reston.va.us
9. Security
Security issues are discussed in section 4.6.
10. Author's
Robert M.
Manager, Internet
Sun Microsystems, Inc
MS MTV5-44
2550 Garcia Ave
Mt. View, CA 94303
Phone: (415) 336-2082
Fax: (415) 336-6016
EMail: hinden@eng.sun.
11.
[ADDR] Francis, P., "Simple Internet Protocol Plus (SIPP):
Hierarchical Address Assignment", Work in Progress,
1994.
[AUTH] Atkinson, R., "SIPP Authentication Payload",
Work in Progress, January, 1994.
[CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting
an Address Assignment and Aggregation Strategy", RFC 1338,
BARRNet, cisco, Merit, OARnet, June 1992.
Hinden [Page 22]
RFC 1710 SIPP IPng White Paper October 1994
[DISC] Simpson, W., "SIPP Neighbor Discovery", Work in Progress
March 1994.
[DIS2] Simpson, W., "SIPP Neighbor Discovery -- ICMP
Formats", Work in Progress, March 1994.
[DHCP] Thomson, S., "Simple Internet Protocol Plus (SIPP):
Host Address Assignment", Work in Progress, March 1994.
[DNS] Thomson, S., and C. Huitema, "DNS Extensions to
Simple Internet Protocol Plus (SIPP)", Work in Progress
March 1994.
[ICMP] Govindan, R., and S. Deering, "ICMP and IGMP for the
Internet Protocol Plus (SIPP)", Work in Progress, March 1994.
[IDRP] Hares, S., "IDRP for SIP", Work in Progress, November 1993.
[IPAE] Gilligan, R., et al, "IPAE: The SIPP Interoperability
Transition Mechanism", Work in Progress, March 1994.
[IPV4] Postel, J., "Internet Protocol- DARPA Internet
Protocol Specification", STD 5, RFC 791, DARPA
September 1981.
[OSPF] Francis, P., "OSPF for SIPP", Work in Progress,
1994.
[RIP2] Malkin, G., and C. Huitema, "SIP-RIP", Work in Progress
March 1993.
[ROUT] Deering, S., et al, "Simple Internet Protocol Plus (SIPP):
Routing and Addressing", Work in Progress, February 1994.
[SARC] Atkinson, R., "SIPP Security Architecture", Work in Progress
January 1994.
[SECR] Atkinson, R., "SIPP Encapsulating Security Payload (ESP)",
Work in Progress, January 1994.
[SIPP] Deering, S., "Simple Internet Protocol Plus (SIPP
Specification", Work in Progress, February 1994.
Hinden [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
