Internet DRAFT - draft-ietf-tuba-trans
draft-ietf-tuba-trans
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 08:55:50 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 09 Sep 1994 19:39:52 GMT
ETag: "3ddf1a-11c38-2e70ba08"
Accept-Ranges: bytes
Content-Length: 72760
Connection: close
Content-Type: text/plain
TUBA Working Group D. Piscitello
Internet Draft Core Competence, Inc.
Expires 15 January 1995 15 July 1994
File name draft-ietf-tuba-transition-01.txt
Transition Plan for TUBA/CLNP
15 July 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 15 January 1995.
Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other
than as a "working draft" or "work in progress." Please check
the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other
Internet Draft.
Distribution of this memo is unlimited.
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: (1) the Internet backbone and regional
networks suffer from the need to maintain large and growing amounts of routing
information;and (2) the Internet is gradually running out of IP network numbers
to assign.
Piscitello Expires 15 January 1995 Page 1
TUBA Working Group TUBA Transition
CIDR [3] offers temporary relief from problem (1). 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.
All proposed solutions to these problems introduce
fundamental changes 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, (i.e.,
minimize the need for synchronization points during
transition)
f) Provide end users the flexibility to transition from IPv4
to IPng when the need arises
g) Minimize the impact on existing applications and
programming interfaces
Several techniques have been proposed to address general coexistence issues
during transition to any next generation IP. These techniques fall into three
categories:
1) Dual internet protocol environment (IPv4 and IPng), with
eventual transition to sole use and support of IPng.
Piscitello Expires 15 January 1995 Page 2
TUBA Working Group TUBA Transition
2) Tunneling (encapsulating IPng in IPv4 and IPv4 in 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), but
we also recognize the need for techniques (2) and (3) where
operational needs and local policies dictate their use. The
focal point of this transition strategy is the implementation
of both IPv4 and CLNP in hosts and routers (i.e., a dual internetworking
protocol environment). This architectural approach, initially described in RFC
1347, TUBA is depicted in Figure 1.
+------------------------+
| Internet |
| applications |
| (ftp,telnet,mail,etc.) |
+------------------------+
| tcp/udp |
+------------------------+
| | |
| IPv4 & | CLNP & |
| routing | routing |
| protocols | protocols |
+------------------------+
Figure 1. Dual internet protocol host
Encapsulation may be used where needed and is explicitly
supported. The transition strategy described herein does not
preclude the use of translation techniques (3), but it is
expected that, in the general case, use of such techniques as
network address translation and network protocol conversion
can, and should, be minimized (localized).
The remainder of this paper is organized as follows:
Chapter 2 describes 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 provide
details of the components of the transition-period Internet. Chapter 8 discusses
general issues regarding transition. Chapter 9 shows a timeline for TUBA
transition.
Chapter 10 discusses network layer security issues.
The reader can gain an understanding of TUBA and the problems
it attempts to resolve by reading chapters 2 through 4.
Implementors should also read chapters 5 through 10. References for all
TUBA-related documentation are appended to this memo.
Piscitello Expires 15 January 1995 Page 3
TUBA Working Group TUBA Transition
2. IPng 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 two decades ago can now
be seen to be 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 information overload problem can be summarized as
follows. Historically, IPv4 network numbers have not been
assigned in an hierarchical manner. Network numbers were assigned using
estimates of the size of the requesting organization (i.e., numbers of hosts,
subnets) to determine the number of addresses required, as well as the address
class (e.g., A, B, or C). No attempt was made to allocate addresses to reflect
the typically hierarchical organization of interconnected networks. As a
consequence of this practice, IPv4 routing (i.e., routing protocols, and
forwarding mechanisms) treat remote IP network addresses as a flat space,
processing and storing distinct routes to each destination network. This near
linear relationship between the number of attached networks and the
corresponding routing information has become a critical factor (especially for
backbone networks), threatening to limit the growth and routing stability of the
Internet. CIDR and BGP-4 deployment have begun to lessen this situation but
these measures are "stop-gap" at best.
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 before the end of this millenium.
Piscitello Expires 15 January 1995 Page 4
TUBA Working Group TUBA Transition
IPv4 only supports fixed 32-bit addresses. The need for larger network addresses
will require that the Internet Protocol itself be changed or replaced. Modifying
or replacing IPv4 will be a critical and fundamental change to the core Internet
infrastructure.
3. TUBA Overview
TUBA [4] solves the problems described in section 2 by using:
1) OSI network service access point (NSAP) addresses, a
flexible and extensible network addressing plan which
accommodates multiple administrations and multiple levels
of addressing hierarchy for routing purposes ([6], [7a],
[7b])
2) OSI connectionless network layer protocol (CLNP, [8]), 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 1629 (nee 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 scales to a very large
Internet. (RFC 1237 guidelines have been adapted for IP
and form the basis for CIDR allocation and deployment
strategies for extending the lifetime of the IPv4-based
Internet.)
TUBA allows the current Internet applications (e.g., Telnet,
SNMP, FTP, SMTP/822 electronic mail, NFS, AFS, BOOTP, X
window system) 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 uses the same naming conventions and infrastructure as IPv4; i.e.,
the Domain Name System, with extensions to accommodate NSAP address to domain
name mappings. (Note: throughout this document the discussion of
transition issues related to name services -- name to address and address to
name translation systems -- is couched in terms specific to the Domain Name
System. The same concepts would apply to other name to address translation
systems.
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
Piscitello Expires 15 January 1995 Page 5
TUBA Working Group TUBA Transition
are 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.
CLNP is already supported (implemented) by developers of
Internet products and deployed by many operators of backbone
(regional, midlevel) and attached (client) networks in the
Internet infrastructure. CLNP implementations exist today for
most host and router systems. The routing architecture is
similar to that implemented for IPv4 (OSPF and IS-IS share a
common ancestry, as do BGP-4 and IDRP, see [24]). A major advantage of using
CLNP as a replacement for IPNG is that the routing architecture has already been
specified, implemented in products, and deployed in large-scale production
networks (operational experience with Integrated IS-IS is documented in [23]).
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 CLNP 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 NSAP addresses (see [6] and [7]). NSAP addresses are already
applied in those portions of the global Internet that offer CLNP connectivity
according to guidelines developed within the IETF; the assignment and allocation
guidelines defined in RFC 1237 form the basis for the development of CIDR [3].
Based on operational experience with CLNP on the Internet, RFC 1237 has been
updated, and RFC 1629 now accommodates internationally-defined NSAP addresses.
The referenced addressing documents ([6], [7a], [7b]) specify a maximum NSAP
address length of 20 octets. The encoding of CLNP is such that its specification
woud not have to change if longer addresses were created (to a maximum of
approximately 100 octets per address).
The AFI mechanism can also be used to introduce additional addressing
authorities (e.g., ISOC, or a globally
Piscitello Expires 15 January 1995 Page 6
TUBA Working Group TUBA Transition
administered IPX space). This satisfies the IPng objective of effectively
unlimited addressing (if not already satisfied by the 20-octet addresses
available). A further advantage of NSAP addresses is that they can be structured
in a manner that allows the embedding other network or link layer addresses,
IPv4, Novell IPX, or Ethernet/IEEE 802, which is useful for autoconfiguration of
hosts (see [16] for a description of how these may be encoded as system
identifiers within an RFC 1629 NSAP address).
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 internetworking protocol. This simple architectural tenet is a
major part of the its success.
Practical experience acquired in the design and deployment of very large,
complex, and highly-interdependent systems suggests that such systems are
difficult to deploy and manage. Even when one succeeds 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 TUBA-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.)
Piscitello Expires 15 January 1995 Page 7
TUBA Working Group TUBA Transition
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 five 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 implementers 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 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) DNS servers are extended to return NSAP addresses (DNS
systems must continue to support IPv4 name-to-address
resolution). Initially, DNS will operate over IPv4.
3) TUBA/CLNP is introduced as new host software is deployed.
Internet applications are operated over TUBA. New software
is expected to support TCP/UDP over both IPv4 and CLNP
4) CLNP connectivity is provided to all sites.
5) The population of IPv4-only hosts on the network
diminishes and the number of dual internet protocol
capable hosts increases
6) DNS support is moved onto the CLNP infrastructure.
7) The CLNP infrastructure is used extensively in production
environments.
A detailed timeline for the transition plan is provided in
Section 9.
To make the transition from IPv4 to TUBA as smooth as possible, the following
objectives must be taken into consideration:
Piscitello Expires 15 January 1995 Page 8
TUBA Working Group TUBA Transition
1) The transition should impose a minimum impact on the end
users of hosts, and should leverage as much of the users'
and administrators' investment in existing Internet
operations and training 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.
2) Users and network operators should be able to transition
at their own pace; i.e., users should be able to upgrade
hosts and routers when they are ready, and incrementally.
3) Sites which deploy a dual internet protocol environment
should accumulate the benefits and features of TUBA as
they deploy. For example a new TUBA host should be able to
use the autoconfiguration mechanisms immediately.
4) The larger addresses of TUBA/CNLP should be used to solve
the IPv4 route scaling problem early on in the transition.
5) The transition plan must provide complete, global
connectivity between TUBA and IPv4 hosts for as long as
IPv4 can provide global connectivity.
6) 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.
4.1. Dual Internet Protocol Operation
In the dual internet protocol transition plan, software in
new and updated hosts supports Internet transport protocols
on top of both IPv4 and CLNP. The host is configured to use
both IPv4 and CLNP; the order of network layer precedence
(selection) is locally controlled at the host (at a system or
per application level, see section 4.2.4). When a dual
internet protocol host is attached to the dual internet
protocol infrastructure, this fact is advertised to other
hosts on the Internet through the administrative process of
incorporating both its IPv4 address(es) and its NSAP address(es) into the DNS.
Dual internet protocol hosts thus recognize each other by the existence of their
NSAP addresses in the DNS.
Figure 4 illustrates a single Internet routing domain, which
is also interconnected with Internet backbones or regionals.
The two "updated" Internet Hosts, D1 and D2, can send
either IPv4 or CLNP packets. Figure 4 also illustrates two
IPv4-only hosts, H1 and H2, a DNS server, and 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 by using (i) multi-protocol routers, which can
Piscitello Expires 15 January 1995 Page 9
TUBA Working Group TUBA Transition
forward both protocol suites; (ii) a different set of routers for each suite;
(iii) tunneling as described in section 4.3; or (iv) translation as described in
section 4.4.
............. ...................
: : : :
: H1 : : Internet :
: :----R1----: :
: H2 : : Backbones :
: : : :
: DNS : : :
: : : and :
: D1 : : :
: : : Regionals :
: D2 :----R2----: :
: : : :
:...........: :.................:
Key
DNS DNS server
Hn IPv4 only host
Dn Updated Internet host
R Border Router
Figure 4 - TUBA transition example
When attempting communication, a dual internet protocol host
queries the DNS for the IPv4, NSAP address, or both forms of
address(es) of the target host (based on local host controls,
again, see section 4.2.4). Consider case (1) where D1 wishes
to communicate with D2, and where local host controls at D1
indicate that the host should attempt to use CLNP first, but
if not available, use IPv4. In this case, D1 requests both
"A" and "NSAP" resource records (RRs) for D2. If the DNS returns both IPv4 and
NSAP resource records for D2, then D1 concludes that target host is another dual
internet protocol host connected to the dual internet protocol infrastructure,
and the communication can take place using CLNP (since it was
indicated as the preferred network layer).
Suppose D2 has not yet been put onto the dual internet
protocol infrastructure. In this case, D2's NSAP address would not be present in
the DNS; only its IPv4 address would be returned, and D1 would correctly
conclude that it should
use IPv4 to communicate with D2. (Note that if the decision
is made to use IPv4, nothing has changed!)
Given the local control configuration (prefer CLNP), if D2's NSAP addresses were
registered, but D2 were not yet attached
Piscitello Expires 15 January 1995 Page 10
TUBA Working Group TUBA Transition
to the dual internet protocol infrastructure, the DNS would return both "A" and
"NSAP" resource records. D1 would try
D2's NSAP address(es), its attempts to communicate with D2 over CLNP would fail,
and D1 would then try D2's IPv4 address(es), see section 4.2.4.
Now consider case (2), where D1 wishes to communicate with
H1. Assuming the same local controls, D1 again requests both
"A" and "NSAP" RRs for D2; here, only the "A" resource
record(s) containing the IPv4 address(es) of H1 is returned.
D1 concludes that the target host is not a dual internet
protocol host and uses IPv4 for communication.
These examples demonstrate the importance of the DNS to the transition plan.
Network administrators are encouraged to only configure a host's NSAP address
into the DNS if the host should be reachable on the CLNP infrastructure
(Nominally, the host and local network supports CLNP).
Note: Registering NSAP addresses of hosts before such hosts
are to use CLNP cannot precluded; however, since this cannot
be coordinated with individual host settings at a global
level, such registration may result in poor host performance
at application connection time. Consider the case where a
host D1 has its NSAP address registered, but the host does
not have connectivity to the CLNP infrastructure. Suppose the host supports a
server application. Any host D2 attempting to
communicate with D1 having its knob set to prefer CLNP will try all NSAP
addresses and fail before attempting to connect via IPv4.)
4.2 Dual internet protocol and the Internet Infrastructure
The transition to TUBA/CLNP requires several Internet infrastructural components
to evolve to dual internet protocol functionality (see the timeline in section
9). These are:
- Network Service Providers
- The Domain Name System (DNS)
- The Internet registration functions
- Hosts
Many campus, enterprise network, and Internet transit
networks (NASA Sciences Internet, Energy Sciences Network,
Alternet, SURANET, Sesquinet, NEARnet, 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.
Piscitello Expires 15 January 1995 Page 11
TUBA Working Group TUBA Transition
4.2.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.) among Internet service providers.
The current interconnects already switch multiple protocols,
including CLNP. Standard CLNP operations practices are also
in place.
4.2.2 Updating the 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 (see [26]). Prototype
implementations of DNS servers and resolver libraries that
can support multiple address types are available for
TUBA/CLNP.
DNS servers will continue to operate on the IPv4 routed infrastructure until the
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.2.4.
4.2.3 Internet registration functions
Guidelines exist for the assignment of NSAP addresses in the Internet [7a, 7b];
assignment of NSAP addresses 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.
The current set of service provider interconnections performs
route registration and dissemination, i.e., as performed by
Merit/NSFNET, the Ripe NCC and the Japanese JPNIC. The schema
for the current set of databases for the routing registration
and dissemination function has been extended to include CLNP
addresses and prefixes (network numbers).
Piscitello Expires 15 January 1995 Page 12
TUBA Working Group TUBA Transition
4.2.4 Dual internet protocols environments and hosts
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. CPU requirements
for CLNP are also under investigation; this, too, should not
be a barrier for low-end hosts.
Dual internet protocol support in hosts requires coordination
and control on the part of implementers, system
administrators, users, and network administrators. Internet
applications (the business of hosts) must be re-engineered to
selectively use either protocol stack during transition. 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 the network layer with
which to initiate communications 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 Internet applications over
IPv4 only. This is the default setting (and also the only
logical state of IPv4-only hosts). Only "A" resource
records can be obtained from the DNS for this host. The
host only asks for IPv4 addresses.
(2) Prefer IPv4. The host operates Internet applications over
IPv4 and CLNP, and is capable of obtaining both IPv4 and
NSAP addresses from the DNS. Both "A" and "NSAP" resource
records can be obtained from the DNS for this host. The
host will always ask for both address families, but given
a choice, will use an IPv4 path. Under this setting, the
host expects the majority of communication it initiates
to be IPv4 (For a client, most of the servers it expects
to contact are reachable via IPv4). Server applications
on the host may accept incoming connections over CLNP.
(3) Prefer CLNP. In this case, the host is again dual
internet protocol capable. The host will always ask for
both address families but given a choice, it will use a
CLNP path. Under this setting, the host is registered
as a dual internet protocol host, and expects the
majority of communication it initiates to be CLNP
(For a client, most of the servers it expects to contact
are reachable via CLNP). Server applications on host may
accept incoming connections over IPv4 paths.
Piscitello Expires 15 January 1995 Page 13
TUBA Working Group TUBA Transition
(4) CLNP only. This setting is used when all destinations
with which the host expects to communicate support CLNP,
or when there is a strong desire to turn down support for
the local IPv4 infrastructure. The host will only ask for
NSAP addresses.
Nominally, a system wide knob is recommended. Host
implementations are strongly encouraged to extend the knob
abstraction to a per-application basis, as applications
servers may be TUBA-enabled at different times across the
Internet. Thus, a host implementing knobs on a per application basis may have a
knob indicating "Prefer IPv4" for Web service and a knob indicating "Prefer
CLNP" for telnet service.
4.3 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 TUBA hosts, in those
circumstances where native CLNP transport is not available (i.e., across routing
domains that have not introduced a CLNP backbone); and to connect IPv4 hosts, at
such time where global IPv4 connectivity is no longer
Piscitello Expires 15 January 1995 Page 14
TUBA Working Group TUBA Transition
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.
4.4 Address and Protocol Translators
Several approaches may be used, separately or in combination,
for continued operation of IPv4 under circumstances where
global IPv4 connectivity is no longer available. One method
involves splitting the IPv4 Internet into a number of "local
address domains", and performing network address translation.
For example, a subset of an administration's assigned 32-bit
IPv4 addresses might be designated as unique only within a
local address domain. Some number of the administration's 32-
bit IP addresses are designated for global use, and remain
globally unique; these may serve as resources that local
hosts may use when they attempt to communicate to hosts
outside the local address domain. Specifically, when the
local host wishes to communicate to an outside host, it is
(temporarily) assigned a global address (i.e., a translation
from local-to-global address is performed by a border router
-- a network address translator or NAT box -- on the source
address of IPv4 packets that exit the local domain, and
similarly on destination addresses of IPv4 packets that arrive at the local
domain, destined for a host having a temporarily assigned global address). This
allows IPv4-only hosts to communicate locally "forever", and globally for as
long as IPv4 connectivity exists to desired destinations. Several such
techniques are under investigation at this time.
Network layer protocol translation can also be used to extend
the lifetime if IPv4 networks. Translation could take the
form of an IPv4 to CLNP conversion, or from IPv4 to CLNP via
a common translating protocol (e.g., CATNIP).
5. Multiprotocol routers
Multiprotocol routers -- routers that can forward (at least) IPv4 and CLNP
datagrams -- will facilitate the deployment of the dual internet protocol
infrastructure. Multiprotocol routers may use independent routing protocols to
switch IPv4 and CLNP, or they may use integrated routing [21]. Such routers are
available, widely deployed and tractable technology; this notwithstanding, one
can certainly use
Piscitello Expires 15 January 1995 Page 15
TUBA Working Group TUBA Transition
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, and the forwarding of IPv4
datagrams by encapsulating them in IPv4 packets. Protocols currently tunnelled
across IPv4 backbons (Appletalk, IPX) must eventually be tunnelled using CLNP
(see section 4.3).
6. IPv4 Address Lifetime Considerations
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. The
tunneling and translation techiques described in section 4
may be applied to meet the needs of administrations which
find it necessary and appropriate to sustain their investment
in IPv4 beyond the point where the IPv4 addresses remain
unique. Application relays may also suffice..
TUBA transition allows migration to CLNP to be performed
independently from such "life support" for the old IPv4
address space, which may be used to maintain IPv4
connectivity for as long as this is economically and
technically feasible without disrupting migration to IPng.
The dual internet protocol 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 re-use or further extend
the aggregation properties of the current 32-bit address
space (i.e., extending CIDR policies to class A addresses).
6.2 Turning down the IPv4 infrastructure
There are at least two perspectives regarding the issue of
how to phase 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
Piscitello Expires 15 January 1995 Page 16
TUBA Working Group TUBA Transition
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 specific point in the future Under the plan specified
herein, IPv4 and CLNP may co-exist "forever".
7. Dual Internet Protocol Hosts
Hosts must implement CLNP, ES-IS, and several additional modifications to run
TUBA/CNLP alongside IPv4. 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 internet protocol hosts must be able to transmit and
receive both CLNP and IPv4 packets; resolve network addresses
of destinations to hardware addresses. Dual internet protocol
hosts may also be expected to request configuration
information from servers, and request auto registration of
domain names and addresses (see sections 8.2 and 8.3).
7.1. Internetwork Protocol Selection
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., one switch per
host, per destination, per application). The knob abstraction
described in section 4.2.4 offers one way to model this
decision process.
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, address length fields,
and protocol ID 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
Piscitello Expires 15 January 1995 Page 17
TUBA Working Group TUBA Transition
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
transport 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.
When communicating with another dual internet protocol host
using CLNP, TCP uses the full source and destination NSAP addresses and
local/remote port numbers to identify connections and sockets. This provides an
equivalent means of identification (and should suffice until such time as the
Internet community resolves the issue of global endpoint identification).
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. CLNP Error Report Codes for "Protocol
Unreachable" and "Port Unreachable" 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-1 only requires 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)
Piscitello Expires 15 January 1995 Page 18
TUBA Working Group TUBA Transition
through which applications use TCP and UDP (e.g., primarily
a "sockets" based API) and many will already have an API
through which applications use OSI transport protocols (e.g.,
the XTI API)." 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 to open. 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 be extended to carry
variable length NSAP addresses in order to support TUBA/CLNP.
We do not impose any additional 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 internet protocol API are:
1) The new API should allow applications to pass in both 32-
bit IPv4 addresses and NSAP addresses. (Applications
introduced during the transition are likely to use 32 bit
IPv4 addresses and NSAP 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 internet
protocol system with the new API.
3).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 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.
7.6. IPv4 Addresses Embedded in Application Protocols
In this section, we specify how hosts should use existing
application protocols in a dual internet protocol
environment. (Note that this section discusses protocol
changes only; changes to user interfaces, i.e., changes to
APIs, the use of an "NSAP address 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
Piscitello Expires 15 January 1995 Page 19
TUBA Working Group TUBA Transition
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
Internet Gopher (RFC 1436)
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. Protocols that fall
into this category are:
SMTP (RFC 821)
Mail (RFC 822)
MIME (RFC 1341)
BSD "talk" protocol
3) Application protocols that carry IPv4 addresses, but that
are used exclusively by IPv4 itself (i.e., protocols, or
protocol features that are specifc to IPv4 operation and
that would not be changed by adding TUBA support to the
system). New versions of these protocols may be
Piscitello Expires 15 January 1995 Page 20
TUBA Working Group TUBA Transition
necessary 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.
Extensions to FTP to enable its operation over larger
addresses (e.g., NSAP addresses) are defined in [25].
The following application protocols have not been thoroughly
examined or prototyped over a TUBA stack:
Kerberos
Telnet options
POP3 (RFC 1225)
DNS mail routing (RFC 974)
WAIS
World Wide Web
Andrew File System
Archie
X window system
Todate, no critical TUBA-related issues have been identified for these
protocols.
The remainder of this section discusses how dual internet
protocol 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:
Piscitello Expires 15 January 1995 Page 21
TUBA Working Group TUBA Transition
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
use to connect back to the client.
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 NSAP addresses. These extensions include new commands
(LPRT, LPASV) for use when NSAP addresses are exchanged, along with a
corresponding set of completion reply codes (note that PORT, PASV remain for use
by IPv4 systems). Selection of FTP commands and responses is governed by the
local control settings at hosts (see section 4.2.4).
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 checkif 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 NSAP addresses, if desirable.
Piscitello Expires 15 January 1995 Page 22
TUBA Working Group TUBA Transition
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
NSAP addresses to domain names (under the ".NSAP" domain). New hosts may ask for
both the new (NSAP address) 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 (see section 4.2.4).
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
Piscitello Expires 15 January 1995 Page 23
TUBA Working Group TUBA Transition
unchanged and can continue to be used by IPv4 hosts and
routers. A data type exists for 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. These include the tcpConnTable and udpTable. These two
new tables are specified in [40].
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
NSAP addresses, or must incorporated into a new host configuration scheme. The
ONC RPC system includes a version 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 (to test all bit patterns at IP level)
BGP-4 peer checking tool (equivalent IDRP 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,
Piscitello Expires 15 January 1995 Page 24
TUBA Working Group TUBA Transition
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 internet protocol,
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 internet protocol internets an operator may:
1) IPv4 "ping" an IPv4-only system to test whether the host
is IPv4-reachable and alive.
2) IPv4 "ping" a dual internet protocol system to determine
whether that dual internet protocol system is IPv4-
reachable and alive
3) CLNP "ping" a dual internet protocol system to determine
whether that dual internet protocol 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
No protocol changes to SNMP are required to support TUBA. MIBs have been defined
for CLNP and ES-IS [34] and IS-IS. An IDRP MIB is in preparation. Tables in the
MIB-II tcp and udp groups use IPv4 addresses and corresponding tables that use
NSAP addresses must be defined (A consequence of this is that a network
management station must traverse both the IPv4-indexed and NSAP address-indexed
tcpConnTable and udpListenerTable to know of all the open connections on a dual
internet protocol 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.
Piscitello Expires 15 January 1995 Page 25
TUBA Working Group TUBA Transition
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 internet protocol system is IPv4-reachable and the
interface is {up, down,testing}
3) "get" ifOperStatus using an NSAP address to test whether a
dual internet protocol 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 internet protocol 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 for all IPng candidates.
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.
Piscitello Expires 15 January 1995 Page 26
TUBA Working Group TUBA Transition
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. [30] describes Path MTU
discovery for IPv4-based hosts; hosts with IPv4 connectivity should continue to
use [30]. [31] 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]. CATNIP
should also be evaluated for suitability by the TUBA WG as a
compression mechanism.
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 (parts of Internet
| routed using Integrated IS-IS)
|---> CIDR and BGP-4 deployment
|---> CLNP routed in parts of internet using IS-IS
|---> limited management instrumentation for CLNP
|---> tuba/clnp prototypes (effectively knobs=IPv4only)
|
_|___TIME=1_____
|
|---> majority of hosts remain IPv4 capable only
|---> DNS NSAP support begins (over IPv4 paths) on servers
| that are primaries/secondaries for the NSAP address
| RRs of TUBA/CLNP hosts
|---> multicast support using CLNP begins
|---> TUBA/CLNP software installation begins in hosts;
| CLNP-capable hosts operate in production with
| knobs=prefer_IPv4
Piscitello Expires 15 January 1995 Page 27
TUBA Working Group TUBA Transition
|---> 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 operates 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
|---> Internet operates over CLNP; diminishing IPv4
| infrastructure
|---> CLNP-capable hosts now operate in production with
| knob=prefer_CLNP or knob=CLNP_only
|
_|___TIME=?_____
|
|---> IPv4-only communication is rare or highly localized
|---> 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 NSAP addresses, PROTOcol value (hosts
Piscitello Expires 15 January 1995 Page 28
TUBA Working Group TUBA Transition
implementing [5] encode the PROTOcol value in the network selector of the
destination NSAP address), 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. One
such integrated network layer security protocol (I-NLSP) has
been specified for TUBA [39], to provide confidentiality and
integrity services. Dual internet protocol hosts that support
this protocol will be capable of secure operations with (1)
other TUBA/I-NLSP systems using either CLNP or IP, and or (2)
existing IPv4 operating behind TUBA/I-NLSP capable secure
ISs. [39] specifies the I-NLSP, and addresses coexistence and
interoperability issues as well.
10.0 Acknowledgements
This document draws most of its content from efforts of (and
electronic postings to the mailing lists of three IETF
working groups: TUBA, NOOP, and TPIX/CATNIP. 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, Doug Montgomery, and Jim West
(NIST/CSL), Cathy Wittbrodt (BARRnet), Sue Hares (MERIT), Robert Ullman (Lotus),
and Bill Manning (SESQUINET).
Author's Address
David M. Piscitello
Core Competence, Inc.
1620 Tuckerstown Road
Dresher, PA USA 19025
dave@corecom.com
1-215-830-0692
Piscitello Expires 15 January 1995 Page 29
TUBA Working Group TUBA Transition
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. OSI Network Layer Service and
Addressing.
[7a] Callon, R., R. Colella, and R. Hagens, NSAP Guidelines
for the Internet, RFC 1237, July 1991.
[7b] R. Colella, R. Callon, E. Gardner & Y. Rekhter,
Guidelines for OSI NSAP Allocation in the Internet, RFC
1629, May 1994.
[8] ISO/IEC 8473:1992. Protocol for Providing the
Connectionless-mode Network Service, 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 (draft-ietf-tuba-host-clnp-multicas-
01.txt)
[11] Perkins & Rehkter, Y., "Mobility for CLNP". Internet-
draft (draft-ietf-tuba-mobility-00.txt)
[12] Kastenholz, F. "Criteria for choosing IPv7 Selection",
Internet-draft (draft-kastenholz-ipng-criteria-02.txt).
[13] ISO/IEC 9542:1988. End System to intermediate system
routeing exchange protocol for use in conjunction with
CLNP (ISO/IEC 8473).
[14] ISO/IEC 10589:1992. Intermediate system to intermediate
system routeing exchange protocol for use in conjunction
CLNP (ISO/IEC 8473).
[15] ISO/IEC 10747:1992, Protocol for exchange of interdomain
routeing information among intermediate systems to
support forwarding of ISO/IEC 8473 PDUs.
[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 (draft-ietf-tuba-eon-00.txt).
[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.
Piscitello Expires 15 January 1995 Page 30
TUBA Working Group TUBA Transition
[21] Callon, R., and Perlman, R., Integrated IS-IS, RFC 1195.
[22] Tsuchiya, P. Network Address Translator (NAT),
electronically available via ftp from SIGCOMM/CCR.
[23] Gunner, C., Montgomery, D., Experience with the
Integrated IS-IS Protocol, Internet Draft
(draft-ietf-isis-opexp-01.txt)
[24] Piscitello, D., and Chapin, L., Open Systems Networking:
TCP/IP and OSI. Addison Wesley Publishers, August 1993.
[25] Piscitello, D., FTP Operation Over Big Address Records
(FOOBAR), RFC 1639, October 1993 (replaces RFC 1545).
[26] Manning, Colella, DNS RRs for NSAP addresses, RFC 1637.
[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.
[30] Mogul, J., and S. Deering, RFC 1191, MTU Discovery.
[31] Piscitello, D.,"MTU discovery for CLNP-based hosts",
Internet-Draft (draft-ietf-tuba-mtu-01.txt).
[32] Whyman, ICAO CLNP Header Compression algorithm.
[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".
[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] Glenn, K. Robert, "Integrated Network Layer Security
Protocol," Internet Draft (draft-glenn-layer-security-
00.txt), September 1993.
[40] West, J., "Extensions to MIB-II for TUBA/CLNP systems",
Internet Draft (draft-ietf-tuba-mib-00.txt).
Piscitello Expires 15 January 1995 Page 31
