Multiprotocol Interoperability In IPng
RFC 1683

Document Type RFC - Informational (August 1994; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1683 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
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

             +-----------------------------------+
Show full document text