From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1683.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc1683.txt (limited to 'doc/rfc/rfc1683.txt') diff --git a/doc/rfc/rfc1683.txt b/doc/rfc/rfc1683.txt new file mode 100644 index 0000000..1faed2e --- /dev/null +++ b/doc/rfc/rfc1683.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group R. Clark +Request for Comments: 1683 M. Ammar +Category: Informational K. Calvert + Georgia Institute of Technology + August 1994 + + + Multiprotocol Interoperability In IPng + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This document was submitted to the IETF IPng area in response to RFC + 1550. Publication of this document does not imply acceptance by the + IPng area of any ideas expressed within. Comments should be + submitted to the big-internet@munnari.oz.au mailing list. + +1. Executive Summary + + The two most commonly cited issues motivating the introduction of + IPng are address depletion and routing table growth in IPv4. Further + motivation is the fact that the Internet is witnessing an increasing + diversity in the protocols and services found in the network. When + evaluating alternatives for IPng, we should consider how well each + alternative addresses the problems arising from this diversity. In + this document, we identify several features that affect a protocol's + ability to operate in a multiprotocol environment and propose the + incorporation of these features into IPng. + + Our thesis, succinctly stated, is: The next generation Internet + Protocol should have features that support its use with a variety of + protocol architectures. + +2. Introduction + + The Internet is not a single protocol network [4]. While TCP/IP + remains the primary protocol suite, other protocols (e.g., IPX, + AppleTalk, OSI) exist either natively or encapsulated as data within + IP. As new protocols continue to be developed, we are likely to find + that a significant portion of the traffic in future networks is not + from single-protocol communications. It is important to recognize + that multiprotocol networking is not just a transition issue. For + instance, we will continue to see tunneling used to carry IPX traffic + + + +Clark, Ammar & Calvert [Page 1] + +RFC 1683 Multiprotocol Interoperability In IPng August 1994 + + + over the Internet between two Novell networks. Furthermore, the + introduction of IPng is not going to result in a near term + elimination of IPv4. Even when IPng becomes the primary protocol + used in the Internet, there will still be IPv4 systems in use. We + should consider such multiprotocol uses of the network as we design + future protocols that can efficiently handle mixed protocol traffic. + + We have identified several issues related to the way in which + protocols operate in a multiprotocol environment. Many of these + issues have traditionally been deemed "less important" by protocol + designers since their goal was to optimize for the case where all + systems supported the same protocol. With the increasing diversity + of network protocols, this approach is no longer practical. By + addressing the issues outlined in this paper, we can simplify the + introduction of IPng to the Internet and reduce the risk for network + managers faced with the prospect of supporting a new protocol. This + will result in a faster, wider acceptance of IPng and increased + interoperability between Internet hosts. In addition, by designing + IPng to address these issues, we will make the introduction of future + protocols (IPng2) even easier. + + The outline for this document is as follows. In Section 3 we + motivate the issues of multiprotocol networking with a discussion of + an example system. In Section 4 we describe three main techniques + for dealing with multiple protocols. This is followed in Section 5 + by a description of the various protocol features that are important + for implementing these three techniques. We conclude in Section 6 + with a summary of the issues raised. + +3. Multiprotocol Systems + + Consider the multiprotocol architecture depicted in Figure 1. A + system supporting this architecture provides a generic file-transfer + service using either the Internet or OSI protocol stacks. The + generic service presents the user with a consistent interface, + regardless of the actual protocols used. The user can transfer files + between this host and hosts supporting either of the single protocol + stacks presented in Figures 2a and 2b. To carry out this file + transfer, the user is not required to decide which protocols to use + or to adjust between different application interfaces. + + + + + + + + + + + +Clark, Ammar & Calvert [Page 2] + +RFC 1683 Multiprotocol Interoperability In IPng August 1994 + + + +-----------------------------------+ + | File Transfer Service | + +-----------+-----------------------+ + | | FTAM | + | +-----------------------+ + | FTP | ISO 8823 | + | +-----------------------+ + | | ISO 8327 | + | +-----------+-----------+ + | |TP0/RFC1006| TP4 | + +-----------+-----------+ | + | TCP | | + +-----------+-----------+-----------+ + | IP | CLNP | + +-----------+-----------------------+ + + + Figure 1: Multiprotocol architecture providing file-transfer service + + + +-----------+ +-----------+ +-----------+ +-----------+ + | FTP | | FTAM | | FTAM | | FTP | + +-----------+ +-----------+ +-----------+ +-----------+ + | TCP | | ISO 8823 | | ISO 8823 | | TCP | + +-----------+ +-----------+ +-----------+ +-----------+ + | IP | | ISO 8327 | | ISO 8327 | | CLNP | + +-----------+ +-----------+ +-----------+ +-----------+ + | TP4 | |TP0/RFC1006| + +-----------+ +-----------+ + | CLNP | | TCP | + +-----------+ +-----------+ + | IP | + +-----------+ + + a) TCP/IP b) OSI c) RFC 1006 d) TUBA + + + Figure 2: Protocol stacks providing file-transfer service. + + Figure 2c depicts a mixed stack architecture that provides the upper + layer OSI services using the Internet protocols. This is an example + of a "transition architecture" for providing OSI applications without + requiring a full OSI implementation. Figure 2d depicts a mixed stack + architecture that provides the upper layer Internet applications + using the OSI network protocol. In addition to communicating with + the two previous simple protocol stacks, the multiprotocol system of + Figure 1 includes all the protocols necessary to communicate with + these two new, mixed protocol stacks. + + + +Clark, Ammar & Calvert [Page 3] + +RFC 1683 Multiprotocol Interoperability In IPng August 1994 + + + It is likely that many future network systems will be configured to + support multiple protocols including IPng. As the IPng protocol is + deployed, it is unreasonable to expect that users will be willing to + give up any aspect of their current connectivity for the promise of a + better future. In reality, most IPng installations will be made "in + addition to" the current protocols. The resulting systems will + resemble Figure 1 in that they will be able to communicate with + systems supporting several different protocols. + + Unfortunately, in most current examples, the architecture of Figure 1 + is implemented as independent protocol stacks. This means that even + though both TCP and CLNP exist on the system, there is no way to use + TCP and CLNP in the same communication. The problem with current + implementations of architectures like Figure 1 is that they are + designed as co-existence architectures and are not integrated + interoperability systems. We believe future systems should include + mechanisms to overcome this traditional limitation. By integrating + the components of multiple protocol stacks in a systematic way, we + can interoperate with hosts supporting any of the individual stacks + as well as those supporting various combinations of the stacks. + + In order to effectively use multiple protocols, a system must + identify which of the available protocols to use for a given + communication task. We call this the Protocol Determination [2] + task. In performing this task, a system determines the combination + of protocols necessary to provide the needed service. For achieving + interoperability, protocols are selected from the intersection of + those supported on the systems that must communicate. + +4. Multiprotocol Techniques + + In this section we identify three main techniques to dealing with + multiprotocol networks that are in use today and will continue to be + used in the Internet. The first two techniques, tunneling and + conversion, are categorized as intermediate-system techniques in that + they are designed to achieve multiprotocol support without changing + the end-systems. The third technique explicitly calls for the + support of multiple protocols in end-systems. By describing these + techniques here, we can motivate the need for the specific protocol + features described in Section 5. + +4.1 Encapsulation/Tunneling + + Encapsulation or tunneling is commonly used when two networks that + support a common protocol must be connected using a third + intermediate network running a different protocol. Protocol packets + from the two end networks are carried as data within the protocol of + the intermediate network. This technique is only appropriate when + + + +Clark, Ammar & Calvert [Page 4] + +RFC 1683 Multiprotocol Interoperability In IPng August 1994 + + + both end-systems support the same protocol stack. It does not + provide interoperability between these end systems and systems that + only support the protocol stack in the intermediate network. Some + examples of this technique are: a mechanism for providing the OSI + transport services on top of the Internet protocols [13], + encapsulating IEEE 802.2 frames in IPX network packets [5], tunneling + IPX [10] and AppleTalk traffic over the Internet backbone. We expect + IPng to be used for tunneling other network protocols over IPng and + to be encapsulated. + +4.2 Translation/Conversion + + Despite their known limitations [8], translation or conversion + gateways are another technique for handling multiple protocols [11, + 12]. These gateways perform direct conversion of network traffic + from one protocol to another. The most common examples of conversion + gateways are the many electronic mail gateways now in use in the + Internet. In certain cases it may also be feasible to perform + conversion of lower layer protocols such as the network layer. This + technique has been suggested as part of the transition plan for some + of the current IPng proposals [3, 15]. + +4.3 Multiprotocol End-Systems + + We expect that IPng will be introduced as an additional protocol in + many network systems. This means that IPng should be able to coexist + with other protocols on both end- and intermediate-systems. + Specifically, IPng should be designed to support the Protocol + Determination task described in Section 3. + + One technique that we consider for solving the Protocol Determination + problem is to employ a directory service in distributing system + protocol configuration information. We have developed and + implemented mechanism for using the Internet Domain Name System (DNS) + [6, 7] to distribute this protocol information [2]. Using this + mechanism, a multiprotocol host can determine the protocol + configuration of a desired host when it retrieves the network address + for that host. Then the multiprotocol host can match the + configuration of the desired host to its own configuration and + determine which protocols should be used to carry out the requested + communication service. + + Another alternative to determining protocol information about another + host is Protocol Discovery. Using this approach, a host determines + which protocols to use by trial-and-error with the protocols + currently available. The initiating host monitors successive + attempts to communicate and uses the information gained from that + monitoring to build a knowledge base of the possible protocols of the + + + +Clark, Ammar & Calvert [Page 5] + +RFC 1683 Multiprotocol Interoperability In IPng August 1994 + + + remote system. + + This knowledge is used to determine whether or not a communication + link can be established and if it can, which protocol should be used. + + An important aspect of the Protocol Discovery approach is that it + requires an error and control feedback system similar to ICMP [9], + but with additional functionality (See Section 5). + +5. Protocol Features + + In this section we identify features that affect a protocol's ability + to support the multiprotocol techniques described in the previous + section. These features indicate specific areas that should be + considered when comparing proposed protocols. We present two + different types of protocol features: those that should be included + as part of the IPng protocol standard, and those that should be + considered as part of the implementation and deployment requirements + for IPng. + +5.1 Protocol Standard Features + + o Addressing + + A significant problem in dealing with multiprotocol networks is + that most of the popular network protocols use different + addressing mechanisms. The problem is not just with different + lengths but also with different semantics (e.g., hierarchical vs. + flat addresses). In order to accommodate these multiple formats, + IPng should have the flexibility to incorporate many address + formats within its addressing mechanism. + + A specific example might be for IPng to have the ability to + include an IPv4 or IPX address as a subfield of the IPng address. + This would reduce the complexity of performing address conversion + by limiting the number of external mechanisms (e.g., lookup + tables) needed to convert an address. This reduction in + complexity would facilitate both tunneling and conversion. It + would also simplify the task of using IPng with legacy + applications which rely on a particular address format. + + o Header Option Handling + + In any widely used protocol, it is advantageous to define option + mechanisms for including header information that is not required + in all packets or is not yet defined. This is especially true in + multiprotocol networks where there is wide variation in the + requirements of protocol users. IPng should provide efficient, + + + +Clark, Ammar & Calvert [Page 6] + +RFC 1683 Multiprotocol Interoperability In IPng August 1994 + + + flexible support for future header options. This will better + accommodate the different user needs and will facilitate + conversion between IPng and other protocols with different + standard features. + + As part of the support for protocol options, IPng should include a + mechanism for specifying how a system should handle unsupported + options. If a network system adds an option header, it should be + able to specify whether another system that does not support the + option should drop the packet, drop the packet and return an + error, forward it as is, or forward it without the option header. + The ability to request the "forward as is" option is important + when conversion is used. When two protocols have different + features, a converter may introduce an option header that is not + understood by an intermediate node but may be required for + interpretation of the packet at the ultimate destination. On the + other hand, consider the case where a source is using IPng with a + critical option like encryption. In this situation the user would + not want a conversion to be performed where the option was not + understood by the converter. The "drop the packet" or "drop and + return error" options would likely be used in this scenario. + + o Multiplexing + + The future Internet protocol should support the ability to + distinguish between multiple users of the network. This includes + the ability to handle traditional "transport layer" protocols like + TCP and UDP, as well as other payload types such as encapsulated + AppleTalk packets or future real-time protocols. This kind of + protocol multiplexing can be supported with an explicit header + field as in IPv4 or by reserving part of the address format as is + done with OSI NSEL's. + + In a multiprotocol network there will likely be a large number of + different protocols running atop IPng. It should not be necessary + to use a transport layer protocol for the sole purpose of + providing multiplexing for the various network users. The cost of + this additional multiplexing is prohibitive for future high-speed + networks [14]. In order to avoid the need for an additional level + of multiplexing, the IPng should either use a payload selector + larger than the 8-bits used in IPv4 or provide an option for + including additional payload type information within the header. + + o Status/Control Feedback + + With multiple protocols, the correct transmission of a packet + might include encapsulation in another protocol and/or multiple + conversions to different protocols before the packet finally + + + +Clark, Ammar & Calvert [Page 7] + +RFC 1683 Multiprotocol Interoperability In IPng August 1994 + + + reaches its destination. This means that there are many different + places the transmission can fail and determining what went wrong + will be a challenge. + + In order to handle this situation, a critical protocol feature in + multiprotocol networks is a powerful error reporting mechanism. + + In addition to reporting traditional network level errors, such as + those reported by ICMP [9], the IPng error mechanism should + include feedback on tunneling and conversion failures. Also, + since it is impossible to know exactly which part of a packet is + an encapsulated header, it is important that the feedback + mechanism include as much of the failed packet as possible in the + returned error message. + + In addition to providing new types of feedback, this mechanism + should support variable resolution such that a transmitting system + can request limited feedback or complete information about the + communication process. This level of control would greatly + facilitate the Protocol Discovery process described in Section + 4.3. For example, a multiprotocol system could request maximal + feedback when it sends packets to a destination it has not + communicated with for some time. After the first few packets to + this "new" destination, the system would revert back to limited + feedback, freeing up the resources used by the network feedback + mechanisms. + + Finally, it is important that the information provided by the + feedback mechanism be available outside the IPng implementation. + In multiprotocol networks it is often the case that the solution + to a communication problem requires an adjustment in one of the + protocols outside the network layer. In order for this to happen, + the other protocols must be able to access and interpret these + feedback messages. + + o MTU Discovery or Fragmentation + + A form of multiprotocol support that has long been a part of + networking is the use of diverse data link and physical layers. + One aspect of this support that affects the network layer is the + different Maximum Transmission Units (MTU) used by various media + formats. For efficiency, many protocols will attempt to avoid + fragmentation at intermediate nodes by using the largest packet + size possible, without exceeding the minimum MTU along the route. + To achieve this, a network protocol performs MTU discovery to find + the smallest MTU on a path. + + + + + +Clark, Ammar & Calvert [Page 8] + +RFC 1683 Multiprotocol Interoperability In IPng August 1994 + + + The choice of mechanism for dealing with differing MTUs is also + important when doing conversion or tunneling with multiple + protocols. When tunneling is performed by an intermediate node, + the resulting packets may be too large to meet the MTU + requirements. Similarly, if conversion at an intermediate node + results in a larger protocol header, the new packets may also be + too large. In both cases, it may be desirable to have the source + host reduce the transmission size used in order to prevent the + need for additional fragmentation. This information could be sent + to the source host as part of the previously described feedback + mechanism or as an additional MTU discovery message. + +5.2 Implementation/Deployment Features + + o Switching + + We define switching in a protocol as the capability to + simultaneously use more than one different underlying protocol + [1]. In network layer protocols, this implies using different + datalink layers. For example, it may be necessary to select + between the 802.3 LLC and traditional Ethernet interfaces when + connecting a host to an "ethernet" network. Additionally, in some + systems IPng will not be used directly over a datalink layer but + will be encapsulated within another network protocol before being + transmitted. It is important that IPng be designed to support + different underlying datalink services and that it provide + mechanisms allowing IPng users to specify which of the available + services should be used. + + o Directory Service Requirements + + While not specifically a part of the IPng protocol, it is clear + that the future Internet will include a directory service for + obtaining address information for IPng. In light of this, there + are some features of the directory service that should be + considered vis-a-vis their support for multiple protocols. + + First, the directory service should be able to distribute address + formats for several different protocol families, not just IPng and + IPv4. This is necessary for the use of tunneling, conversion, and + the support of multiprotocol systems. Second, the directory + service should include support for distributing protocol + configuration information in addition to addressing information + for the network hosts. This feature will support the protocol + determination task to be carried out by multiprotocol systems [2]. + + + + + + +Clark, Ammar & Calvert [Page 9] + +RFC 1683 Multiprotocol Interoperability In IPng August 1994 + + +6. Conclusion + + Future networks will incorporate multiple protocols to meet diverse + user requirements. Because of this, we are likely to find that a + significant portion of the traffic in the Internet will not be from + single-protocol communications (e.g., TCPng/IPng). This will not + just be true of near term, transitional networks but will remain as a + reality for most of the Internet. As we pursue the selection of + IPng, we should consider the special needs of multiprotocol networks. + In particular, IPng should include mechanisms to handle mixed + protocol traffic that includes tunneling, conversion, and + multiprotocol end-systems. + +7. Acknowledgments + + The authors would like to acknowledge the support for this work by a + grant from the National Science Foundation (NCR-9305115) and the + TRANSOPEN project of the Army Research Lab (formerly AIRMICS) under + contract number DAKF11-91-D-0004. + +8. References + + [1] Clark, R., Ammar, M., and K. Calvert, "Multi-protocol + architectures as a paradigm for achieving inter-operability", In + Proceedings of IEEE INFOCOM, April 1993. + + [2] Clark, R., Calvert, K. and M. Ammar, "On the use of directory + services to support multiprotocol interoperability", To appear in + proceedings of IEEE INFOCOM, 1994. Technical Report GIT-CC-93/56, + College of Computing, Georgia Institute of Technology, ATLANTA, + GA 30332-0280, August 1993. + + [3] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: the SIPP + Interoperability and Transition Mechanism, Work in Progress, + November 1993. + + [4] Leiner, B., and Y. Rekhter, "The Multiprotocol Internet", RFC + 1560, USRA, IBM, December 1993. + + [5] McLaughlin, L., "Standard for the Transmission of 802.2 Packets + over IPX Networks", RFC 1132, The Wollongong Group, November + 1989. + + [6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD + 13, RFC 1034, USC/Information Sciences Institute, November 1987. + + + + + + +Clark, Ammar & Calvert [Page 10] + +RFC 1683 Multiprotocol Interoperability In IPng August 1994 + + + [7] Mockapetris, P., "Domain Names - Implementation and + Specification. STD 13, RFC 1035, USC/Information Sciences + Institute, November 1987. + + [8] Padlipsky, M., Gateways, Architectures, and Heffalumps", RFC 875, + MITRE, September 1982. + + [9] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, + USC/Information Sciences Institute, September 1981. + + [10] Provan, D., "Tunneling IPX Traffic Through IP Networks", RFC + 1234, Novell, Inc., June 1991. + + [11] Rose, M., "The Open Book", Prentice-Hall, Englewood Cliffs, New + Jersey, 1990. + + [12] Rose, M., "The ISO Development Environment User's Manual - + Version 7.0.", Performance Systems International, July 1991. + + [13] Rose, M., and D. Cass, "ISO Transport Services on top of the + TCP", STD 35, RFC 1006, Northrop Research and Technology Center, + May 1987. + + [14] Tennenhouse, D., "Layered multiplexing considered harmful", In + IFIP Workshop on Protocols for High-Speed Networks. Elsevier, May + 1989. + + [15] Ullmann, R., "CATNIP: Common architecture technology for next- + generation internet protocol", Work in Progress, October 1993. + +9. Security Considerations + + Security issues are not discussed in this memo. + + + + + + + + + + + + + + + + + + +Clark, Ammar & Calvert [Page 11] + +RFC 1683 Multiprotocol Interoperability In IPng August 1994 + + +10. Authors' Addresses + + Russell J. Clark + College of Computing Georgia Institute of Technology + Atlanta, GA 30332-0280 + + EMail: rjc@cc.gatech.edu + + + Mostafa H. Ammar + College of Computing Georgia Institute of Technology + Atlanta, GA 30332-0280 + + EMail: ammar@cc.gatech.edu + + + Kenneth L. Calvert + College of Computing Georgia Institute of Technology + Atlanta, GA 30332-0280 + + EMail: calvert@cc.gatech.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Clark, Ammar & Calvert [Page 12] + -- cgit v1.2.3