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