summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1683.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1683.txt')
-rw-r--r--doc/rfc/rfc1683.txt675
1 files changed, 675 insertions, 0 deletions
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]
+