(sipp) Deployment and Routing
William Allen Simpson <bill.simpson@um.cc.umich.edu> Sat, 23 July 1994 22:06 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11036; 23 Jul 94 18:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11032; 23 Jul 94 18:06 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa11846; 23 Jul 94 18:05 EDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA00509; Sat, 23 Jul 94 15:05:01 PDT
Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA02668; Sat, 23 Jul 94 15:06:48 PDT
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01184; Sat, 23 Jul 94 15:06:59 PDT
Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01178; Sat, 23 Jul 94 15:06:48 PDT
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA21229; Sat, 23 Jul 94 15:04:29 PDT
Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA00502; Sat, 23 Jul 94 15:04:20 PDT
Received: from Bill.Simpson.DialUp.Merit.edu (pm002-01.dialip.mich.net [35.1.48.82]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA26537 for <sipp@sunroof.eng.sun.com>; Sat, 23 Jul 1994 18:04:05 -0400
Date: Sat, 23 Jul 1994 21:47:13 +0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson@um.cc.umich.edu>
Message-Id: <2931.bill.simpson@um.cc.umich.edu>
To: sipp@sunroof.eng.sun.com
Subject: (sipp) Deployment and Routing
X-Orig-Sender: owner-sipp@sunroof.eng.sun.com
Precedence: bulk
Reply-To: sipp@sunroof.eng.sun.com
It was suggested by some folks that rather than complaining about the
SIPP SST plan, I should come up with one myself. Here's the first pass:
Network Working Group W A Simpson
Internet Draft Daydreamer
expires in six months July 1994
SIPP Deployment and Routing
draft-simpson-sipp-dar-00.txt (A)
Status of this Memo
Another in a series of "mad ravings of the lunatic engineer". [1]
Publication of this document does not imply acceptance by the IPng
Area of any ideas expressed within. Comments should be submitted to
the big-internet@munnari.oz.au mailing list.
Distribution of this memo is unlimited.
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. 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 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net,
venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current
status of any Internet Draft.
Abstract
This document specifies strategies related to deployment and routing
for consideration in design and selection of the Next Generation of
IP.
Simpson expires in six months [Page i]
DRAFT SIPP Deployment July 1994
1. Introduction
SIPP routing techniques will follow SIPP deployment in stages, rather
than emerging from whole cloth. The routing available is dependent
on deployment of the systems which participate in the routing
methodology.
Therefore, a realistic routing scheme needs be designed according to
practical deployment considerations.
This emphasis is contrary to the common paradigm of "Routing and
Addressing". Addressing is merely a tool for routing. Addressing
must follow the chosen technique for routing, which followed the
necessities of deployment.
1.1. Assumptions
Limit routing knowledge in hosts.
Limit human configuration of hosts.
In order to make SIPP a natural progression of the Internet, early
deployment must be effortless, and take very little new training of
operators.
No special encapsulation or translation procedures are implemented in
hosts.
2. Stage Zero -- Basic Facilities
SIPP+IPv4 Host H1 SIPP+IPv4 Host H2
| |
--+--------------------------+--
The simplest case is that where IPv4 and SIPP nodes are deployed on a
single link or bridged LAN, and no internetwork router is available.
This may occur only when no router has yet been deployed, no router
has been configured into each node, and no router has been found
using Router Discovery.
Simpson expires in six months [Page 1]
DRAFT SIPP Deployment July 1994
2.1. Finding Other Nodes
In the absence of a router, all other nodes must be assumed to be
located on the same link.
Each target SIPP node must be identified by an SIPP address. A node
which is capable of other modes of communication, such as IPv4, would
be identified by other forms of address. When SIPP addresses are
learned together with other addresses, the SIPP address and header
are used.
The addresses of the target nodes are likely to be statically
configured. This requires no more configuration than IPv4.
However, it is not required that all nodes be statically configured.
For instance, only transaction processing nodes might be configured,
thus reducing the need for static configuration.
This leads to the second addressing requirement. Each node should be
capable of a generating a local-use SIPP address, that indicates no
topological information, which can be used as a return address when
communicating with target nodes on the same link. The local-use
address need only be unique within the scope of the link.
In addition, certain link media have the capability to broadcast or
multicast messages to more than one node at one time. Each node can
determine whether to accept or ignore these messages.
This leads to the third addressing requirement. A special class of
SIPP addresses is needed which map to the broadcast or multicast
capability of the link.
2.2. SIPP Services
It is desirable that when a service becomes available to the link,
that the service be found by dynamic means, thus eliminating the need
for static configuration.
This leads to the fourth addressing requirement. A special class of
SIPP addresses is needed which are preassigned to the various
services. These addresses would map to the broadcast or multicast
capability of the link.
When a query is sent using one of these addresses, more than one
server may answer. Since no particular routing mechanism is in
effect, it is the responsibility of the querying node to
Simpson expires in six months [Page 2]
DRAFT SIPP Deployment July 1994
differentiate and choose among multiple replies.
2.3. Configuration Servers
The first such service used by a node might a configuration server.
The SIPP node should first attempt to access the SIPP version of the
server, followed by the IPv4 version of the server. The SIPP
configuration server will return bootstrap and other information.
In addition, the SIPP configuration server should determine that
there exists a registered name for the node which is unique within
the administrative domain. The registration may require a query and
response interaction, in order to ensure the uniqueness of the name
or to provide security for the registration.
The SIPP node will only register its SIPP local-use address with an
SIPP configuration server.
These name-address tables are then distributed by the Domain Name
Service, instead of relying on static configuration. The DNS will
not include SIPP values in response to a non-SIPP query.
2.4. Security Issues
The use of dynamic name and address registration presents a potential
security threat. In order to register a name to be used by other
nodes, the configuration server must perform some form of
authentication.
The authentication requires a configured private secret key for each
node to register with the configuration server.
Greatest security would occur if approval were given to each such
registration, with a different secret key for each client and server
pair.
A simpler approach which requires less configuration would be to use
a single secret per link or area, for access to the configuration and
registration service, after which other secrets are used for other
services. This secret should be changed on a regular basis, and
should not be used on a site basis.
Simpson expires in six months [Page 3]
DRAFT SIPP Deployment July 1994
2.5. Installation/Configuration Consequences
By default, no changes to current installation procedures are
required.
The need for configuration of a static address can be eliminated when
there is a method of generating a local-use address, and name
registration is used or the node operates only as a client rather
than as a server.
When new services such as name registration become available, a
secret must be configured at secured servers, and supplied by the
operator or configuration during host initialization.
3. Stage One -- No SIPP Routers
SIPP+IPv4 Host H1 SIPP+IPv4 Host H2
| |
--+--------------------------+-- (subnet A)
|
IPv4-only Router R1
|
--+--------------------------+-- (subnet B)
| |
SIPP+IPv4 Host H3 IPv4-only Host H4
The first SIPP nodes are likely to be deployed as part of the normal
installation of a new system, or the periodic upgrade of an old
system. Therefore, consideration must be made of the effect of
deployment of SIPP hosts prior to the deployment of SIPP routers.
3.1. Finding Other Nodes
A determination must be made as to whether another node is located on
the same link. This determination is made as defined for IPv4,
rather than SIPP.
When SIPP addresses are learned together with IPv4 addresses, the
IPv4 address and header are used.
Local-use addresses are used only for communication with SIPP servers
located on the same link.
Simpson expires in six months [Page 4]
DRAFT SIPP Deployment July 1994
3.2. SIPP Services
The IPv4 routers cannot be depended upon to correctly forward SIPP
Service Discovery techniques. Queries are limited to those services
located on the same link.
3.3. Configuration Servers
The SIPP node will only register its SIPP local-use address with an
SIPP configuration server.
3.4. Security Issues
No new security issues arise.
3.5. Installation/Configuration Consequences
Since use of IPv4 Router Discovery is not sufficiently widespread,
the presence of an IPv4 router must be configured into each host.
Therefore, no changes to current installation procedures are
required.
Note particularly that no tunnels are configured, and no special SIPP
or IPv4 areas or masks are configured.
4. Stage Two -- Intra-Domain SIPP+IPv4 Routers
SIPP+IPv4 Host H1 SIPP+IPv4 Host H2
|
--+--------------------------+-- (subnet A)
| |
SIPP+IPv4 Router R2 IPv4-only Router R1
| |
--+--------------------------+-- (subnet B)
| |
SIPP+IPv4 Host H3 IPv4-only Host H4
The first SIPP routers are likely to be deployed as part of the
normal installation of a new router, or the periodic upgrade of an
old router. These routers are expected to route both SIPP and IPv4
Simpson expires in six months [Page 5]
DRAFT SIPP Deployment July 1994
traffic.
All SIPP routers can be depended upon to implement Router Discovery.
The SIPP Router Advertisements provide an automatic signal that this
stage of deployment has been reached.
The SIPP addresses are longer. Operators will configure IPv4
addresses. When SIPP addresses are based upon IPv4 addresses, this
will minimize new training, resulting in fewer and shorter items of
configuration.
This leads to the fifth addressing requirement. Until IPv4 addresses
are exhausted, SIPP addresses should contain embedded IPv4 addresses,
with a leading zero prefix to extend to the new size.
This also allows transport checksum calculation to be the same for
both IPv4 and SIPP.
While the SIPP routing prefix is also longer, it will always be a
superset of the IPv4 prefix, which is already required to be
configured. Therefore, SIPP routing prefix generation should be
automatic.
While SIPP+IPv4 routers maintain adjacencies with both IPv4 and SIPP
routers, only SIPP tables are required internally. This minimizes
the space needed for the tables.
4.1. Finding Other Nodes
No determination is made as to whether another node is located on the
same link. All traffic is first sent to the preferred SIPP router.
That router makes the determination, and a redirect is issued when
another router is to be used, or the target node is on the directly
attached link. This redirect will be to the all-nodes multicast, to
update all nodes which are using the destination concurrently.
When SIPP addresses are learned together with other addresses, the
SIPP address and header are preferred. The longest prefix which
matches a prefix bound to the node is used.
At this stage, the prefix of all SIPP addresses bound to the node is
zero. When the prefix of a target SIPP address is non-zero, that
address is unreachable.
Simpson expires in six months [Page 6]
DRAFT SIPP Deployment July 1994
4.2. SIPP Services
The SIPP routers are required to correctly forward SIPP Service
Discovery techniques, but only within the scope of the SIPP deployed
routing.
4.3. Configuration Servers
Having learned its SIPP prefix from the SIPP routers, the SIPP node
can register its qualified SIPP addresses with an SIPP configuration
server. At this stage, the SIPP prefix is always zero.
While the configuration server may use the local-use address in its
authentication to distinguish the SIPP node, the registration of a
qualified SIPP address must invalidate any previously registered
local-use address. Such local-use addresses must not continue to be
propagated by the Domain Name Service.
The DNS will now carry at least 2 records for each SIPP+IPv4 node --
the IPv4 address, and the leading zero prefix SIPP equivalent.
4.4. Encapsulation in IPv4
In order to allow SIPP nodes to communicate with other SIPP nodes
which can only be reached via intervening IPv4 routers, an SIPP in
IPv4 encapsulation technique is used. This is further described in
[].
When an SIPP+IPv4 router determines that the next hop for an SIPP
datagram is only served by an IPv4 router, the SIPP+IPv4 router
encapsulates the SIPP header inside an IPv4 header. Since the upper
part of such an SIPP address is always zero, the embedded IPv4
address from the lower part is used as the new destination.
In choosing the destination, the progression of specified
intermediate routing points is important for correct operation.
These SIPP routing header entries will not be recognized while the
datagram is encapsulated. Therefore, the SIPP routing header
mechanism must update the SIPP header destination before
encapsulation.
When an SIPP+IPv4 router determines that the next hop for an SIPP in
IPv4 datagram is served by an SIPP router, the SIPP+IPv4 router
decapsulates the SIPP header.
Simpson expires in six months [Page 7]
DRAFT SIPP Deployment July 1994
Encapsulation and decapsulation may occur repeatedly in the path of
the datagram.
4.5. Mobility
The SIPP routers are required to correctly intercept and forward
datagrams for mobile SIPP nodes. When mobility is accomplished using
either source routing or encapsulation techniques, SIPP mobility is
not dependent on global SIPP routing.
4.6. Security
The use of redirect on a link presents a potential security threat.
Several authentication techniques may be employed to verify the
redirect.
Each host must verify that the redirect came from a source that is
presently the next hop for the target destination.
The router will also receive the redirect, and may examine the source
of all redirects, to detect the presence of another node spoofing the
use of its source address.
Those hosts that require special authentication should establish a
separate security relationship with each router from which it expects
redirects.
The use of dynamic location registration also presents a potential
security threat. In order to register a change of location by a
mobile node, the mobility server must perform some form of
authentication.
Greatest security would occur if approval were given to each such
registration, with a different secret key for each client and server
pair.
A simpler approach which requires less configuration would be to use
the same secret as the name and address registration service.
4.7. Installation/Configuration Consequences
Unlike deployment of hosts, deployment of routers will require some
Simpson expires in six months [Page 8]
DRAFT SIPP Deployment July 1994
degree of new training of operators.
However, at this stage there is no longer a need for static
configuration of IPv4 routers in SIPP hosts. This is a reduction of
configuration.
When new services such as mobility registration become available, a
secret must be configured at secured servers, and supplied by the
operator or configuration during host initialization.
5. Stage Three -- Inter-Domain SIPP+IPv4 Routers
Eventually, SIPP routers will be deployed between Administrative
Domains. Current plans call for the Inter-Domain Routing Protocol
(IDRP) to be used.
Each SIPP border router will be configured with a Routing Domain
Identifier (RDI). This RDI is used as the non-zero SIPP prefix
indicating the Administrative Domain. This prefix also has an
associated size.
Each border router will also be assigned its own number for extending
the RDI to make a routing prefix. The routing prefix is propagated
to adjacent SIPP routers within the Administrative Domain.
Each intra-domain router extends the routing prefix by allocating
enough bits for the number of its interfaces, and propagates the
extended prefix in turn to its adjacent SIPP routers. The interface
from which the new prefix was learned is always assigned a zero in
the extended prefix.
Some routers will learn more than one prefix. In order to prevent
loops, the router propagates only those prefixes with the shortest
prefix size. For example, having heard prefixes 1234, 1256, 123456,
and 123789, only 1234 and 1256 would be propagated.
The prefixes propagated by the routers are learned by the hosts. The
non-zero prefix is automatically used to generate one or more
additional SIPP addresses for each node.
5.1. Finding Other Nodes
At this stage, the SIPP node can reach SIPP inter-domain routing.
This is indicated by a non-zero prefix SIPP address.
Simpson expires in six months [Page 9]
DRAFT SIPP Deployment July 1994
When non-zero prefix SIPP addresses are learned together with other
addresses, the longest prefix which matches a prefix bound to the
node is used.
When crossing a domain which does not yet have complete SIPP routing,
this will continue to be the zero prefix SIPP address.
5.2. SIPP Services
No new service issues arise.
5.3. Configuration Servers
Having learned its SIPP prefix from the SIPP routers, the SIPP node
can register its qualified SIPP addresses with an SIPP configuration
server. At this stage, the SIPP prefix is not zero.
However, the zero prefix address form continues to be registered
whenever an IPv4 address is also registered.
The DNS will now carry at least 3 records for each SIPP+IPv4 node --
the IPv4 address, the leading zero prefix SIPP equivalent, and the
Administrative Domain prefixed SIPP equivalent.
5.4. Encapsulation in IPv4
When a non-zero prefix SIPP destination is used, it is not necessary
to encapsulate in IPv4. There is a complete SIPP routed path from
every non-zero prefixed address to every other such address.
5.5. Mobility
No new mobility issues arise.
5.6. Security
No new security issues arise.
Simpson expires in six months [Page 10]
DRAFT SIPP Deployment July 1994
5.7. Installation/Configuration Consequences
Deployment of inter-domain routers will likely require considerably
more training of operators.
Configuration of the RDI is already a requirement of IPv4.
Note that the routing prefix aggregates along the shortest number of
hops. This is not necessarily the lowest metric.
6. Stage Four -- Depleted IPv4 Addresses
Finally, there will not be more IPv4 addresses available. New SIPP
nodes will no longer be assigned IPv4 addresses. These nodes are
termed SIPP-only nodes.
6.1. Finding Other Nodes
At this stage, old IPv4 nodes will not be able to communicate with
new SIPP-only nodes.
Also, SIPP+IPv4 nodes which have not yet acquired non-zero prefixes
will not be able to communicate with new SIPP-only nodes.
6.2. SIPP Services
No new service issues arise.
6.3. Configuration Servers
The zero prefix address form will not be registered, since no IPv4
address is registered.
The DNS will now carry at least 3 records for each SIPP+IPv4 node --
the IPv4 address, the leading zero prefix SIPP equivalent, and the
Administrative Domain prefixed SIPP equivalent.
Simpson expires in six months [Page 11]
DRAFT SIPP Deployment July 1994
6.4. Encapsulation in IPv4
No new encapsulation issues arise.
6.5. Mobility
No new mobility issues arise.
6.6. Security
No new security issues arise.
6.7. Installation/Configuration Consequences
SIPP-only nodes must always be located where SIPP routing is
completed. Such nodes are not required to continue to support IPv4
features such as ARP, FTP PORT, and other anachronisms.
7. Addressing Summary
Each target SIPP node must be identified by an SIPP identifying-
address.
Each node should be capable of a creating a local-use SIPP address,
that indicates no topological information, which can be used as a
return address when communicating with target nodes on the same link.
The local-use address need only be unique within the scope of the
link.
A special class of SIPP addresses is needed which map to the
broadcast or multicast capability of the link.
A special class of SIPP addresses is needed which are preassigned to
the various services. These addresses would map to the broadcast or
multicast capability of the link.
Until IPv4 addresses are exhausted, SIPP addresses should contain
embedded IPv4 addresses, with a leading zero prefix to extend to the
new size. The SIPP routing prefix is automatically derived from the
IPv4 prefix mask.
Simpson expires in six months [Page 12]
DRAFT SIPP Deployment July 1994
A non-zero prefix indicates that the node has reached SIPP inter-
domain routability. This address is not required to contain an
embedded IPv4 address.
The plan is accomplished without header translation, or mapping of
addresses.
The plan does not preclude new routing paradigms after Stage Two.
References
[1] Malamud, "Exploring the Internet", pp 149-150, 1992.
Acknowledgements
Chair's Address
The working group can be contacted via the current chairs:
Author's Address
Questions about this memo can also be directed to:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com
Simpson expires in six months [Page 13]
DRAFT SIPP Deployment July 1994
Table of Contents
1. Introduction .......................................... 1
1.1 Assumptions ..................................... 1
2. Stage Zero -- Basic Facilities ........................ 1
2.1 Finding Other Nodes ............................. 2
2.2 SIPP Services ................................... 2
2.3 Configuration Servers ........................... 3
2.4 Security Issues ................................. 3
2.5 Installation/Configuration Consequences ......... 4
3. Stage One -- No SIPP Routers .......................... 4
3.1 Finding Other Nodes ............................. 4
3.2 SIPP Services ................................... 5
3.3 Configuration Servers ........................... 5
3.4 Security Issues ................................. 5
3.5 Installation/Configuration Consequences ......... 5
4. Stage Two -- Intra-Domain SIPP+IPv4 Routers ........... 5
4.1 Finding Other Nodes ............................. 6
4.2 SIPP Services ................................... 7
4.3 Configuration Servers ........................... 7
4.4 Encapsulation in IPv4 ........................... 7
4.5 Mobility ........................................ 8
4.6 Security ........................................ 8
4.7 Installation/Configuration Consequences ......... 8
5. Stage Three -- Inter-Domain SIPP+IPv4 Routers ......... 9
5.1 Finding Other Nodes ............................. 9
5.2 SIPP Services ................................... 10
5.3 Configuration Servers ........................... 10
5.4 Encapsulation in IPv4 ........................... 10
5.5 Mobility ........................................ 10
5.6 Security ........................................ 10
5.7 Installation/Configuration Consequences ......... 11
6. Stage Four -- Depleted IPv4 Addresses ................. 11
6.1 Finding Other Nodes ............................. 11
6.2 SIPP Services ................................... 11
6.3 Configuration Servers ........................... 11
6.4 Encapsulation in IPv4 ........................... 12
6.5 Mobility ........................................ 12
6.6 Security ........................................ 12
6.7 Installation/Configuration Consequences ......... 12
7. Addressing Summary .................................... 12
Simpson expires in six months [Page ii]
DRAFT SIPP Deployment July 1994
REFERENCES ................................................... 13
ACKNOWLEDGEMENTS ............................................. 13
CHAIR'S ADDRESS .............................................. 13
AUTHOR'S ADDRESS ............................................. 13
------------------------------------------------------------------------------
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) Deployment and Routing William Allen Simpson