Internet Draft TUBA Transition Plan 4 March 1994
Transition Plan for TUBA/CLNP
(draft-ietf-tuba-transition-00.txt)
4 March 1994
David M. Piscitello
Core Competence, Inc.
dave@corecom.com
Status of this Memo
This memo is an Internet Draft. 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 August 31, 1994.
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.
Abstract
The ARPA internet protocol suite -- commonly referred to as
TCP/IP (after the core protocols, Transmission Control
Protocol [1] and Internet Protocol [2]) -- is arguably the
most widely used, wide area internetworking solution in the
world today. Availability of on-line documentation, multiple
vendor-interoperable implementations, and an internationally
connected private and commercial infrastructure have most
recently contributed to remarkable growth in the size of the
global IP-based Internet. Deployment of IP-based networks
and hosts cannot continue at the present pace unless certain
addressing, protocol and operational limitations are
corrected. Two problems of immediate concern are: (i)
Internet backbone and regional networks suffer from the need
to maintain large and growing amounts of routing
information;and (ii) the Internet is gradually running out
of IP network numbers to assign.
CIDR [3] offers temporary relief from problem (i). This
affords the Internet community time to develop and deploy an
approach to addressing and routing which allows scaling to
several orders of magnitude larger than the existing
Internet.
Piscitello Expires 28 August 1994 Page 1
All proposed solutions to these problems introduce
fundamental (protocol levels of) change to various
components of the Internet architecture (internet layer,
applications), as well as administrative and operational
changes. The large installed base of IP version 4 (IPv4)
hosts and IPv4-based internets dictates that new systems
which are IP "next generation" (IPng) capable must co-exist
with IPv4 systems for an indeterminable transition period.
It is necessary for changes of this magnitude to be deployed
in an incremental manner. This allows a graceful transition
from the current Internet without disruption of service. It
is also necessary to continue and extend the lifetime of
IPv4, in order to minimize network disruption during the
migration period from the current IPv4-based Internet to one
that is IPng-based. This paper discusses the transition
strategy from the current IPv4-based Internet to one based
on the use of ISO/IEC 8473, CLNP, and TUBA [4,5],
hereinafter referred to as TUBA/CLNP.
1. Introduction
This paper discusses a strategy for a transition from IPv4
to CLNP that meets the following generalized IPv4-to-IPng
goals:
a) Provide for interoperation between IPv4-only systems and
IPng capable systems
b) Provide a simple transition for network operators, sites
and end users
c) Minimize the introduction of new technologies
d) Minimize the introduction of new Internet operational
concepts and methods
e) Minimize interdependencies between IPv4 and IPng, which
should minimize the need for synchronization points
during transition and provide end users the flexibility
to transition when they need to
f) Minimize the impact on existing applications and
programming interfaces
Several techniques have been proposed for the general case
IPng transition. These techniques fall into three
categories:
1) Evolution from a dual internet protocol environment to an
integrated network layer (i.e., IPv4 and IPng eventually
reduced to IPng)
2) Tunneling (encapsulation of IPng over IPv4 and IPv4 over
IPng)
3) Network Address/Protocol Translation
In this paper, we recommend that the burden of transition
from IPv4 to CLNP/TUBA be supported using technique (1). The
focal point of this transition strategy is thus the
implementation of both IPv4 and CLNP network layers in hosts
and routers, initially described in RFC 1347, TUBA (See
Figure 1).
+------------------------+
| Internet |
| applications |
| (ftp,telnet,mail,etc.) |
+------------------------+
| tcp/udp |
+------------------------+
| | |
| IPv4 & | CLNP & |
| routing | routing |
| protocols | protocols |
+------------------------+
Figure 1. Dual stack
While encapsulation (technique 2) may be used where needed
and is explicitly supported, we seek to minimize its use.
The transition strategy described herein does not preclude
the use of translation techniques (3); translation is
sufficiently complicated that we try to avoid this
technique.
The remainder of this paper is organized as follows:
Chapter 2 details the scaling problems that TUBA is
designed to overcome.
Chapter 3 gives an overview of TUBA.
Chapter 4 describes the transition to TUBA/CLNP.
Chapters 5, 6, and 7 give detailed specifications and
requirements for the components of the transition-period
Internet.
Chapter 8 discusses remaining, general issues regarding
transition.
Chapter 9 shows a timeline for TUBA transition
Chapter 10 discusses security issues relating to the
network layer.
The reader can gain an understanding of TUBA and the
problems it attempts to resolve by reading chapters 2
through 4. Implementors should read chapters 5 through 9.
2. Problem Statement
The Internet is growing at a remarkable pace, and there is
every indication that this pace will continue to accelerate
at least through the end of this millennium. Such growth
could not be anticipated by the original designers of IP,
who should be applauded for providing an enabling vehicle
for internetworking that has endured beyond expectations.
Still, addressing design choices made over 2 decades ago are
now insufficient, and as a result, the Internet must
overcome two serious problems: (1) routing information
overload and (2) exhaustion of available IP network numbers.
The routing table overload problem can be summarized as
follows. Historically, IPv4 network numbers have not been
assigned in an hierarchical manner; organizations asked for
network numbers and the numbers were distributed according
to presumed (in many cases, conjectured!) "numbers of hosts"
needs and not according to any presumed hierarchy of
internetworked networks. Although this method of assignment
is no longer practiced, a consequence of this assignment
practice is that IPv4 routers assume the address space is
flat (i.e., that the network number(s) of neighboring
networks do not necessarily have any similarity in the IPv4
network portion of their address), and record routes to (and
maintain an entry for large numbers of networks in the
Internet. Thus, as the number of interconnected networks
increases, so does the size of routing tables, especially
for backbone networks (continentals, mid levels, regionals).
The address exhaustion problem can be summarized as follows.
Although 32-bits of the IPv4 address space can in theory be
used to identify about 4 billion nodes, this space has been
partitioned along octet boundaries to facilitate assignment
and aggregation into classes of networks (A, B, C, D),
thereby significantly reducing the number of addressable
hosts. The pool of available class B network numbers,
especially popular because there is a high ratio of
addressable hosts per network number, has depleted rapidly.
Exhaustion of other assigned network number spaces,
especially the Class C numbers, has increased rapidly since
a prudent assignment policy has been applied (to Class B's).
While opinions vary as to how long the available pool of
addresses will last, it is generally acknowledged that a
new, larger address space is required.
An additional consequence of changing the length of IP
addresses is that IP itself must be changed or replaced, as
it supports fixed length header fields for IP addresses. We
are thus forced to change the "core" Internet at its most
fundamental (internet) level, by introducing a successor to
IPv4, its addressing and routing architecture.
To make the transition from IPv4 to TUBA as smooth as
possible, the following objectives must be taken into
consideration:
1) The transition should impose a minimum impact on the end
users of hosts.
2) The transition should leverage as much of the users' and
administrators' investment in existing Internet
operations, training, terminology as possible. We should
recognize that users, administrators, and network
operators have made substantial investments in
"understanding" IPv4. Administrators and network
operators in many cases have made an investment in
"understanding CLNP". Neither investment should be
discounted or lost.
3) Users and network operators should be able to transition
at their own pace.
4) Users should be able to upgrade hosts and routers
incrementally.
5) Sites which deploy a dual stack environment should
accumulate the benefits and features of TUBA as they
deploy. For example a new TUBA host should be able to use
the auto-configuration mechanisms immediately.
6) The larger addresses of TUBA/CNLP should be used to solve
the IPv4 route scaling problem early on in the
transition.
7) The transition plan must provide complete, global
connectivity between TUBA and IPv4 hosts for as long as
IPv4 can provide global connectivity.
8) The transition plan should provide global connectivity
for IPv4 traffic for as long as necessary.
9) It should leverage the existing IPv4 routing and DNS
infrastructure wherever possible.
3. TUBA Overview
TUBA [4] solves the problems described in section 2 by
using:
1) OSI network service access point addresses (NSAPAs), a
flexible and extensible network addressing plan which
accommodates multiple administrations and multiple levels
of addressing hierarchy for routing purposes (see [6] and
[7])
2) OSI connectionless network layer protocol (CLNP), a
network layer datagram.
3) OSI routing protocols, which provide host/router
discovery and autoconfiguration (ES-IS, see [13]);
dynamic, (link-state) intradomain routing (IS-IS, see
[14]); and policy-based routing (see IDRP, [15]).
(4) RFC 1237 assignment guidelines, which describe an
addressing architecture based upon the use of prefix-
based address administration and routing. This
architecture supports aggregation of addresses by
country, by service provider, and by area. This allows
for substantial route aggregation, and appears to scale
to a very large Internet. (RFC 1237 guidelines have been
adapted for IP and form the basis for CIDR allocation and
deployment strategies for the IPv4-based Internet.)
TUBA allows the current Internet applications -- Telnet,
SNMP, FTP, SMTP/822 electronic mail, and the internet
information retrieval navigators and services (WAIS, WWW,
gopher, prospero, archie, veronica, netfind, finger) -- to
operate using native transport protocols -- UDP and TCP --
on top of CLNP in place of IPv4.
TUBA replaces the IPv4 network layer (datagram and routing
protocols) with CLNP [8], ES-IS [13], IS-IS [14], and IDRP
[15]). The architectural features and functionality of CLNP
is nearly identical to that of IPv4 (see [5] for an overview
and comparison). CLNP accommodates variable length
addresses, provides fundamentally the same level of service
as IPv4 (see [8]), and with the addition of [9, 10, 11],
meets IPng selection criteria described in [12]. [5] defines
the use of CLNP in TUBA environments, providing the rules
for network layer protocol and pseudo-header composition,
application of the PROTOcol mechanism in the CLNP header,
and the use of the CLNP error reports as replacements for
corresponding ICMP messages. The CLNP, and transport header
layout is summarized as follows:
+------------------------+
| data link layer header |
+------------------------+
| CLNP header |
| (NSEL=PROTO=TCP) |
+------------------------+
| TCP |
+------------------------+
Figure 2. Header layout for TUBA/CLNP
CLNP is already understood by most developers of Internet
products and by many operators of backbone regional/mid
level, and attached (client) networks in the Internet
infrastructure. CLNP implementations exist today for most
host and router systems. The routing architecture (a) is
similar to that implemented for IPv4 (OSPF vs. IS-IS, BGP-4
vs. IDRP). A major advantage of using CLNP as a replacement
for IPNG is that the routing architecture has already been
specified, standardized, implemented in products, and
deployed in large-scale production networks.
As the Internet evolves it may be necessary to enhance the
routing system to introduce new capabilities, such as
support for mobility, multicast, flows, and provider based
selection. Many of these capabilities can be implemented in
CLNS using techniques and protocols analogous to those
applied in the IPv4 context. Several of these enhancements
([9], [10], [11]) are currently under investigation within
the IETF.
CLNP is distinguished from IPv4 by its use of flexible,
variable length network addresses, or NSAPAs (see [6] and
[7]). These addresses are already applied in those portions
of the global Internet that offer CLNP connectivity
according to guidelines developed within the IETF (see RFC
1237). The assignment and allocation guidelines defined in
RFC 1237 formed the basis for the development of CIDR [3].
Although the referenced addressing documents specify a
maximum NSAPA length of 20 octets, formats that accommodate
larger addresses can be added by the introduction of
additional authority and format indicators (AFIs) in [6],
and CLNP will accommodate these longer addresses as well.
This satisfies the IPng objective of effectively unlimited
addressing (if not already satisfied by the generous 20-
octet addresses available). A significant advantage of
NSAPAs is that they can be structured in a manner that
allows embedding other network layer addresses, such IPv4
and Novell IPX (see [16] for a description of how these may
be encoded as system identifiers (or globally unique
endpoint identifiers) within an RFC 1237 compliant NSAPA).
4. Transition to TUBA/CLNP
The TCP/IP Internet is a large and complex system. However,
the operation of the Internet is based on a very simple
notion: ubiquitous end to end connectivity provided by a
single datagram network layer protocol. This simple building
basis for the Internet is a major part of the its success.
An important lesson in the design and deployment of very
complex systems is that very large, complex, and highly-
interdependent systems are difficult to deploy and manage.
Even in those rare circumstances where one might succeed in
deploying such a system, it becomes difficult or impossible
to update one part of the overall system without upsetting
other parts of the system.
The transition from IPv4 to CLNP will be gradual, and will
be accomplished over an extended but as yet indeterminable
period of time. During this time frame, both IPv4 and CLNP
may need to be updated to respond to new requirements. If
the end-to-end operation of IPv4 is dependent upon CLNP, and
if end-to-end operation of CLNP is simultaneously dependent
upon IPv4, then it may become very difficult to update both
protocols to respond to new requirements over time (this is
true in general for any IPng).
An important consideration for the transition from IPv4 to
CLNP is thus to minimize the overall complexity of the
system, and to simultaneously minimize the interdependencies
between these major parts of the system. TUBA places a new
network layer beside IPv4 in new (and all future) system
implementations. New hosts continue to communicate with IPv4-
only hosts over an IPv4 infrastructure which remains fully
operational (in parallel with the new infrastructure) until
such time as the IPv4 address space is depleted. At such
time, it is expected that the vast majority of systems will
be CLNP-capable, and IPv4 communication may be phased out.
(Note that the decision to turn off IPv4 ultimately lies in
the hands of individual administrations; the transition plan
imposes no timeframe for IPv4 shutdown.)
The presence of a second network layer protocol in the
Internet is nothing news(worthy). Multiprotocol
internetworking is very much the norm in today's complex
internets (see RFC 1560 [20]). It is common to find networks
that support 5 or more protocol stacks (including TCP/IP,
IPX, Appletalk, SNA/APPN, DECnet, CLNP, and others). Network
managers are used to deploying and managing multiple
independent protocol stacks. The routers and hosts from all
major vendors already support multi-stack operation. The
TUBA transition scheme therefore makes use of techniques and
concepts with which network managers and implementors are
already familiar.
The TUBA transition plan acknowledges that host software
will be the gating function of any transition due to the
large number of Internet hosts compared to routers. The
components of the transition are as follows:
1) The routed infrastructure is upgraded to support CLNP.
Routers not already capable of doing so must be updated
(or configured) to support forwarding of both IPv4 and
CLNP packets. (Routing and forwarding of IP and CLNP
packets may be done independently, or at the discretion
of a routing domain administration, integrated routing
[21] may be used.)
2) The Domain Name System is upgraded to support NSAPAs. DNS
servers are modified to return NSAP addresses (DNS
systems must continue to support IPv4 name-to-address
resolution). Initially, DNS will operate over IPv4
service.
3) TUBA/CLNP is introduced as new host software is deployed,
and internet applications are operated over TUBA/CLNP
(new host software is expected to support TCP/UDP over
IPv4 and CLNP).
4) CLNP connectivity is provided to all sites.
5) The network is "swamped" with TUBA/CLNP-capable hosts.
6) DNS support is moved onto the CLNP infrastructure.
7) Production networks operate over the CLNP infrastructure.
A detailed timeline for the transition plan is provided in
Section 9.
TUBA transition is compatible with (and independent from) a
wide range of techniques for extending the life of the "pure
IPv4" Internet. (Discussion of techniques that have been
proposed for this purpose can be found in [22], [23], [24].)
4.1. Dual Stack Operation
Figure 4 illustrates the basic operation of TUBA transition.
Illustrated is a single Internet routing domain, which is
also interconnected with Internet backbones and/or
regionals. The two "updated" Internet Hosts, N1 and N2, must
be able to send either old-style packets (using IPv4), or
new style packet (using CLNP). N1 and N2 thus communicate
with old Internet hosts using the current Internet suite
unchanged, and with other updated Internet hosts using CLNP.
Which to send is determined via the name-to-address lookup
mechanism. (Although we rely on the DNS in this example, the
transition plan does not actually depend upon the DNS for
its operation. Any method that is used for obtaining
Internet addresses; e.g., statically configured tables) may
be updated to be able to return both IPv4 and NSAP addresses
when queried with a domain name.)
Figure 4 illustrate two older hosts H1 and H2, plus a DNS
server, plus two border routers, R1 and R2. Routers internal
to the routing domain are capable of forwarding both IPv4
and CLNP traffic (this could be done either by using multi-
protocol routers which can forward both protocol suites; by
using a different set of routers for each suite; or by using
tunneling/encapsulation as described in section 4.2).
............. ...................
: : : :
: : : :
: H1 : : Internet :
: :----R1----: :
: H2 : : Backbones :
: : : :
: DNS : : :
: : : and :
: N1 : : :
: : : Regionals :
: N2 :----R2----: :
: : : :
:...........: :.................:
Key
DNS DNS server
H IP host
N Updated Internet host
R Border Router
Figure 4 - TUBA transition
Thus, in case (1), suppose that host N1 wants to communicate
with host H1. In this case, N1 asks its local DNS server for
the network address(es) associated with H1. Since H1 is an
older (not-updated) host, the address available for H1 is an
IPv4 address, and thus the DNS response returned to N1
specifies an IPv4 address. On the basis of the address
returned, N1 knows that it must use an IPv4 packet to
communicate with H1.
Suppose (case 2) host N1 wants to communicate with host N2.
Again N1 contacts the DNS server. If the routers in the
domain have not been updated (to forward CLNP), or if the
DNS resource record for N2 has not been updated to include
NSAPAs, then the DNS server will respond with an IPv4
address, and communication between N1 and N2 will use IPv4.
However, assuming that the routers in the domain have been
updated (to forward CLNP), that the DNS server has been
updated (to be able to return NSAP addresses), and that the
appropriate resource records for NSAP addresses have been
configured into the DNS server, then the DNS server will
respond to N1 with the NSAP address for N2, allowing N1 to
know to use CLNP (instead of IPv4) for communication with
N2.
To assure that the assumptions for case 2 are satisfied
prior to attempting communication using CLNP, network
administrators are encouraged to register NSAPAs of
TUBA/CLNP hosts in the DNS (or other name->address system)
only after CLNP connectivity is provided to these hosts.
CLNP connectivity may be provided at some points in the
Internet via tunnels, but this is assumed to be an interim
step while native CLNP connectivity is being arranged. The
means by which TUBA systems communicate with IPv4 and other
TUBA systems are summarized in the following table:
+-----------+-----------+--------------+----------+
| ORIGIN | RECIPIENT | DNS_REPLY | USE |
+===========+===========+==============+==========+
| IPv4 host | IPv4 host | IPv4 addr | IPv4 (1) |
+-----------+-----------+--------------+----------+
| IPv4 host | TUBA host | IPv4 addr | IPv4 (1) |
+-----------+-----------+--------------+----------+
| TUBA host | IPv4 host | IPv4 addr | IPv4 (1) |
+-----------+-----------+--------------+----------+
| TUBA host | TUBA host | IPv4 addr | IPv4 (2) |
+-----------+-----------+--------------+----------+
| TUBA host | TUBA host | IPv4 addr, | CLNP (3) |
| | | NSAP addr | |
+-----------+-----------+--------------+----------+
Table 1. Framework for TUBA host communication
Notes:
1) end-to-end IPv4 connectivity not available, can use CLNP
to tunnel IPv4 [19]. This is viewed as necessary to
support "legacy (IPv4)" hosts.
2) this is the situation where the destination host is not
yet reachable via CLNP; the destination NSAPA is not
registered and cannot be obtained via a DNS lookup.
3) use IPv4 tunnel [18]. This is viewed as necessary when
CLNP connectivity is not available between originator and
recipient.
The Internet has several infrastructural components which
must have dual stack functionality (eventually, see the
timeline in section 9):
- Network Service Providers
- The Domain Name System (DNS)
- The Internet address and name assignment function (NICs
and IANA).
- Hosts
Many campus, enterprise network, and Internet transit
networks (NASA Sciences Internet, Energy Sciences Network,
Alternet, SURANET, Sesquinet, the Italian Research
Network/INFN, Switch, etc.) already route and forward
multiple network layer protocols at the same time, including
CLNP. The presence of this operational infrastructure
provides an accelerated baseline for deployment.
4.1.1 Network Service Providers
A commonly overlooked component in IPng transition is the
need to coordinate routing for protocols other than IPv4.
This coordination creates well known "interconnects" (e.g.
FIX, CIX, GIX, NAP, etc.) and provides routing registration
anddissemination as done by Merit/NSFNET, the Ripe NCC and
the Japanese JPNIC. The current interconnects already switch
multiple protocols, including CLNP. The schema for the
current set of databases for the routing registration and
dissemination function has been extended to include CLNP
addresses and prefixes (e.g. network numbers). Standard CLNP
operations practices are also in place.
4.1.2 Updating DNS Infrastructure
In the current Internet architecture the DNS maps between
Internet names and IPv4 addresses. The DNS must be extended
to also support NSAP addresses. Prototype implementations of
DNS servers and resolver libraries that can support multiple
address types are available for TUBA/CLNP.
DNS servers shall operate on the IPv4 routed infrastructure
until the CLNP transition is complete since IPv4-only hosts
will always generate IPv4 specific DNS queries. DNS queries
shall by default use IPv4 connectivity unless explicitly
configured to use CLNP connectivity (transition to use of a
CLNP-routed infrastructure shall thus be governed by a
configuration option for DNS servers). The DNS server
implementations must eventually be updated to run on top of
a multiprotocol Internet.
DNS clients will use the same method of choosing the active
network layer protocol as other host applications. This is
detailed in section 4.1.4.
4.1.3 Internet address and name assignment functions
Guidelines exist for the assignment of NSAPAs in the
Internet [7]; assignment of NSAPAs shall continue under
these guidelines. The current practices for assignment of
IPv4 addresses shall remain in place (only refinements and
extensions to CIDR allocation are expected to influence
current practices). Domain name assignment is unaffected by
this plan.
4.1.4 Dual stacks and hosts
A general discussion of the implications of IPng
implementation on hosts can be found in [39]. The impact on
host run-time resources for TUBA hosts is under
investigation, but preliminary results indicate that memory
requirements to support the CLNP network layer alongside
IPv4 should not be a barrier for low-end hosts.
Dual internet protocol support in hosts requires
coordination and control on the part of implementors, system
administrators, users, and network administrators. Internet
applications (the business of hosts) must be re-engineered
to selectively use either stack during transition. If DNS is
used, then as a rule, the host should be registered in the
DNS as an IPv4-only system until such time as it intends to
make use of CLNP. Thereafter, selection of network layer
should be under local control.
A helpful abstraction for local control is the notion of a
soft switch or knob on a host that controls its (network
layer) operation. For example, a knob should have 4
settings:
(1) IPv4 only. The host operates over IPv4-only. This is the
default setting (the only logical state of IPv4-only
hosts).
(2) Prefer IPv4. The host is capable of obtaining both IPv4
and NSAP addresses from the DNS (or other name-to-
address resolver), but given a choice, it will always
use an IPv4 path. Under this setting, the host is
registered as a dual stack host, but expects the
majority of communication it initiates to be IPv4 (i.e.,
most of the servers it expects to contact are reachable
via IPv4). Server applications on host may also accept
incoming connections over CLNP paths.
(3) Prefer CLNP. As in (2), the host is capable of obtaining
both IPv4 and NSAP addresses from the DNS (or other name-
to-address resolver), but given a choice, it will always
use an CLNP path. Under this setting, the host is
registered as a dual stack host, but expects the
majority of communication it initiates to be CLNP (i.e.,
most of the servers it expects to contact are reachable
via CLNP). Server applications on host may also accept
incoming connections over IPv4 paths.
(4) CLNP only. The end state of transition. All hosts in the
Internet are CLNP-capable.
4.2 TUBA Tunnelling
OSI and TUBA/CLNP hosts and routers have used the EON
tunneling protocol [17] to carry CLNP packets over regions
of the Internet that route only IPv4 packets for several
years. The subset of the EON protocol as implemented and
fielded today is a virtual point-to-point encapsulation of
CLNP datagrams between statically configured tunnel
endpoints. (There is no support for simulating a multipoint
subnetwork, nor for dynamic mapping between NSAP addresses
and IPv4 addresses; IPv4 addresses are treated as subnetwork
point of attachment addresses that must be statically
configured to create the tunnel.) Once a tunnel is
established, the ES-IS [13] and IS-IS [14] protocols are
used to dynamically establish neighbor adjacencies and
routing.
The encapsulation is as follows:
+--------------------------+
| IPv4 header |
| (protocol = 80 decimal) |
+--------------------------+
| EON header | (value = hex 01 00 FC 02)
+--------------------------+
| OSI Network Layer packet |
+--------------------------+
Figure 3. EON encapsulation
Tunneling is one of the mechanisms that will be employed
during the IPv4-CLNP transition period to connect:
a) TUBA hosts, in those circumstances where native CLNP
transport is not available (i.e., across routing domains
that have not introduced a CLNP backbone)
b) IPv4 hosts, at such time where global IPv4 connectivity
is no longer available, and IPv4 hosts in separated
(isolated) routing domains must use the CLNP backbone for
transport
[18] describes the encapsulating protocol that should be
applied when CLNP is the "payload packet" within an IPv4
datagram.
[19] describes a generic encapsulating protocol that may be
applied when IPv4 is the "payload packet" within a CLNP
datagram.
The TUBA transition plan does not require the translation
between IPv4 and CLNP network layer datagrams. Appendix A
discusses issues and unresolved concerns that form the basis
for the decision not to use translation.
5. Multiprotocol routers
TUBA relies on the existence of multiprotocol routers --
routers that can forward (at least) IPv4 and CLNP datagrams.
Multiprotocol routers are available, widely deployed and
eminently tractable technology. (Note: one can certainly use
separate routers and topologies to switch IPv4 and CLNP, if
this is desirable or necessary.)
During the transition, certain routers may be expected to
support tunnels; i.e., to support the forwarding of CLNP
datagrams by encapsulating them in IPv4 packets.
Details of the tunneling mechanisms for TUBA are described
in separate documents (see [18] and [19]). Section 9
discusses the timeline for CLNP and tunnel deployment for
TUBA transition.
6. TUBA and address translation.
Prudent allocation of IPv4 addresses and application of CIDR
provides a "grace period" for the development and selection
of an IPng; eventually, however, the IPv4 address space will
become inadequate for global routing and addressing, and
IPv4-only hosts will no longer be able to interoperate
directly over the global Internet.
6.1 When 32-bit addresses run out
Some administrations may wish to extend the lifetime of IPv4
addressing (and hence IPv4) beyond this point in time. There
are several approaches that may be used (separately, or in
combination) for continued operation of IPv4 under these
circumstances. One method involves splitting the IPv4
Internet into a number of "local address domains". 32-bit IP
addresses will be meaningful only within a local address
domain. This allows the old IPv4-only hosts to communicate
locally. For communication between local address domains,
systems may use (a) a convergence protocol and addressing
extensions (e.g., IPAE); (b) translation to a common, future
protocol (e.g., CATNIP); (c) tunnels established
specifically for this purpose (providing all the addresses
at tunnel endpoints remain unique); (d) application relays
(again, in the case where applications manipulate IPv4
addresses, all the addresses at tunnel endpoints must remain
unique); or (e) network address translation.
The dual internet protocol transition allows migration to
CLNP to be performed independently from "life support" for
the old IPv4 address space; i.e., a variety of means may be
used to maintain IPv4 connectivity for as long as this is
economically and technically feasible without disrupting
migration to IPng. The dual stack environment present during
the transition from IPv4 to CLNP will not interfere with
such attempts to maximize the lifetime of IPv4 internets,
nor would it interfere with attempts to recycle (re-use) or
further extend the aggregation properties of the current 32-
bit address space (i.e., by extending CIDR policies to class
A addresses).
At this time, we do not recommend translators for the
transition from IPv4 to TUBA/CLNP.
6.2 Turning down the IPv4 infrastructure
There are at least two perspectives regarding the issue of
how to phased out IPv4:
1) In "n" years, IPv4 should be turned off. Given the
current rate of Internet growth, plus the possibility of
updating existing systems, the number of IPv4-only systems
will be dwarfed by the number of IPng systems, and the
impact will be small.
2) There will be sufficient permutations and combinations of
IPv4 lifetime extensions implemented that "n" is likely to
approach infinity.
Nothing in this transition plan forces an administration to
turn off IPv4 at any given time "t". Under the plan
specified herein, IPv4 and CLNP may co-exist "forever".
7. TUBA/CLNP Hosts
TUBA/CNLP hosts must implement CLNP, ES-IS, and several
additional modifications to run "dual-stack". The
modifications affect the internet and transport layers of
the protocol software, and the application program interface
(API) offered by the transport layer. Some internet
applications must change as well, especially those that make
direct use of IPv4 addressing rather than domain names.
Dual stack hosts must be able to transmit and receive both
CLNP and IPv4 packets; resolve network addresses of
destinations to hardware addresses. Dual stack hosts may
also be expected to request configuration information from
servers, and request auto registration of domain names and
addresses (see sections 7.2 and 7.3).
7.1. What packet format to send.
The first decision a host must make is which form of packet
to transmit: IPv4 or CLNP. This may be accomplished through
a local (to the host) configuration switch (which reflects
the default or desired state of the global connectivity),
and could be set at various granularities (i.e., on switch
per host, per destination).
7.2. Transport pseudo-header checksum.
TCP and UDP both define a checksum that covers the data
portion of the segment along with a 96-bit "pseudo header"
that includes the IPv4 source and destination addresses,
protocol ID and length fields from the IPv4 header.
Including this pseudo header in the transport checksum
protects the transport layer against misrouted segments.
The pseudo header used in the transport checksum when TCP
and UDP are layered above CLNP is described in [5].It
includes the source and destination NSAP addresses
(including selectors, protocol ID, length fields from the
CLNP header.
7.3. TCP and UDP connection identification for TUBA hosts
TCP uses the concatenation of local and remote IPv4 address
with local and remote port number to uniquely identify a
connection. TCP uses the term "socket" to identify one
endpoint of a connection. The local socket is identified by
the local IPv4 address and local port number, while the
remote socket is identified by the remote IPv4 address and
remote port number. This path is unaffected when a dual
stack host communicates with IPv4-only host. This is also
true when
dual stack hosts process received segments and ICMP error
messages.
When communicating with another dual-stack host, TCP uses
the full source and destination NSAP addresses and
local/remote port numbers to identify connections and
sockets.
7.4. Error and Control Messages
Systems involved in the forwarding of IPv4 datagrams shall
continue to use ICMP for error and control messages. Systems
involved in the forwarding of CLNP datagrams shall use CLNP
error report messages. [5] defines the mapping between ICMP
message types and CLNP error report types. Currently, there
are no corresponding CLNP Error Report Codes for the
"Protocol Unreachable" and "Port Unreachable". These should
be assigned from the code points available in the error
report type code block in ISO/IEC 8473.
The use of ICMP shall continue unchanged. CLNP error reports
should include the "offending packet" in the data part of
the packet. The "offending packet" should include the CLNP
header plus at least the first 8 octets of the packet that
caused the error being reported. The offending packet is
used by the recipient of the ICMP error message to locate
the transport-layer endpoint that caused the error.
NOTE: ISO/IEC 8473 only guarantees that the entire header of
the offending packet shall be returned; thus, if the
minimumm MSS of 512 octets is used, and the combined lengths
of the error report header and the offending packet header
exceed 504 octets, fewer than 8 octets of data would be
returned.
7.5. Transport API changes.
Most IPv4 systems that are modified to support TUBA/CLNP
will already have an existing application program interface
(API) through which applications use TCP and UDP, and many
will already have an API through which applications use OSI
transport protocols (e.g., those that support XTI). For
IPv4, these APIs typically carry a 32 bit IPv4 address in
order to bind a TCP or UDP endpoint to a local address, to
specify the destination address of a UDP datagram being
sent, or to specify the destination address of a TCP
connection being opened. The 32 bit IPv4 address shows up in
other parts of the API, such as the return value from a
hostname-to-IPv4 address lookup function. Generally, these
APIs provide fixed-size fields to hold IPv4 addresses and
TCP and UDP port numbers. These APIs must modified be to
carry variable length NSAP addresses in order to support
TUBA/CLNP.
We do not impose any specific requirements on how the APIs
should be changed to support TUBA/CLNP. However, we offer
here some general considerations in designing these new
APIs.
Some desirable features of a dual stack API are:
1) The new API should allow applications to pass in both 32-
bit IPv4 addresses and variable length addresses. (New
applications are likely to encounter 32 bit IPv4
addresses.)
2) The new API should provide both source and binary
compatibility with the existing IPv4 API. Applications
written to the old API should continue to operate when
run in binary form, or when re-compiled on an dual stack
system with the new API.
3) Un-modified applications should provide as much TUBA/CLNP
service as possible.
4).Application protocols that do not manipulate IP addresses
should run without any modifications.
Along with the API changes, application programs that
manipulate IPv4 addresses must usually be modified. Often
these changes can be isolated to the code that parses NSAP
addresses typed in by users, and the code that deals with
NSAP addresses returned by the name to address translation
functions (DNS lookups).
7.6. IPv4 Addresses Embedded in Application Protocols
In this section, we specify how hosts should use existing
application protocols in a dual stack environment. (Note
that this section discusses protocol changes only; changes
to user interfaces, i.e., changes to APIs, the use of an
"NSAPA domain-literal" instead of an IPv4 domain-literal in
a command line for telnet, etc. are not discussed here).
The application protocols layered above TCP and UDP fall
into four categories:
1) Application protocols that do not carry embedded IPv4
addresses. These protocols can be used immediately by
TUBA hosts. The protocols which require no changes are:
Telnet (RFC 854, RFC 855)
TFTP (RFC 1350)
BSD "rlogin" protocol (RFC 1282)
BSD "rsh" protocol (uses port number, not IP addr)
BSD "biff" protocol (in.comsat)
BSD "lpr" protocol (RFC 1179)
BSD "syslog" protocol
ONC RPC protocol (RFC 1057)
ONC original "portmap" protocol (RFC 1057)
ONC+ new "rpcbind" protocol (replaces portmap)
Echo - TCP & UDP (RFC 862)
Discard - TCP & UDP (RFC 863)
Chargen - TCP & UDP (RFC 864)
Quote of the Day - TCP & UDP (RFC 865)
Active users - TCP or UDP (RFC 866)
Daytime - TCP or UDP (RFC 867)
Time - TCP or UDP (RFC 868) Nicname/Whois (RFC 954)
Finger (RFC 1288)
SNMP (RFC 1157)
Concise-MIB (RFC 1212)
Content type mail header field (RFC 1049)
NNTP (RFC 977)
BSD "rexec" protocol
NTP (RFC 1119)
NFS
2) Application protocols that carry IPv4 addresses, but the
protocol or its use of IPv4 addresses is obsolete. These
protocols do not need to be changed. They can continue to
be used by TUBA hosts indefinitely. The protocols which
carry IPv4 addresses, but do not need to be changed
because their use of IPv4 is obsolete are:
SMTP (RFC 821)
Mail (RFC 822)
BSD "talk" protocol
3) Application protocols that carry IPv4 addresses, but that
are used exclusively by IPv4 systems. These protocols
need not be changed, although new versions of them may be
necessary in order to support the same function in
TUBA/CLNP systems. Protocols that fall into this category
are:
IP Forwarding table MIB (RFC 1354)
RARP (RFC 903)
BOOTP (RFC 951, RFC 1084)
DHCP (RFC 1531)
PPP IP address negotiation options
ONC "bootparams" RPC protocol
DNS (RFC 1034, RFC 1035)
Traceroute
Ping (Echo)
4) Application protocols that carry IPv4 addresses, but that
are not IPv4 specific. FTP falls into this category.
Systems which implement [25] will provides FTP
functionality when used by TUBA/CLNP systems.
We did not have enough information to evaluate these
application protocols:
Kerberos
Telnet options
POP3 (RFC 1225)
DNS mail routing (RFC 974)
MIME (RFC 1341)
The remainder of this section discusses how dual stack hosts
should accommodate those application protocols which
manipulate IPv4 addresses.
7.6.1. FTP
IPv4 addresses are encoded in FTP in two places:
- the arguments to the PORT command.
- the reply to the PASV command.
Both the argument to the PORT command and the reply to the
PASV command contain a 32-bit IPv4 address and a 16-bit TCP
port number.
These commands are used for two specific purposes:
1) In a 2-party FTP transaction, the client uses the PORT
command to specify a TCP port number on the client's
machine other than the default (port 20) for the server
to connect back to the client on.
2) In a 3-party FTP transaction involving one client FTP and
two server FTPs. The client gives the PASV command
command to FTP server 1 and records the address reply.
Then it sends the PORT command command to FTP server 2,
giving the address returned by server 1. Then it sends
the STOR or RETR command to server 2 to transfer file(s)
directly between server 1 and server 2.
[25] describes general extensions to FTP that enable hosts
to operate the application using addresses other than 32-bit
IP addresses, including variable length NSAPAs.
7.6.2. SMTP (RFC 821) and Mail (RFC 822)
IPv4 addresses may appear in the RFC 821 HELO reply codes
and RFC 822 mail header format in the "domain literal"
address construct. It is possible to specify a domain
address as a dotted-decimal address. For example, one could
specify a mail user in an 822 encoded mail header as:
beavis@[10.9.9.1]
This construct is specified in section 6.2.3 of RFC 822. The
RFC includes the following warning:
"Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.
It is permitted only as a means of bypassing temporary
system limitations, such as name tables which are not
complete."
It is recommended that the campaign to "discourage" the
domain-literal address construct continue. We do not
recommend that the domain-literal address construct syntax
be modified to support NSAP addresses. Domain literal
addresses will still be useful globally so long as IPv4
addresses are globally unique.
Some systems perform a reverse DNS lookup to ensure that the
source IPv4 address maps to the source DNS name contained in
the mail header as a form of very weak authentication.
Implementations may require extensions to perform this
function using NSAPAs, if desirable.
7.6.3. Domain Name System (DNS)
There are two places within the DNS where IPv4 addresses are
encoded:
- The "A" record format.
- The structure of the "in-addr.arpa" tree.
A new resource record type is defined for NSAP addresses
[26]. [26] also describes how the PTR resource record used
under the "IN-ADDR.ARPA" domain may be used to map from
NSAPAs to domain names (under the ".NSAP" domain). New hosts
ask for both the new (NSAPA) and old (IPv4 address) resource
records. Older DNS servers will not have the new resource
record type, and will therefore respond with only IPv4
address information. Updated DNS servers will have the new
resource record information for the requested DNS name only
if the associated host has been updated (otherwise the
updated DNS server again will respond with an IPv4 address).
Hosts and/or applications which do not use DNS operate in a
similar method. For example, suppose that local name to
address records are maintained in host table entries on each
local workstation (i.e., in a hosts.txt file). When a
workstation is updated to be able to run Internet
applications over TUBA/CLNP, then the host table on the host
may also be updated to contain updated NSAP addresses for
other hosts which have also been updated ([37] describes an
"osi host.txt" file format that should be used for OSI or
TUBA applications). The associated entries for non-updated
hosts would continue to contain IPv4 addresses. Thus, again
when an updated host wants to initiate communication with
another host, it would look up the associated Internet
address in the normal manner. If the address returned is a
32-bit IP address, then the host would initiate a request
using an Internet application over TCP (or UDP) over IP (as
at present). If the returned address is an NSAP address,
then the host would initiate a request using an Internet
application over TCP (or UDP) over CLNP.
The rules for hosts to contact DNS servers, and for DNS
servers to contact other DNS servers, are the same as for a
host to contact a host. Old (not updated) hosts use IPv4 for
all of these purposes. Updated hosts obtain the address of
their local DNS server the same way that they do at present.
If an updated (NSAP) address is returned, then they send DNS
requests over CLNP. If an old (IPv4) address is returned,
then they send DNS requests over IPv4. Similarly, DNS
servers contact DNS servers using either IPv4 or CLNP,
depending on the form of address that they obtain.
7.6.4. SMI, MIB-II
The SMI RFC defines a data type for the 32-bit IPv4 address.
This type is named "IpAddress". The MIB-II and some other
MIBs use this data structure. These definitions can remain
unchanged and can continue to be used by IPv4 hosts and
routers. A data type exists for variable length NSAP address
[27a, 27b, 27c]. A corresponding MIB table to those MIB
tables that include IP address data types must be defined
for TUBA/CLNP systems (this is preferred over modification
of the existing tables). These include:
tcpConnTable
udpTable
The SNMPv1 and SNMPv2 ASN.1 definitions for two new tables,
tcpTubaConnTable and udpTubaTable, are appended to this
transition plan for initial consideration. These will be
submitted at a future time to the IETF NM area.
7.6.5. RARP, BOOTP, DHCP, Bootparams
RARP, BOOTP, DHCP, and Bootparams are all used to support
booting. RARP, BOOTP, and DHCP all provide a mechanism for a
host to acquires its own IPv4 address. These protocols can
continue to be used without change by IPv4 systems.
A RARP equivalent function may be provided using the ES-IS
protocol [13]. BOOTP and DHCP must be revised to return
variable length NSAP addresses, or must incorporated into a
new host configuration scheme. The ONC RPC system includes a
versioning mechanism that should allow the revision of the
bootparams protocol in a compatible way.
7.6.6. BSD talk protocol.
This protocol is obsolete. We make no attempt to operate it
over CLNP.
8. General Issues
8.1. Management, monitoring, network operations
During the transition period, the current set of management
and monitoring tools must continue to work for IPv4 links.
This set includes such applications as
tcpdump/snoop/iptrace/tcpview
netstat
ifconfig
IPv4 traceroute tools
IPv4 ping tools
SNMP network management systems
AS-traceroute
Configuration retrieval tools
Statistics tools
DNS registry tools
Line test programs (e.g., tools that test of all bit
patterns at IP level)
IDRP peer checking tool (equivalent to BGP-4 peer checking
tool)
Corresponding tools for these and other operations-related
applications must be developed for CLNP. Some exist today.
RFC 1574 [37], Essential Tools for the OSI Internet,
describes a traceroute, route dump, and ping which are
suitable for operation in conjunction with CLNP-based
internets.
8.1.1 Ping
RFC 1575, ISO CLNP Ping [38], specifes the use of the CLNP
echo request and reply packets to support a ping application
(CLNP). Since the TUBA transition is dual stack, CLNP
operation is independent of IP operation at the network
layer (except for encapsulation over virtual links). Thus IP
Ping and CLNP Ping (each based on a respective set of
network layer echo request and reply packets) are used
independently. Pings may be used to test for (a) host
reachability, and (b) host status (alive or dead). When
using "pings" to manage dual stack internets an operator
may:
1) IPv4 "ping" an IPv4-only system to test whether the host
is IPv4-reachable and alive (including situations where
tunneling is used)
2) IPv4 "ping" a dual stack system to determine whether that
dual stack system is IPv4-reachable and alive
3) CLNP "ping" a dual stack system to determine whether that
dual stack system is CLNP-reachable and alive
8.1.2 Traceroute
Traceroute operation is the same for IPv4 and CLNP; only the
packet formats differ. The application of traceroute follows
the same logic as for ping (see RFC 1574).
8.1.3 SNMP
There are no protocol changes to SNMP. MIBs have been
defined for CLNP and ES-IS [34]. IS-IS and IDRP MIBs are
under preparation. Tables in the MIB-II tcp and udp groups
use IPv4 addresses and corresponding tables that use NSAPAs
must be defined (A consequence of this is that a network
management station must traverse both the IPv4-indexed and
NSAPA-indexed tcpConnTable and udpListenerTable to know of
all the open connections on a dual stack host.)
IPng systems should use the preferred (UDP) encapsulation
for SNMP request, response and trap messages. Management
systems may use CLNP paths to acquire IPv4-related
management objects in those circumstances where managed
agents cannot be reached via IPv4 paths.
Operational practices must be extended to manage dual
internet protocol environments (if such practices are not
already in place). For example, if operators use the
ifOperStatus managed object rather than ping to test
reachability between a management station and a managed
agent, the practice of determining the status of all the
interfaces of a dual internet protocol network might be
extended as follows:
1) "get" ifOperStatus using an IPv4 address to test whether
an IPv4-only system is IPv4-reachable and the interface
is {up, down,testing}
2) "get" ifOperStatus using an IPv4 address to test whether
a dual stack system is IPv4-reachable and the interface
is {up, down,testing}
3) "get" ifOperStatus using an NSAP address to test whether
a dual stack system is CLNP-reachable and the interface
is {up, down,testing}
During the transition period, operators must know the state
of IPv4 and CLNP connectivity, so it is expected that SNMP
NMSs would be configured to get the value of ifOperStatus
over both paths to dual stack systems.
Extensions would also be applied for the reception of trap
messages by NMSs. Consider, for example, an NMS operating
with a knob=PreferCLNP; agents expected to generate trap
messages would be configured with the NSAP addresses of NMSs
that are to receive traps.
8.2 Autoconfiguration
[5] recommends that TUBA implementations support the
assignment of system identifiers for TUBA/CLNP hosts defined
in [16] for the purposes of host address autoconfiguration
as described in [28] and [29].
8.3 Autoregistration
Automatic registration of host information into the DNS is
on
the "to do" list.
8.4 Multicast
"Host group extensions for CLNP multicast" [10] discusses
multicast support for CLNP-based systems. During the
transition period, IPv4-only and dual-stack systems can use
IPv4-based multicast. Multicast groups comprised of dual-
stack (and CLNP-multicast-capable) systems can use CLNP-
based multicasting.
8.5 Path MTU Discovery
Hosts that send small IPv4 datagrams over paths that
accommodate larger ones waste Internet resources; this also
contributes to suboptimal application performance (esp.
throughput). [30] describes Path MTU discovery for IPv4-
based hosts; hosts with IPv4 connectivity should continue to
use [30]. [31], in preparation, discusses MTU discovery for
CLNP-based hosts.
8.6 Mobility
[11] discusses describes an approach to transparent mobile
internetworking that allows hosts to roam a CLNP-based
internet in a fashion transparent to transport layer
protocols.
8.7 CLNP Header Compression
[32] describes a CLNP header compression algorithm. This
should be evaluated for suitability by the TUBA WG. Hosts
with IPv4 connectivity should continue to use [33].
9. Timeline for transition
The following timeline depicts the major activities and
benchmarks for TUBA transition:
_Time=0 today
|
|--->all hosts are IPv4 capable
|---> IPv4 routed and managed globally,
|---> CIDR and BGP-4 deployment
|---> CLNP routed in parts of internet IS-IS
|---> limited management instrumentation for CLNP
|---> tuba/clnp prototypes (effectively knob=IPv4only
|
_Time=1
|
|---> majority of hosts remain IPv4 capable only
|---> DNS support begins over IPv4 paths on servers that
| are primaries/secondaries for the NSAPA RRs of
| TUBA/CLNP hosts
|---> multicast support using CLNP begins
|---> TUBA/CLNP software installation begins in hosts;
| CLNP-capable hosts operate in production with
| knob=prefer_IPv4
|---> sites experiment with Internet applications over
| TUBA/CLNP
|---> CLNP routed infrastructure is expanded more
| networks support CLNP & IS-IS
|---> IDRP deployment begins
|---> development of CLNP management instrumentation
| complementing that used for IPv4 begins
|---> CLNP tunneled over IPv4 paths to connect TUBA hosts
| where no "native CLNP" exists
|
_Time=2
|
|---> TUBA/CLNP software installation expands in hosts
|---> CLNP routed infrastructure is extensive
|--->
|---> CLNP multicasting expands
|---> experiments begin with CLNP flows, mobility
|---> CLNP replaces IPv4 as encapsulate for tunneled
| protocols
|---> IDRP deployment is extensive
|---> instances of CLNP tunnels diminishes
|---> CLNP management instrumentation is extensive
|---> Internet operations over CLNP and IPv4 infrastructure
|---> sites turn on CLNP; majority of hosts now operate in
| production with knob=prefer_CLNP
|---> IPv4-only population diminishes
|
_Time=3
|
|---> IPv4 addresses no longer unique; IPv4-only
| communication confined to "islands"
|---> CLNP multicasting is extensive
|---> CLNP flows and mobility expand
|---> TUBA/CLNP software is ubiquitous
|---> Internet is entirely CLNP routed
|---> DNS supported on CLNP infrastructure
|---> CLNP operations IPv4 infrastructure
|---> CLNP-capable hosts now operate in production with
| knob=prefer_CLNP
|
_ Time=?
|---> IPv4-only communication is rare or non-existent
|---> sites elect to turn down IPv4 operations & support
10. Security
Screening routers should continue to perform IPv4 packet
filtering; for CLNP, they should packet filter on source and
destination NSAPAs, PROTOcol value (hosts implementing [5]
encode the PROTOcol value in the network selector of the
destination NSAPA), and port number to block traffic between
networks or specific hosts on an port level. Bastion hosts,
dual-homed gateways, and other forms of firewalls must be
expanded to provide the same safeguards as those developed
for IPv4 environments.
RFC 1108 Security can be encoded in CLNP headers, see [5].
Access control, authentication, data integrity, and
confidentiality are recognized as security services that are
required in the current as well as future global Internet.
One solution to providing these services is through a secure
network layer packet encapsulation protocol supported by a
key management protocol for exchanging security information
associated with a particular instance of communication.
Since the secure network layer packet encapsulation protocol
design must accommodate IPv4 and IPng, the protocol should
be a modular one that, borrowing from Phill Karn, "rides
above the internet datagram" and is distinguished using the
value of PROTOcol in the IPv4 or CLNP header. The IPv4 or
CLNP header is transmitted in the clear. The UDP or TCP
fragments are then encapsulated by the security protocol,
and distinguished by a separate PROTOcol value (i.e., a
field inside the encrypted security protocol header). The
header layout is illustrated in Figure 5:
+-------------------------------+ ^
| | |
| CLNP header (or IPv4 header) | cleartext
| (NSEL=PROTO=SECURITYprotocol) | |
| | v
+-------------------------------+ ^
| | |
| Security protocol header | encrypted
| (NSEL=PROTO=TCP or UDP) | |
| | |
+-------------------------------+ |
| | |
| TCP or UDP | |
| data fragment | |
| | |
+-------------------------------+ v
Figure 5. Header layout for IP security protocol
A security protocol that adheres to this architecture can be
used in conjunction with any network layer datagram,
regardless of address size or format, and under any
transport protocol.
The IETF IPSEC Working Group, is developing an encasulation
protocol solution for IPv4. TUBA/CLNP, as a functionally
isomorphic datagram protocol, also requires an encapsulation
protocol. It is desirable that the same protocols that
provide these security services for IPv4 also provide them
for CLNP. While the IPSEC Working Group is chartered to
provide a set of security protocols only for IPv4, the
protocol that they are designing can provide the same
security services for CLNP. This transition plan encourages
this convergence, and recommends that the IPSEC WG charter
be expanded to reflect this.
There are at least two existence proofs that a single
security encapsulation protocol can be used to support both
IPv4 and CLNP. The SDNS protocol, SP3 [42], and the
connectionless portion of the OSI Network Layer Security
Protocol [43], NSLP-CL, provides the same sets of security
services for both IPv4 and CLNP. SP3 specifically allows
for both IPv4 and CLNP packets to be encapsulated by the SP3
protocol. NLSP-CL, while originally designed to provide
security for CLNP, has been shown to provide the same set of
services for IPv4. The Internet Draft I-NLSP (Integrated
Network Layer Security Protocol) [44], describes in detail
how NLSP-CL can provide these services for both IPv4 and
CLNP. It is the intent of TUBA to adopt the IPSEC protocol.
The key management protocol work of the IPSEC WG has not yet
gotten off the ground. Assuming that the encapsulation
protocol for IPv4 and CLNP is the same, it follows that the
key management protocol developed by the IPSEC WG also could
be used to support secure operation of both datagram
protocols. Since key management is viewed as an application,
such dual use is not expected to pose any significant
technical hurdles.
Acknowledgements
This document draws most of its content from efforts of (and
electronic postings to the mailing lists of) three IETF
working groups the TUBA working group, the NOOP working
group, and the TPIX/CATNIP working group. A number of
individuals have made significant contributions to the TUBA
effort, either through implementation, production of
internet-drafts, or by posting electronic mail of such
completeness and quality that preparation of a transition
plan was often a matter of integration of ideas. Those who
merit special attention include Dave Katz (Cisco Systems),
Ross Callon (Wellfleet Communications), Jim Bound (DEC),
Brian Carpenter (CERN), Yakov Rehkter (IBM), Mark Knopper
(AADS), Peter Ford (LANL), Rich Colella and Jim West
(NIST/CSL), Cathy Wittbrodt (BARRnet), Sue Hares (MERIT),
Robert Ullman (Lotus), Bill Manning (SESQUINET), and Phil
Karn (Qualcomm).
The organization and preparation of this transition plan was
facilitated by the excellent efforts of Gilligan, et. al.,
in the preparation of "IPAE: The SIPP Interoperability and
Transition Mechanism" [35].
References
[1] Postel, J., Transmission Control Protocol (TCP). STD 7,
RFC 793, September 1981.
[2] Postel, J., Internet Protocol (IP). STD 5, RFC 791,
September 1981.
[3] Rekhter, Y., and Li, T., Architecture for IP Address
Allocation with CIDR, RFC 1518, September 1993.
[4] Callon, R., TCP/UDP over Bigger Addresses (TUBA), RFC
1347, May 1992.
[5] Piscitello, D., Use of ISO CLNP in TUBA environments,
RFC 1562, December 1993.
[6] ISO/IEC 8348-1992. International Standards Organization-
-Data Communications--OSI Network Layer Service and
Addressing.
[7] Callon, R., R. Colella, and R. Hagens, NSAPA Guidelines
for the Internet, RFC 1237, July 1991.
[8] ISO/IEC 8473. International Standards Organization --
Data Communications -- Protocol for Providing the
Connectionless-mode Network Service, ISO/IEC 8473:1992,
Edition 2.
[9] Callon, R., "A proposal for adding flow support to
CLNP", Internet-Draft
[10] Marlow, D., "Host group extensions for CLNP Multicast",
Internet-Draft
[11] Perkins & Rehkter, Y., "Mobility for CLNP".
[12] Partridge, C., "Criteria for choosing IPv7 Selection",
Internet-draft.
[13] ISO/IEC 9542. International Standards Organization --
Telecommunications and Information Exchange between
Systems -- End System to intermediate system routeing
exchange protocol for use in conjunction with the
protocol for providing the connectionless-mode network
service (ISO/IEC 8473), ISO 9542:1988.
[14] ISO/IEC 10589, Intermediate system to intermediate
system routeing exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode network service (ISO/IEC 8473), ISO
10589:1992.
[15] ISO/IEC 10747, Protocol for exchange of interdomain
routeing information among intermediate systems to
support forwarding of ISO/IEC 8473 PDUs, ISO /IEC
10747:1992.
[16] Piscitello, D., Assignment of System Identifiers for
TUBA/CLNP hosts, RFC 1526, November 1993.
[17] Katz, D., Tunneling the OSI Network Layer over CLNP
(EON), Internet-draft.
[18] Hanks. S, T. Li, D. Farinacci, P. Traina, Generic
Routing Encapsulation over IPv4 networks, Internet-
draft, September 1993.
[19] Hanks. S, T. Li, D. Farinacci, P. Traina, Generic
Routing Encapsulation, Internet-Draft, September 1993.
[20] Leiner, B., Rehkter, Y., The Multiprotocol Internet,
RFC 1560, December 1993.
[21] Callon, R., and Perlman, R., Integrated IS-IS, RFC
1195.
[22] Tsuchiya, P. NAT paper from SIGCOMM/CCR.
[23] H. W. Braun, P.Ford, Y.Rekhter,"CIDR and the Evolution
of the Internet Protocol", Proceedings of INET '93,
August 1993.
[24] Callon, "how to extend IP", Internet-draft in
preparation.
[25] Piscitello, D., FTP Operation Over Big Address Records
(FOOBAR), RFC 1545, October 1993.
[26] Manning, Colella, DNS RRs for NSAPAs, RFC in
preparation
[27a] Rose, M., SNMP over OSI. RFC 1418, 1993 March.
[27b] Rose, M., SNMP over OSI. RFC 1283 1991 December
[27c] Satz, G., CLNS MIB for use with Connectionless Network
Protocol (ISO 8473) and End System to Intermediate
System (ISO 9542), RFC 1238
[28] Katz, "Suggested System ID Option for the ES-IS
Protocol", Internet-Draft in preparation
[29] Katz, "Dynamic Assignment of OSI NSAP Addresses in the
Internet", Internet-Draft in preparation.
[31] Mogul, J., and S. Deering, RFC 1191, MTU Discovery.
[31] Piscitello, D.,"MTU discovery for CLNP-based hosts",
Internet-Draft in preparation.
[32] Whyman, "ICAO CLNP Header Compression
algorithm",available by anonymous FTP, in compressed
postscript form, from comm.cenaath.cena.dgac.fr as
/atn/icao-clnp-compress-ps.zand
[33] IPv4 header compression RFCs
[34] Satz, G., Request for Comments 1238, Connectionless-
mode Network Service Management Information Base - for
use with Connectionless Network Protocol (ISO 8473) and
End system to Intermediate System Protocol (ISO 9452)",
Internet Architecture Board, June 1991.
[35] Gilligan, R., and B. Hinden, "IPAE: The SIPP
Interoperability and Transition Mechanism", Internet-
draft, November 1993.
[36] Katz, D., P. Ford, "TUBA: Replacing IP with CLNP",
March 24 1993.
[37] Wittbrodt, C., and S. Hares, Essential Tools for the
OSI Internet, Request for Comments 1574, March 1994.
[38] Wittbrodt, C., and S. Hares, CLNP Ping (Echo), Request
for Comments 1575, March 1994.
[39] Bound, J., IPng Host Implementation Analysis, IPng
white paper, February 1994.
[40] Phil Karn, electronic mail message to ipsec@ans.net
entitled "Re: IPSEC & ROAD", 29 November 1992.
[42] SDNS, "Security Protocol 3 (SP3)," Specification
SDN.301/Revision 1.5, May 1989.
[43] ISO/IEC, "Information technology -- Open Systems
Interconnection -- Network Layer Security Protocol,"
International Standard 11577, November 1993.
[44] Glenn, K. Robert, "Integrated Network Layer Security
Protocol," Internet Draft (draft-glenn-layer-security-
00.txt), September 1993 (work in progress).
Author's Address
David M. Piscitello
Core Competence, Inc.
1620 Tuckerstown Road
Dresher, PA USA 19025
dave@corecom.com
1.215.830.0692
Appendix A. ASN.1 Definitions for TUBA MIB-II extensions
TUBA-MIB DEFINITIONS ::= BEGIN
IMPORTS
OBJECT-TYPE
FROM RFC-1212
private, internet
FROM RFC1155-SMI
NsapAddress
FROM SNMPv2-SMI;
nistPrivate OBJECT IDENTIFIER ::= { private 724 }
nistTUBAModules OBJECT IDENTIFIER ::= { nistPrivate 1 }
nistTUBAMIB OBJECT IDENTIFIER ::= { nistPrivate 2 }
tcpTUBAGroup OBJECT IDENTIFIER ::= { nistTUBAMIB 1 }
udpTUBAGroup OBJECT IDENTIFIER ::= { nistTUBAMIB 2 }
-- created from tubaMIB (9403101200Z)
tubaMIB OBJECT IDENTIFIER ::= { nistTUBAModules 1 }
tcpTubaConnTable OBJECT-TYPE
SYNTAX SEQUENCE OF TcpTubaConnEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A table containing TCP over CLNP (TUBA)
connection-specific information."
::= { tcpTUBAGroup 1 }
tcpTubaConnEntry OBJECT-TYPE
SYNTAX TcpTubaConnEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Information about a particular current TCP over
CLNP connection. An object of this type is
transient, in that it ceases to exist when (or
soon after) the connection makes the transition
to the CLOSED state."
INDEX { tcpConnLocalNSAPAddress, tcpTubaConnLocalPort,
tcpConnRemNSAPAddress, tcpTubaConnRemPort }
::= { tcpTubaConnTable 1 }
TcpTubaConnEntry ::=
SEQUENCE {
tcpTubaConnState
INTEGER,
tcpConnLocalNSAPAddress
NsapAddress,
tcpTubaConnLocalPort
INTEGER,
tcpConnRemNSAPAddress
NsapAddress,
tcpTubaConnRemPort
INTEGER
}
tcpTubaConnState OBJECT-TYPE
SYNTAX INTEGER {
closed(1),
listen(2),
synSent(3),
synReceived(4),
established(5),
finWait1(6),
finWait2(7),
closeWait(8),
lastAck(9),
closing(10),
timeWait(11),
deleteTCB(12)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The state of this TCP connection.
The only value which may be set by a management
station is deleteTCB(12). Accordingly, it is
appropriate for an agent to return a `badValue'
response if a management station attempts to set
this object to any other value.
If a management station sets this object to the
value deleteTCB(12), then this has the effect of
deleting the TCB (as defined in RFC 793) of the
corresponding connection on the managed node,
resulting in immediate termination of the
connection.
As an implementation-specific option, a RST
segment may be sent from the managed node to the
other TCP endpoint (note however that RST
segments
are not sent reliably)."
::= { tcpTubaConnEntry 1 }
tcpConnLocalNSAPAddress OBJECT-TYPE
SYNTAX NsapAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The local NSAP address for this TCP connection.
In
the case of a connection in the listen state which
is willing to accept connections for any NSAP
interface associated with the node, the value
0 is used. This is a zero length NSAP Address"
::= { tcpTubaConnEntry 2 }
tcpTubaConnLocalPort OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The local port number for this TCP connection."
::= { tcpTubaConnEntry 3 }
tcpConnRemNSAPAddress OBJECT-TYPE
SYNTAX NsapAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The remote NSAP address for this TCP
connection."
::= { tcpTubaConnEntry 4 }
tcpTubaConnRemPort OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The remote port number for this TCP connection."
::= { tcpTubaConnEntry 5 }
udpTubaTable OBJECT-TYPE
SYNTAX SEQUENCE OF UdpTubaEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A table containing UDP listener information."
::= { udpTUBAGroup 1 }
udpTubaEntry OBJECT-TYPE
SYNTAX UdpTubaEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Information about a particular current UDP
listener."
INDEX { udpLocalNSAPAddress, udpTubaLocalPort }
::= { udpTubaTable 1 }
UdpTubaEntry ::=
SEQUENCE {
udpLocalNSAPAddress
NsapAddress,
udpTubaLocalPort
INTEGER
}
udpLocalNSAPAddress OBJECT-TYPE
SYNTAX NsapAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The local NSAP address for this UDP listener. In
the case of a UDP listener which is willing to
accept datagrams for any IP interface associated
with the node, the value 0 is used."
::= { udpTubaEntry 1 }
udpTubaLocalPort OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The local port number for this UDP listener."
::= { udpTubaEntry 2 }
END
------------------------------------------------------------
TUBA-MIB DEFINITIONS ::= BEGIN
IMPORTS internet, private FROM RFC1155-SMI
NsapAddress FROM SNMPv2-SMI
MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI;
nistPrivate OBJECT IDENTIFIER ::= { private 724 }
nistTUBAModules OBJECT IDENTIFIER ::= { nistPrivate 1 }
nistTUBAMIB OBJECT IDENTIFIER ::= { nistPrivate 2 }
tcpTUBAGroup OBJECT IDENTIFIER ::= { nistTUBAMIB 1 }
udpTUBAGroup OBJECT IDENTIFIER ::= { nistTUBAMIB 2 }
tubaMIB MODULE-IDENTITY
LAST-UPDATED "9403101200Z"
ORGANIZATION "NIST"
CONTACT-INFO
" Jim West
Postal: NIST
Building 225/B217
Gaithersburg MD, 20899
US
Tel: +1 301 975 3619
Fax: +1 301 590 XXXX
E-mail: west@osi.ncsl.nist.gov"
DESCRIPTION
"The MIB module for TUBA systems"
::= { nistTUBAModules 1 }
-- the TCP TUBA Connection table
-- This table serves the same purpose as MIB-II's
-- tcpConnTable;
-- It contains information about this entity's
-- existing TCP connections.
-- It is expected that a TUBA agent will instantiate
-- this table as well
-- as the tcpConnTable in MIB-II. A manager will
-- have to access both
-- table to get a complete picture of the TCP
-- connections active on a
-- TUBA end system.
--
-- NOTE: This is not a complete reproduction of
-- MIB-II's TCP group. Many of the objects in the
TCP
-- group are not dependent on Network addresses.
-- This group only address portions of the
-- TCP group that depend on Network addresses.
tcpTubaConnTable OBJECT-TYPE
SYNTAX SEQUENCE OF TcpTubaConnEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing TCP over CLNP
(TUBA) connection-specific
information."
::= { tcpTUBAGroup 1 }
tcpTubaConnEntry OBJECT-TYPE
SYNTAX TcpTubaConnEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular current
TCP over CLNP connection. An object
of this type istransient, in that it
ceases to exist when (or soon after)
the connection makes the transition to
the CLOSED state."
INDEX { tcpConnLocalNSAPAddress,
tcpTubaConnLocalPort,
tcpConnRemNSAPAddress,
tcpTubaConnRemPort }
::= { tcpTubaConnTable 1 }
TcpTubaConnEntry ::=
SEQUENCE {
tcpTubaConnState
INTEGER,
tcpConnLocalNSAPAddress
NsapAddress,
tcpTubaConnLocalPort
INTEGER (0..65535),
tcpConnRemNSAPAddress
NsapAddress,
tcpTubaConnRemPort
INTEGER (0..65535)
}
tcpTubaConnState OBJECT-TYPE
SYNTAX INTEGER {
closed(1),
listen(2),
synSent(3),
synReceived(4),
established(5),
finWait1(6),
finWait2(7),
closeWait(8),
lastAck(9),
closing(10),
timeWait(11),
deleteTCB(12)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The state of this TCP connection.
The only value which may be set by a
management station is deleteTCB(12).
Accordingly, it is appropriate for an
agent to return a `badValue' response
if a management station attempts to set
this object to any other value.
If a management station sets this
object to the value deleteTCB(12),
then this has the effect of deleting
the TCB (as defined in RFC 793) of the
corresponding connection on the managed
node, resulting in immediate
termination of the connection.
As an implementation-specific option,
a RST segment may be sent from the
managed node to the other TCP endpoint
(note however that RST segments
are not sent reliably)."
::= { tcpTubaConnEntry 1 }
tcpConnLocalNSAPAddress OBJECT-TYPE
SYNTAX NsapAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The local NSAP address for this TCP
connection. In the case of a
connection in the listen state which
is willing to accept connections for
any NSAP interface associated with the
node, the value 0 is used. This is a
zero length NSAP Address"
::= { tcpTubaConnEntry 2 }
tcpTubaConnLocalPort OBJECT-TYPE
SYNTAX INTEGER (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The local port number for this TCP
connection."
::= { tcpTubaConnEntry 3 }
tcpConnRemNSAPAddress OBJECT-TYPE
SYNTAX NsapAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The remote NSAP address for this TCP
connection."
::= { tcpTubaConnEntry 4 }
tcpTubaConnRemPort OBJECT-TYPE
SYNTAX INTEGER (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The remote port number for this TCP
connection."
::= { tcpTubaConnEntry 5 }
-- TUBA UDP Group
-- the UDP TUBA Listener table
-- As with the TCP table, this table serves the
-- same purpose as the udpTable from MIB-II. The
-- UDP listener table contains information about
-- this entity's UDP end-points on which a local
-- application is currently accepting datagrams.
udpTubaTable OBJECT-TYPE
SYNTAX SEQUENCE OF UdpTubaEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing UDP listener
information."
::= { udpTUBAGroup 1 }
udpTubaEntry OBJECT-TYPE
SYNTAX UdpTubaEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular current
UDP listener."
INDEX { udpLocalNSAPAddress,udpTubaLocalPort }
::= { udpTubaTable 1 }
UdpTubaEntry ::=
SEQUENCE {
udpLocalNSAPAddress
NsapAddress,
udpTubaLocalPort
INTEGER (0..65535)
}
udpLocalNSAPAddress OBJECT-TYPE
SYNTAX NsapAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The local NSAP address for this UDP
listener. In the case of a UDP listener
which is willing to accept datagrams for
any IP interface associated
with the node, the value 0 is used."
::= { udpTubaEntry 1 }
udpTubaLocalPort OBJECT-TYPE
SYNTAX INTEGER (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The local port number for this UDP
listener."
::= { udpTubaEntry 2 }
END
Datatracker
Report a datatracker bug
draft-ietf-tuba-transition-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats |