(sipp) SST overview paper
owner-sipp@sunroof2.eng.sun.com Mon, 18 July 1994 16:25 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06831; 18 Jul 94 12:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06826; 18 Jul 94 12:25 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa11991; 18 Jul 94 12:25 EDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA24418; Mon, 18 Jul 94 09:22:46 PDT
Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA19553; Mon, 18 Jul 94 09:23:33 PDT
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01801; Mon, 18 Jul 94 09:24:32 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: owner-sipp@sunroof2.eng.sun.com
Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01572; Sun, 17 Jul 94 22:09:09 PDT
Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA10279; Sun, 17 Jul 1994 22:06:58 -0700
Received: by kandinsky.Eng.Sun.COM (5.0/SMI-SVR4) id AA12089; Sun, 17 Jul 1994 22:06:43 +0800
Date: Sun, 17 Jul 1994 22:06:43 +0800
>From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan)
Message-Id: <9407180506.AA12089@kandinsky.Eng.Sun.COM>
To: sipp@sunroof.eng.sun.com
Subject: (sipp) SST overview paper
X-Orig-Sender: owner-sipp@sunroof.eng.sun.com
Precedence: bulk
Reply-To: sipp@sunroof.eng.sun.com
As promised, I have written up an overview paper explaining the Simple
SIPP Transition (SST) proposal. I'll send this in to the internet
drafts editor today so that it can be entered into the archives before
the Toronto meeting. Send comments, questions or suggestions to me or
the list. We can discuss SST more at the SIPP working group meeting
in Toronto.
Bob.
Internet Engineering Task Force Robert E. Gilligan
INTERNET-DRAFT Sun Microsystems, Inc.
July 17, 1994
Simple SIPP Transition (SST) Overview
<draft-ietf-sipp-sst-overview-00.txt>
Abstract
In order to address problems of scaling and address space, the Simple
Internet Protocol Plus (SIPP) has been proposed as the new version of
the Internet Protocol (IP). If SIPP is to be widely adopted in the
global Internet, the transition from the current IP must be simple and
easy for users as well as network operators. In order for this to
occur, hosts and routers implementing the new protocol must interoperate
with the large installed base of systems which continue to use the
existing IP. In addition, the transition process must not disrupt the
operation of the Internet. This paper provides an overview of a set of
mechanisms, operational practices, and transition plans that can be used
for transitioning the Internet from IPv4 to SIPP. These techniques are
collectively termed the Simple SIPP Transition (SST).
While specifically designed to transition the IPv4 Internet to SIPP, the
methods used in SST could be adapted to transition other internet layer
protocols such as IPX or CLNP to SIPP.
Status of this Memo
Internet Drafts are working documents of the Internet Engineering Task
Force (IETF), its Areas, and its Working Groups. Note that other groups
may also distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
This Internet Draft expires on January 17, 1995. Internet Drafts may be
updated, replaced, or obsoleted by other documents at any time. It is
not appropriate to use Internet Drafts as reference material or to cite
them other than as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.
Distribution of this memo is unlimited.
draft-ietf-sipp-sst-overview-00.txt [Page 1]
INTERNET-DRAFT SST Overview July 1994
History and Acknowledgements
SST is the result of the efforts of the SIPP, SIP, PIP, and IPAE
working groups over a period of more than two years. SST is based on
the IPAE proposal [IPAE]. IPAE was based on ideas originally
developed by Dave Crocker and Bob Hinden. Erik Nordmark, Ron Jacoby,
Steve Deering, Bob Hinden and Dave Crocker made significant
contributions to the design of IPAE.
SST can be viewed as a simplification of IPAE. A number of people
provided feedback on IPAE and suggested changes which lead to SST.
SST incorporates many of these changes, including:
- Complete elimination of table-based IPv4/SIPP address mapping,
as suggested by John Curran.
- Elimination of the C-bit, and replacing it with a simplified
form of "IPv4 compatible SIPP address", using the 32-bit "C
prefix" suggested by Bill Simpson.
- More use of the "dual stack" technique in both hosts and
routers, as suggested by Ross Callon.
- A consistent and intuitive nomenclature, as suggested by Jim
Bound.
A number of people have provided feedback and suggestions on earlier
drafts of this paper, including ...
draft-ietf-sipp-sst-overview-00.txt [Page 2]
INTERNET-DRAFT SST Overview July 1994
1. Introduction
The Simple SIPP Transition (SST) is a set of mechanisms and practices to
transition the Internet from IP version 4 (IPv4) to the Simple Internet
Protocol Plus (SIPP).
SST is made up of a number of elements:
- A SIPP addressing structure that embeds IPv4 addresses in SIPP
addresses, and encodes other information used by the transition
mechanisms within SIPP addresses.
- Transition mechanisms such as SIPP-in-IPv4 encapsulation and
SIPP/IPv4 header translation, which are implemented in hosts,
routers, and special header translating routers. These
mechanisms allow SIPP nodes to interoperate with IPv4 nodes, and
allow SIPP nodes to utilize IPv4 routing infrastructures.
- Operational practices for assigning IPv4 and SIPP addresses.
- Operational practices for upgrading hosts and routers and
deploying new hosts and routers.
- Operational practices for deploying DNS servers that support
the SIPP address record type.
- Plans for transitioning individual Internet sites to SIPP.
- Plans for transitioning the global Internet to SIPP.
SST provides a number of features, including:
- Incremental upgrade. Existing installed IPv4 hosts and routers
may be upgraded to SIPP at any time without being dependent on
any other hosts or routers being upgraded.
- Incremental deployment. New SIPP hosts and routers can be
installed at any time without any prerequisites.
- Easy Addressing. When existing installed IPv4 hosts or routers
are upgraded to SIPP, they may continue to use their existing
address. They do not need to be assigned new addresses.
- Low start-up costs. Little or no preparation work is needed in
order to upgrade existing IPv4 systems to SIPP, or to deploy new
SIPP systems.
1.1. Additional Documents
draft-ietf-sipp-sst-overview-00.txt [Page 3]
INTERNET-DRAFT SST Overview July 1994
This paper provides an overview of SST. It gives an introduction to the
concepts used in the transition, and describes the mechanisms that are
employed. This is not a specification document. The requirements on
the hosts, routers and header translating routers are detailed in two
companion documents:
- SIPP Transition Mechanisms for Hosts and Routers [SST-HR]
This is a detailed specification of the transition mechanisms
that hosts and routers implement. This is a specification
document, written with the standard MUST/SHOULD/MAY wording.
- SIPP Transition Mechanisms for Header Translating Routers [SST-TR]
This a detailed specification of the special mechanisms that
translating routers must implement. This is a specification
document, written with the standard MUST/SHOULD/MAY wording.
No transition proposal can be complete without a detailed plan for how
the transition will be carried out operationally. For SST, this
information is detailed in a companion document:
- SIPP Transition Plan [SST-TP]
This is an informational paper detailing the specific
operational steps that must be taken to transition the Internet
to using SIPP globally. This paper includes time lines for the
transition, and identifies specific milestones.
1.2. Intended Audience
Individuals such as end users and system administrators who are
interested in the concepts of SST can read this paper by itself.
People implementing host and router software which will incorporate the
transition mechanisms should read this paper in conjunction with the
specification documents.
People who will be involved in the transitioning the operational
Internet should read this paper along with the SIPP Transition Plan.
All readers should be familiar with SIPP and IPv4. The SIPP
specification [SIPP] should be read before reading this document.
1.3. Notation
This paper is written assuming a 128-bit SIPP address size. We use
draft-ietf-sipp-sst-overview-00.txt [Page 4]
INTERNET-DRAFT SST Overview July 1994
the following notation to write SIPP addresses:
xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ddd.ddd.ddd.ddd
Where "x" represents a hex digit, and "d" represents a decimal digit.
Each group of hex digits separated by ":" represents 16 bits of the
address. Leading zero digits in each group are suppressed. Each group
of decimal digits separated by "." represents 8 bits of the address.
Leading zero digits are suppressed here also. It is expected that the
notation for 128-bit SIPP addresses will eventually be standardized and
defined in the SIPP specification document.
1.4. Adaptability to Other Internet Layer Protocols
If SIPP is successful as a successor to IPv4, then organizations
operating networks of other internet layer protocols, such as CLNP or
IPX, may wish to transition them also to SIPP. The techniques in SST
can be adapted to transition virtually any existing internet layer
infrastructure to SIPP so long as the following assumptions hold:
- Addresses in the other internet layer protocol can be mapped
into the SIPP address space efficiently.
- The semantics of the other internet layer protocol are similar
enough for header translation to work.
If these assumptions do not hold, or if the population of nodes
running the other protocol is small, a "pure dual stack" transition
approach may be more appropriate.
The first assumption appears to be true for CLNP and IPX. SIPP
address space has been assigned for CLNP NSAP and IPX addresses in the
SIPP Routing and Addressing specification document [SIPP-ROAD]. And
both CLNP and IPX are semantically close enough to SIPP to believe
that header translation may be possible.
draft-ietf-sipp-sst-overview-00.txt [Page 5]
INTERNET-DRAFT SST Overview July 1994
2. Definitions
A number of new terms are introduced in this paper.
IPv4-only node:
A host or router that speaks only IPv4. An IPv4-only node does
not understand SIPP. The existing installed base of IPv4 hosts
and routers today are all IPv4-only nodes.
SIPP/IPv4 node:
A host or router that speaks both IPv4 and SIPP. SIPP/IPv4
nodes must implement transition mechanisms (e.g. tunneling) in
addition to the basic SIPP and IPv4 protocols.
SIPP-only node:
A host or router that speaks only SIPP and implements a few
simple transition mechanisms. A SIPP-only node does not
understand IPv4.
SIPP/IPv4 header translating router:
A SIPP/IPv4 router that performs SIPP/IPv4 header translation.
IPv4-compatible SIPP address:
A SIPP address that holds an IPv4 address embedded in the
low-order 32-bits. IPv4-compatible SIPP addresses bear the
prefix 0:0:0:0:0:0 or 0:0:0:0:0:1. IPv4-compatible SIPP
addresses with the prefix 0:0:0:0:0:0 identify IPv4-only nodes.
IPv4-compatible SIPP addresses with the prefix 0:0:0:0:0:1 are
assigned to SIPP/IPv4 or SIPP-only nodes.
IPv4-incompatible SIPP address:
A SIPP address that does not necessarily hold an IPv4-address
embedded in the low-order 32-bits. IPv4-incompatible SIPP
addresses bear the prefixes 0:0:0:0:0:2 through
ffff:ffff:ffff:ffff:ffff:ffff. IPv4-incompatible SIPP addresses
are assigned to SIPP/IPv4 or SIPP-only nodes.
SIPP/IPv4 area:
A region of infrastructure interconnected by IPv4-only or
SIPP/IPv4 routers.
draft-ietf-sipp-sst-overview-00.txt [Page 6]
INTERNET-DRAFT SST Overview July 1994
SIPP-only area:
A region of infrastructure interconnected by SIPP-only routers.
SIPP-in-IPv4 tunneling (encapsulation):
The technique of encapsulating SIPP packets within IPv4 so that
it can be carried across the IPv4 topology of a SIPP/IPv4 area.
SIPP/IPv4 header translation:
The technique of translating SIPP packets into IPv4, and IPv4
packets into SIPP, so that IPv4-only and SIPP-only hosts can
interoperate.
draft-ietf-sipp-sst-overview-00.txt [Page 7]
INTERNET-DRAFT SST Overview July 1994
3. Transition Model
The design of SST is based on two fundamental assumptions about how the
transition will take place. The first is that the Internet will
transition to SIPP in an evolutionary fashion over an extended period of
time. The second is that the sites that make up the Internet will
transition at different rates and on different time schedules.
It is expected that, for most Internet sites, the transition will occur
in two phases. First, they will evolve from their initial state, in
which all hosts and routers support only IPv4, to a state where most
hosts and routers support both SIPP and IPv4. In the second phase,
Internet sites would evolve to a state where all of the hosts and
routers support only SIPP, and none directly support IPv4. The second
phase is optional. Sites may elect to stop when the first phase is
complete.
The transition from an "IPv4-only" infrastructure to a "dual SIPP and
IPv4" infrastructure will take place at different speeds in different
Internet sites. Some organizations will transition rapidly, while
others will delay transition for quite some time. This transition phase
can begin immediately, but may be carried out over an extended period of
time.
The eventual transition of some areas of the Internet to a "SIPP-only"
infrastructure is unlikely to begin immediately. It will more likely
begin only after the first phase of transition is completed, or at least
well under way. Even after some areas begin a transition to SIPP-only,
other areas of the Internet may choose to remain IPv4-only or SIPP/IPv4
indefinitely. In order to accommodate this, SST provides a way for
hosts that only support SIPP to continue to interoperate with hosts that
only support IPv4.
Most organizations that do decide to transition to a SIPP-only
infrastructure will likely do so only after first transitioning to a
dual SIPP/IPv4 infrastructure. However, this is not strictly required.
Sites may transition directly from IPv4-only to SIPP-only if they wish.
And organizations building entirely new infrastructures may elect to
make them SIPP-only.
The general timeline of transition for the Internet can be viewed as:
IPv4 only -----> Dual SIPP/IPv4 -----> SIPP only
(first phase) (second phase)
Today --- Time ---> Future
draft-ietf-sipp-sst-overview-00.txt [Page 8]
INTERNET-DRAFT SST Overview July 1994
SST is designed to optimize what is expected to be the common case for
most sites: a two-phase transition. SST makes the first phase --
transition to dual SIPP/IPv4 -- quite easy, requiring virtually no
interdependencies. The second phase -- transition to a SIPP-only
infrastructure -- requires somewhat more effort. Some planning is
needed, and translating routers must be deployed, before any SIPP-only
infrastructure can be built. Nevertheless, once a site has transitioned
to SIPP/IPv4, its subsequent transition to SIPP-only is straightforward.
draft-ietf-sipp-sst-overview-00.txt [Page 9]
INTERNET-DRAFT SST Overview July 1994
4. System Components
SST assumes that three different types of hosts and routers will exist:
- "IPv4-only nodes" are routers and hosts that only support IPv4;
They do not support SIPP. At the beginning of the transition,
all hosts and routers in the Internet are IPv4-only.
- "SIPP/IPv4 nodes" are hosts and routers that support both SIPP
and IPv4, as well as some additional transition mechanisms such
as SIPP-in-IPv4 tunneling. SIPP/IPv4 nodes can directly
interoperate with both SIPP and IPv4 nodes, although to
interoperate with IPv4-only nodes, they must be configured with
an "IPv4-compatible" SIPP address. The first transition phase
in a site involves converting most or all hosts and routers in
that site from IPv4-only to SIPP/IPv4.
- "SIPP-only nodes" are hosts and routers that support only
SIPP. SIPP-only nodes implement a few simple features (such
as a compatible TCP pseudo-header checksum algorithm) that
allow them to interoperate with IPv4 nodes, but they do not
provide an IPv4 protocol implementation. Like SIPP/IPv4
nodes, SIPP-only nodes must be configured with
"IPv4-compatible" SIPP addresses in order to interoperate with
IPv4 nodes. The second phase of transition in a site involves
converting all of the hosts and routers in that site to
SIPP-only.
Note: The simple IPv4-compatibility features implement are
optional. They need not be implemented in SIPP-only nodes
that never will interoperate with IPv4 nodes. However,
SIPP-only nodes that do not interoperate with IPv4 are outside
the scope of this paper.
One additional type of node is used in the transition:
- "SIPP/IPv4 header translating routers" are SIPP/IPv4 routers
that translate IPv4 packets into SIPP, and SIPP packets into
IPv4. Translating routers are needed in order for SIPP-only
nodes that are configured with IPv4-compatible addresses to
interoperate with IPv4-only nodes.
It is expected that as part of their normal evolution, most products
that implement the Internet Protocols will eventually become
"SIPP/IPv4". Vendors may deliver this product change as part of a
normal software release. Users will install such upgrades as part of
their normal operational procedures. Thus hosts and routers may
transition from IPv4-only to SIPP/IPv4 as part of a normal system
draft-ietf-sipp-sst-overview-00.txt [Page 10]
INTERNET-DRAFT SST Overview July 1994
upgrade. Since SIPP/IPv4 hosts and routers keep their complete IPv4
implementation, any IPv4-only host or router can be upgraded to
SIPP/IPv4 without affecting its IPv4 functionallity in any way. Thus
most IPv4-only nodes can be upgraded to SIPP/IPv4 at any time. .bp 5.
Addressing
The SIPP addressing structure which SST uses encodes the following
information into SIPP addresses:
- An IPv4 address. Some SIPP addresses hold an IPv4 address in
the low-order 32-bits.
- Whether an IPv4 address is embedded. The high-order 96-bits of
the address encode whether the low-order 32-bits hold an IPv4
address.
- Whether the node is IPv4-only. The high-order 96-bits of the
address encode whether the address identifies an IPv4-only node
or a SIPP node.
SST employs two special 96-bit SIPP address prefixes: 0:0:0:0:0:0 and
0:0:0:0:0:1. All SIPP addresses with these two prefixes hold an IPv4
address in the low-order 32 bits. These addresses are termed
"IPv4-compatible SIPP addresses."
The first prefix, 0:0:0:0:0:0, is used to identify IPv4-only nodes. The
addresses of all IPv4-only nodes are mapped into the SIPP address space
under the prefix 0:0:0:0:0:0. In other words, a SIPP address of the
form:
0:0:0:0:0:0:<IPv4-address>
identifies an IPv4-only host or router that has been assigned the IPv4
address <IPv4-address>. Addresses with the 0:0:0:0:0:0 prefix show up
in packets, but not in the DNS. SIPP "ASEQ" address records are NOT
listed in the DNS for IPv4-only nodes. IPv4-only nodes continue to have
only IPv4 "A" records listed in the DNS.
The prefix 0:0:0:0:0:1 is used to assign addresses to SIPP nodes
(SIPP/IPv4 or SIPP-only) that wish to interoperate with IPv4 nodes. Any
SIPP node that wishes to interoperate with IPv4 nodes must be assigned
an address of the form:
0:0:0:0:0:1:<IPv4-address>
If a SIPP node does not have at least one address with the prefix
0:0:0:0:0:1 it can not interoperate with IPv4 hosts.
draft-ietf-sipp-sst-overview-00.txt [Page 11]
INTERNET-DRAFT SST Overview July 1994
When an address with the prefix 0:0:0:0:0:1 is assigned to a SIPP node,
the low-order 32-bits (the <IPv4-address> portion) must be a valid,
globally unique, IPv4 address assigned according to the IPv4 numbering
plan used on the subnet to which that node is attached. Two address
records must be listed in the DNS. The full 128-bit SIPP address must
be listed in the DNS with an ASEQ record. In addition, the low-order
32-bits of the address must be listed in the DNS with an A record.
Listing A records in the DNS allows IPv4-only nodes to contact SIPP
nodes that have IPv4-compatible addresses.
The remainder of the SIPP address space -- those addresses with 96-bit
prefixes from 0:0:0:0:0:2 through ffff:ffff:ffff:ffff:ffff:ffff -- are
used to assign addresses to SIPP nodes that DO NOT wish to interoperate
with IPv4 nodes. These are termed "IPv4-incompatible" SIPP addresses
because they are not be used for interoperating with IPv4 nodes.
IPv4-incompatible addresses may hold an embedded IPv4 address, however,
the transition mechanisms do not require or use that information.
The entire space of IPv4-incompatible SIPP addresses is available for
use in a global SIPP addressing plan that is not burdened with
transition requirements. For example, an addressing plan for
auto-configured addresses could be developed which is completely
independent of the transition mechanisms.
When IPv4-incompatible SIPP addresses are assigned to SIPP nodes, only
"ASEQ" records are listed in the DNS. "A" records are not needed -- or
even possible -- because IPv4-incompatible SIPP addresses can not be
used for interoperating with IPv4 nodes.
SIPP Addressing Summary:
Embedded DNS Record
IPv4 Type of Type
High-order 96-bit prefix Addr Node Required
------------------------ ------- ---------- -------
0:0:0:0:0:0 Yes IPv4-only A only
0:0:0:0:0:1 Yes SIPP/IPv4 or A and
SIPP-only ASEQ
0:0:0:0:0:2 through
ffff:ffff:ffff:ffff:ffff:ffff No SIPP/IPv4 or ASEQ only
SIPP-only
draft-ietf-sipp-sst-overview-00.txt [Page 12]
INTERNET-DRAFT SST Overview July 1994
The ability of IPv4-only, SIPP/IPv4 and SIPP-only nodes to interoperate
is as follows:
---------------------------
SIPP-only node \
w/ IPv4-incompatible \
Address \
------------------------ \
SIPP-only node \ \
w/ IPv4-compatible \ \
Address \ \
--------------------- \ \
SIPP/IPv4 node \ \ \
w/ IPv4-incompatible \ \ \
Address \ \ |
------------------ \ \ |
SIPP/IPv4 node \ \ | |
w/ IPv4-compatible \ \ | |
Address \ | | |
--------------- \ | | |
IPv4-only node \ | | | |
------------\ \ | | | |
---------------------+---+----+----+----+----+
IPv4-only node | D | D | N | T | N |
---------------------+---+----+----+----+----+
SIPP/IPv4 node | | | | | |
w/ IPv4-compatible | D | D | D | D | D |
Address | | | | | |
---------------------+---+----+----+----+----+
SIPP/IPv4 node | | | | | |
w/ IPv4-incompatible | N | D | D | D | D |
Address | | | | | |
---------------------+---+----+----+----+----+
SIPP-only node | | | | | |
w/ IPv4-compatible | T | D | D | D | D |
Address | | | | | |
---------------------+---+----+----+----+----+
SIPP-only node | | | | | |
w/ IPv4-incompatible | N | D | D | D | D |
Address | | | | | |
---------------------+---+----+----+----+----+
D = Direct Interoperability
T = Interoperability with aid of a translating router
N = Non Interoperable
draft-ietf-sipp-sst-overview-00.txt [Page 13]
INTERNET-DRAFT SST Overview July 1994
6. Tunneling and Translation
6.1. Topologies
The routing model used in SST is designed to deal with the routing
topologies that are likely to develop in the Internet as the transition
progresses:
- "SIPP/IPv4 areas" are topologies that are connected either by
IPv4-only routers or SIPP/IPv4 routers. SIPP/IPv4 areas route
IPv4 completely to ALL subnets within the area. In addition,
they may route SIPP, although this is not required. If SIPP
routing is provided in a SIPP/IPv4 area, it may not be to every
subnet within the area. Topologies that consist exclusively of
IPv4-only routers are considered SIPP/IPv4 areas.
There are some restrictions on what types of hosts can operate
in SIPP/IPv4 areas. They may hold IPv4-only or SIPP/IPv4 hosts.
However SIPP-only hosts can not be deployed in SIPP/IPv4 areas
because SIPP routers are not present on every subnet.
- "SIPP-only areas" are topologies that are connected by SIPP-only
routers, or SIPP/IPv4 routers with IPv4 routing disabled. SIPP
is routed completely within SIPP-only areas, and IPv4 is not
routed at all. Thus SIPP-only areas can directly carry ONLY
SIPP packets.
There are some restrictions on what hosts can operate in
SIPP-only ares. SIPP/IPv4 or SIPP-only can be deployed, but
IPv4-only hosts may not be deployed in SIPP-only areas because
IPv4 routers are not present.
Note that SST is not designed to deal with a single area that is
composed of a mixture of IPv4-only and SIPP-only routers. It is not
generally possible to mix SIPP-only and IPv4 only routers. The two can
not exchange packets because they do not share a common protocol.
However, area sizes may be quite flexible: a single node may be treated
as an area, as may the entire Internet.
SIPP/IPv4 and SIPP-only areas may be interconnected subject to a few
restrictions:
- SIPP/IPv4 areas can be inter-connected with other SIPP/IPv4
areas by IPv4-only or SIPP/IPv4 routers, forming larger
SIPP/IPv4 areas. For example:
SIPP/IPv4 area ---- SIPP/IPv4 router ---- SIPP/IPv4 area
draft-ietf-sipp-sst-overview-00.txt [Page 14]
INTERNET-DRAFT SST Overview July 1994
or
SIPP/IPv4 area ---- IPv4 router ---- SIPP/IPv4 area
- SIPP-only areas may be interconnected with other SIPP-only
areas by SIPP-only routers, or SIPP/IPv4 routers with IPv4
disabled, forming larger SIPP-only areas. For example:
SIPP-only area ---- SIPP-only router ---- SIPP-only area
or
SIPP-only area ---- SIPP/IPv4 router ---- SIPP-only area
(IPv4 disabled)
- SIPP/IPv4 areas may ONLY be interconnected with SIPP-only areas
by a translating router. SIPP/IPv4 and SIPP-only areas MAY NOT
be interconnected by standard IPv4-only, SIPP/IPv4 or SIPP-only
routers. For example:
SIPP/IPv4 area ---- Translating router ---- SIPP-only area
6.2. SIPP-in-IPv4 Tunneling
SIPP packets can be carried across segments of the IPv4 topology of
SIPP/IPv4 areas by using the SIPP-in-IPv4 tunneling technique. A
SIPP/IPv4 node that has IPv4 reachability to another SIPP/IPv4 node may
send SIPP packets to that node by encapsulating them within IPv4
headers. In order for this technique to work, both nodes must be
assigned IPv4-compatible SIPP addresses. This is necessary because the
low-order 32-bits of those addresses are used as source and destination
addresses of the encapsulating IPv4 header.
For example, say two SIPP/IPv4 nodes N1 and N2 are attached to a common
SIPP/IPv4 area:
SIPP/IPv4 ------- SIPP/IPv4 area ------- SIPP/IPv4
Node N1 Node N2
(0:0:0:0:0:1:129.144.1.2) (0:0:0:0:0:1:192.9.5.3)
If N1 wishes to send a SIPP packet to N2, it could encapsulate that
packet within an IPv4 packet as follows:
+---------------------+
| |
| src = 129.144.1.2 | IPv4 Header
| dst = 192.9.5.3 |
| |
draft-ietf-sipp-sst-overview-00.txt [Page 15]
INTERNET-DRAFT SST Overview July 1994
+---------------------+
| |
. . SIPP Header
. .
. .
When N2 receives this packet, it decapsulates it (remove the IPv4
header), and then process the SIPP header as it would any received SIPP
packet.
Note that the source address of the encapsulating IPv4 packet is the
low-order 32-bits of N1's IPv4-compatible SIPP address, and the
destination address is the low-order 32-bits of N2's IPv4-compatible
SIPP address.
The SIPP-in-IPv4 tunneling technique can be used between two SIPP/IPv4
hosts. In that case, the tunneling is "end-to-end". Tunneling can also
be used between two SIPP/IPv4 routers, between a SIPP/IPv4 router and a
SIPP/IPv4 host, or between a SIPP/IPv4 host and a SIPP/IPv4 router. In
these three cases, the tunneling is over only a segment of the complete
end-to-end path. In all cases, however, the source address of the IPv4
header is the low-order 32-bits of the SIPP address of the node that
performs the encapsulation, and the destination address of the IPv4
header is low-order 32-bits of the SIPP address of the node that the
encapsulating node expects to decapsulate the packet.
Constructing the encapsulating IPv4 header is straightforward when a
SIPP/IPv4 host or router is tunneling a SIPP packet directly to the
destination host: The "tunnel endpoint" address (destination address of
the encapsulating IPv4 packet) is simply the low-order 32-bits of the
SIPP packet's destination address. Since the "tunnel endpoint" address
is carried in the SIPP packet being tunneled, tunneling to end-hosts can
be viewed as "stateless" or "automatic".
When tunneling to an intermediary router, the tunnel endpoint address is
the low-order 32-bits of the router's SIPP address. Since this
information is not carried in the packet, tunneling to intermediary
routers requires configuration on the host or router doing the
tunneling. This configuration information could come in the form of
routing table information on a host, or neighbor configuration
information on a router.
Hosts and routers in SST make extensive use of "automatic" tunneling to
hosts, but only tunnel to intermediary routers when configured to do so.
Except for the case of translating routers (see next section), the
intermediary routers on the path between the encapsulating node and the
decapsulating node do not look at the SIPP header of the packet. They
draft-ietf-sipp-sst-overview-00.txt [Page 16]
INTERNET-DRAFT SST Overview July 1994
route the packet entirely based on its IPv4 header. This is the case
even if the routers along the path are SIPP/IPv4 routers.
In summary, SIPP-in-IPv4 tunneling can be done between the following
pairs of SIPP/IPv4 nodes:
Encapsulating Decapsulating
Node Node Tunnel Endpoint IPv4 Address
----------- ---- ----------------------------
Source Host Dest Host Low-order 32-bits of dest addr
Source Host Router Low-order 32-bits of router addr
Router Router Low-order 32-bits of router addr
Router Dest Host Low-order 32-bits of dest addr
6.3. Header Translation.
Header translating routers bridge the IPv4 infrastructure of SIPP/IPv4
areas into the SIPP infrastructure of SIPP-only areas. There are two
kinds of traffic that need to be so bridged: IPv4 packets sent to or
from IPv4-only nodes, and SIPP packets encapsulated within IPv4 headers
sent between SIPP nodes.
Translating routers must provide all of the features required of
SIPP/IPv4 routers since they must route both SIPP and IPv4 packets. In
addition to their routing responsibilities, they must perform three
specific functions:
- Translate IPv4 headers into SIPP. The IPv4 packets that must
be translated are those that are generated by IPv4-only nodes,
and addressed to SIPP nodes located within SIPP-only areas.
For example:
(IPv4 packet) --> (Translate to SIPP) --> (SIPP Packet)
SIPP/IPv4 area ----- Translating router ----- SIPP-only area
| |
| |
IPv4-only node SIPP-only node
- Translate SIPP headers into IPv4. The SIPP packets that must
be translated are those that are generated by SIPP nodes
located within SIPP-only areas, and addressed to IPv4-only
draft-ietf-sipp-sst-overview-00.txt [Page 17]
INTERNET-DRAFT SST Overview July 1994
node. For example:
(IPv4 packet) <-- (Translate to IPv4) <-- (SIPP Packet)
SIPP/IPv4 area ----- Translating router ----- SIPP-only area
| |
| |
IPv4-only node SIPP-only node
- Decapsulate SIPP-in-IPv4 packets. Translating routers must
decapsulate all SIPP-in-IPv4 packets, even those that are not
addressed to them. For example:
(SIPP packet
encapsulated
in IPv4) --> (Decapsulate) --> (SIPP Packet)
SIPP/IPv4 area ----- Translating routers ----- SIPP-only area
| |
| |
SIPP/IPv4 node SIPP-only node
6.4. Routing Decisions
When sending packets, SIPP/IPv4 nodes must decide whether to use
SIPP-in-IPv4 tunneling. Generally speaking, a SIPP/IPv4 node may
encapsulate when the following are true:
- It is configured with an IPv4-compatible SIPP address (i.e.
its own SIPP address has the prefix 0:0:0:0:0:1).
- The destination or the next hop router is a SIPP node
represented by an IPv4-compatible SIPP address (i.e. has the
prefix 0:0:0:0:0:1).
- It is attached to a SIPP/IPv4 area.
- The destination or the next hop router is attached to the same
SIPP/IPv4 area. (Since SIPP/IPv4 areas must provide complete
IPv4 routing, this implies IPv4 reachability between the two
nodes.)
The first two items can be determined simply by inspecting the source
and destination SIPP addresses.
draft-ietf-sipp-sst-overview-00.txt [Page 18]
INTERNET-DRAFT SST Overview July 1994
The third item -- whether the node is attached to a SIPP/IPv4 area -- is
not so trivial. However, since SIPP-only areas hold no IPv4 routers
(even SIPP/IPv4 routers operating in SIPP-only areas are required to
have IPv4 routing disabled) and SIPP/IPv4 areas require IPv4 routing to
all subnets, a SIPP/IPv4 node may safely assume that it is attached to a
SIPP/IPv4 area if it has at least one neighbor IPv4 router.
The fourth item -- whether the destination is attached to the same
SIPP/IPv4 area -- can not be directly determined. However, because of
the decapsulation algorithm that all translating routers perform, a
SIPP/IPv4 node may safely assume that ALL destinations are within the
same SIPP/IPv4 area. If this assumption is false, and the destination
actually is located within a SIPP-only area, the translating router at
the border of that area will decapsulate the packet and forward it based
on its SIPP destination address.
In many instances, especially as SIPP/IPv4 routers are being deployed in
a site, a node will have the ability to tunnel to a destination, and
also have a route via an on-subnet SIPP router to that destination. In
some cases, a node may even have a route to a destination via an
off-subnet SIPP router that could be reached by tunneling. In general,
SIPP/IPv4 nodes should prefer routes via on-subnet SIPP routers. If a
route via an on-subnet router is not available, they should prefer a
route via an off-subnet router. Only if no routes via SIPP routers are
available should a SIPP/IPv4 node tunnel directly to the destination.
While this routing policy should be the default, administrators should
have the ability to override it.
Route preference summary:
Preference Route
---------- -----
First Via on-subnet SIPP router
Second Via off-subnet SIPP router (tunnel to router)
Third Tunnel to destination
This preference ordering provides a number of advantages:
- Less overhead because non-encapsulated SIPP packets are smaller
than SIPP-in-IPv4 packets.
- Traffic can take advantage of SIPP routing features such as
special handling by flow ID.
- Ensures that SIPP routing topology will be used as it is
deployed.
draft-ietf-sipp-sst-overview-00.txt [Page 19]
INTERNET-DRAFT SST Overview July 1994
7. Node Requirements
This section gives an overview of the mechanisms that each of the three
system components -- SIPP/IPv4 nodes, SIPP-only nodes, and translating
routers -- must implement.
7.1. SIPP/IPv4 Nodes
SIPP/IPv4 nodes provide complete implementations of both IPv4 and SIPP.
They must adhere to all SIPP and IPv4 specifications pertinent to their
role as a host or router.
Since SIPP/IPv4 nodes implement both protocols, they can directly
interoperate with both SIPP and IPv4 nodes located on the same attached
subnet.
SIPP/IPv4 nodes must implement the SIPP-in-IPv4 tunneling mechanism, and
must be able to determine which destinations can be reached by
encapsulation as outlined in the previous section.
They must implement the IPv4-compatible TCP, UDP, and ICMP pseudo-header
checksum algorithm that is specified in [SIPP].
SIPP/IPv4 routers must have the ability to participate in both SIPP and
IPv4 routing systems. System administrators must have the ability to
disable IPv4 routing on SIPP/IPv4 routers, because those routers
operating in SIPP-only areas must not route IPv4.
Generally, when SIPP/IPv4 nodes send packets to IPv4-only nodes, they
send those packets in the IPv4 format. However, if an IPv4 destination
is not located on an attached subnet, and there are no IPv4 routers on
the attached subnet, it must send a SIPP format packet. This packet
will be translated back to IPv4 form by a translating router before it
is delivered to the destination IPv4 node.
When sending SIPP format packets to IPv4 destinations, it composes the
destination address by prepending the 0:0:0:0:0:0 prefix to the
destination's IPv4 address.
A SIPP/IPv4 node must be configured with an IPv4-compatible SIPP address
with the prefix 0:0:0:0:0:1 in order to interoperate with IPv4 nodes.
When sending IPv4 packets to IPv4 nodes, a SIPP/IPv4 node uses the
low-order 32-bits of its own IPv4-compatible SIPP address as the source
address. When sending SIPP format packets, they must use their full
IPv4-compatible SIPP address as the source.
SIPP/IPv4 nodes should have the ability to be configured with multiple
SIPP addresses per interface. In particular, a SIPP/IPv4 node should
draft-ietf-sipp-sst-overview-00.txt [Page 20]
INTERNET-DRAFT SST Overview July 1994
have the ability to configure each interface with an IPv4-compatible as
well as an IPv4-incompatible SIPP addresses.
If a SIPP/IPv4 node is configured with no IPv4-compatible SIPP
addresses, it must treat all attempts to send packets to IPv4
destinations as "unreachable". This is necessary because the node can
provide no valid IPv4 source address in the packets it would send.
7.2. SIPP-only nodes
SIPP-only nodes provide a complete SIPP implementation, but no IPv4
implementation. They can directly interoperate with other SIPP nodes,
but can not interoperate with IPv4-only nodes only with the assistance
of a translating router. SIPP-only nodes must implement a few simple
mechanisms in order make interoperability with IPv4 nodes possible.
Like SIPP/IPv4 nodes, they must implement the IPv4-compatible TCP, UDP,
and ICMP pseudo-header checksum algorithm that is specified in [SIPP].
Also like SIPP/IPv4 nodes, SIPP-only nodes must have the ability to send
SIPP format packets to IPv4-only nodes. However, since SIPP-only nodes
never send IPv4 format packets, the algorithm to do this can be simpler.
When requested to send a packet to an IPv4 destination, a SIPP-only node
can simply pre-pend the prefix 0:0:0:0:0:0 to that address, and send a
SIPP format packet to the resulting SIPP address.
SIPP-only nodes must also have the ability to handle "A" records in the
DNS. Since IPv4-only nodes will only have A records listed in the DNS,
SIPP-only nodes must be able to utilize these records when they are
found in a DNS lookup. Since there is a one-to-one mapping from the
IPv4 addresses of IPv4-only hosts to their corresponding SIPP address,
SIPP-only hosts can easily transform the IPv4 address of an IPv4-only
host into its SIPP address by pre-pending the prefix 0:0:0:0:0:0.
The mapping of IPv4 addresses into SIPP addresses need not affect the
SIPP or transport layer code in a SIPP-only host. It can usually be
isolated in the DNS resolver or address parsing libraries.
SIPP-only routers participate in only the SIPP routing systems.
Like SIPP/IPv4 nodes, SIPP-only must be configured with IPv4-compatible
SIPP addresses in order to interoperate with IPv4 nodes. And SIPP-only
nodes should have the ability to configure multiple SIPP addresses per
interface.
7.3. Header Translating Routers
draft-ietf-sipp-sst-overview-00.txt [Page 21]
INTERNET-DRAFT SST Overview July 1994
Header translating routers are SIPP/IPv4 routers which implement the
translation mechanisms discussed in section 5.
Translating routers must be configured to know which packets must be
translated, and which can be simply forwarded without translation. This
can be done by configuring the translating router to know which SIPP
addresses are located within the SIPP-only area that it serves.
Translating routers use this configuration information, along with the
destination SIPP or IPv4 addresses of packets they receive to determine
which packets to translate. They must:
- Translate SIPP packets addressed to IPv4-only nodes outside the
SIPP-only area to IPv4
- Translate IPv4 packets addressed to nodes within the SIPP-only
area to SIPP.
- Translate IPv4 packets addressed to nodes outside the SIPP-only
area to SIPP if the resulting packets may transit the SIPP-only
area.
When translating SIPP packets to IPv4, translating routers use the
low-order 32-bits of the source and destination SIPP addresses to
generate the addresses for the IPv4 packet.
When translating IPv4 packets to SIPP, translating routers pre-pend the
prefix 0:0:0:0:0:0 to the IPv4 source address to generate the source
address for the SIPP packet. They prepend either the prefix 0:0:0:0:0:1
or 0:0:0:0:0:0 to generate the destination address. They use the
0:0:0:0:0:1 prefix if the destination is located within, and the prefix
0:0:0:0:0:0 if the destination is located outside, the SIPP-only area
that the translating router serves.
draft-ietf-sipp-sst-overview-00.txt [Page 22]
INTERNET-DRAFT SST Overview July 1994
8. Upgrade Dependencies
Perhaps the most important issue for those who must carry out the
transition from IPv4 to SIPP is that of upgrade dependencies: Which
transition steps must be performed before other steps can be taken? SST
is designed so that the prerequisites to installation of SIPP/IPv4 nodes
are minimal, while the steps that must be taken before SIPP-only nodes
may be deployed are more involved. Essentially the only operation that
must be performed before deploying SIPP/IPv4 nodes is that the DNS
servers must be upgraded to support the SIPP ASEQ record type.
The upgrade dependencies are summarized in the table below:
| Transition Step | Depends On |
+-------------------------------+------------------------------+
| DNS upgrade to support | None |
| ASEQ records (1) | |
+-------------------------------+------------------------------+
| Upgrade IPv4 host or router | DNS upgrade to support |
| to SIPP/IPv4 | ASEQ records (2) |
+-------------------------------+------------------------------+
| Deploy new SIPP/IPv4 host or | DNS upgrade to support |
| router | ASEQ records (2) |
+-------------------------------+------------------------------+
| Change SIPP/IPv4 area to | Install Translating router |
| SIPP-only | at border |
| | Upgrade all routers within |
| | area to SIPP/IPv4 |
| | Disable IPv4 routing inside |
| | area. |
+-------------------------------+------------------------------+
| Upgrade SIPP/IPv4 host or | Change area from SIPP/IPv4 |
| router to SIPP-only | to SIPP-only |
+-------------------------------+------------------------------+
| Deploy new SIPP-only | Change area from SIPP/IPv4 |
| host or router | to SIPP-only |
+-------------------------------+------------------------------+
Notes:
(1) Strictly speaking, a DNS server being upgraded to
support the SIPP ASEQ address record type does not
itself need to be upgraded to SIPP. An IPv4-only
DNS server may support ASEQ record types.
(2) The DNS upgrade is only required if node being
upgraded or installed is going to be listed in the
DNS. "Unlisted" nodes do not have this dependency.
draft-ietf-sipp-sst-overview-00.txt [Page 23]
INTERNET-DRAFT SST Overview July 1994
9. Examples
Two SIPP/IPv4 hosts may use SIPP-in-IPv4 tunneling to communicate via
an IPv4 infrastructure:
SIPP/IPv4 Host H1
(0:0:0:0:0:1:129.144.1.2)
|
--+--------------------------+-- (subnet A)
|
(0:0:0:0:0:0:129.144.1.3)
IPv4-only Router R1
(0:0:0:0:0:0:129.144.2.3)
|
-------+-----------------+----- (subnet B)
|
(0:0:0:0:0:1:129.144.2.4)
SIPP/IPv4 Host H2
When H1 sends a packet to H2, the packets that will be transmitted on
subnets A and B are:
Packet Dest Addr in Dest Addr in Datalink
Subnet Type SIPP Header IPv4 Header Next hop
------ ----- ----------------------- ------------ --------
A Enc. 0:0:0:0:0:1:129.144.2.4 129.144.2.4 R1
B Enc. 0:0:0:0:0:1:129.144.2.4 129.144.2.4 H2
Note:
Enc. = SIPP-in-IPv4 encapsulation
If a SIPP/IPv4 router is added to this topology, H1 will have multiple
routes to reach H2. It could use SIPP-in-IPv4 tunneling, sending the
traffic via R1 or R2, or use the raw SIPP format routing via R2. Since
SIPP/IPv4 hosts prefer routes via SIPP routers, H1 will use send the
traffic via R2:
draft-ietf-sipp-sst-overview-00.txt [Page 24]
INTERNET-DRAFT SST Overview July 1994
SIPP/IPv4 Host H1
(0:0:0:0:0:1:129.144.1.2)
|
--+-----+-------------------------------+-- (subnet A)
| |
(0:0:0:0:0:1:129.144.1.4) (0:0:0:0:0:0:129.144.1.3)
SIPP/IPv4 Router R2 IPv4-only Router R1
(0:0:0:0:0:1:129.144.2.6) (0:0:0:0:0:0:129.144.2.3)
| |
----+--+----------------------------+----- (subnet B)
|
(0:0:0:0:0:1:129.144.2.4)
SIPP/IPv4 Host H2
Now when H1 sends a packet to H2, the packets that will be transmitted
on subnets A and B are:
Packet Dest Addr in Datalink
Subnet Type SIPP Header Next hop
------ ----- ----------------------- --------
A SIPP 0:0:0:0:0:1:129.144.2.4 R2
B SIPP 0:0:0:0:0:1:129.144.2.4 H2
draft-ietf-sipp-sst-overview-00.txt [Page 25]
INTERNET-DRAFT SST Overview July 1994
10. Author's Address
Robert E. Gilligan
Sun Microsystems, Inc.
2550 Garcia Ave.
Mailstop UMTV 05-44
Mountain View, California 94043
415-336-1012 (voice)
415-336-6015 (fax)
Bob.Gilligan@Eng.Sun.COM
11. References
[IPAE] R. E. Gilligan. IPAE: The SIPP Interoperability and
Transition Mechanism. March 1994. Internet Draft.
[SIPP] S. Deering. Simple Internet Protocol Plus (SIPP)
Specification. February 1994. Internet Draft.
[SIPP-ROAD] S. Deering, P. Francis, R. Govindan. Simple Internet
Protocol Plus (SIPP): Routing and Addressing. February
1994. Internet Draft.
[SST-HR] SIPP Transition Mechanisms for Hosts and Routers.
Internet Draft to be written.
[SST-TR] SIPP Transition Mechanisms for Header Translating
routers. Internet Draft to be written.
[SST-TP] SIPP Transition Plan. Internet Draft to be written.
draft-ietf-sipp-sst-overview-00.txt [Page 26]
-----------------------------------------------------------------------------
IETF SIPP Working Group - Archives: parcftp.xerox.com:/pub/sipp
Unsubscribe: unsubscribe sipp (as message body, not subject)
Direct all administrative requests to majordomo@sunroof.eng.sun.com
- (sipp) SST overview paper owner-sipp
- Re: (sipp) SST overview paper William Allen Simpson