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