idnits 2.17.1 draft-ietf-tuba-transition-01.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-23) 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 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. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 pages 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. ** There are 152 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** 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 308 has weird spacing: '...tifiers withi...' == Line 1007 has weird spacing: '...m). New ver...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (15 July 1994) is 10875 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: '7' is mentioned on line 285, but not defined == Unused Reference: '22' is defined on line 1532, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 1561, but no explicit reference was found in the text == Unused Reference: '36' is defined on line 1564, 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. '7a') (Obsoleted by RFC 1629) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Experimental draft: draft-ietf-tuba-host-clnp-multicas (ref. '10') -- Possible downref: Normative reference to a draft: ref. '11' ** Downref: Normative reference to an Informational draft: draft-kastenholz-ipng-criteria (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: Normative reference to a draft: 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: Normative reference to a draft: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' ** Obsolete normative reference: RFC 1545 (ref. '25') (Obsoleted by RFC 1639) ** Obsolete normative reference: RFC 1637 (ref. '26') (Obsoleted by RFC 1706) ** 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: Normative reference to a draft: 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: Normative reference to a draft: ref. '39' -- Possible downref: Normative reference to a draft: ref. '40' Summary: 28 errors (**), 0 flaws (~~), 8 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TUBA Working Group D. Piscitello 2 Internet Draft Core Competence, Inc. 3 Expires 15 January 1995 15 July 1994 5 File name draft-ietf-tuba-transition-01.txt 7 Transition Plan for TUBA/CLNP 9 15 July 1994 10 David M. Piscitello 11 Core Competence, Inc. 12 dave@corecom.com 14 Status of this Memo 16 This memo is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its 18 Areas, and its Working Groups. Note that other groups may 19 also distribute working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of 21 six months. This Internet Draft expires on 15 January 1995. 22 Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use 24 Internet Drafts as reference material or to cite them other 25 than as a "working draft" or "work in progress." Please check 26 the I-D abstract listing contained in each Internet Draft 27 directory to learn the current status of this or any other 28 Internet Draft. 30 Distribution of this memo is unlimited. 32 Abstract 34 The ARPA internet protocol suite -- commonly referred to as 35 TCP/IP (after the core protocols, Transmission Control 36 Protocol [1] and Internet Protocol [2]) -- is arguably the 37 most widely used, wide area internetworking solution in the 38 world today. Availability of on-line documentation, multiple 39 vendor-interoperable implementations, and an internationally 40 connected private and commercial infrastructure have most 41 recently contributed to remarkable growth in the size of the 42 global IP-based Internet. 44 Deployment of IP-based networks and hosts cannot continue at the present pace 45 unless certain addressing, protocol and operational limitations are corrected. 46 Two problems of immediate concern are: (1) the Internet backbone and regional 47 networks suffer from the need to maintain large and growing amounts of routing 48 information;and (2) the Internet is gradually running out of IP network numbers 49 to assign. 51 TUBA Working Group TUBA Transition 53 CIDR [3] offers temporary relief from problem (1). This 54 affords the Internet community time to develop and deploy an 55 approach to addressing and routing which allows scaling to 56 several orders of magnitude larger than the existing 57 Internet. 59 All proposed solutions to these problems introduce 60 fundamental changes to various components of the Internet architecture (internet 61 layer, applications), as well as administrative and operational changes. The 62 large installed base of IP version 4 (IPv4) hosts and IPv4-based internets 63 dictates that new systems which are IP "next generation" (IPng) capable must 64 co-exist with IPv4 systems for an indeterminable transition period. It is 65 necessary for 66 changes of this magnitude to be deployed in an incremental 67 manner. This allows a graceful transition from the current 68 Internet without disruption of service. It is also necessary 69 to continue and extend the lifetime of IPv4, in order to 70 minimize network disruption during the migration period from 71 the current IPv4-based Internet to one that is IPng-based. 72 This paper discusses the transition strategy from the current 73 IPv4-based Internet to one based on the use of ISO/IEC 8473, 74 CLNP, and TUBA [4,5], hereinafter referred to as TUBA/CLNP. 76 1. Introduction 78 This paper discusses a strategy for a transition from IPv4 to 79 CLNP that meets the following generalized IPv4-to-IPng goals: 81 a) Provide for interoperation between IPv4-only systems and 82 IPng capable systems 83 b) Provide a simple transition for network operators, sites 84 and end users 85 c) Minimize the introduction of new technologies 86 d) Minimize the introduction of new Internet operational 87 concepts and methods 88 e) Minimize interdependencies between IPv4 and IPng, (i.e., 89 minimize the need for synchronization points during 90 transition) 91 f) Provide end users the flexibility to transition from IPv4 92 to IPng when the need arises 93 g) Minimize the impact on existing applications and 94 programming interfaces 96 Several techniques have been proposed to address general coexistence issues 97 during transition to any next generation IP. These techniques fall into three 98 categories: 100 1) Dual internet protocol environment (IPv4 and IPng), with 101 eventual transition to sole use and support of IPng. 103 TUBA Working Group TUBA Transition 105 2) Tunneling (encapsulating IPng in IPv4 and IPv4 in IPng) 106 3) Network Address/Protocol Translation 108 In this paper, we recommend that the burden of transition 109 from IPv4 to CLNP/TUBA be supported using technique (1), but 110 we also recognize the need for techniques (2) and (3) where 111 operational needs and local policies dictate their use. The 112 focal point of this transition strategy is the implementation 113 of both IPv4 and CLNP in hosts and routers (i.e., a dual internetworking 114 protocol environment). This architectural approach, initially described in RFC 115 1347, TUBA is depicted in Figure 1. 117 +------------------------+ 118 | Internet | 119 | applications | 120 | (ftp,telnet,mail,etc.) | 121 +------------------------+ 122 | tcp/udp | 123 +------------------------+ 124 | | | 125 | IPv4 & | CLNP & | 126 | routing | routing | 127 | protocols | protocols | 128 +------------------------+ 130 Figure 1. Dual internet protocol host 132 Encapsulation may be used where needed and is explicitly 133 supported. The transition strategy described herein does not 134 preclude the use of translation techniques (3), but it is 135 expected that, in the general case, use of such techniques as 136 network address translation and network protocol conversion 137 can, and should, be minimized (localized). 139 The remainder of this paper is organized as follows: 141 Chapter 2 describes the scaling problems that TUBA is 142 designed to overcome. Chapter 3 gives an overview of TUBA. 143 Chapter 4 describes the transition to TUBA/CLNP. Chapters 5, 6, and 7 provide 144 details of the components of the transition-period Internet. Chapter 8 discusses 145 general issues regarding transition. Chapter 9 shows a timeline for TUBA 146 transition. 147 Chapter 10 discusses network layer security issues. 149 The reader can gain an understanding of TUBA and the problems 150 it attempts to resolve by reading chapters 2 through 4. 151 Implementors should also read chapters 5 through 10. References for all 152 TUBA-related documentation are appended to this memo. 154 TUBA Working Group TUBA Transition 156 2. IPng Problem Statement 158 The Internet is growing at a remarkable pace, and there is 159 every indication that this pace will continue to accelerate 160 at least through the end of this millennium. Such growth 161 could not be anticipated by the original designers of IP, who 162 should be applauded for providing an enabling vehicle for 163 internetworking that has endured beyond expectations. Still, 164 addressing design choices made over two decades ago can now 165 be seen to be insufficient, and as a result, the Internet 166 must overcome two serious problems: (1) routing information 167 overload and (2) exhaustion of available IP network numbers. 169 The routing information overload problem can be summarized as 170 follows. Historically, IPv4 network numbers have not been 171 assigned in an hierarchical manner. Network numbers were assigned using 172 estimates of the size of the requesting organization (i.e., numbers of hosts, 173 subnets) to determine the number of addresses required, as well as the address 174 class (e.g., A, B, or C). No attempt was made to allocate addresses to reflect 175 the typically hierarchical organization of interconnected networks. As a 176 consequence of this practice, IPv4 routing (i.e., routing protocols, and 177 forwarding mechanisms) treat remote IP network addresses as a flat space, 178 processing and storing distinct routes to each destination network. This near 179 linear relationship between the number of attached networks and the 180 corresponding routing information has become a critical factor (especially for 181 backbone networks), threatening to limit the growth and routing stability of the 182 Internet. CIDR and BGP-4 deployment have begun to lessen this situation but 183 these measures are "stop-gap" at best. 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 a 196 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 new, 199 larger address space is required before the end of this millenium. 201 TUBA Working Group TUBA Transition 203 IPv4 only supports fixed 32-bit addresses. The need for larger network addresses 204 will require that the Internet Protocol itself be changed or replaced. Modifying 205 or replacing IPv4 will be a critical and fundamental change to the core Internet 206 infrastructure. 208 3. TUBA Overview 210 TUBA [4] solves the problems described in section 2 by using: 212 1) OSI network service access point (NSAP) addresses, a 213 flexible and extensible network addressing plan which 214 accommodates multiple administrations and multiple levels 215 of addressing hierarchy for routing purposes ([6], [7a], 216 [7b]) 217 2) OSI connectionless network layer protocol (CLNP, [8]), a 218 network layer datagram. 219 3) OSI routing protocols, which provide host/router discovery 220 and autoconfiguration (ES-IS, see [13]); dynamic, (link- 221 state) intradomain routing (IS-IS, see [14]); and policy- 222 based routing (see IDRP, [15]). 223 4) RFC 1629 (nee RFC 1237) assignment guidelines, which 224 describe an addressing architecture based upon the use of 225 prefix-based address administration and routing. This 226 architecture supports aggregation of addresses by country, 227 by service provider, and by area. This allows for 228 substantial route aggregation, and scales to a very large 229 Internet. (RFC 1237 guidelines have been adapted for IP 230 and form the basis for CIDR allocation and deployment 231 strategies for extending the lifetime of the IPv4-based 232 Internet.) 234 TUBA allows the current Internet applications (e.g., Telnet, 235 SNMP, FTP, SMTP/822 electronic mail, NFS, AFS, BOOTP, X 236 window system) and the internet information retrieval 237 navigators and services (WAIS, WWW, gopher, prospero, archie, 238 veronica, netfind, finger) to operate using native 239 transport protocols -- UDP and TCP -- on top of CLNP in place 240 of IPv4. TUBA uses the same naming conventions and infrastructure as IPv4; i.e., 241 the Domain Name System, with extensions to accommodate NSAP address to domain 242 name mappings. (Note: throughout this document the discussion of 243 transition issues related to name services -- name to address and address to 244 name translation systems -- is couched in terms specific to the Domain Name 245 System. The same concepts would apply to other name to address translation 246 systems. 248 TUBA replaces the IPv4 network layer (datagram and routing 249 protocols) with CLNP [8], ES-IS [13], IS-IS [14], and IDRP 250 [15]). The architectural features and functionality of CLNP 252 TUBA Working Group TUBA Transition 254 are nearly identical to that of IPv4 (see [5] for an overview 255 and comparison). CLNP accommodates variable length addresses, 256 provides fundamentally the same level of service as IPv4 (see 257 [8]), and with the addition of [9, 10, 11], meets IPng 258 selection criteria described in [12]. [5] defines the use of 259 CLNP in TUBA environments, providing the rules for network 260 layer protocol and pseudo-header composition, application of 261 the PROTOcol mechanism in the CLNP header, and the use of the 262 CLNP error reports as replacements for corresponding ICMP 263 messages. 265 CLNP is already supported (implemented) by developers of 266 Internet products and deployed by many operators of backbone 267 (regional, midlevel) and attached (client) networks in the 268 Internet infrastructure. CLNP implementations exist today for 269 most host and router systems. The routing architecture is 270 similar to that implemented for IPv4 (OSPF and IS-IS share a 271 common ancestry, as do BGP-4 and IDRP, see [24]). A major advantage of using 272 CLNP as a replacement for IPNG is that the routing architecture has already been 273 specified, implemented in products, and deployed in large-scale production 274 networks (operational experience with Integrated IS-IS is documented in [23]). 276 As the Internet evolves it may be necessary to enhance the 277 routing system to introduce new capabilities, such as support 278 for mobility, multicast, flows, and provider based selection. 279 Many of these capabilities can be implemented in CLNP using 280 techniques and protocols analogous to those applied in the 281 IPv4 context. Several of these enhancements ([9], [10], [11]) 282 are currently under investigation within the IETF. 284 CLNP is distinguished from IPv4 by its use of flexible, 285 variable length NSAP addresses (see [6] and [7]). NSAP addresses are already 286 applied in those portions of the global Internet that offer CLNP connectivity 287 according to guidelines developed within the IETF; the assignment and allocation 288 guidelines defined in RFC 1237 form the basis for the development of CIDR [3]. 289 Based on operational experience with CLNP on the Internet, RFC 1237 has been 290 updated, and RFC 1629 now accommodates internationally-defined NSAP addresses. 292 The referenced addressing documents ([6], [7a], [7b]) specify a maximum NSAP 293 address length of 20 octets. The encoding of CLNP is such that its specification 294 woud not have to change if longer addresses were created (to a maximum of 295 approximately 100 octets per address). 297 The AFI mechanism can also be used to introduce additional addressing 298 authorities (e.g., ISOC, or a globally 300 TUBA Working Group TUBA Transition 302 administered IPX space). This satisfies the IPng objective of effectively 303 unlimited addressing (if not already satisfied by the 20-octet addresses 304 available). A further advantage of NSAP addresses is that they can be structured 305 in a manner that allows the embedding other network or link layer addresses, 306 IPv4, Novell IPX, or Ethernet/IEEE 802, which is useful for autoconfiguration of 307 hosts (see [16] for a description of how these may be encoded as system 308 identifiers within an RFC 1629 NSAP address). 310 4. Transition to TUBA/CLNP 312 The TCP/IP Internet is a large and complex system. However, 313 the operation of the Internet is based on a very simple 314 notion: ubiquitous end to end connectivity provided by a 315 single datagram internetworking protocol. This simple architectural tenet is a 316 major part of the its success. 318 Practical experience acquired in the design and deployment of very large, 319 complex, and highly-interdependent systems suggests that such systems are 320 difficult to deploy and manage. Even when one succeeds in deploying such a 321 system, it becomes difficult or impossible to update one part of the overall 322 system without upsetting other parts of the system. 324 The transition from IPv4 to CLNP will be gradual, and will be 325 accomplished over an extended but as yet indeterminable 326 period of time. During this time frame, both IPv4 and CLNP 327 may need to be updated to respond to new requirements. If the 328 end-to-end operation of IPv4 is dependent upon CLNP, and if 329 end-to-end operation of CLNP is simultaneously dependent upon 330 IPv4, then it may become very difficult to update both 331 protocols to respond to new requirements over time (this is 332 true in general for any IPng). 334 An important consideration for the transition from IPv4 to 335 CLNP is thus to minimize the overall complexity of the 336 system, and to simultaneously minimize the interdependencies 337 between these major parts of the system. TUBA places a new 338 network layer beside IPv4 in new (and all future) system 339 implementations. New hosts continue to communicate with IPv4- 340 only hosts over an IPv4 infrastructure which remains fully 341 operational (in parallel with the new infrastructure) until 342 such time as the IPv4 address space is depleted. At such 343 time, it is expected that the vast majority of systems will 344 be TUBA-capable, and IPv4 communication may be phased out. 345 (Note that the decision to turn off IPv4 ultimately lies in 346 the hands of individual administrations; the transition plan 347 imposes no timeframe for IPv4 shutdown.) 349 TUBA Working Group TUBA Transition 351 The presence of a second network layer protocol in the 352 Internet is nothing news(worthy). Multiprotocol 353 internetworking is very much the norm in today's complex 354 internets (see RFC 1560, [20]). It is common to find networks 355 that support five or more protocol stacks (including TCP/IP, 356 IPX, Appletalk, SNA/APPN, DECnet, CLNP, and others). Network 357 managers are used to deploying and managing multiple 358 independent protocol stacks. The routers and hosts from all 359 major vendors already support multi-stack operation. The TUBA 360 transition scheme therefore makes use of techniques and 361 concepts with which network managers and implementers are 362 already familiar. 364 The TUBA transition plan acknowledges that host software will 365 be the gating function of any transition due to the large 366 number of Internet hosts compared to routers. The components 367 of the transition are as follows: 369 1) The routed infrastructure is upgraded to support CLNP. 370 Routers not already capable of doing so must be updated to 371 support forwarding of both IPv4 and CLNP packets. (Routing 372 and forwarding of IP and CLNP packets may be done 373 independently, or at the discretion of a routing domain 374 administration, integrated routing [21] may be used.) 376 2) DNS servers are extended to return NSAP addresses (DNS 377 systems must continue to support IPv4 name-to-address 378 resolution). Initially, DNS will operate over IPv4. 380 3) TUBA/CLNP is introduced as new host software is deployed. 381 Internet applications are operated over TUBA. New software 382 is expected to support TCP/UDP over both IPv4 and CLNP 384 4) CLNP connectivity is provided to all sites. 386 5) The population of IPv4-only hosts on the network 387 diminishes and the number of dual internet protocol 388 capable hosts increases 390 6) DNS support is moved onto the CLNP infrastructure. 392 7) The CLNP infrastructure is used extensively in production 393 environments. 395 A detailed timeline for the transition plan is provided in 396 Section 9. 398 To make the transition from IPv4 to TUBA as smooth as possible, the following 399 objectives must be taken into consideration: 401 TUBA Working Group TUBA Transition 403 1) The transition should impose a minimum impact on the end 404 users of hosts, and should leverage as much of the users' 405 and administrators' investment in existing Internet 406 operations and training as possible. We should recognize 407 that users, administrators, and network operators have 408 made substantial investments in "understanding" IPv4. 409 Administrators and network operators in many cases have 410 made an investment in "understanding CLNP". Neither 411 investment should be discounted or lost. 412 2) Users and network operators should be able to transition 413 at their own pace; i.e., users should be able to upgrade 414 hosts and routers when they are ready, and incrementally. 415 3) Sites which deploy a dual internet protocol environment 416 should accumulate the benefits and features of TUBA as 417 they deploy. For example a new TUBA host should be able to 418 use the autoconfiguration mechanisms immediately. 419 4) The larger addresses of TUBA/CNLP should be used to solve 420 the IPv4 route scaling problem early on in the transition. 421 5) The transition plan must provide complete, global 422 connectivity between TUBA and IPv4 hosts for as long as 423 IPv4 can provide global connectivity. 424 6) The transition plan should provide global connectivity for 425 IPv4 traffic for as long as necessary. 426 9) It should leverage the existing IPv4 routing and DNS 427 infrastructure wherever possible. 429 4.1. Dual Internet Protocol Operation 431 In the dual internet protocol transition plan, software in 432 new and updated hosts supports Internet transport protocols 433 on top of both IPv4 and CLNP. The host is configured to use 434 both IPv4 and CLNP; the order of network layer precedence 435 (selection) is locally controlled at the host (at a system or 436 per application level, see section 4.2.4). When a dual 437 internet protocol host is attached to the dual internet 438 protocol infrastructure, this fact is advertised to other 439 hosts on the Internet through the administrative process of 440 incorporating both its IPv4 address(es) and its NSAP address(es) into the DNS. 441 Dual internet protocol hosts thus recognize each other by the existence of their 442 NSAP addresses in the DNS. 444 Figure 4 illustrates a single Internet routing domain, which 445 is also interconnected with Internet backbones or regionals. 446 The two "updated" Internet Hosts, D1 and D2, can send 447 either IPv4 or CLNP packets. Figure 4 also illustrates two 448 IPv4-only hosts, H1 and H2, a DNS server, and two border 449 routers, R1 and R2. Routers internal to the routing domain 450 are capable of forwarding both IPv4 and CLNP traffic. This 451 could be done by using (i) multi-protocol routers, which can 453 TUBA Working Group TUBA Transition 455 forward both protocol suites; (ii) a different set of routers for each suite; 456 (iii) tunneling as described in section 4.3; or (iv) translation as described in 457 section 4.4. 459 ............. ................... 460 : : : : 461 : H1 : : Internet : 462 : :----R1----: : 463 : H2 : : Backbones : 464 : : : : 465 : DNS : : : 466 : : : and : 467 : D1 : : : 468 : : : Regionals : 469 : D2 :----R2----: : 470 : : : : 471 :...........: :.................: 473 Key 475 DNS DNS server 476 Hn IPv4 only host 477 Dn Updated Internet host 478 R Border Router 480 Figure 4 - TUBA transition example 482 When attempting communication, a dual internet protocol host 483 queries the DNS for the IPv4, NSAP address, or both forms of 484 address(es) of the target host (based on local host controls, 485 again, see section 4.2.4). Consider case (1) where D1 wishes 486 to communicate with D2, and where local host controls at D1 487 indicate that the host should attempt to use CLNP first, but 488 if not available, use IPv4. In this case, D1 requests both 489 "A" and "NSAP" resource records (RRs) for D2. If the DNS returns both IPv4 and 490 NSAP resource records for D2, then D1 concludes that target host is another dual 491 internet protocol host connected to the dual internet protocol infrastructure, 492 and the communication can take place using CLNP (since it was 493 indicated as the preferred network layer). 495 Suppose D2 has not yet been put onto the dual internet 496 protocol infrastructure. In this case, D2's NSAP address would not be present in 497 the DNS; only its IPv4 address would be returned, and D1 would correctly 498 conclude that it should 499 use IPv4 to communicate with D2. (Note that if the decision 500 is made to use IPv4, nothing has changed!) 502 Given the local control configuration (prefer CLNP), if D2's NSAP addresses were 503 registered, but D2 were not yet attached 505 TUBA Working Group TUBA Transition 507 to the dual internet protocol infrastructure, the DNS would return both "A" and 508 "NSAP" resource records. D1 would try 509 D2's NSAP address(es), its attempts to communicate with D2 over CLNP would fail, 510 and D1 would then try D2's IPv4 address(es), see section 4.2.4. 512 Now consider case (2), where D1 wishes to communicate with 513 H1. Assuming the same local controls, D1 again requests both 514 "A" and "NSAP" RRs for D2; here, only the "A" resource 515 record(s) containing the IPv4 address(es) of H1 is returned. 516 D1 concludes that the target host is not a dual internet 517 protocol host and uses IPv4 for communication. 519 These examples demonstrate the importance of the DNS to the transition plan. 520 Network administrators are encouraged to only configure a host's NSAP address 521 into the DNS if the host should be reachable on the CLNP infrastructure 522 (Nominally, the host and local network supports CLNP). 524 Note: Registering NSAP addresses of hosts before such hosts 525 are to use CLNP cannot precluded; however, since this cannot 526 be coordinated with individual host settings at a global 527 level, such registration may result in poor host performance 528 at application connection time. Consider the case where a 529 host D1 has its NSAP address registered, but the host does 530 not have connectivity to the CLNP infrastructure. Suppose the host supports a 531 server application. Any host D2 attempting to 532 communicate with D1 having its knob set to prefer CLNP will try all NSAP 533 addresses and fail before attempting to connect via IPv4.) 535 4.2 Dual internet protocol and the Internet Infrastructure 537 The transition to TUBA/CLNP requires several Internet infrastructural components 538 to evolve to dual internet protocol functionality (see the timeline in section 539 9). These are: 541 - Network Service Providers 542 - The Domain Name System (DNS) 543 - The Internet registration functions 544 - Hosts 546 Many campus, enterprise network, and Internet transit 547 networks (NASA Sciences Internet, Energy Sciences Network, 548 Alternet, SURANET, Sesquinet, NEARnet, the Italian Research 549 Network/INFN, Switch, etc.) already route and forward 550 multiple network layer protocols at the same time, including 551 CLNP. The presence of this operational infrastructure 552 provides an accelerated baseline for deployment. 554 TUBA Working Group TUBA Transition 556 4.2.1 Network Service Providers 558 A commonly overlooked component in IPng transition is the 559 need to coordinate routing for protocols other than IPv4. 560 This coordination creates well known "interconnects" (e.g. 561 FIX, CIX, GIX, NAP, etc.) among Internet service providers. 562 The current interconnects already switch multiple protocols, 563 including CLNP. Standard CLNP operations practices are also 564 in place. 566 4.2.2 Updating the DNS Infrastructure 568 In the current Internet architecture the DNS maps between 569 Internet names and IPv4 addresses. The DNS must be extended 570 to also support NSAP addresses (see [26]). Prototype 571 implementations of DNS servers and resolver libraries that 572 can support multiple address types are available for 573 TUBA/CLNP. 575 DNS servers will continue to operate on the IPv4 routed infrastructure until the 576 transition is complete since IPv4-only hosts will always generate IPv4 specific 577 DNS queries. DNS queries shall by default use IPv4 connectivity unless 578 explicitly configured to use CLNP connectivity (transition to 579 use of a CLNP-routed infrastructure shall thus be governed by a configuration 580 option for DNS servers). The DNS server 581 implementations must eventually be updated to run on top of a 582 multiprotocol Internet. 584 DNS clients will use the same method of choosing the active 585 network layer protocol as other host applications. This is 586 detailed in section 4.2.4. 588 4.2.3 Internet registration functions 590 Guidelines exist for the assignment of NSAP addresses in the Internet [7a, 7b]; 591 assignment of NSAP addresses shall continue under these guidelines. The current 592 practices for assignment of IPv4 addresses shall remain in place (only 593 refinements and extensions to CIDR allocation are expected to influence current 594 practices). Domain name assignment is unaffected by this plan. 596 The current set of service provider interconnections performs 597 route registration and dissemination, i.e., as performed by 598 Merit/NSFNET, the Ripe NCC and the Japanese JPNIC. The schema 599 for the current set of databases for the routing registration 600 and dissemination function has been extended to include CLNP 601 addresses and prefixes (network numbers). 603 TUBA Working Group TUBA Transition 605 4.2.4 Dual internet protocols environments and hosts 607 The impact on host run-time resources for TUBA hosts is under 608 investigation, but preliminary results indicate that memory 609 requirements to support the CLNP network layer alongside IPv4 610 should not be a barrier for low-end hosts. CPU requirements 611 for CLNP are also under investigation; this, too, should not 612 be a barrier for low-end hosts. 614 Dual internet protocol support in hosts requires coordination 615 and control on the part of implementers, system 616 administrators, users, and network administrators. Internet 617 applications (the business of hosts) must be re-engineered to 618 selectively use either protocol stack during transition. As a rule, the host 619 should be registered in the DNS as an IPv4-only system until such time as it 620 intends to make use of CLNP. Thereafter, selection of the network layer with 621 which to initiate communications should be under local control. 623 A helpful abstraction for local control is the notion of a 624 soft switch or knob on a host that controls its (network 625 layer) operation. For example, a knob should have 4 settings: 627 (1) IPv4 only. The host operates Internet applications over 628 IPv4 only. This is the default setting (and also the only 629 logical state of IPv4-only hosts). Only "A" resource 630 records can be obtained from the DNS for this host. The 631 host only asks for IPv4 addresses. 633 (2) Prefer IPv4. The host operates Internet applications over 634 IPv4 and CLNP, and is capable of obtaining both IPv4 and 635 NSAP addresses from the DNS. Both "A" and "NSAP" resource 636 records can be obtained from the DNS for this host. The 637 host will always ask for both address families, but given 638 a choice, will use an IPv4 path. Under this setting, the 639 host expects the majority of communication it initiates 640 to be IPv4 (For a client, most of the servers it expects 641 to contact are reachable via IPv4). Server applications 642 on the host may accept incoming connections over CLNP. 644 (3) Prefer CLNP. In this case, the host is again dual 645 internet protocol capable. The host will always ask for 646 both address families but given a choice, it will use a 647 CLNP path. Under this setting, the host is registered 648 as a dual internet protocol host, and expects the 649 majority of communication it initiates to be CLNP 650 (For a client, most of the servers it expects to contact 651 are reachable via CLNP). Server applications on host may 652 accept incoming connections over IPv4 paths. 654 TUBA Working Group TUBA Transition 656 (4) CLNP only. This setting is used when all destinations 657 with which the host expects to communicate support CLNP, 658 or when there is a strong desire to turn down support for 659 the local IPv4 infrastructure. The host will only ask for 660 NSAP addresses. 662 Nominally, a system wide knob is recommended. Host 663 implementations are strongly encouraged to extend the knob 664 abstraction to a per-application basis, as applications 665 servers may be TUBA-enabled at different times across the 666 Internet. Thus, a host implementing knobs on a per application basis may have a 667 knob indicating "Prefer IPv4" for Web service and a knob indicating "Prefer 668 CLNP" for telnet service. 670 4.3 TUBA Tunnelling 672 OSI and TUBA/CLNP hosts and routers have used the EON 673 tunneling protocol [17] to carry CLNP packets over regions of 674 the Internet that route only IPv4 packets for several years. 675 The subset of the EON protocol as implemented and fielded 676 today is a virtual point-to-point encapsulation of CLNP 677 datagrams between statically configured tunnel endpoints. 678 There is no support for simulating a multipoint subnetwork, 679 nor for dynamic mapping between NSAP addresses and IPv4 680 addresses; IPv4 addresses are treated as subnetwork point of 681 attachment addresses that must be statically configured to 682 create the tunnel. Once a tunnel is established, the ES-IS 683 [13] and IS-IS [14] protocols are used to dynamically 684 establish neighbor adjacencies and routing. 686 The encapsulation is as follows: 688 +--------------------------+ 689 | IPv4 header | 690 | (protocol = 80 decimal) | 691 +--------------------------+ 692 | EON header | (value = hex 01 00 FC 02) 693 +--------------------------+ 694 | OSI Network Layer packet | 695 +--------------------------+ 697 Figure 3. EON encapsulation 699 Tunneling is one of the mechanisms that will be employed 700 during the IPv4-CLNP transition period to connect TUBA hosts, in those 701 circumstances where native CLNP transport is not available (i.e., across routing 702 domains that have not introduced a CLNP backbone); and to connect IPv4 hosts, at 703 such time where global IPv4 connectivity is no longer 705 TUBA Working Group TUBA Transition 707 available, and IPv4 hosts in separated (isolated) routing domains must use the 708 CLNP backbone for transport 710 [18] describes the encapsulating protocol that should be 711 applied when CLNP is the "payload packet" within an IPv4 712 datagram. [19] describes a generic encapsulating protocol that may be applied 713 when IPv4 is the "payload packet" within a CLNP datagram. 715 4.4 Address and Protocol Translators 717 Several approaches may be used, separately or in combination, 718 for continued operation of IPv4 under circumstances where 719 global IPv4 connectivity is no longer available. One method 720 involves splitting the IPv4 Internet into a number of "local 721 address domains", and performing network address translation. 723 For example, a subset of an administration's assigned 32-bit 724 IPv4 addresses might be designated as unique only within a 725 local address domain. Some number of the administration's 32- 726 bit IP addresses are designated for global use, and remain 727 globally unique; these may serve as resources that local 728 hosts may use when they attempt to communicate to hosts 729 outside the local address domain. Specifically, when the 730 local host wishes to communicate to an outside host, it is 731 (temporarily) assigned a global address (i.e., a translation 732 from local-to-global address is performed by a border router 733 -- a network address translator or NAT box -- on the source 734 address of IPv4 packets that exit the local domain, and 735 similarly on destination addresses of IPv4 packets that arrive at the local 736 domain, destined for a host having a temporarily assigned global address). This 737 allows IPv4-only hosts to communicate locally "forever", and globally for as 738 long as IPv4 connectivity exists to desired destinations. Several such 739 techniques are under investigation at this time. 741 Network layer protocol translation can also be used to extend 742 the lifetime if IPv4 networks. Translation could take the 743 form of an IPv4 to CLNP conversion, or from IPv4 to CLNP via 744 a common translating protocol (e.g., CATNIP). 746 5. Multiprotocol routers 748 Multiprotocol routers -- routers that can forward (at least) IPv4 and CLNP 749 datagrams -- will facilitate the deployment of the dual internet protocol 750 infrastructure. Multiprotocol routers may use independent routing protocols to 751 switch IPv4 and CLNP, or they may use integrated routing [21]. Such routers are 752 available, widely deployed and tractable technology; this notwithstanding, one 753 can certainly use 755 TUBA Working Group TUBA Transition 757 separate routers and topologies to switch IPv4 and CLNP, if this is desirable or 758 necessary. 760 During the transition, certain routers may be expected to 761 support tunnels; i.e., to support the forwarding of CLNP 762 datagrams by encapsulating them in IPv4 packets, and the forwarding of IPv4 763 datagrams by encapsulating them in IPv4 packets. Protocols currently tunnelled 764 across IPv4 backbons (Appletalk, IPX) must eventually be tunnelled using CLNP 765 (see section 4.3). 767 6. IPv4 Address Lifetime Considerations 769 Prudent allocation of IPv4 addresses and application of CIDR 770 provides a "grace period" for the development and selection 771 of an IPng; eventually, however, the IPv4 address space will 772 become inadequate for global routing and addressing, and 773 IPv4-only hosts will no longer be able to interoperate 774 directly over the global Internet. 776 6.1 When 32-bit addresses run out 778 Some administrations may wish to extend the lifetime of IPv4 779 addressing (and hence IPv4) beyond this point in time. The 780 tunneling and translation techiques described in section 4 781 may be applied to meet the needs of administrations which 782 find it necessary and appropriate to sustain their investment 783 in IPv4 beyond the point where the IPv4 addresses remain 784 unique. Application relays may also suffice.. 786 TUBA transition allows migration to CLNP to be performed 787 independently from such "life support" for the old IPv4 788 address space, which may be used to maintain IPv4 789 connectivity for as long as this is economically and 790 technically feasible without disrupting migration to IPng. 791 The dual internet protocol environment present during the 792 transition from IPv4 to CLNP will not interfere with such 793 attempts to maximize the lifetime of IPv4 internets, nor 794 would it interfere with attempts to re-use or further extend 795 the aggregation properties of the current 32-bit address 796 space (i.e., extending CIDR policies to class A addresses). 798 6.2 Turning down the IPv4 infrastructure 800 There are at least two perspectives regarding the issue of 801 how to phase out IPv4: 803 1) In "n" years, IPv4 should be turned off. Given the current 804 rate of Internet growth, plus the possibility of updating 805 existing systems, the number of IPv4-only systems will be 807 TUBA Working Group TUBA Transition 809 dwarfed by the number of IPng systems, and the impact will 810 be small. 812 2) There will be sufficient permutations and combinations of 813 IPv4 lifetime extensions implemented that "n" is likely to 814 approach infinity. 816 Nothing in this transition plan forces an administration to 817 turn off IPv4 at any specific point in the future Under the plan specified 818 herein, IPv4 and CLNP may co-exist "forever". 820 7. Dual Internet Protocol Hosts 822 Hosts must implement CLNP, ES-IS, and several additional modifications to run 823 TUBA/CNLP alongside IPv4. The modifications affect the internet and transport 824 layers of the protocol software, and the application program interface (API) 825 offered by the transport layer. Some internet applications must change as well, 826 especially those that make 827 direct use of IPv4 addressing rather than domain names. 829 Dual internet protocol hosts must be able to transmit and 830 receive both CLNP and IPv4 packets; resolve network addresses 831 of destinations to hardware addresses. Dual internet protocol 832 hosts may also be expected to request configuration 833 information from servers, and request auto registration of 834 domain names and addresses (see sections 8.2 and 8.3). 836 7.1. Internetwork Protocol Selection 838 The first decision a host must make is which form of packet 839 to transmit: IPv4 or CLNP. This may be accomplished through a 840 local (to the host) configuration switch (which reflects the 841 default or desired state of the global connectivity), and 842 could be set at various granularities (i.e., one switch per 843 host, per destination, per application). The knob abstraction 844 described in section 4.2.4 offers one way to model this 845 decision process. 847 7.2. Transport pseudo-header checksum. 849 TCP and UDP both define a checksum that covers the data 850 portion of the segment along with a 96-bit "pseudo header" 851 that includes the IPv4 source and destination addresses, address length fields, 852 and protocol ID from the IPv4 header. Including this pseudo header in the 853 transport checksum protects the transport layer against misrouted segments. 855 The pseudo header used in the transport checksum when TCP and 856 UDP are layered above CLNP is described in [5].It includes 858 TUBA Working Group TUBA Transition 860 the source and destination NSAP addresses, including 861 selectors, protocol ID, length fields from the CLNP header. 863 7.3. TCP and UDP connection identification for TUBA hosts 865 TCP uses the concatenation of local and remote IPv4 address 866 with local and remote port number to uniquely identify a 867 transport connection. TCP uses the term "socket" to identify 868 one endpoint of a connection. The local socket is identified 869 by the local IPv4 address and local port number, while the 870 remote socket is identified by the remote IPv4 address and 871 remote port number. 873 When communicating with another dual internet protocol host 874 using CLNP, TCP uses the full source and destination NSAP addresses and 875 local/remote port numbers to identify connections and sockets. This provides an 876 equivalent means of identification (and should suffice until such time as the 877 Internet community resolves the issue of global endpoint identification). 879 7.4. Error and Control Messages 881 Systems involved in the forwarding of IPv4 datagrams shall 882 continue to use ICMP for error and control messages. Systems 883 involved in the forwarding of CLNP datagrams shall use CLNP 884 error report messages. [5] defines the mapping between ICMP 885 message types and CLNP error report types. CLNP Error Report Codes for "Protocol 886 Unreachable" and "Port Unreachable" should be assigned from the code points 887 available in the error report type code block in ISO/IEC 8473. 889 The use of ICMP shall continue unchanged. CLNP error reports 890 should include the "offending packet" in the data part of the 891 packet. The "offending packet" should include the CLNP header 892 plus at least the first 8 octets of the packet that caused 893 the error being reported. The offending packet is used by the 894 recipient of the ICMP error message to locate the transport- 895 layer endpoint that caused the error. 897 (NOTE: ISO/IEC 8473-1 only requires that the entire header of 898 the offending packet shall be returned; thus, if the minimumm MSS of 512 octets 899 is used, and the combined lengths of the error report header and the offending 900 packet header exceed 504 octets, fewer than 8 octets of data would be returned.) 902 7.5. Transport API changes. 904 Most IPv4 systems that are modified to support TUBA/CLNP will 905 already have an existing application program interface (API) 907 TUBA Working Group TUBA Transition 909 through which applications use TCP and UDP (e.g., primarily 910 a "sockets" based API) and many will already have an API 911 through which applications use OSI transport protocols (e.g., 912 the XTI API)." For IPv4, these APIs typically carry a 32 bit IPv4 address in 913 order to bind a TCP or UDP endpoint to a local address, to specify the 914 destination address of a UDP datagram being sent, or to specify the destination 915 address of a TCP connection to open. The 32 bit IPv4 address shows up in other 916 parts of the API, such as the return value from a hostname-to-IPv4 address 917 lookup function. Generally, these APIs provide fixed-size fields to hold IPv4 918 addresses and TCP and UDP port numbers. These APIs must be extended to carry 919 variable length NSAP addresses in order to support TUBA/CLNP. 921 We do not impose any additional requirements on how the APIs 922 should be changed to support TUBA/CLNP. However, we offer 923 here some general considerations in designing these new APIs. 925 Some desirable features of a dual internet protocol API are: 927 1) The new API should allow applications to pass in both 32- 928 bit IPv4 addresses and NSAP addresses. (Applications 929 introduced during the transition are likely to use 32 bit 930 IPv4 addresses and NSAP addresses.) 931 2) The new API should provide both source and binary 932 compatibility with the existing IPv4 API. Applications 933 written to the old API should continue to operate when run 934 in binary form, or when re-compiled on an dual internet 935 protocol system with the new API. 936 3).Application protocols that do not manipulate IP addresses 937 should run without any modifications. 939 Along with the API changes, application programs that 940 manipulate IPv4 addresses must be modified. Often these changes can be isolated 941 to the code that parses NSAP addresses typed in by users, and the code that 942 deals with 943 NSAP addresses returned by the name to address translation 944 functions. 946 7.6. IPv4 Addresses Embedded in Application Protocols 948 In this section, we specify how hosts should use existing 949 application protocols in a dual internet protocol 950 environment. (Note that this section discusses protocol 951 changes only; changes to user interfaces, i.e., changes to 952 APIs, the use of an "NSAP address domain-literal" instead of an IPv4 953 domain-literal in a command line for telnet, etc. are not discussed here). 955 The application protocols layered above TCP and UDP fall into 957 TUBA Working Group TUBA Transition 959 four categories: 961 1) Application protocols that do not carry embedded IPv4 962 addresses. These protocols can be used immediately by TUBA 963 hosts. The protocols which require no changes are: 965 Telnet (RFC 854, RFC 855) 966 TFTP (RFC 1350) 967 BSD "rlogin" protocol (RFC 1282) 968 BSD "rsh" protocol (uses port number, not IP addr) 969 BSD "biff" protocol (in.comsat) 970 BSD "lpr" protocol (RFC 1179) 971 BSD "syslog" protocol 972 ONC RPC protocol (RFC 1057) 973 ONC original "portmap" protocol (RFC 1057) 974 ONC+ new "rpcbind" protocol (replaces portmap) 975 Echo - TCP & UDP (RFC 862) 976 Discard - TCP & UDP (RFC 863) 977 Chargen - TCP & UDP (RFC 864) 978 Quote of the Day - TCP & UDP (RFC 865) 979 Active users - TCP or UDP (RFC 866) 980 Daytime - TCP or UDP (RFC 867) 981 Time - TCP or UDP (RFC 868) Nicname/Whois (RFC 954) 982 Finger (RFC 1288) 983 SNMP (RFC 1157) 984 Concise-MIB (RFC 1212) 985 Content type mail header field (RFC 1049) 986 NNTP (RFC 977) 987 BSD "rexec" protocol 988 NTP (RFC 1119) 989 NFS 990 Internet Gopher (RFC 1436) 992 2) Application protocols that carry IPv4 addresses, but the 993 protocol or its use of IPv4 addresses is obsolete. These 994 protocols do not need to be changed. They can continue to 995 be used by TUBA hosts indefinitely. Protocols that fall 996 into this category are: 998 SMTP (RFC 821) 999 Mail (RFC 822) 1000 MIME (RFC 1341) 1001 BSD "talk" protocol 1003 3) Application protocols that carry IPv4 addresses, but that 1004 are used exclusively by IPv4 itself (i.e., protocols, or 1005 protocol features that are specifc to IPv4 operation and 1006 that would not be changed by adding TUBA support to the 1007 system). New versions of these protocols may be 1009 TUBA Working Group TUBA Transition 1011 necessary to support the same function in TUBA/CLNP 1012 systems. Protocols that fall into this category are: 1014 IP Forwarding table MIB (RFC 1354) 1015 RARP (RFC 903) 1016 BOOTP (RFC 951, RFC 1084) 1017 DHCP (RFC 1531) 1018 PPP IP address negotiation options 1019 ONC "bootparams" RPC protocol 1020 DNS (RFC 1034, RFC 1035) 1021 Traceroute 1022 Ping (Echo) 1024 4) Application protocols that carry IPv4 addresses, but that 1025 are not IPv4 specific. FTP falls into this category. 1026 Extensions to FTP to enable its operation over larger 1027 addresses (e.g., NSAP addresses) are defined in [25]. 1029 The following application protocols have not been thoroughly 1030 examined or prototyped over a TUBA stack: 1032 Kerberos 1033 Telnet options 1034 POP3 (RFC 1225) 1035 DNS mail routing (RFC 974) 1036 WAIS 1037 World Wide Web 1038 Andrew File System 1039 Archie 1040 X window system 1042 Todate, no critical TUBA-related issues have been identified for these 1043 protocols. 1045 The remainder of this section discusses how dual internet 1046 protocol hosts should accommodate those application protocols 1047 which manipulate IPv4 addresses. 1049 7.6.1. FTP 1051 IPv4 addresses are encoded in FTP in two places: 1053 - the arguments to the PORT command. 1054 - the reply to the PASV command. 1056 Both the argument to the PORT command and the reply to the 1057 PASV command contain a 32-bit IPv4 address and a 16-bit TCP 1058 port number. 1060 These commands are used for two specific purposes: 1062 TUBA Working Group TUBA Transition 1064 1) In a 2-party FTP transaction, the client uses the PORT 1065 command to specify a TCP port number on the client's 1066 machine other than the default (port 20) for the server to 1067 use to connect back to the client. 1068 2) In a 3-party FTP transaction involving one client FTP and 1069 two server FTPs. The client gives the PASV command command 1070 to FTP server 1 and records the address reply. Then it 1071 sends the PORT command command to FTP server 2, giving the 1072 address returned by server 1. Then it sends the STOR or 1073 RETR command to server 2 to transfer file(s) directly 1074 between server 1 and server 2. 1076 [25] describes general extensions to FTP that enable hosts to 1077 operate the application using addresses other than 32-bit IP 1078 addresses, including NSAP addresses. These extensions include new commands 1079 (LPRT, LPASV) for use when NSAP addresses are exchanged, along with a 1080 corresponding set of completion reply codes (note that PORT, PASV remain for use 1081 by IPv4 systems). Selection of FTP commands and responses is governed by the 1082 local control settings at hosts (see section 4.2.4). 1084 7.6.2. SMTP (RFC 821) and Mail (RFC 822) 1086 IPv4 addresses may appear in the RFC 821 HELO reply codes and 1087 RFC 822 mail header format in the "domain literal" address 1088 construct. It is possible to specify a domain address as a 1089 dotted-decimal address. For example, one could specify a mail user in an 822 1090 encoded mail header as: 1092 beavis@[10.9.9.1] 1094 This construct is specified in section 6.2.3 of RFC 822. The 1095 RFC includes the following warning: 1097 "Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It 1098 is permitted only as a means of bypassing temporary system 1099 limitations, such as name tables which are not complete." 1101 It is recommended that the campaign to "discourage" the 1102 domain-literal address construct continue. We do not 1103 recommend that the domain-literal address construct syntax be 1104 modified to support NSAP addresses. Domain literal addresses 1105 will still be useful globally so long as IPv4 addresses are 1106 globally unique. 1108 Some systems perform a reverse DNS lookup to checkif the 1109 source IPv4 address maps to the source DNS name contained in 1110 the mail header as a form of very weak authentication. 1111 Implementations may require extensions to perform this 1112 function using NSAP addresses, if desirable. 1114 TUBA Working Group TUBA Transition 1116 7.6.3. Domain Name System (DNS) 1118 There are two places within the DNS where IPv4 addresses are 1119 encoded: 1121 - The "A" record format. 1122 - The structure of the "in-addr.arpa" tree. 1124 A new resource record type is defined for NSAP addresses 1125 [26]. [26] also describes how the PTR resource record used 1126 under the "IN-ADDR.ARPA" domain may be used to map from 1127 NSAP addresses to domain names (under the ".NSAP" domain). New hosts may ask for 1128 both the new (NSAP address) and old (IPv4 address) resource records. Older DNS 1129 servers will not have the new resource record type, and will therefore respond 1130 with only IPv4 address information. Updated DNS servers will have the new 1131 resource record information for the requested DNS name only if the associated 1132 host has been updated (otherwise the updated DNS server again will respond with 1133 an IPv4 address). 1135 Hosts and/or applications which do not use DNS operate in a similar method. For 1136 example, suppose that local name to 1137 address records are maintained in host table entries on each 1138 local workstation (i.e., in a hosts.txt file). When a 1139 workstation is updated to be able to run Internet applications over TUBA/CLNP, 1140 then the host table on the host 1141 may also be updated to contain updated NSAP addresses for 1142 other hosts which have also been updated. ([37] describes an 1143 "osi host.txt" file format that should be used for OSI or 1144 TUBA applications). The associated entries for non-updated 1145 hosts would continue to contain IPv4 addresses. Thus, again 1146 when an updated host wants to initiate communication with 1147 another host, it would look up the associated Internet 1148 address in the normal manner. If the address returned is a 1149 32-bit IP address, then the host would initiate a request 1150 using an Internet application over TCP (or UDP) over IP (as 1151 at present). If the returned address is an NSAP address, then 1152 the host would initiate a request using an Internet 1153 application over TCP (or UDP) over CLNP. 1155 The rules for hosts to contact DNS servers, and for DNS 1156 servers to contact other DNS servers, are the same as for a 1157 host to contact a host (see section 4.2.4). 1159 7.6.4. SMI, MIB-II 1161 The SMI RFC defines a data type for the 32-bit IPv4 address. 1162 This type is named "IpAddress". The MIB-II and some other 1163 MIBs use this data structure. These definitions can remain 1165 TUBA Working Group TUBA Transition 1167 unchanged and can continue to be used by IPv4 hosts and 1168 routers. A data type exists for NSAP address [27a, 27b, 27c]. A corresponding 1169 MIB table to those MIB tables that include IP address data types must be defined 1170 for TUBA/CLNP systems. These include the tcpConnTable and udpTable. These two 1171 new tables are specified in [40]. 1173 7.6.5. RARP, BOOTP, DHCP, Bootparams 1175 RARP, BOOTP, DHCP, and Bootparams are all used to support 1176 booting. RARP, BOOTP, and DHCP all provide a mechanism for a 1177 host to acquires its own IPv4 address. These protocols can 1178 continue to be used without change by IPv4 systems. 1180 A RARP equivalent function may be provided using the ES-IS 1181 protocol [13]. BOOTP and DHCP must be revised to return 1182 NSAP addresses, or must incorporated into a new host configuration scheme. The 1183 ONC RPC system includes a version mechanism that should allow the revision of 1184 the bootparams protocol in a compatible way. 1186 7.6.6. BSD talk protocol. 1188 This protocol is obsolete. We make no attempt to operate it 1189 over CLNP. 1191 8. General Issues 1193 8.1. Management, monitoring, network operations 1195 During the transition period, the current set of management 1196 and monitoring tools must continue to work for IPv4 links. 1197 This set includes such applications as 1199 tcpdump/snoop/iptrace/tcpview 1200 netstat 1201 ifconfig 1202 IPv4 traceroute tools 1203 IPv4 ping tools 1204 SNMP network management systems 1205 AS-traceroute 1206 Configuration retrieval tools 1207 Statistics tools 1208 DNS registry tools 1209 Line test programs (to test all bit patterns at IP level) 1210 BGP-4 peer checking tool (equivalent IDRP peer checking tool) 1212 Corresponding tools for these and other operations-related 1213 applications must be developed for CLNP. Some exist today. 1214 RFC 1574 [37], Essential Tools for the OSI Internet, 1216 TUBA Working Group TUBA Transition 1218 describes a traceroute, route dump, and ping which are 1219 suitable for operation in conjunction with CLNP-based 1220 internets. 1222 8.1.1 Ping 1224 RFC 1575, ISO CLNP Ping [38], specifes the use of the CLNP 1225 echo request and reply packets to support a ping application 1226 (CLNP). Since the TUBA transition is dual internet protocol, 1227 CLNP operation is independent of IP operation at the network 1228 layer (except for encapsulation over virtual links). Thus IP 1229 Ping and CLNP Ping (each based on a respective set of network 1230 layer echo request and reply packets) are used independently. 1231 Pings may be used to test for (a) host reachability, and (b) 1232 host status (alive or dead). When using "pings" to manage 1233 dual internet protocol internets an operator may: 1235 1) IPv4 "ping" an IPv4-only system to test whether the host 1236 is IPv4-reachable and alive. 1237 2) IPv4 "ping" a dual internet protocol system to determine 1238 whether that dual internet protocol system is IPv4- 1239 reachable and alive 1240 3) CLNP "ping" a dual internet protocol system to determine 1241 whether that dual internet protocol system is CLNP- 1242 reachable and alive 1244 8.1.2 Traceroute 1246 Traceroute operation is the same for IPv4 and CLNP; only the 1247 packet formats differ. The application of traceroute follows 1248 the same logic as for ping (see RFC 1574). 1250 8.1.3 SNMP 1252 No protocol changes to SNMP are required to support TUBA. MIBs have been defined 1253 for CLNP and ES-IS [34] and IS-IS. An IDRP MIB is in preparation. Tables in the 1254 MIB-II tcp and udp groups use IPv4 addresses and corresponding tables that use 1255 NSAP addresses must be defined (A consequence of this is that a network 1256 management station must traverse both the IPv4-indexed and NSAP address-indexed 1257 tcpConnTable and udpListenerTable to know of all the open connections on a dual 1258 internet protocol host.) 1260 IPng systems should use the preferred (UDP) encapsulation for 1261 SNMP request, response and trap messages. Management systems 1262 may use CLNP paths to acquire IPv4-related management objects 1263 in those circumstances where managed agents cannot be reached 1264 via IPv4 paths. 1266 TUBA Working Group TUBA Transition 1268 Operational practices must be extended to manage dual 1269 internet protocol environments (if such practices are not 1270 already in place). For example, if operators use the 1271 ifOperStatus managed object rather than ping to test 1272 reachability between a management station and a managed 1273 agent, the practice of determining the status of all the 1274 interfaces of a dual internet protocol network might be 1275 extended as follows: 1277 1) "get" ifOperStatus using an IPv4 address to test whether 1278 an IPv4-only system is IPv4-reachable and the interface is 1279 {up, down,testing} 1280 2) "get" ifOperStatus using an IPv4 address to test whether a 1281 dual internet protocol system is IPv4-reachable and the 1282 interface is {up, down,testing} 1283 3) "get" ifOperStatus using an NSAP address to test whether a 1284 dual internet protocol system is CLNP-reachable and the 1285 interface is {up, down,testing} 1287 During the transition period, operators must know the state 1288 of IPv4 and CLNP connectivity, so it is expected that SNMP 1289 NMSs would be configured to get the value of ifOperStatus 1290 over both paths to dual internet protocol systems. 1292 Extensions would also be applied for the reception of trap 1293 messages by NMSs. Consider, for example, an NMS operating 1294 with a knob=PreferCLNP; agents expected to generate trap 1295 messages would be configured with the NSAP addresses of NMSs 1296 that are to receive traps. 1298 8.2 Autoconfiguration 1300 [5] recommends that TUBA implementations support the 1301 assignment of system identifiers for TUBA/CLNP hosts defined 1302 in [16] for the purposes of host address autoconfiguration as 1303 described in [28] and [29]. 1305 8.3 Autoregistration 1307 Automatic registration of host information into the DNS is on 1308 the "to do" list for all IPng candidates. 1310 8.4 Multicast 1312 "Host group extensions for CLNP multicast" [10] discusses 1313 multicast support for CLNP-based systems. During the 1314 transition period, IPv4-only and dual-stack systems can use 1315 IPv4-based multicast. Multicast groups comprised of dual- 1316 stack (and CLNP-multicast-capable) systems can use CLNP-based 1317 multicasting. 1319 TUBA Working Group TUBA Transition 1321 8.5 Path MTU Discovery 1323 Hosts that send small IPv4 datagrams over paths that 1324 accommodate larger ones waste Internet resources; this also 1325 contributes to suboptimal application performance. [30] describes Path MTU 1326 discovery for IPv4-based hosts; hosts with IPv4 connectivity should continue to 1327 use [30]. [31] discusses MTU discovery for CLNP-based hosts. 1329 8.6 Mobility 1331 [11] discusses describes an approach to transparent mobile 1332 internetworking that allows hosts to roam a CLNP-based 1333 internet in a fashion transparent to transport layer 1334 protocols. 1336 8.7 CLNP Header Compression 1338 [32] describes a CLNP header compression algorithm. This 1339 should be evaluated for suitability by the TUBA WG. Hosts 1340 with IPv4 connectivity should continue to use [33]. CATNIP 1341 should also be evaluated for suitability by the TUBA WG as a 1342 compression mechanism. 1344 9. Timeline for transition 1346 The following timeline depicts the major activities and 1347 benchmarks for TUBA transition: 1349 _____TIME=0_____ (today) 1350 | 1351 | 1352 |---> all hosts are IPv4 capable 1353 |---> IPv4 routed and managed globally (parts of Internet 1354 | routed using Integrated IS-IS) 1355 |---> CIDR and BGP-4 deployment 1356 |---> CLNP routed in parts of internet using IS-IS 1357 |---> limited management instrumentation for CLNP 1358 |---> tuba/clnp prototypes (effectively knobs=IPv4only) 1359 | 1360 _|___TIME=1_____ 1361 | 1362 |---> majority of hosts remain IPv4 capable only 1363 |---> DNS NSAP support begins (over IPv4 paths) on servers 1364 | that are primaries/secondaries for the NSAP address 1365 | RRs of TUBA/CLNP hosts 1366 |---> multicast support using CLNP begins 1367 |---> TUBA/CLNP software installation begins in hosts; 1368 | CLNP-capable hosts operate in production with 1369 | knobs=prefer_IPv4 1371 TUBA Working Group TUBA Transition 1373 |---> sites experiment with Internet applications over 1374 | TUBA/CLNP 1375 |---> CLNP routed infrastructure is expanded more 1376 | networks support CLNP & IS-IS 1377 |---> IDRP deployment begins 1378 |---> development of CLNP management instrumentation 1379 | complementing that used for IPv4 begins 1380 |---> CLNP tunneled over IPv4 paths to connect TUBA hosts 1381 | where no "native CLNP" exists 1382 | 1383 _|__TIME=2_____ 1384 | 1385 |---> TUBA/CLNP software installation expands in hosts 1386 |---> CLNP routed infrastructure is extensive 1387 |---> CLNP multicasting expands 1388 |---> experiments begin with CLNP flows, mobility 1389 |---> CLNP replaces IPv4 as encapsulate for tunneled 1390 | protocols 1391 |---> IDRP deployment is extensive 1392 |---> instances of CLNP tunnels diminishes 1393 |---> CLNP management instrumentation is extensive 1394 |---> Internet operates over CLNP and IPv4 infrastructure 1395 |---> sites turn on CLNP; majority of hosts now operate in 1396 | production with knob=prefer_CLNP 1397 |---> IPv4-only population diminishes 1398 | 1399 _|___TIME=3_____ 1400 | 1401 |---> IPv4 addresses no longer unique; IPv4-only 1402 | communication confined to "islands" 1403 |---> CLNP multicasting is extensive 1404 |---> CLNP flows and mobility expand 1405 |---> TUBA/CLNP software is ubiquitous 1406 |---> Internet is entirely CLNP routed 1407 |---> DNS supported on CLNP infrastructure 1408 |---> Internet operates over CLNP; diminishing IPv4 1409 | infrastructure 1410 |---> CLNP-capable hosts now operate in production with 1411 | knob=prefer_CLNP or knob=CLNP_only 1412 | 1413 _|___TIME=?_____ 1414 | 1415 |---> IPv4-only communication is rare or highly localized 1416 |---> sites elect to turn down IPv4 operations & support 1418 10. Security 1420 Screening routers should continue to perform IPv4 packet 1421 filtering; for CLNP, they should packet filter on source and 1422 destination NSAP addresses, PROTOcol value (hosts 1424 TUBA Working Group TUBA Transition 1426 implementing [5] encode the PROTOcol value in the network selector of the 1427 destination NSAP address), and port number to block traffic between networks or 1428 specific hosts on an port level. Bastion hosts, dual-homed gateways, and other 1429 forms of firewalls must be expanded to provide the same safeguards as those 1430 developed for IPv4 environments. 1432 RFC 1108 Security can be encoded in CLNP headers, see [5]. 1434 Access control, authentication, data integrity, and 1435 confidentiality are recognized as security services that are 1436 required in the current as well as future global Internet. 1437 One solution to providing these services is through a secure 1438 network layer packet encapsulation protocol supported by a 1439 key management protocol for exchanging security information 1440 associated with a particular instance of communication. One 1441 such integrated network layer security protocol (I-NLSP) has 1442 been specified for TUBA [39], to provide confidentiality and 1443 integrity services. Dual internet protocol hosts that support 1444 this protocol will be capable of secure operations with (1) 1445 other TUBA/I-NLSP systems using either CLNP or IP, and or (2) 1446 existing IPv4 operating behind TUBA/I-NLSP capable secure 1447 ISs. [39] specifies the I-NLSP, and addresses coexistence and 1448 interoperability issues as well. 1450 10.0 Acknowledgements 1452 This document draws most of its content from efforts of (and 1453 electronic postings to the mailing lists of three IETF 1454 working groups: TUBA, NOOP, and TPIX/CATNIP. A number of 1455 individuals have made significant contributions to the TUBA 1456 effort, either through implementation, production of 1457 internet-drafts, or by posting electronic mail of such 1458 completeness and quality that preparation of a transition 1459 plan was often a matter of integration of ideas. Those who 1460 merit special attention include Dave Katz (Cisco Systems), 1461 Ross Callon (Wellfleet Communications), Jim Bound (DEC), 1462 Brian Carpenter (CERN), Yakov Rehkter (IBM), Mark Knopper 1463 (AADS), Peter Ford (LANL), Rich Colella, Doug Montgomery, and Jim West 1464 (NIST/CSL), Cathy Wittbrodt (BARRnet), Sue Hares (MERIT), Robert Ullman (Lotus), 1465 and Bill Manning (SESQUINET). 1467 Author's Address 1469 David M. Piscitello 1470 Core Competence, Inc. 1471 1620 Tuckerstown Road 1472 Dresher, PA USA 19025 1473 dave@corecom.com 1474 1-215-830-0692 1476 TUBA Working Group TUBA Transition 1478 References 1480 [1] Postel, J., Transmission Control Protocol (TCP). STD 7, 1481 RFC 793, September 1981. 1482 [2] Postel, J., Internet Protocol (IP). STD 5, RFC 791, 1483 September 1981. 1484 [3] Rekhter, Y., and Li, T., Architecture for IP Address 1485 Allocation with CIDR, RFC 1518, September 1993. 1486 [4] Callon, R., TCP/UDP over Bigger Addresses (TUBA), RFC 1487 1347, May 1992. 1488 [5] Piscitello, D., Use of ISO CLNP in TUBA environments, 1489 RFC 1562, December 1993. 1490 [6] ISO/IEC 8348:1992. OSI Network Layer Service and 1491 Addressing. 1492 [7a] Callon, R., R. Colella, and R. Hagens, NSAP Guidelines 1493 for the Internet, RFC 1237, July 1991. 1494 [7b] R. Colella, R. Callon, E. Gardner & Y. Rekhter, 1495 Guidelines for OSI NSAP Allocation in the Internet, RFC 1496 1629, May 1994. 1497 [8] ISO/IEC 8473:1992. Protocol for Providing the 1498 Connectionless-mode Network Service, Edition 2. 1499 [9] Callon, R., "A proposal for adding flow support to 1500 CLNP", Internet-Draft 1501 [10] Marlow, D., "Host group extensions for CLNP Multicast", 1502 Internet-Draft (draft-ietf-tuba-host-clnp-multicas- 1503 01.txt) 1504 [11] Perkins & Rehkter, Y., "Mobility for CLNP". Internet- 1505 draft (draft-ietf-tuba-mobility-00.txt) 1506 [12] Kastenholz, F. "Criteria for choosing IPv7 Selection", 1507 Internet-draft (draft-kastenholz-ipng-criteria-02.txt). 1508 [13] ISO/IEC 9542:1988. End System to intermediate system 1509 routeing exchange protocol for use in conjunction with 1510 CLNP (ISO/IEC 8473). 1511 [14] ISO/IEC 10589:1992. Intermediate system to intermediate 1512 system routeing exchange protocol for use in conjunction 1513 CLNP (ISO/IEC 8473). 1514 [15] ISO/IEC 10747:1992, Protocol for exchange of interdomain 1515 routeing information among intermediate systems to 1516 support forwarding of ISO/IEC 8473 PDUs. 1517 [16] Piscitello, D., Assignment of System Identifiers for 1518 TUBA/CLNP hosts, RFC 1526, November 1993. 1519 [17] Katz, D., Tunneling the OSI Network Layer over CLNP 1520 (EON), Internet-draft (draft-ietf-tuba-eon-00.txt). 1521 [18] Hanks. S, T. Li, D. Farinacci, P. Traina, Generic 1522 Routing Encapsulation over IPv4 networks, Internet- 1523 draft, September 1993. 1524 [19] Hanks. S, T. Li, D. Farinacci, P. Traina, Generic 1525 Routing Encapsulation, Internet-Draft, September 1993. 1526 [20] Leiner, B., Rehkter, Y., The Multiprotocol Internet, RFC 1527 1560, December 1993. 1529 TUBA Working Group TUBA Transition 1531 [21] Callon, R., and Perlman, R., Integrated IS-IS, RFC 1195. 1532 [22] Tsuchiya, P. Network Address Translator (NAT), 1533 electronically available via ftp from SIGCOMM/CCR. 1534 [23] Gunner, C., Montgomery, D., Experience with the 1535 Integrated IS-IS Protocol, Internet Draft 1536 (draft-ietf-isis-opexp-01.txt) 1537 [24] Piscitello, D., and Chapin, L., Open Systems Networking: 1538 TCP/IP and OSI. Addison Wesley Publishers, August 1993. 1539 [25] Piscitello, D., FTP Operation Over Big Address Records 1540 (FOOBAR), RFC 1639, October 1993 (replaces RFC 1545). 1541 [26] Manning, Colella, DNS RRs for NSAP addresses, RFC 1637. 1542 [27a] Rose, M., SNMP over OSI. RFC 1418, 1993 March. 1543 [27b] Rose, M., SNMP over OSI. RFC 1283 1991 December 1544 [27c] Satz, G., CLNS MIB for use with Connectionless Network 1545 Protocol (ISO 8473) and End System to Intermediate 1546 System (ISO 9542), RFC 1238 1547 [28] Katz, "Suggested System ID Option for the ES-IS 1548 Protocol", Internet-Draft in preparation 1549 [29] Katz, "Dynamic Assignment of OSI NSAP Addresses in the 1550 Internet", Internet-Draft in preparation. 1551 [30] Mogul, J., and S. Deering, RFC 1191, MTU Discovery. 1552 [31] Piscitello, D.,"MTU discovery for CLNP-based hosts", 1553 Internet-Draft (draft-ietf-tuba-mtu-01.txt). 1554 [32] Whyman, ICAO CLNP Header Compression algorithm. 1555 [33] IPv4 header compression RFCs 1556 [34] Satz, G., Request for Comments 1238, Connectionless-mode 1557 Network Service Management Information Base - for use 1558 with Connectionless Network Protocol (ISO 8473) and End 1559 system to Intermediate System Protocol (ISO 9452)", 1560 Internet Architecture Board, June 1991. 1561 [35] Gilligan, R., and B. Hinden, "IPAE: The SIPP 1562 Interoperability and Transition Mechanism", Internet- 1563 draft November 1993. 1564 [36] Katz, D., P. Ford, "TUBA: Replacing IP with CLNP". 1565 [37] Wittbrodt, C., and S. Hares, Essential Tools for the OSI 1566 Internet, Request for Comments 1574, March 1994. 1567 [38] Wittbrodt, C., and S. Hares, CLNP Ping (Echo), Request 1568 for Comments 1575, March 1994. 1569 [39] Glenn, K. Robert, "Integrated Network Layer Security 1570 Protocol," Internet Draft (draft-glenn-layer-security- 1571 00.txt), September 1993. 1572 [40] West, J., "Extensions to MIB-II for TUBA/CLNP systems", 1573 Internet Draft (draft-ietf-tuba-mib-00.txt).