idnits 2.17.1 draft-ietf-tuba-transition-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-tuba-transition-00.txt)', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-tuba-transition-00.txt)', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-tuba-transition-00.txt)', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-tuba-transition-00.txt)', but the file name used is 'draft-ietf-tuba-transition-00' ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2013 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [4,5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 568 has weird spacing: '...routing regis...' == Line 1928 has weird spacing: '...opriate for a...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (4 March 1994) is 11004 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '30' is mentioned on line 1299, but not defined == Unused Reference: '36' is defined on line 1590, but no explicit reference was found in the text == Unused Reference: '40' is defined on line 1598, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293) ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. '3') ** Downref: Normative reference to an Historic RFC: RFC 1347 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1562 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1237 (ref. '7') (Obsoleted by RFC 1629) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Downref: Normative reference to an Informational RFC: RFC 1526 (ref. '16') -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' ** Downref: Normative reference to an Informational RFC: RFC 1560 (ref. '20') -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' ** Obsolete normative reference: RFC 1545 (ref. '25') (Obsoleted by RFC 1639) -- Possible downref: Non-RFC (?) normative reference: ref. '26' ** Downref: Normative reference to an Historic RFC: RFC 1418 (ref. '27a') ** Obsolete normative reference: RFC 1283 (ref. '27b') (Obsoleted by RFC 1418) ** Downref: Normative reference to an Experimental RFC: RFC 1238 (ref. '27c') -- Possible downref: Non-RFC (?) normative reference: ref. '28' -- Possible downref: Non-RFC (?) normative reference: ref. '29' -- Possible downref: Non-RFC (?) normative reference: ref. '31' -- Possible downref: Non-RFC (?) normative reference: ref. '32' -- Possible downref: Non-RFC (?) normative reference: ref. '33' -- Duplicate reference: RFC1238, mentioned in '34', was also mentioned in '27c'. ** Downref: Normative reference to an Experimental RFC: RFC 1238 (ref. '34') -- Possible downref: Non-RFC (?) normative reference: ref. '35' -- Possible downref: Non-RFC (?) normative reference: ref. '36' ** Downref: Normative reference to an Informational RFC: RFC 1574 (ref. '37') -- Possible downref: Non-RFC (?) normative reference: ref. '39' -- Possible downref: Non-RFC (?) normative reference: ref. '40' -- Possible downref: Non-RFC (?) normative reference: ref. '42' -- Possible downref: Non-RFC (?) normative reference: ref. '43' -- Possible downref: Normative reference to a draft: ref. '44' Summary: 26 errors (**), 1 flaw (~~), 9 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Transition Plan for TUBA/CLNP 2 (draft-ietf-tuba-transition-00.txt) 3 4 March 1994 5 David M. Piscitello 6 Core Competence, Inc. 7 dave@corecom.com 9 Status of this Memo 11 This memo is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 Areas, and its Working Groups. Note that other groups may 14 also distribute working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of 16 six months. This Internet Draft expires on August 31, 1994. 17 Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use 19 Internet Drafts as reference material or to cite them other 20 than as a "working draft" or "work in progress." Please 21 check the I-D abstract listing contained in each Internet 22 Draft directory to learn the current status of this or any 23 other Internet Draft. 25 Distribution of this memo is unlimited. 27 Abstract 29 The ARPA internet protocol suite -- commonly referred to as 30 TCP/IP (after the core protocols, Transmission Control 31 Protocol [1] and Internet Protocol [2]) -- is arguably the 32 most widely used, wide area internetworking solution in the 33 world today. Availability of on-line documentation, multiple 34 vendor-interoperable implementations, and an internationally 35 connected private and commercial infrastructure have most 36 recently contributed to remarkable growth in the size of the 37 global IP-based Internet. Deployment of IP-based networks 38 and hosts cannot continue at the present pace unless certain 39 addressing, protocol and operational limitations are 40 corrected. Two problems of immediate concern are: (i) 41 Internet backbone and regional networks suffer from the need 42 to maintain large and growing amounts of routing 43 information;and (ii) the Internet is gradually running out 44 of IP network numbers to assign. 46 CIDR [3] offers temporary relief from problem (i). This 47 affords the Internet community time to develop and deploy an 48 approach to addressing and routing which allows scaling to 49 several orders of magnitude larger than the existing 50 Internet. 52 All proposed solutions to these problems introduce 53 fundamental (protocol levels of) change to various 54 components of the Internet architecture (internet layer, 55 applications), as well as administrative and operational 56 changes. The large installed base of IP version 4 (IPv4) 57 hosts and IPv4-based internets dictates that new systems 58 which are IP "next generation" (IPng) capable must co-exist 59 with IPv4 systems for an indeterminable transition period. 60 It is necessary for changes of this magnitude to be deployed 61 in an incremental manner. This allows a graceful transition 62 from the current Internet without disruption of service. It 63 is also necessary to continue and extend the lifetime of 64 IPv4, in order to minimize network disruption during the 65 migration period from the current IPv4-based Internet to one 66 that is IPng-based. This paper discusses the transition 67 strategy from the current IPv4-based Internet to one based 68 on the use of ISO/IEC 8473, CLNP, and TUBA [4,5], 69 hereinafter referred to as TUBA/CLNP. 71 1. Introduction 73 This paper discusses a strategy for a transition from IPv4 74 to CLNP that meets the following generalized IPv4-to-IPng 75 goals: 77 a) Provide for interoperation between IPv4-only systems and 78 IPng capable systems 79 b) Provide a simple transition for network operators, sites 80 and end users 81 c) Minimize the introduction of new technologies 82 d) Minimize the introduction of new Internet operational 83 concepts and methods 84 e) Minimize interdependencies between IPv4 and IPng, which 85 should minimize the need for synchronization points 86 during transition and provide end users the flexibility 87 to transition when they need to 88 f) Minimize the impact on existing applications and 89 programming interfaces 91 Several techniques have been proposed for the general case 92 IPng transition. These techniques fall into three 93 categories: 95 1) Evolution from a dual internet protocol environment to an 96 integrated network layer (i.e., IPv4 and IPng eventually 97 reduced to IPng) 98 2) Tunneling (encapsulation of IPng over IPv4 and IPv4 over 99 IPng) 100 3) Network Address/Protocol Translation 102 In this paper, we recommend that the burden of transition 103 from IPv4 to CLNP/TUBA be supported using technique (1). The 104 focal point of this transition strategy is thus the 105 implementation of both IPv4 and CLNP network layers in hosts 106 and routers, initially described in RFC 1347, TUBA (See 107 Figure 1). 109 +------------------------+ 110 | Internet | 111 | applications | 112 | (ftp,telnet,mail,etc.) | 113 +------------------------+ 114 | tcp/udp | 115 +------------------------+ 116 | | | 117 | IPv4 & | CLNP & | 118 | routing | routing | 119 | protocols | protocols | 120 +------------------------+ 121 Figure 1. Dual stack 123 While encapsulation (technique 2) may be used where needed 124 and is explicitly supported, we seek to minimize its use. 125 The transition strategy described herein does not preclude 126 the use of translation techniques (3); translation is 127 sufficiently complicated that we try to avoid this 128 technique. 130 The remainder of this paper is organized as follows: 132 Chapter 2 details the scaling problems that TUBA is 133 designed to overcome. 135 Chapter 3 gives an overview of TUBA. 137 Chapter 4 describes the transition to TUBA/CLNP. 139 Chapters 5, 6, and 7 give detailed specifications and 140 requirements for the components of the transition-period 141 Internet. 143 Chapter 8 discusses remaining, general issues regarding 144 transition. 146 Chapter 9 shows a timeline for TUBA transition 148 Chapter 10 discusses security issues relating to the 149 network layer. 151 The reader can gain an understanding of TUBA and the 152 problems it attempts to resolve by reading chapters 2 153 through 4. Implementors should read chapters 5 through 9. 155 2. Problem Statement 157 The Internet is growing at a remarkable pace, and there is 158 every indication that this pace will continue to accelerate 159 at least through the end of this millennium. Such growth 160 could not be anticipated by the original designers of IP, 161 who should be applauded for providing an enabling vehicle 162 for internetworking that has endured beyond expectations. 163 Still, addressing design choices made over 2 decades ago are 164 now insufficient, and as a result, the Internet must 165 overcome two serious problems: (1) routing information 166 overload and (2) exhaustion of available IP network numbers. 168 The routing table overload problem can be summarized as 169 follows. Historically, IPv4 network numbers have not been 170 assigned in an hierarchical manner; organizations asked for 171 network numbers and the numbers were distributed according 172 to presumed (in many cases, conjectured!) "numbers of hosts" 173 needs and not according to any presumed hierarchy of 174 internetworked networks. Although this method of assignment 175 is no longer practiced, a consequence of this assignment 176 practice is that IPv4 routers assume the address space is 177 flat (i.e., that the network number(s) of neighboring 178 networks do not necessarily have any similarity in the IPv4 179 network portion of their address), and record routes to (and 180 maintain an entry for large numbers of networks in the 181 Internet. Thus, as the number of interconnected networks 182 increases, so does the size of routing tables, especially 183 for backbone networks (continentals, mid levels, regionals). 185 The address exhaustion problem can be summarized as follows. 186 Although 32-bits of the IPv4 address space can in theory be 187 used to identify about 4 billion nodes, this space has been 188 partitioned along octet boundaries to facilitate assignment 189 and aggregation into classes of networks (A, B, C, D), 190 thereby significantly reducing the number of addressable 191 hosts. The pool of available class B network numbers, 192 especially popular because there is a high ratio of 193 addressable hosts per network number, has depleted rapidly. 194 Exhaustion of other assigned network number spaces, 195 especially the Class C numbers, has increased rapidly since 196 a prudent assignment policy has been applied (to Class B's). 197 While opinions vary as to how long the available pool of 198 addresses will last, it is generally acknowledged that a 199 new, larger address space is required. 201 An additional consequence of changing the length of IP 202 addresses is that IP itself must be changed or replaced, as 203 it supports fixed length header fields for IP addresses. We 204 are thus forced to change the "core" Internet at its most 205 fundamental (internet) level, by introducing a successor to 206 IPv4, its addressing and routing architecture. 208 To make the transition from IPv4 to TUBA as smooth as 209 possible, the following objectives must be taken into 210 consideration: 212 1) The transition should impose a minimum impact on the end 213 users of hosts. 214 2) The transition should leverage as much of the users' and 215 administrators' investment in existing Internet 216 operations, training, terminology as possible. We should 217 recognize that users, administrators, and network 218 operators have made substantial investments in 219 "understanding" IPv4. Administrators and network 220 operators in many cases have made an investment in 221 "understanding CLNP". Neither investment should be 222 discounted or lost. 223 3) Users and network operators should be able to transition 224 at their own pace. 225 4) Users should be able to upgrade hosts and routers 226 incrementally. 227 5) Sites which deploy a dual stack environment should 228 accumulate the benefits and features of TUBA as they 229 deploy. For example a new TUBA host should be able to use 230 the auto-configuration mechanisms immediately. 231 6) The larger addresses of TUBA/CNLP should be used to solve 232 the IPv4 route scaling problem early on in the 233 transition. 234 7) The transition plan must provide complete, global 235 connectivity between TUBA and IPv4 hosts for as long as 236 IPv4 can provide global connectivity. 237 8) The transition plan should provide global connectivity 238 for IPv4 traffic for as long as necessary. 239 9) It should leverage the existing IPv4 routing and DNS 240 infrastructure wherever possible. 242 3. TUBA Overview 244 TUBA [4] solves the problems described in section 2 by 245 using: 247 1) OSI network service access point addresses (NSAPAs), a 248 flexible and extensible network addressing plan which 249 accommodates multiple administrations and multiple levels 250 of addressing hierarchy for routing purposes (see [6] and 251 [7]) 252 2) OSI connectionless network layer protocol (CLNP), a 253 network layer datagram. 254 3) OSI routing protocols, which provide host/router 255 discovery and autoconfiguration (ES-IS, see [13]); 256 dynamic, (link-state) intradomain routing (IS-IS, see 257 [14]); and policy-based routing (see IDRP, [15]). 258 (4) RFC 1237 assignment guidelines, which describe an 259 addressing architecture based upon the use of prefix- 260 based address administration and routing. This 261 architecture supports aggregation of addresses by 262 country, by service provider, and by area. This allows 263 for substantial route aggregation, and appears to scale 264 to a very large Internet. (RFC 1237 guidelines have been 265 adapted for IP and form the basis for CIDR allocation and 266 deployment strategies for the IPv4-based Internet.) 268 TUBA allows the current Internet applications -- Telnet, 269 SNMP, FTP, SMTP/822 electronic mail, and the internet 270 information retrieval navigators and services (WAIS, WWW, 271 gopher, prospero, archie, veronica, netfind, finger) -- to 272 operate using native transport protocols -- UDP and TCP -- 273 on top of CLNP in place of IPv4. 275 TUBA replaces the IPv4 network layer (datagram and routing 276 protocols) with CLNP [8], ES-IS [13], IS-IS [14], and IDRP 277 [15]). The architectural features and functionality of CLNP 278 is nearly identical to that of IPv4 (see [5] for an overview 279 and comparison). CLNP accommodates variable length 280 addresses, provides fundamentally the same level of service 281 as IPv4 (see [8]), and with the addition of [9, 10, 11], 282 meets IPng selection criteria described in [12]. [5] defines 283 the use of CLNP in TUBA environments, providing the rules 284 for network layer protocol and pseudo-header composition, 285 application of the PROTOcol mechanism in the CLNP header, 286 and the use of the CLNP error reports as replacements for 287 corresponding ICMP messages. The CLNP, and transport header 288 layout is summarized as follows: 290 +------------------------+ 291 | data link layer header | 292 +------------------------+ 293 | CLNP header | 294 | (NSEL=PROTO=TCP) | 295 +------------------------+ 296 | TCP | 297 +------------------------+ 298 Figure 2. Header layout for TUBA/CLNP 300 CLNP is already understood by most developers of Internet 301 products and by many operators of backbone regional/mid 302 level, and attached (client) networks in the Internet 303 infrastructure. CLNP implementations exist today for most 304 host and router systems. The routing architecture (a) is 305 similar to that implemented for IPv4 (OSPF vs. IS-IS, BGP-4 306 vs. IDRP). A major advantage of using CLNP as a replacement 307 for IPNG is that the routing architecture has already been 308 specified, standardized, implemented in products, and 309 deployed in large-scale production networks. 311 As the Internet evolves it may be necessary to enhance the 312 routing system to introduce new capabilities, such as 313 support for mobility, multicast, flows, and provider based 314 selection. Many of these capabilities can be implemented in 315 CLNS using techniques and protocols analogous to those 316 applied in the IPv4 context. Several of these enhancements 317 ([9], [10], [11]) are currently under investigation within 318 the IETF. 320 CLNP is distinguished from IPv4 by its use of flexible, 321 variable length network addresses, or NSAPAs (see [6] and 322 [7]). These addresses are already applied in those portions 323 of the global Internet that offer CLNP connectivity 324 according to guidelines developed within the IETF (see RFC 325 1237). The assignment and allocation guidelines defined in 326 RFC 1237 formed the basis for the development of CIDR [3]. 328 Although the referenced addressing documents specify a 329 maximum NSAPA length of 20 octets, formats that accommodate 330 larger addresses can be added by the introduction of 331 additional authority and format indicators (AFIs) in [6], 332 and CLNP will accommodate these longer addresses as well. 333 This satisfies the IPng objective of effectively unlimited 334 addressing (if not already satisfied by the generous 20- 335 octet addresses available). A significant advantage of 336 NSAPAs is that they can be structured in a manner that 337 allows embedding other network layer addresses, such IPv4 338 and Novell IPX (see [16] for a description of how these may 339 be encoded as system identifiers (or globally unique 340 endpoint identifiers) within an RFC 1237 compliant NSAPA). 342 4. Transition to TUBA/CLNP 344 The TCP/IP Internet is a large and complex system. However, 345 the operation of the Internet is based on a very simple 346 notion: ubiquitous end to end connectivity provided by a 347 single datagram network layer protocol. This simple building 348 basis for the Internet is a major part of the its success. 350 An important lesson in the design and deployment of very 351 complex systems is that very large, complex, and highly- 352 interdependent systems are difficult to deploy and manage. 353 Even in those rare circumstances where one might succeed in 354 deploying such a system, it becomes difficult or impossible 355 to update one part of the overall system without upsetting 356 other parts of the system. 358 The transition from IPv4 to CLNP will be gradual, and will 359 be accomplished over an extended but as yet indeterminable 360 period of time. During this time frame, both IPv4 and CLNP 361 may need to be updated to respond to new requirements. If 362 the end-to-end operation of IPv4 is dependent upon CLNP, and 363 if end-to-end operation of CLNP is simultaneously dependent 364 upon IPv4, then it may become very difficult to update both 365 protocols to respond to new requirements over time (this is 366 true in general for any IPng). 368 An important consideration for the transition from IPv4 to 369 CLNP is thus to minimize the overall complexity of the 370 system, and to simultaneously minimize the interdependencies 371 between these major parts of the system. TUBA places a new 372 network layer beside IPv4 in new (and all future) system 373 implementations. New hosts continue to communicate with IPv4- 374 only hosts over an IPv4 infrastructure which remains fully 375 operational (in parallel with the new infrastructure) until 376 such time as the IPv4 address space is depleted. At such 377 time, it is expected that the vast majority of systems will 378 be CLNP-capable, and IPv4 communication may be phased out. 379 (Note that the decision to turn off IPv4 ultimately lies in 380 the hands of individual administrations; the transition plan 381 imposes no timeframe for IPv4 shutdown.) 383 The presence of a second network layer protocol in the 384 Internet is nothing news(worthy). Multiprotocol 385 internetworking is very much the norm in today's complex 386 internets (see RFC 1560 [20]). It is common to find networks 387 that support 5 or more protocol stacks (including TCP/IP, 388 IPX, Appletalk, SNA/APPN, DECnet, CLNP, and others). Network 389 managers are used to deploying and managing multiple 390 independent protocol stacks. The routers and hosts from all 391 major vendors already support multi-stack operation. The 392 TUBA transition scheme therefore makes use of techniques and 393 concepts with which network managers and implementors are 394 already familiar. 396 The TUBA transition plan acknowledges that host software 397 will be the gating function of any transition due to the 398 large number of Internet hosts compared to routers. The 399 components of the transition are as follows: 401 1) The routed infrastructure is upgraded to support CLNP. 402 Routers not already capable of doing so must be updated 403 (or configured) to support forwarding of both IPv4 and 404 CLNP packets. (Routing and forwarding of IP and CLNP 405 packets may be done independently, or at the discretion 406 of a routing domain administration, integrated routing 407 [21] may be used.) 408 2) The Domain Name System is upgraded to support NSAPAs. DNS 409 servers are modified to return NSAP addresses (DNS 410 systems must continue to support IPv4 name-to-address 411 resolution). Initially, DNS will operate over IPv4 412 service. 413 3) TUBA/CLNP is introduced as new host software is deployed, 414 and internet applications are operated over TUBA/CLNP 415 (new host software is expected to support TCP/UDP over 416 IPv4 and CLNP). 417 4) CLNP connectivity is provided to all sites. 418 5) The network is "swamped" with TUBA/CLNP-capable hosts. 419 6) DNS support is moved onto the CLNP infrastructure. 420 7) Production networks operate over the CLNP infrastructure. 422 A detailed timeline for the transition plan is provided in 423 Section 9. 425 TUBA transition is compatible with (and independent from) a 426 wide range of techniques for extending the life of the "pure 427 IPv4" Internet. (Discussion of techniques that have been 428 proposed for this purpose can be found in [22], [23], [24].) 430 4.1. Dual Stack Operation 432 Figure 4 illustrates the basic operation of TUBA transition. 433 Illustrated is a single Internet routing domain, which is 434 also interconnected with Internet backbones and/or 435 regionals. The two "updated" Internet Hosts, N1 and N2, must 436 be able to send either old-style packets (using IPv4), or 437 new style packet (using CLNP). N1 and N2 thus communicate 438 with old Internet hosts using the current Internet suite 439 unchanged, and with other updated Internet hosts using CLNP. 440 Which to send is determined via the name-to-address lookup 441 mechanism. (Although we rely on the DNS in this example, the 442 transition plan does not actually depend upon the DNS for 443 its operation. Any method that is used for obtaining 444 Internet addresses; e.g., statically configured tables) may 445 be updated to be able to return both IPv4 and NSAP addresses 446 when queried with a domain name.) 448 Figure 4 illustrate two older hosts H1 and H2, plus a DNS 449 server, plus two border routers, R1 and R2. Routers internal 450 to the routing domain are capable of forwarding both IPv4 451 and CLNP traffic (this could be done either by using multi- 452 protocol routers which can forward both protocol suites; by 453 using a different set of routers for each suite; or by using 454 tunneling/encapsulation as described in section 4.2). 456 ............. ................... 457 : : : : 458 : : : : 459 : H1 : : Internet : 460 : :----R1----: : 461 : H2 : : Backbones : 462 : : : : 463 : DNS : : : 464 : : : and : 465 : N1 : : : 466 : : : Regionals : 467 : N2 :----R2----: : 468 : : : : 469 :...........: :.................: 471 Key 473 DNS DNS server 474 H IP host 475 N Updated Internet host 476 R Border Router 478 Figure 4 - TUBA transition 480 Thus, in case (1), suppose that host N1 wants to communicate 481 with host H1. In this case, N1 asks its local DNS server for 482 the network address(es) associated with H1. Since H1 is an 483 older (not-updated) host, the address available for H1 is an 484 IPv4 address, and thus the DNS response returned to N1 485 specifies an IPv4 address. On the basis of the address 486 returned, N1 knows that it must use an IPv4 packet to 487 communicate with H1. 489 Suppose (case 2) host N1 wants to communicate with host N2. 490 Again N1 contacts the DNS server. If the routers in the 491 domain have not been updated (to forward CLNP), or if the 492 DNS resource record for N2 has not been updated to include 493 NSAPAs, then the DNS server will respond with an IPv4 494 address, and communication between N1 and N2 will use IPv4. 495 However, assuming that the routers in the domain have been 496 updated (to forward CLNP), that the DNS server has been 497 updated (to be able to return NSAP addresses), and that the 498 appropriate resource records for NSAP addresses have been 499 configured into the DNS server, then the DNS server will 500 respond to N1 with the NSAP address for N2, allowing N1 to 501 know to use CLNP (instead of IPv4) for communication with 502 N2. 504 To assure that the assumptions for case 2 are satisfied 505 prior to attempting communication using CLNP, network 506 administrators are encouraged to register NSAPAs of 507 TUBA/CLNP hosts in the DNS (or other name->address system) 508 only after CLNP connectivity is provided to these hosts. 510 CLNP connectivity may be provided at some points in the 511 Internet via tunnels, but this is assumed to be an interim 512 step while native CLNP connectivity is being arranged. The 513 means by which TUBA systems communicate with IPv4 and other 514 TUBA systems are summarized in the following table: 516 +-----------+-----------+--------------+----------+ 517 | ORIGIN | RECIPIENT | DNS_REPLY | USE | 518 +===========+===========+==============+==========+ 519 | IPv4 host | IPv4 host | IPv4 addr | IPv4 (1) | 520 +-----------+-----------+--------------+----------+ 521 | IPv4 host | TUBA host | IPv4 addr | IPv4 (1) | 522 +-----------+-----------+--------------+----------+ 523 | TUBA host | IPv4 host | IPv4 addr | IPv4 (1) | 524 +-----------+-----------+--------------+----------+ 525 | TUBA host | TUBA host | IPv4 addr | IPv4 (2) | 526 +-----------+-----------+--------------+----------+ 527 | TUBA host | TUBA host | IPv4 addr, | CLNP (3) | 528 | | | NSAP addr | | 529 +-----------+-----------+--------------+----------+ 531 Table 1. Framework for TUBA host communication 533 Notes: 535 1) end-to-end IPv4 connectivity not available, can use CLNP 536 to tunnel IPv4 [19]. This is viewed as necessary to 537 support "legacy (IPv4)" hosts. 538 2) this is the situation where the destination host is not 539 yet reachable via CLNP; the destination NSAPA is not 540 registered and cannot be obtained via a DNS lookup. 541 3) use IPv4 tunnel [18]. This is viewed as necessary when 542 CLNP connectivity is not available between originator and 543 recipient. 545 The Internet has several infrastructural components which 546 must have dual stack functionality (eventually, see the 547 timeline in section 9): 549 - Network Service Providers 550 - The Domain Name System (DNS) 551 - The Internet address and name assignment function (NICs 552 and IANA). 553 - Hosts 555 Many campus, enterprise network, and Internet transit 556 networks (NASA Sciences Internet, Energy Sciences Network, 557 Alternet, SURANET, Sesquinet, the Italian Research 558 Network/INFN, Switch, etc.) already route and forward 559 multiple network layer protocols at the same time, including 560 CLNP. The presence of this operational infrastructure 561 provides an accelerated baseline for deployment. 563 4.1.1 Network Service Providers 565 A commonly overlooked component in IPng transition is the 566 need to coordinate routing for protocols other than IPv4. 567 This coordination creates well known "interconnects" (e.g. 568 FIX, CIX, GIX, NAP, etc.) and provides routing registration 569 anddissemination as done by Merit/NSFNET, the Ripe NCC and 570 the Japanese JPNIC. The current interconnects already switch 571 multiple protocols, including CLNP. The schema for the 572 current set of databases for the routing registration and 573 dissemination function has been extended to include CLNP 574 addresses and prefixes (e.g. network numbers). Standard CLNP 575 operations practices are also in place. 577 4.1.2 Updating DNS Infrastructure 579 In the current Internet architecture the DNS maps between 580 Internet names and IPv4 addresses. The DNS must be extended 581 to also support NSAP addresses. Prototype implementations of 582 DNS servers and resolver libraries that can support multiple 583 address types are available for TUBA/CLNP. 585 DNS servers shall operate on the IPv4 routed infrastructure 586 until the CLNP transition is complete since IPv4-only hosts 587 will always generate IPv4 specific DNS queries. DNS queries 588 shall by default use IPv4 connectivity unless explicitly 589 configured to use CLNP connectivity (transition to use of a 590 CLNP-routed infrastructure shall thus be governed by a 591 configuration option for DNS servers). The DNS server 592 implementations must eventually be updated to run on top of 593 a multiprotocol Internet. 595 DNS clients will use the same method of choosing the active 596 network layer protocol as other host applications. This is 597 detailed in section 4.1.4. 599 4.1.3 Internet address and name assignment functions 601 Guidelines exist for the assignment of NSAPAs in the 602 Internet [7]; assignment of NSAPAs shall continue under 603 these guidelines. The current practices for assignment of 604 IPv4 addresses shall remain in place (only refinements and 605 extensions to CIDR allocation are expected to influence 606 current practices). Domain name assignment is unaffected by 607 this plan. 609 4.1.4 Dual stacks and hosts 611 A general discussion of the implications of IPng 612 implementation on hosts can be found in [39]. The impact on 613 host run-time resources for TUBA hosts is under 614 investigation, but preliminary results indicate that memory 615 requirements to support the CLNP network layer alongside 616 IPv4 should not be a barrier for low-end hosts. 618 Dual internet protocol support in hosts requires 619 coordination and control on the part of implementors, system 620 administrators, users, and network administrators. Internet 621 applications (the business of hosts) must be re-engineered 622 to selectively use either stack during transition. If DNS is 623 used, then as a rule, the host should be registered in the 624 DNS as an IPv4-only system until such time as it intends to 625 make use of CLNP. Thereafter, selection of network layer 626 should be under local control. 628 A helpful abstraction for local control is the notion of a 629 soft switch or knob on a host that controls its (network 630 layer) operation. For example, a knob should have 4 631 settings: 633 (1) IPv4 only. The host operates over IPv4-only. This is the 634 default setting (the only logical state of IPv4-only 635 hosts). 636 (2) Prefer IPv4. The host is capable of obtaining both IPv4 637 and NSAP addresses from the DNS (or other name-to- 638 address resolver), but given a choice, it will always 639 use an IPv4 path. Under this setting, the host is 640 registered as a dual stack host, but expects the 641 majority of communication it initiates to be IPv4 (i.e., 642 most of the servers it expects to contact are reachable 643 via IPv4). Server applications on host may also accept 644 incoming connections over CLNP paths. 645 (3) Prefer CLNP. As in (2), the host is capable of obtaining 646 both IPv4 and NSAP addresses from the DNS (or other name- 647 to-address resolver), but given a choice, it will always 648 use an CLNP path. Under this setting, the host is 649 registered as a dual stack host, but expects the 650 majority of communication it initiates to be CLNP (i.e., 651 most of the servers it expects to contact are reachable 652 via CLNP). Server applications on host may also accept 653 incoming connections over IPv4 paths. 654 (4) CLNP only. The end state of transition. All hosts in the 655 Internet are CLNP-capable. 657 4.2 TUBA Tunnelling 659 OSI and TUBA/CLNP hosts and routers have used the EON 660 tunneling protocol [17] to carry CLNP packets over regions 661 of the Internet that route only IPv4 packets for several 662 years. The subset of the EON protocol as implemented and 663 fielded today is a virtual point-to-point encapsulation of 664 CLNP datagrams between statically configured tunnel 665 endpoints. (There is no support for simulating a multipoint 666 subnetwork, nor for dynamic mapping between NSAP addresses 667 and IPv4 addresses; IPv4 addresses are treated as subnetwork 668 point of attachment addresses that must be statically 669 configured to create the tunnel.) Once a tunnel is 670 established, the ES-IS [13] and IS-IS [14] protocols are 671 used to dynamically establish neighbor adjacencies and 672 routing. 674 The encapsulation is as follows: 676 +--------------------------+ 677 | IPv4 header | 678 | (protocol = 80 decimal) | 679 +--------------------------+ 680 | EON header | (value = hex 01 00 FC 02) 681 +--------------------------+ 682 | OSI Network Layer packet | 683 +--------------------------+ 685 Figure 3. EON encapsulation 687 Tunneling is one of the mechanisms that will be employed 688 during the IPv4-CLNP transition period to connect: 690 a) TUBA hosts, in those circumstances where native CLNP 691 transport is not available (i.e., across routing domains 692 that have not introduced a CLNP backbone) 693 b) IPv4 hosts, at such time where global IPv4 connectivity 694 is no longer available, and IPv4 hosts in separated 695 (isolated) routing domains must use the CLNP backbone for 696 transport 698 [18] describes the encapsulating protocol that should be 699 applied when CLNP is the "payload packet" within an IPv4 700 datagram. 702 [19] describes a generic encapsulating protocol that may be 703 applied when IPv4 is the "payload packet" within a CLNP 704 datagram. 706 The TUBA transition plan does not require the translation 707 between IPv4 and CLNP network layer datagrams. Appendix A 708 discusses issues and unresolved concerns that form the basis 709 for the decision not to use translation. 711 5. Multiprotocol routers 713 TUBA relies on the existence of multiprotocol routers -- 714 routers that can forward (at least) IPv4 and CLNP datagrams. 715 Multiprotocol routers are available, widely deployed and 716 eminently tractable technology. (Note: one can certainly use 717 separate routers and topologies to switch IPv4 and CLNP, if 718 this is desirable or necessary.) 720 During the transition, certain routers may be expected to 721 support tunnels; i.e., to support the forwarding of CLNP 722 datagrams by encapsulating them in IPv4 packets. 724 Details of the tunneling mechanisms for TUBA are described 725 in separate documents (see [18] and [19]). Section 9 726 discusses the timeline for CLNP and tunnel deployment for 727 TUBA transition. 729 6. TUBA and address translation. 731 Prudent allocation of IPv4 addresses and application of CIDR 732 provides a "grace period" for the development and selection 733 of an IPng; eventually, however, the IPv4 address space will 734 become inadequate for global routing and addressing, and 735 IPv4-only hosts will no longer be able to interoperate 736 directly over the global Internet. 738 6.1 When 32-bit addresses run out 740 Some administrations may wish to extend the lifetime of IPv4 741 addressing (and hence IPv4) beyond this point in time. There 742 are several approaches that may be used (separately, or in 743 combination) for continued operation of IPv4 under these 744 circumstances. One method involves splitting the IPv4 745 Internet into a number of "local address domains". 32-bit IP 746 addresses will be meaningful only within a local address 747 domain. This allows the old IPv4-only hosts to communicate 748 locally. For communication between local address domains, 749 systems may use (a) a convergence protocol and addressing 750 extensions (e.g., IPAE); (b) translation to a common, future 751 protocol (e.g., CATNIP); (c) tunnels established 752 specifically for this purpose (providing all the addresses 753 at tunnel endpoints remain unique); (d) application relays 754 (again, in the case where applications manipulate IPv4 755 addresses, all the addresses at tunnel endpoints must remain 756 unique); or (e) network address translation. 758 The dual internet protocol transition allows migration to 759 CLNP to be performed independently from "life support" for 760 the old IPv4 address space; i.e., a variety of means may be 761 used to maintain IPv4 connectivity for as long as this is 762 economically and technically feasible without disrupting 763 migration to IPng. The dual stack environment present during 764 the transition from IPv4 to CLNP will not interfere with 765 such attempts to maximize the lifetime of IPv4 internets, 766 nor would it interfere with attempts to recycle (re-use) or 767 further extend the aggregation properties of the current 32- 768 bit address space (i.e., by extending CIDR policies to class 769 A addresses). 771 At this time, we do not recommend translators for the 772 transition from IPv4 to TUBA/CLNP. 774 6.2 Turning down the IPv4 infrastructure 776 There are at least two perspectives regarding the issue of 777 how to phased out IPv4: 779 1) In "n" years, IPv4 should be turned off. Given the 780 current rate of Internet growth, plus the possibility of 781 updating existing systems, the number of IPv4-only systems 782 will be dwarfed by the number of IPng systems, and the 783 impact will be small. 785 2) There will be sufficient permutations and combinations of 786 IPv4 lifetime extensions implemented that "n" is likely to 787 approach infinity. 789 Nothing in this transition plan forces an administration to 790 turn off IPv4 at any given time "t". Under the plan 791 specified herein, IPv4 and CLNP may co-exist "forever". 793 7. TUBA/CLNP Hosts 795 TUBA/CNLP hosts must implement CLNP, ES-IS, and several 796 additional modifications to run "dual-stack". The 797 modifications affect the internet and transport layers of 798 the protocol software, and the application program interface 799 (API) offered by the transport layer. Some internet 800 applications must change as well, especially those that make 801 direct use of IPv4 addressing rather than domain names. 803 Dual stack hosts must be able to transmit and receive both 804 CLNP and IPv4 packets; resolve network addresses of 805 destinations to hardware addresses. Dual stack hosts may 806 also be expected to request configuration information from 807 servers, and request auto registration of domain names and 808 addresses (see sections 7.2 and 7.3). 810 7.1. What packet format to send. 812 The first decision a host must make is which form of packet 813 to transmit: IPv4 or CLNP. This may be accomplished through 814 a local (to the host) configuration switch (which reflects 815 the default or desired state of the global connectivity), 816 and could be set at various granularities (i.e., on switch 817 per host, per destination). 819 7.2. Transport pseudo-header checksum. 821 TCP and UDP both define a checksum that covers the data 822 portion of the segment along with a 96-bit "pseudo header" 823 that includes the IPv4 source and destination addresses, 824 protocol ID and length fields from the IPv4 header. 825 Including this pseudo header in the transport checksum 826 protects the transport layer against misrouted segments. 828 The pseudo header used in the transport checksum when TCP 829 and UDP are layered above CLNP is described in [5].It 830 includes the source and destination NSAP addresses 831 (including selectors, protocol ID, length fields from the 832 CLNP header. 834 7.3. TCP and UDP connection identification for TUBA hosts 836 TCP uses the concatenation of local and remote IPv4 address 837 with local and remote port number to uniquely identify a 838 connection. TCP uses the term "socket" to identify one 839 endpoint of a connection. The local socket is identified by 840 the local IPv4 address and local port number, while the 841 remote socket is identified by the remote IPv4 address and 842 remote port number. This path is unaffected when a dual 843 stack host communicates with IPv4-only host. This is also 844 true when 845 dual stack hosts process received segments and ICMP error 846 messages. 848 When communicating with another dual-stack host, TCP uses 849 the full source and destination NSAP addresses and 850 local/remote port numbers to identify connections and 851 sockets. 853 7.4. Error and Control Messages 855 Systems involved in the forwarding of IPv4 datagrams shall 856 continue to use ICMP for error and control messages. Systems 857 involved in the forwarding of CLNP datagrams shall use CLNP 858 error report messages. [5] defines the mapping between ICMP 859 message types and CLNP error report types. Currently, there 860 are no corresponding CLNP Error Report Codes for the 861 "Protocol Unreachable" and "Port Unreachable". These should 862 be assigned from the code points available in the error 863 report type code block in ISO/IEC 8473. 865 The use of ICMP shall continue unchanged. CLNP error reports 866 should include the "offending packet" in the data part of 867 the packet. The "offending packet" should include the CLNP 868 header plus at least the first 8 octets of the packet that 869 caused the error being reported. The offending packet is 870 used by the recipient of the ICMP error message to locate 871 the transport-layer endpoint that caused the error. 873 NOTE: ISO/IEC 8473 only guarantees that the entire header of 874 the offending packet shall be returned; thus, if the 875 minimumm MSS of 512 octets is used, and the combined lengths 876 of the error report header and the offending packet header 877 exceed 504 octets, fewer than 8 octets of data would be 878 returned. 880 7.5. Transport API changes. 882 Most IPv4 systems that are modified to support TUBA/CLNP 883 will already have an existing application program interface 884 (API) through which applications use TCP and UDP, and many 885 will already have an API through which applications use OSI 886 transport protocols (e.g., those that support XTI). For 887 IPv4, these APIs typically carry a 32 bit IPv4 address in 888 order to bind a TCP or UDP endpoint to a local address, to 889 specify the destination address of a UDP datagram being 890 sent, or to specify the destination address of a TCP 891 connection being opened. The 32 bit IPv4 address shows up in 892 other parts of the API, such as the return value from a 893 hostname-to-IPv4 address lookup function. Generally, these 894 APIs provide fixed-size fields to hold IPv4 addresses and 895 TCP and UDP port numbers. These APIs must modified be to 896 carry variable length NSAP addresses in order to support 897 TUBA/CLNP. 899 We do not impose any specific requirements on how the APIs 900 should be changed to support TUBA/CLNP. However, we offer 901 here some general considerations in designing these new 902 APIs. 904 Some desirable features of a dual stack API are: 906 1) The new API should allow applications to pass in both 32- 907 bit IPv4 addresses and variable length addresses. (New 908 applications are likely to encounter 32 bit IPv4 909 addresses.) 910 2) The new API should provide both source and binary 911 compatibility with the existing IPv4 API. Applications 912 written to the old API should continue to operate when 913 run in binary form, or when re-compiled on an dual stack 914 system with the new API. 915 3) Un-modified applications should provide as much TUBA/CLNP 916 service as possible. 917 4).Application protocols that do not manipulate IP addresses 918 should run without any modifications. 920 Along with the API changes, application programs that 921 manipulate IPv4 addresses must usually be modified. Often 922 these changes can be isolated to the code that parses NSAP 923 addresses typed in by users, and the code that deals with 924 NSAP addresses returned by the name to address translation 925 functions (DNS lookups). 927 7.6. IPv4 Addresses Embedded in Application Protocols 929 In this section, we specify how hosts should use existing 930 application protocols in a dual stack environment. (Note 931 that this section discusses protocol changes only; changes 932 to user interfaces, i.e., changes to APIs, the use of an 933 "NSAPA domain-literal" instead of an IPv4 domain-literal in 934 a command line for telnet, etc. are not discussed here). 936 The application protocols layered above TCP and UDP fall 937 into four categories: 939 1) Application protocols that do not carry embedded IPv4 940 addresses. These protocols can be used immediately by 941 TUBA hosts. The protocols which require no changes are: 943 Telnet (RFC 854, RFC 855) 944 TFTP (RFC 1350) 945 BSD "rlogin" protocol (RFC 1282) 946 BSD "rsh" protocol (uses port number, not IP addr) 947 BSD "biff" protocol (in.comsat) 948 BSD "lpr" protocol (RFC 1179) 949 BSD "syslog" protocol 950 ONC RPC protocol (RFC 1057) 951 ONC original "portmap" protocol (RFC 1057) 952 ONC+ new "rpcbind" protocol (replaces portmap) 953 Echo - TCP & UDP (RFC 862) 954 Discard - TCP & UDP (RFC 863) 955 Chargen - TCP & UDP (RFC 864) 956 Quote of the Day - TCP & UDP (RFC 865) 957 Active users - TCP or UDP (RFC 866) 958 Daytime - TCP or UDP (RFC 867) 959 Time - TCP or UDP (RFC 868) Nicname/Whois (RFC 954) 960 Finger (RFC 1288) 961 SNMP (RFC 1157) 962 Concise-MIB (RFC 1212) 963 Content type mail header field (RFC 1049) 964 NNTP (RFC 977) 965 BSD "rexec" protocol 966 NTP (RFC 1119) 967 NFS 969 2) Application protocols that carry IPv4 addresses, but the 970 protocol or its use of IPv4 addresses is obsolete. These 971 protocols do not need to be changed. They can continue to 972 be used by TUBA hosts indefinitely. The protocols which 973 carry IPv4 addresses, but do not need to be changed 974 because their use of IPv4 is obsolete are: 976 SMTP (RFC 821) 977 Mail (RFC 822) 978 BSD "talk" protocol 980 3) Application protocols that carry IPv4 addresses, but that 981 are used exclusively by IPv4 systems. These protocols 982 need not be changed, although new versions of them may be 983 necessary in order to support the same function in 984 TUBA/CLNP systems. Protocols that fall into this category 985 are: 987 IP Forwarding table MIB (RFC 1354) 988 RARP (RFC 903) 989 BOOTP (RFC 951, RFC 1084) 990 DHCP (RFC 1531) 991 PPP IP address negotiation options 992 ONC "bootparams" RPC protocol 993 DNS (RFC 1034, RFC 1035) 994 Traceroute 995 Ping (Echo) 997 4) Application protocols that carry IPv4 addresses, but that 998 are not IPv4 specific. FTP falls into this category. 999 Systems which implement [25] will provides FTP 1000 functionality when used by TUBA/CLNP systems. 1002 We did not have enough information to evaluate these 1003 application protocols: 1005 Kerberos 1006 Telnet options 1007 POP3 (RFC 1225) 1008 DNS mail routing (RFC 974) 1009 MIME (RFC 1341) 1011 The remainder of this section discusses how dual stack hosts 1012 should accommodate those application protocols which 1013 manipulate IPv4 addresses. 1015 7.6.1. FTP 1017 IPv4 addresses are encoded in FTP in two places: 1019 - the arguments to the PORT command. 1020 - the reply to the PASV command. 1022 Both the argument to the PORT command and the reply to the 1023 PASV command contain a 32-bit IPv4 address and a 16-bit TCP 1024 port number. 1026 These commands are used for two specific purposes: 1028 1) In a 2-party FTP transaction, the client uses the PORT 1029 command to specify a TCP port number on the client's 1030 machine other than the default (port 20) for the server 1031 to connect back to the client on. 1032 2) In a 3-party FTP transaction involving one client FTP and 1033 two server FTPs. The client gives the PASV command 1034 command to FTP server 1 and records the address reply. 1035 Then it sends the PORT command command to FTP server 2, 1036 giving the address returned by server 1. Then it sends 1037 the STOR or RETR command to server 2 to transfer file(s) 1038 directly between server 1 and server 2. 1040 [25] describes general extensions to FTP that enable hosts 1041 to operate the application using addresses other than 32-bit 1042 IP addresses, including variable length NSAPAs. 1044 7.6.2. SMTP (RFC 821) and Mail (RFC 822) 1046 IPv4 addresses may appear in the RFC 821 HELO reply codes 1047 and RFC 822 mail header format in the "domain literal" 1048 address construct. It is possible to specify a domain 1049 address as a dotted-decimal address. For example, one could 1050 specify a mail user in an 822 encoded mail header as: 1052 beavis@[10.9.9.1] 1054 This construct is specified in section 6.2.3 of RFC 822. The 1055 RFC includes the following warning: 1057 "Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. 1058 It is permitted only as a means of bypassing temporary 1059 system limitations, such as name tables which are not 1060 complete." 1062 It is recommended that the campaign to "discourage" the 1063 domain-literal address construct continue. We do not 1064 recommend that the domain-literal address construct syntax 1065 be modified to support NSAP addresses. Domain literal 1066 addresses will still be useful globally so long as IPv4 1067 addresses are globally unique. 1069 Some systems perform a reverse DNS lookup to ensure that the 1070 source IPv4 address maps to the source DNS name contained in 1071 the mail header as a form of very weak authentication. 1072 Implementations may require extensions to perform this 1073 function using NSAPAs, if desirable. 1075 7.6.3. Domain Name System (DNS) 1077 There are two places within the DNS where IPv4 addresses are 1078 encoded: 1080 - The "A" record format. 1081 - The structure of the "in-addr.arpa" tree. 1083 A new resource record type is defined for NSAP addresses 1084 [26]. [26] also describes how the PTR resource record used 1085 under the "IN-ADDR.ARPA" domain may be used to map from 1086 NSAPAs to domain names (under the ".NSAP" domain). New hosts 1087 ask for both the new (NSAPA) and old (IPv4 address) resource 1088 records. Older DNS servers will not have the new resource 1089 record type, and will therefore respond with only IPv4 1090 address information. Updated DNS servers will have the new 1091 resource record information for the requested DNS name only 1092 if the associated host has been updated (otherwise the 1093 updated DNS server again will respond with an IPv4 address). 1095 Hosts and/or applications which do not use DNS operate in a 1096 similar method. For example, suppose that local name to 1097 address records are maintained in host table entries on each 1098 local workstation (i.e., in a hosts.txt file). When a 1099 workstation is updated to be able to run Internet 1100 applications over TUBA/CLNP, then the host table on the host 1101 may also be updated to contain updated NSAP addresses for 1102 other hosts which have also been updated ([37] describes an 1103 "osi host.txt" file format that should be used for OSI or 1104 TUBA applications). The associated entries for non-updated 1105 hosts would continue to contain IPv4 addresses. Thus, again 1106 when an updated host wants to initiate communication with 1107 another host, it would look up the associated Internet 1108 address in the normal manner. If the address returned is a 1109 32-bit IP address, then the host would initiate a request 1110 using an Internet application over TCP (or UDP) over IP (as 1111 at present). If the returned address is an NSAP address, 1112 then the host would initiate a request using an Internet 1113 application over TCP (or UDP) over CLNP. 1115 The rules for hosts to contact DNS servers, and for DNS 1116 servers to contact other DNS servers, are the same as for a 1117 host to contact a host. Old (not updated) hosts use IPv4 for 1118 all of these purposes. Updated hosts obtain the address of 1119 their local DNS server the same way that they do at present. 1120 If an updated (NSAP) address is returned, then they send DNS 1121 requests over CLNP. If an old (IPv4) address is returned, 1122 then they send DNS requests over IPv4. Similarly, DNS 1123 servers contact DNS servers using either IPv4 or CLNP, 1124 depending on the form of address that they obtain. 1126 7.6.4. SMI, MIB-II 1128 The SMI RFC defines a data type for the 32-bit IPv4 address. 1129 This type is named "IpAddress". The MIB-II and some other 1130 MIBs use this data structure. These definitions can remain 1131 unchanged and can continue to be used by IPv4 hosts and 1132 routers. A data type exists for variable length NSAP address 1133 [27a, 27b, 27c]. A corresponding MIB table to those MIB 1134 tables that include IP address data types must be defined 1135 for TUBA/CLNP systems (this is preferred over modification 1136 of the existing tables). These include: 1138 tcpConnTable 1139 udpTable 1141 The SNMPv1 and SNMPv2 ASN.1 definitions for two new tables, 1142 tcpTubaConnTable and udpTubaTable, are appended to this 1143 transition plan for initial consideration. These will be 1144 submitted at a future time to the IETF NM area. 1146 7.6.5. RARP, BOOTP, DHCP, Bootparams 1148 RARP, BOOTP, DHCP, and Bootparams are all used to support 1149 booting. RARP, BOOTP, and DHCP all provide a mechanism for a 1150 host to acquires its own IPv4 address. These protocols can 1151 continue to be used without change by IPv4 systems. 1153 A RARP equivalent function may be provided using the ES-IS 1154 protocol [13]. BOOTP and DHCP must be revised to return 1155 variable length NSAP addresses, or must incorporated into a 1156 new host configuration scheme. The ONC RPC system includes a 1157 versioning mechanism that should allow the revision of the 1158 bootparams protocol in a compatible way. 1160 7.6.6. BSD talk protocol. 1162 This protocol is obsolete. We make no attempt to operate it 1163 over CLNP. 1165 8. General Issues 1167 8.1. Management, monitoring, network operations 1169 During the transition period, the current set of management 1170 and monitoring tools must continue to work for IPv4 links. 1171 This set includes such applications as 1173 tcpdump/snoop/iptrace/tcpview 1174 netstat 1175 ifconfig 1176 IPv4 traceroute tools 1177 IPv4 ping tools 1178 SNMP network management systems 1179 AS-traceroute 1180 Configuration retrieval tools 1181 Statistics tools 1182 DNS registry tools 1183 Line test programs (e.g., tools that test of all bit 1184 patterns at IP level) 1185 IDRP peer checking tool (equivalent to BGP-4 peer checking 1186 tool) 1188 Corresponding tools for these and other operations-related 1189 applications must be developed for CLNP. Some exist today. 1190 RFC 1574 [37], Essential Tools for the OSI Internet, 1191 describes a traceroute, route dump, and ping which are 1192 suitable for operation in conjunction with CLNP-based 1193 internets. 1195 8.1.1 Ping 1197 RFC 1575, ISO CLNP Ping [38], specifes the use of the CLNP 1198 echo request and reply packets to support a ping application 1199 (CLNP). Since the TUBA transition is dual stack, CLNP 1200 operation is independent of IP operation at the network 1201 layer (except for encapsulation over virtual links). Thus IP 1202 Ping and CLNP Ping (each based on a respective set of 1203 network layer echo request and reply packets) are used 1204 independently. Pings may be used to test for (a) host 1205 reachability, and (b) host status (alive or dead). When 1206 using "pings" to manage dual stack internets an operator 1207 may: 1209 1) IPv4 "ping" an IPv4-only system to test whether the host 1210 is IPv4-reachable and alive (including situations where 1211 tunneling is used) 1212 2) IPv4 "ping" a dual stack system to determine whether that 1213 dual stack system is IPv4-reachable and alive 1214 3) CLNP "ping" a dual stack system to determine whether that 1215 dual stack system is CLNP-reachable and alive 1217 8.1.2 Traceroute 1219 Traceroute operation is the same for IPv4 and CLNP; only the 1220 packet formats differ. The application of traceroute follows 1221 the same logic as for ping (see RFC 1574). 1223 8.1.3 SNMP 1225 There are no protocol changes to SNMP. MIBs have been 1226 defined for CLNP and ES-IS [34]. IS-IS and IDRP MIBs are 1227 under preparation. Tables in the MIB-II tcp and udp groups 1228 use IPv4 addresses and corresponding tables that use NSAPAs 1229 must be defined (A consequence of this is that a network 1230 management station must traverse both the IPv4-indexed and 1231 NSAPA-indexed tcpConnTable and udpListenerTable to know of 1232 all the open connections on a dual stack host.) 1234 IPng systems should use the preferred (UDP) encapsulation 1235 for SNMP request, response and trap messages. Management 1236 systems may use CLNP paths to acquire IPv4-related 1237 management objects in those circumstances where managed 1238 agents cannot be reached via IPv4 paths. 1240 Operational practices must be extended to manage dual 1241 internet protocol environments (if such practices are not 1242 already in place). For example, if operators use the 1243 ifOperStatus managed object rather than ping to test 1244 reachability between a management station and a managed 1245 agent, the practice of determining the status of all the 1246 interfaces of a dual internet protocol network might be 1247 extended as follows: 1249 1) "get" ifOperStatus using an IPv4 address to test whether 1250 an IPv4-only system is IPv4-reachable and the interface 1251 is {up, down,testing} 1252 2) "get" ifOperStatus using an IPv4 address to test whether 1253 a dual stack system is IPv4-reachable and the interface 1254 is {up, down,testing} 1255 3) "get" ifOperStatus using an NSAP address to test whether 1256 a dual stack system is CLNP-reachable and the interface 1257 is {up, down,testing} 1259 During the transition period, operators must know the state 1260 of IPv4 and CLNP connectivity, so it is expected that SNMP 1261 NMSs would be configured to get the value of ifOperStatus 1262 over both paths to dual stack systems. 1264 Extensions would also be applied for the reception of trap 1265 messages by NMSs. Consider, for example, an NMS operating 1266 with a knob=PreferCLNP; agents expected to generate trap 1267 messages would be configured with the NSAP addresses of NMSs 1268 that are to receive traps. 1270 8.2 Autoconfiguration 1272 [5] recommends that TUBA implementations support the 1273 assignment of system identifiers for TUBA/CLNP hosts defined 1274 in [16] for the purposes of host address autoconfiguration 1275 as described in [28] and [29]. 1277 8.3 Autoregistration 1279 Automatic registration of host information into the DNS is 1280 on 1281 the "to do" list. 1283 8.4 Multicast 1285 "Host group extensions for CLNP multicast" [10] discusses 1286 multicast support for CLNP-based systems. During the 1287 transition period, IPv4-only and dual-stack systems can use 1288 IPv4-based multicast. Multicast groups comprised of dual- 1289 stack (and CLNP-multicast-capable) systems can use CLNP- 1290 based multicasting. 1292 8.5 Path MTU Discovery 1294 Hosts that send small IPv4 datagrams over paths that 1295 accommodate larger ones waste Internet resources; this also 1296 contributes to suboptimal application performance (esp. 1297 throughput). [30] describes Path MTU discovery for IPv4- 1298 based hosts; hosts with IPv4 connectivity should continue to 1299 use [30]. [31], in preparation, discusses MTU discovery for 1300 CLNP-based hosts. 1302 8.6 Mobility 1304 [11] discusses describes an approach to transparent mobile 1305 internetworking that allows hosts to roam a CLNP-based 1306 internet in a fashion transparent to transport layer 1307 protocols. 1309 8.7 CLNP Header Compression 1311 [32] describes a CLNP header compression algorithm. This 1312 should be evaluated for suitability by the TUBA WG. Hosts 1313 with IPv4 connectivity should continue to use [33]. 1315 9. Timeline for transition 1317 The following timeline depicts the major activities and 1318 benchmarks for TUBA transition: 1320 _Time=0 today 1321 | 1322 |--->all hosts are IPv4 capable 1323 |---> IPv4 routed and managed globally, 1324 |---> CIDR and BGP-4 deployment 1325 |---> CLNP routed in parts of internet IS-IS 1326 |---> limited management instrumentation for CLNP 1327 |---> tuba/clnp prototypes (effectively knob=IPv4only 1328 | 1329 _Time=1 1330 | 1331 |---> majority of hosts remain IPv4 capable only 1332 |---> DNS support begins over IPv4 paths on servers that 1333 | are primaries/secondaries for the NSAPA RRs of 1334 | TUBA/CLNP hosts 1335 |---> multicast support using CLNP begins 1336 |---> TUBA/CLNP software installation begins in hosts; 1337 | CLNP-capable hosts operate in production with 1338 | knob=prefer_IPv4 1339 |---> sites experiment with Internet applications over 1340 | TUBA/CLNP 1341 |---> CLNP routed infrastructure is expanded more 1342 | networks support CLNP & IS-IS 1343 |---> IDRP deployment begins 1344 |---> development of CLNP management instrumentation 1345 | complementing that used for IPv4 begins 1346 |---> CLNP tunneled over IPv4 paths to connect TUBA hosts 1347 | where no "native CLNP" exists 1348 | 1349 _Time=2 1350 | 1351 |---> TUBA/CLNP software installation expands in hosts 1352 |---> CLNP routed infrastructure is extensive 1353 |---> 1354 |---> CLNP multicasting expands 1355 |---> experiments begin with CLNP flows, mobility 1356 |---> CLNP replaces IPv4 as encapsulate for tunneled 1357 | protocols 1358 |---> IDRP deployment is extensive 1359 |---> instances of CLNP tunnels diminishes 1360 |---> CLNP management instrumentation is extensive 1361 |---> Internet operations over CLNP and IPv4 infrastructure 1362 |---> sites turn on CLNP; majority of hosts now operate in 1363 | production with knob=prefer_CLNP 1364 |---> IPv4-only population diminishes 1365 | 1366 _Time=3 1367 | 1368 |---> IPv4 addresses no longer unique; IPv4-only 1369 | communication confined to "islands" 1370 |---> CLNP multicasting is extensive 1371 |---> CLNP flows and mobility expand 1372 |---> TUBA/CLNP software is ubiquitous 1373 |---> Internet is entirely CLNP routed 1374 |---> DNS supported on CLNP infrastructure 1375 |---> CLNP operations IPv4 infrastructure 1376 |---> CLNP-capable hosts now operate in production with 1377 | knob=prefer_CLNP 1378 | 1379 _ Time=? 1380 |---> IPv4-only communication is rare or non-existent 1381 |---> sites elect to turn down IPv4 operations & support 1383 10. Security 1385 Screening routers should continue to perform IPv4 packet 1386 filtering; for CLNP, they should packet filter on source and 1387 destination NSAPAs, PROTOcol value (hosts implementing [5] 1388 encode the PROTOcol value in the network selector of the 1389 destination NSAPA), and port number to block traffic between 1390 networks or specific hosts on an port level. Bastion hosts, 1391 dual-homed gateways, and other forms of firewalls must be 1392 expanded to provide the same safeguards as those developed 1393 for IPv4 environments. 1395 RFC 1108 Security can be encoded in CLNP headers, see [5]. 1397 Access control, authentication, data integrity, and 1398 confidentiality are recognized as security services that are 1399 required in the current as well as future global Internet. 1400 One solution to providing these services is through a secure 1401 network layer packet encapsulation protocol supported by a 1402 key management protocol for exchanging security information 1403 associated with a particular instance of communication. 1405 Since the secure network layer packet encapsulation protocol 1406 design must accommodate IPv4 and IPng, the protocol should 1407 be a modular one that, borrowing from Phill Karn, "rides 1408 above the internet datagram" and is distinguished using the 1409 value of PROTOcol in the IPv4 or CLNP header. The IPv4 or 1410 CLNP header is transmitted in the clear. The UDP or TCP 1411 fragments are then encapsulated by the security protocol, 1412 and distinguished by a separate PROTOcol value (i.e., a 1413 field inside the encrypted security protocol header). The 1414 header layout is illustrated in Figure 5: 1416 +-------------------------------+ ^ 1417 | | | 1418 | CLNP header (or IPv4 header) | cleartext 1419 | (NSEL=PROTO=SECURITYprotocol) | | 1420 | | v 1421 +-------------------------------+ ^ 1422 | | | 1423 | Security protocol header | encrypted 1424 | (NSEL=PROTO=TCP or UDP) | | 1425 | | | 1426 +-------------------------------+ | 1427 | | | 1428 | TCP or UDP | | 1429 | data fragment | | 1430 | | | 1431 +-------------------------------+ v 1433 Figure 5. Header layout for IP security protocol 1435 A security protocol that adheres to this architecture can be 1436 used in conjunction with any network layer datagram, 1437 regardless of address size or format, and under any 1438 transport protocol. 1440 The IETF IPSEC Working Group, is developing an encasulation 1441 protocol solution for IPv4. TUBA/CLNP, as a functionally 1442 isomorphic datagram protocol, also requires an encapsulation 1443 protocol. It is desirable that the same protocols that 1444 provide these security services for IPv4 also provide them 1445 for CLNP. While the IPSEC Working Group is chartered to 1446 provide a set of security protocols only for IPv4, the 1447 protocol that they are designing can provide the same 1448 security services for CLNP. This transition plan encourages 1449 this convergence, and recommends that the IPSEC WG charter 1450 be expanded to reflect this. 1452 There are at least two existence proofs that a single 1453 security encapsulation protocol can be used to support both 1454 IPv4 and CLNP. The SDNS protocol, SP3 [42], and the 1455 connectionless portion of the OSI Network Layer Security 1456 Protocol [43], NSLP-CL, provides the same sets of security 1457 services for both IPv4 and CLNP. SP3 specifically allows 1458 for both IPv4 and CLNP packets to be encapsulated by the SP3 1459 protocol. NLSP-CL, while originally designed to provide 1460 security for CLNP, has been shown to provide the same set of 1461 services for IPv4. The Internet Draft I-NLSP (Integrated 1462 Network Layer Security Protocol) [44], describes in detail 1463 how NLSP-CL can provide these services for both IPv4 and 1464 CLNP. It is the intent of TUBA to adopt the IPSEC protocol. 1466 The key management protocol work of the IPSEC WG has not yet 1467 gotten off the ground. Assuming that the encapsulation 1468 protocol for IPv4 and CLNP is the same, it follows that the 1469 key management protocol developed by the IPSEC WG also could 1470 be used to support secure operation of both datagram 1471 protocols. Since key management is viewed as an application, 1472 such dual use is not expected to pose any significant 1473 technical hurdles. 1475 Acknowledgements 1477 This document draws most of its content from efforts of (and 1478 electronic postings to the mailing lists of) three IETF 1479 working groups the TUBA working group, the NOOP working 1480 group, and the TPIX/CATNIP working group. A number of 1481 individuals have made significant contributions to the TUBA 1482 effort, either through implementation, production of 1483 internet-drafts, or by posting electronic mail of such 1484 completeness and quality that preparation of a transition 1485 plan was often a matter of integration of ideas. Those who 1486 merit special attention include Dave Katz (Cisco Systems), 1487 Ross Callon (Wellfleet Communications), Jim Bound (DEC), 1488 Brian Carpenter (CERN), Yakov Rehkter (IBM), Mark Knopper 1489 (AADS), Peter Ford (LANL), Rich Colella and Jim West 1490 (NIST/CSL), Cathy Wittbrodt (BARRnet), Sue Hares (MERIT), 1491 Robert Ullman (Lotus), Bill Manning (SESQUINET), and Phil 1492 Karn (Qualcomm). 1494 The organization and preparation of this transition plan was 1495 facilitated by the excellent efforts of Gilligan, et. al., 1496 in the preparation of "IPAE: The SIPP Interoperability and 1497 Transition Mechanism" [35]. 1499 References 1501 [1] Postel, J., Transmission Control Protocol (TCP). STD 7, 1502 RFC 793, September 1981. 1503 [2] Postel, J., Internet Protocol (IP). STD 5, RFC 791, 1504 September 1981. 1505 [3] Rekhter, Y., and Li, T., Architecture for IP Address 1506 Allocation with CIDR, RFC 1518, September 1993. 1507 [4] Callon, R., TCP/UDP over Bigger Addresses (TUBA), RFC 1508 1347, May 1992. 1509 [5] Piscitello, D., Use of ISO CLNP in TUBA environments, 1510 RFC 1562, December 1993. 1511 [6] ISO/IEC 8348-1992. International Standards Organization- 1512 -Data Communications--OSI Network Layer Service and 1513 Addressing. 1514 [7] Callon, R., R. Colella, and R. Hagens, NSAPA Guidelines 1515 for the Internet, RFC 1237, July 1991. 1516 [8] ISO/IEC 8473. International Standards Organization -- 1517 Data Communications -- Protocol for Providing the 1518 Connectionless-mode Network Service, ISO/IEC 8473:1992, 1519 Edition 2. 1520 [9] Callon, R., "A proposal for adding flow support to 1521 CLNP", Internet-Draft 1522 [10] Marlow, D., "Host group extensions for CLNP Multicast", 1523 Internet-Draft 1524 [11] Perkins & Rehkter, Y., "Mobility for CLNP". 1525 [12] Partridge, C., "Criteria for choosing IPv7 Selection", 1526 Internet-draft. 1527 [13] ISO/IEC 9542. International Standards Organization -- 1528 Telecommunications and Information Exchange between 1529 Systems -- End System to intermediate system routeing 1530 exchange protocol for use in conjunction with the 1531 protocol for providing the connectionless-mode network 1532 service (ISO/IEC 8473), ISO 9542:1988. 1533 [14] ISO/IEC 10589, Intermediate system to intermediate 1534 system routeing exchange protocol for use in 1535 conjunction with the protocol for providing the 1536 connectionless-mode network service (ISO/IEC 8473), ISO 1537 10589:1992. 1538 [15] ISO/IEC 10747, Protocol for exchange of interdomain 1539 routeing information among intermediate systems to 1540 support forwarding of ISO/IEC 8473 PDUs, ISO /IEC 1541 10747:1992. 1542 [16] Piscitello, D., Assignment of System Identifiers for 1543 TUBA/CLNP hosts, RFC 1526, November 1993. 1544 [17] Katz, D., Tunneling the OSI Network Layer over CLNP 1545 (EON), Internet-draft. 1546 [18] Hanks. S, T. Li, D. Farinacci, P. Traina, Generic 1547 Routing Encapsulation over IPv4 networks, Internet- 1548 draft, September 1993. 1549 [19] Hanks. S, T. Li, D. Farinacci, P. Traina, Generic 1550 Routing Encapsulation, Internet-Draft, September 1993. 1551 [20] Leiner, B., Rehkter, Y., The Multiprotocol Internet, 1552 RFC 1560, December 1993. 1553 [21] Callon, R., and Perlman, R., Integrated IS-IS, RFC 1554 1195. 1555 [22] Tsuchiya, P. NAT paper from SIGCOMM/CCR. 1556 [23] H. W. Braun, P.Ford, Y.Rekhter,"CIDR and the Evolution 1557 of the Internet Protocol", Proceedings of INET '93, 1558 August 1993. 1559 [24] Callon, "how to extend IP", Internet-draft in 1560 preparation. 1561 [25] Piscitello, D., FTP Operation Over Big Address Records 1562 (FOOBAR), RFC 1545, October 1993. 1563 [26] Manning, Colella, DNS RRs for NSAPAs, RFC in 1564 preparation 1565 [27a] Rose, M., SNMP over OSI. RFC 1418, 1993 March. 1566 [27b] Rose, M., SNMP over OSI. RFC 1283 1991 December 1567 [27c] Satz, G., CLNS MIB for use with Connectionless Network 1568 Protocol (ISO 8473) and End System to Intermediate 1569 System (ISO 9542), RFC 1238 1570 [28] Katz, "Suggested System ID Option for the ES-IS 1571 Protocol", Internet-Draft in preparation 1572 [29] Katz, "Dynamic Assignment of OSI NSAP Addresses in the 1573 Internet", Internet-Draft in preparation. 1574 [31] Mogul, J., and S. Deering, RFC 1191, MTU Discovery. 1575 [31] Piscitello, D.,"MTU discovery for CLNP-based hosts", 1576 Internet-Draft in preparation. 1577 [32] Whyman, "ICAO CLNP Header Compression 1578 algorithm",available by anonymous FTP, in compressed 1579 postscript form, from comm.cenaath.cena.dgac.fr as 1580 /atn/icao-clnp-compress-ps.zand 1581 [33] IPv4 header compression RFCs 1582 [34] Satz, G., Request for Comments 1238, Connectionless- 1583 mode Network Service Management Information Base - for 1584 use with Connectionless Network Protocol (ISO 8473) and 1585 End system to Intermediate System Protocol (ISO 9452)", 1586 Internet Architecture Board, June 1991. 1587 [35] Gilligan, R., and B. Hinden, "IPAE: The SIPP 1588 Interoperability and Transition Mechanism", Internet- 1589 draft, November 1993. 1590 [36] Katz, D., P. Ford, "TUBA: Replacing IP with CLNP", 1591 March 24 1993. 1592 [37] Wittbrodt, C., and S. Hares, Essential Tools for the 1593 OSI Internet, Request for Comments 1574, March 1994. 1594 [38] Wittbrodt, C., and S. Hares, CLNP Ping (Echo), Request 1595 for Comments 1575, March 1994. 1596 [39] Bound, J., IPng Host Implementation Analysis, IPng 1597 white paper, February 1994. 1598 [40] Phil Karn, electronic mail message to ipsec@ans.net 1599 entitled "Re: IPSEC & ROAD", 29 November 1992. 1600 [42] SDNS, "Security Protocol 3 (SP3)," Specification 1601 SDN.301/Revision 1.5, May 1989. 1602 [43] ISO/IEC, "Information technology -- Open Systems 1603 Interconnection -- Network Layer Security Protocol," 1604 International Standard 11577, November 1993. 1605 [44] Glenn, K. Robert, "Integrated Network Layer Security 1606 Protocol," Internet Draft (draft-glenn-layer-security- 1607 00.txt), September 1993 (work in progress). 1609 Author's Address 1611 David M. Piscitello 1612 Core Competence, Inc. 1613 1620 Tuckerstown Road 1614 Dresher, PA USA 19025 1615 dave@corecom.com 1616 1.215.830.0692 1618 Appendix A. ASN.1 Definitions for TUBA MIB-II extensions 1620 TUBA-MIB DEFINITIONS ::= BEGIN 1622 IMPORTS 1623 OBJECT-TYPE 1624 FROM RFC-1212 1625 private, internet 1626 FROM RFC1155-SMI 1627 NsapAddress 1628 FROM SNMPv2-SMI; 1630 nistPrivate OBJECT IDENTIFIER ::= { private 724 } 1632 nistTUBAModules OBJECT IDENTIFIER ::= { nistPrivate 1 } 1634 nistTUBAMIB OBJECT IDENTIFIER ::= { nistPrivate 2 } 1636 tcpTUBAGroup OBJECT IDENTIFIER ::= { nistTUBAMIB 1 } 1638 udpTUBAGroup OBJECT IDENTIFIER ::= { nistTUBAMIB 2 } 1640 -- created from tubaMIB (9403101200Z) 1642 tubaMIB OBJECT IDENTIFIER ::= { nistTUBAModules 1 } 1644 tcpTubaConnTable OBJECT-TYPE 1645 SYNTAX SEQUENCE OF TcpTubaConnEntry 1646 ACCESS not-accessible 1647 STATUS mandatory 1648 DESCRIPTION 1649 "A table containing TCP over CLNP (TUBA) 1650 connection-specific information." 1651 ::= { tcpTUBAGroup 1 } 1653 tcpTubaConnEntry OBJECT-TYPE 1654 SYNTAX TcpTubaConnEntry 1655 ACCESS not-accessible 1656 STATUS mandatory 1657 DESCRIPTION 1658 "Information about a particular current TCP over 1659 CLNP connection. An object of this type is 1660 transient, in that it ceases to exist when (or 1661 soon after) the connection makes the transition 1662 to the CLOSED state." 1663 INDEX { tcpConnLocalNSAPAddress, tcpTubaConnLocalPort, 1664 tcpConnRemNSAPAddress, tcpTubaConnRemPort } 1665 ::= { tcpTubaConnTable 1 } 1667 TcpTubaConnEntry ::= 1668 SEQUENCE { 1669 tcpTubaConnState 1670 INTEGER, 1672 tcpConnLocalNSAPAddress 1673 NsapAddress, 1675 tcpTubaConnLocalPort 1676 INTEGER, 1678 tcpConnRemNSAPAddress 1679 NsapAddress, 1681 tcpTubaConnRemPort 1682 INTEGER 1683 } 1685 tcpTubaConnState OBJECT-TYPE 1686 SYNTAX INTEGER { 1687 closed(1), 1688 listen(2), 1689 synSent(3), 1690 synReceived(4), 1691 established(5), 1692 finWait1(6), 1693 finWait2(7), 1694 closeWait(8), 1695 lastAck(9), 1696 closing(10), 1697 timeWait(11), 1698 deleteTCB(12) 1699 } 1700 ACCESS read-write 1701 STATUS mandatory 1702 DESCRIPTION 1703 "The state of this TCP connection. 1704 The only value which may be set by a management 1705 station is deleteTCB(12). Accordingly, it is 1706 appropriate for an agent to return a `badValue' 1707 response if a management station attempts to set 1708 this object to any other value. 1710 If a management station sets this object to the 1711 value deleteTCB(12), then this has the effect of 1712 deleting the TCB (as defined in RFC 793) of the 1713 corresponding connection on the managed node, 1714 resulting in immediate termination of the 1715 connection. 1717 As an implementation-specific option, a RST 1718 segment may be sent from the managed node to the 1719 other TCP endpoint (note however that RST 1720 segments 1721 are not sent reliably)." 1722 ::= { tcpTubaConnEntry 1 } 1724 tcpConnLocalNSAPAddress OBJECT-TYPE 1725 SYNTAX NsapAddress 1726 ACCESS read-only 1727 STATUS mandatory 1728 DESCRIPTION 1729 "The local NSAP address for this TCP connection. 1730 In 1731 the case of a connection in the listen state which 1732 is willing to accept connections for any NSAP 1733 interface associated with the node, the value 1734 0 is used. This is a zero length NSAP Address" 1735 ::= { tcpTubaConnEntry 2 } 1737 tcpTubaConnLocalPort OBJECT-TYPE 1738 SYNTAX INTEGER 1739 ACCESS read-only 1740 STATUS mandatory 1741 DESCRIPTION 1742 "The local port number for this TCP connection." 1743 ::= { tcpTubaConnEntry 3 } 1745 tcpConnRemNSAPAddress OBJECT-TYPE 1746 SYNTAX NsapAddress 1747 ACCESS read-only 1748 STATUS mandatory 1749 DESCRIPTION 1750 "The remote NSAP address for this TCP 1751 connection." 1752 ::= { tcpTubaConnEntry 4 } 1754 tcpTubaConnRemPort OBJECT-TYPE 1755 SYNTAX INTEGER 1756 ACCESS read-only 1757 STATUS mandatory 1758 DESCRIPTION 1759 "The remote port number for this TCP connection." 1760 ::= { tcpTubaConnEntry 5 } 1762 udpTubaTable OBJECT-TYPE 1763 SYNTAX SEQUENCE OF UdpTubaEntry 1764 ACCESS not-accessible 1765 STATUS mandatory 1766 DESCRIPTION 1767 "A table containing UDP listener information." 1768 ::= { udpTUBAGroup 1 } 1770 udpTubaEntry OBJECT-TYPE 1771 SYNTAX UdpTubaEntry 1772 ACCESS not-accessible 1773 STATUS mandatory 1774 DESCRIPTION 1775 "Information about a particular current UDP 1776 listener." 1777 INDEX { udpLocalNSAPAddress, udpTubaLocalPort } 1778 ::= { udpTubaTable 1 } 1780 UdpTubaEntry ::= 1781 SEQUENCE { 1782 udpLocalNSAPAddress 1783 NsapAddress, 1785 udpTubaLocalPort 1786 INTEGER 1787 } 1789 udpLocalNSAPAddress OBJECT-TYPE 1790 SYNTAX NsapAddress 1791 ACCESS read-only 1792 STATUS mandatory 1793 DESCRIPTION 1794 "The local NSAP address for this UDP listener. In 1795 the case of a UDP listener which is willing to 1796 accept datagrams for any IP interface associated 1797 with the node, the value 0 is used." 1798 ::= { udpTubaEntry 1 } 1800 udpTubaLocalPort OBJECT-TYPE 1801 SYNTAX INTEGER 1802 ACCESS read-only 1803 STATUS mandatory 1804 DESCRIPTION 1805 "The local port number for this UDP listener." 1806 ::= { udpTubaEntry 2 } 1808 END 1810 ------------------------------------------------------------ 1812 TUBA-MIB DEFINITIONS ::= BEGIN 1814 IMPORTS internet, private FROM RFC1155-SMI 1815 NsapAddress FROM SNMPv2-SMI 1816 MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI; 1818 nistPrivate OBJECT IDENTIFIER ::= { private 724 } 1819 nistTUBAModules OBJECT IDENTIFIER ::= { nistPrivate 1 } 1820 nistTUBAMIB OBJECT IDENTIFIER ::= { nistPrivate 2 } 1822 tcpTUBAGroup OBJECT IDENTIFIER ::= { nistTUBAMIB 1 } 1823 udpTUBAGroup OBJECT IDENTIFIER ::= { nistTUBAMIB 2 } 1825 tubaMIB MODULE-IDENTITY 1826 LAST-UPDATED "9403101200Z" 1827 ORGANIZATION "NIST" 1828 CONTACT-INFO 1829 " Jim West 1831 Postal: NIST 1832 Building 225/B217 1833 Gaithersburg MD, 20899 1834 US 1836 Tel: +1 301 975 3619 1837 Fax: +1 301 590 XXXX 1839 E-mail: west@osi.ncsl.nist.gov" 1840 DESCRIPTION 1841 "The MIB module for TUBA systems" 1842 ::= { nistTUBAModules 1 } 1844 -- the TCP TUBA Connection table 1846 -- This table serves the same purpose as MIB-II's 1847 -- tcpConnTable; 1848 -- It contains information about this entity's 1849 -- existing TCP connections. 1850 -- It is expected that a TUBA agent will instantiate 1851 -- this table as well 1852 -- as the tcpConnTable in MIB-II. A manager will 1853 -- have to access both 1854 -- table to get a complete picture of the TCP 1855 -- connections active on a 1856 -- TUBA end system. 1857 -- 1858 -- NOTE: This is not a complete reproduction of 1859 -- MIB-II's TCP group. Many of the objects in the 1860 TCP 1861 -- group are not dependent on Network addresses. 1862 -- This group only address portions of the 1863 -- TCP group that depend on Network addresses. 1865 tcpTubaConnTable OBJECT-TYPE 1866 SYNTAX SEQUENCE OF TcpTubaConnEntry 1867 MAX-ACCESS not-accessible 1868 STATUS current 1869 DESCRIPTION 1870 "A table containing TCP over CLNP 1871 (TUBA) connection-specific 1872 information." 1873 ::= { tcpTUBAGroup 1 } 1875 tcpTubaConnEntry OBJECT-TYPE 1876 SYNTAX TcpTubaConnEntry 1877 MAX-ACCESS not-accessible 1878 STATUS current 1879 DESCRIPTION 1880 "Information about a particular current 1881 TCP over CLNP connection. An object 1882 of this type istransient, in that it 1883 ceases to exist when (or soon after) 1884 the connection makes the transition to 1885 the CLOSED state." 1887 INDEX { tcpConnLocalNSAPAddress, 1888 tcpTubaConnLocalPort, 1889 tcpConnRemNSAPAddress, 1890 tcpTubaConnRemPort } 1891 ::= { tcpTubaConnTable 1 } 1893 TcpTubaConnEntry ::= 1894 SEQUENCE { 1895 tcpTubaConnState 1896 INTEGER, 1897 tcpConnLocalNSAPAddress 1898 NsapAddress, 1899 tcpTubaConnLocalPort 1900 INTEGER (0..65535), 1901 tcpConnRemNSAPAddress 1902 NsapAddress, 1903 tcpTubaConnRemPort 1904 INTEGER (0..65535) 1905 } 1907 tcpTubaConnState OBJECT-TYPE 1908 SYNTAX INTEGER { 1909 closed(1), 1910 listen(2), 1911 synSent(3), 1912 synReceived(4), 1913 established(5), 1914 finWait1(6), 1915 finWait2(7), 1916 closeWait(8), 1917 lastAck(9), 1918 closing(10), 1919 timeWait(11), 1920 deleteTCB(12) 1921 } 1922 MAX-ACCESS read-write 1923 STATUS current 1924 DESCRIPTION 1925 "The state of this TCP connection. 1926 The only value which may be set by a 1927 management station is deleteTCB(12). 1928 Accordingly, it is appropriate for an 1929 agent to return a `badValue' response 1930 if a management station attempts to set 1931 this object to any other value. 1933 If a management station sets this 1934 object to the value deleteTCB(12), 1935 then this has the effect of deleting 1936 the TCB (as defined in RFC 793) of the 1937 corresponding connection on the managed 1938 node, resulting in immediate 1939 termination of the connection. 1941 As an implementation-specific option, 1942 a RST segment may be sent from the 1943 managed node to the other TCP endpoint 1944 (note however that RST segments 1945 are not sent reliably)." 1946 ::= { tcpTubaConnEntry 1 } 1948 tcpConnLocalNSAPAddress OBJECT-TYPE 1949 SYNTAX NsapAddress 1950 MAX-ACCESS read-only 1951 STATUS current 1952 DESCRIPTION 1953 "The local NSAP address for this TCP 1954 connection. In the case of a 1955 connection in the listen state which 1956 is willing to accept connections for 1957 any NSAP interface associated with the 1958 node, the value 0 is used. This is a 1959 zero length NSAP Address" 1960 ::= { tcpTubaConnEntry 2 } 1962 tcpTubaConnLocalPort OBJECT-TYPE 1963 SYNTAX INTEGER (0..65535) 1964 MAX-ACCESS read-only 1965 STATUS current 1966 DESCRIPTION 1967 "The local port number for this TCP 1968 connection." 1969 ::= { tcpTubaConnEntry 3 } 1971 tcpConnRemNSAPAddress OBJECT-TYPE 1972 SYNTAX NsapAddress 1973 MAX-ACCESS read-only 1974 STATUS current 1975 DESCRIPTION 1976 "The remote NSAP address for this TCP 1977 connection." 1978 ::= { tcpTubaConnEntry 4 } 1980 tcpTubaConnRemPort OBJECT-TYPE 1981 SYNTAX INTEGER (0..65535) 1982 MAX-ACCESS read-only 1983 STATUS current 1984 DESCRIPTION 1985 "The remote port number for this TCP 1986 connection." 1987 ::= { tcpTubaConnEntry 5 } 1989 -- TUBA UDP Group 1990 -- the UDP TUBA Listener table 1992 -- As with the TCP table, this table serves the 1993 -- same purpose as the udpTable from MIB-II. The 1994 -- UDP listener table contains information about 1995 -- this entity's UDP end-points on which a local 1996 -- application is currently accepting datagrams. 1998 udpTubaTable OBJECT-TYPE 1999 SYNTAX SEQUENCE OF UdpTubaEntry 2000 MAX-ACCESS not-accessible 2001 STATUS current 2002 DESCRIPTION 2003 "A table containing UDP listener 2004 information." 2005 ::= { udpTUBAGroup 1 } 2007 udpTubaEntry OBJECT-TYPE 2008 SYNTAX UdpTubaEntry 2009 MAX-ACCESS not-accessible 2010 STATUS current 2011 DESCRIPTION 2012 "Information about a particular current 2013 UDP listener." 2014 INDEX { udpLocalNSAPAddress,udpTubaLocalPort } 2015 ::= { udpTubaTable 1 } 2017 UdpTubaEntry ::= 2018 SEQUENCE { 2019 udpLocalNSAPAddress 2020 NsapAddress, 2021 udpTubaLocalPort 2022 INTEGER (0..65535) 2023 } 2025 udpLocalNSAPAddress OBJECT-TYPE 2026 SYNTAX NsapAddress 2027 MAX-ACCESS read-only 2028 STATUS current 2029 DESCRIPTION 2030 "The local NSAP address for this UDP 2031 listener. In the case of a UDP listener 2032 which is willing to accept datagrams for 2033 any IP interface associated 2034 with the node, the value 0 is used." 2035 ::= { udpTubaEntry 1 } 2037 udpTubaLocalPort OBJECT-TYPE 2038 SYNTAX INTEGER (0..65535) 2039 MAX-ACCESS read-only 2040 STATUS current 2041 DESCRIPTION 2042 "The local port number for this UDP 2043 listener." 2044 ::= { udpTubaEntry 2 } 2046 END