[Top] [All Lists]

Delayed in the mail

1992-04-02 14:22:47

Given the sudden and extreme relevance of the topic, Jordan and I
had hoped to get the enclosed published quickly, but it appears that
some technical difficulties, particularly concerning the handling of
IP addresses at two different levels, are causing delays.  Further,
there is some possibility that our use of software conforming to
the enclosed spec may have delayed the spec "in the mail."  We may
need to follow-up with a specification for the MIB variables needed
to diagnose such a problem.

We are interested in getting widespread review of our proposal and
encourage you to pass it on freely.  Feedback is welcome.


Network Working Group                                           J. Brown
Request for Comments: ipovermts               Quarterdeck Office Systems
                                                              D. Crocker 
                                                       The Branch Office
                                                           April 1, 1992

     The Transmission of IP Datagrams over Message Transfer Service

Status of this Memo

   This memo defines a protocol for the transmission of IP datagrams
   over a Message Transfer Service network, configured as a logical
   IP subnetwork.  This RFC specifies an IAB Proposed Instantaneous 
   Standard protocol for the Internet community.  High demand for this 
   feature precludes the normal period of open discussion and review.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.


   This memo describes use of IP over the extended, asynchronous Internet
   messaging service environment, configured as a logical IP subnetwork.
   The encapsulation method used is described, as well as various
   service-specific issues and expected performance and operations issues.
   This document considers only directly connected IP end-stations or
   routers which are part of the Internet Message Transfer Service, in
   which the Message Transfer Service provides extended, high-latency
   sub-network functionality, for all sites using the Internet standard
   message object formats.

   Issues raised by MAC level bridging are beyond the scope of
   this paper.


   This memo draws heavily in both concept and text from specifications for
   similar IP mappings, specifically [3], written by Dave Piscitello and 
   Joseph Lawrence of Bell Communications Research, [4], written by Jon 
   J Postel and Joyce K. Reynolds of ISI and [5], written by David Katz of 
   Merit, Inc.  The authors would also like to acknowledge the contributions 
   of the staff of the Hilton Queen.


   The following language conventions are used in the items of
   specification in this document:

      o MUST, SHALL, or MANDATORY -- the item is an absolute
        requirement of the specification.

Brown & Crocker                                                      [Page 1]
RFC ipovermts                    IP over MTS                       April 1992

      o SHOULD or RECOMMENDED -- the item should generally be followed
        for all but exceptional circumstances.

      o MAY or OPTIONAL -- the item is truly optional and may be
        followed or ignored according to the needs of the implementor.


   The goal of this specification is to allow compatible and interoperable
   implementations for transmitting IP datagrams, over an extended
   Internet, through the use of its existing MTS.

   The characteristics of the Internet Message Transfer Services are
   presented in [2], [6], and [7].  While use of the Internet MTS has
   been primarily limited to human-to-human communication, there is
   increasing interest in its natural extension, to be used for inter-
   process communication, often called "mail-enabled applications."  This 
   specification provides a well-defined mechanism for permitting such

   Briefly, MTSs offer connectionless, public, datagram-switched
   service.  The operation and features of these services are similar
   to those found in other, classic, packet-switched data networks of
   LANs and WANs:

      o They provide a datagram packet transfer, where each data unit is
        handled and switched separately without the prior establishment of
        a network connection.

      o They exhibit high delay and low throughput, and provide the
        transparent transport and delivery of up to 64K or more octets of
        user information in a single transmission, with only moderate

      o No explicit flow control mechanisms are provided, but substantial
        buffering is available in most MAC-level bridges, in this case
        appearing as Message Transfer Agents (MTAs), having extremely 
        large amounts of under-utilized storage.

      o Both individually and group-addressed (multicast) packets can
        be transferred.

      o Internet MTS address syntax varies, but is represented by a
        variable-length "mailbox" field, a delimiting octet, and a
        variable-length "hostname" field.  The mailbox and hostname fields
        may be composed of octets with values from 33 to 126; see [2] and
        [7] for the exact rules.  The delimiting octet will generally
        have a value of 64, but 37 and 33 are also used.  Interpretation
        of the hostname field is global and the mailbox string has
        private interpretation by the host referenced in the hostname.

Brown & Crocker                                                      [Page 2]
RFC ipovermts                    IP over MTS                       April 1992

   Internet MTS implementations operate over a wide range of platforms
   and underlying protocols.  The common, integrating layer of
   functionality is specified in [2], with underlying connectivity
   provided, for example, by systems utilizing [7] or [6].
   As a consequence, this specification permits an immediate and very
   substantial increase in the "reach" of the Internet.  Examples of
   the resulting stack of services are illustrated in Figure 1:

                         |          IP          |
                         |         MIME         |
                         |        RFC-822       |
                         |  Local Mail Service  |
                         |    UUX    |   SMTP   |
                         |   UUCP    |  TCP/IP  |
                         |  RS-232   |   Ether  |

         Figure 1.  Protocol stack for IP over Message Transfer Service

   This memo describes use of IP over an extended Internet MTS
   environment configured as a logical IP subnetwork.  Issues
   related to transparent data link layer interoperability of
   multi-stack MTSs such as [20] are beyond the scope of this


   o As the logical network defined by an MTS is not bounded by physical IP
     network topologies, IP addresses may be assigned without regard for
     the actual real-time connectivity.  This "hypernet" concept dramatically
     eases the current "address space crunch" - since the entire
     mail-connected Internet, with its thousands of component subnetworks
     can now be represented as a single IP subnet, a handfull of Class A
     network numbers would handle expected growth for several years.  Note
     that unlike current "supernet" proposals, this mechanism does not
     require any changes in the Internet routing protocols.

   o Historically, electronic mail reliability has been fair to poor.  IP 
     over MTS resolves this concern.  Electronic mail over TCP/IP over the 
     MTS, means that a message is transmitted via SMTP and TCP.  Since IP 
     is typically over otherwise unreliable links, TCP retransmission and 
     acknowledgement are automatically provided.  Hence, this permits the use 
     of email, to improve the reliability of email.

   o The multicast services provided are ideally suited for multimedia
     teleconferencing, though due to the transmission characteristics of
     the interface audio may be somewhat bursty.

Brown & Crocker                                                      [Page 3]
RFC ipovermts                    IP over MTS                       April 1992

   o For sites not directly attached to the IP Internet, such as the vast
     array of uucp sites, multi-hop file transfer, via FTP or rcp, is
     made conveniently accessible.

   o This proposal suggests a natural resolution to the heated debate over
     remote procedure call, versus message-queueing inter-process, 
     communication.  This proposal specifies a synchronous -- i.e., 
     RPC-oriented -- mechanism which operates over a fundamentally
     message-queuing service.

Packet Format

      Service SHALL be encapsulated using the MIME message encapsulation
      described in [8].  This memo describes systems based on [2].

      Considerably more extensive connectivity is possible, via gateway
      techniques, to the various commercial and LAN-based proprietary MTSs.
      Specification of MTS-level format-translation, serving the functional
      role of MAC-bridging, is beyond the scope of this document.  Further,
      it seems feasible to contemplate interoperation with messaging based
      upon different hardware technologies, such as postal.  However, the
      likelihood of excessive data corruption due to issues such as
      scanner error rates renders this capability a research topic for
      further study.

      The header mechanism described in [2] allows for a very rich set of
      routing and delivery options.  The basic format allows for MAC-level
      route tracing and performance monitoring, uni- and multi-cast
      messages, unique packet identifiers, and fully extensible user-defined
      fields.  Commonly available implementations [9] include extensions
      for MAC-level acknowledgments, packet prioritization, and error 
      checking. However, such facilities are not yet standardized for the 

      The following fields are required:  To, From, and Date.

                    Content-type: Message/IP
                    Content-transfer-encoding:  hex64
                    <blank line>
                    [Hex-encoded MIME-based version of a single
                     IP datagram]

                    Figure 2.  Data Link Encapsulation

      o The mailbox portion of the values of To and From in the Header
        are "IPoverMTSlink".  Additional aggregate throughput may be
        achieved by the exercise of multiple paths, with different
        mailbox addresses.  However, the specification in this document
        relies upon a single, standard mailbox reference, as is typical
        for other link-level Type protocol identifiers.

Brown & Crocker                                                      [Page 4]
RFC ipovermts                    IP over MTS                       April 1992

      o The total length of the header is variable.  The header is
        terminated by the first instance of the byte sequence 0D, 0A,
        0D, 0A encountered in the packet, as discussed in [2].

      o The choice of specific Content-Transfer-Encoding algorithm is at
        the option of the sender, within the limits of registered
        encoding types and the expected facilities of the recipients. 
        However, the IP context generally is viewed as fully binary, so 
        that Hex64 is the most natural choice.

      o The use of MIME message structuring suggests IP data aggregation
        through a Content-Type of Multi-part, thereby allowing datagram
        "bagging", but the use of such a capability is viewed as an
        enhancement beyond the scope of the current specification.

   A typical data link encapsulation for IP packets is shown in Figure 3.
   All values shown are in Internet NVT ASCII.

        Received:           from localhost by;
                            01 April 1992 1200 +0800
        To:                 ipovermtslink(_at_)mordor(_dot_)stanford(_dot_)edu
        From:               ipovermtslink(_at_)qdeck(_dot_)com
        Date:               01 April 1992 1200 +0800
        Return-Receipt-To:  ip-ack(_at_)qdeck(_dot_)com

             Figure 3.  IP Data Link Encapsulation and Values

   The Figure shows use of the popular, but non-standardized 
   Return-Receipt-To feature available in some MTSs.  This feature
   increases the reliability level of the MTS at the link-level, by
   making detection of delivery failure possible.  This allows the
   option of re-transmission.  It should be noted, however, that support
   for this capability is not universal, thereby suggesting that
   the safest operational model is of the MTS as an unreliable
   and unacknowledged datagram environment.

Address Resolution

   The dynamic mapping of 32-bit Internet addresses to MTS addresses SHOULD
   be done via the reverse address mapping facility of the Domain Name
   System [10].  This IN-ADDR facility produces only a host reference;
   hence this specification has a single, fixed choice for the mailbox
   portion of a reference.  Use of any other mailbox string would
   require prior arrangement among the participating hosts, as well as
   static address mapping tables.

   Each host implementation MUST know its own Internet address and MTS

Brown & Crocker                                                      [Page 5]
RFC ipovermts                    IP over MTS                       April 1992

IP Broadcast Address

   While the MTS environment supports explicit multicast, there is no
   facility for complete broadcast addressing.  However, it is advised
   that there be exploration in the use of features in [18] and [19] to
   provide a relatively efficient broadcast mechanism.

IP Multicast Support

   Source multicast - As the destination field is allowed to contain
   multiple addresses, the source may trivially send a single packet to
   numerous recipients.

   Group multicast - Depending upon the facilities of the underlying MTS,
   hosts may join logical "mailing lists" which provide a single MTS
   address which "explodes" to target numerous "real" MTS addresses,
   and this can be taken to any number of levels.  The mapping of IP
   multicast addresses (Class D) to specific MTS mailing lists will
   initially require private lookup tables.  Development of automated,
   distributed registration and lookup facilities is for further study.

Trailer Formats

   Some versions of Unix 4.x BSD use a different encapsulation method in
   order to get better network performance with the VAX virtual memory
   architecture.  Trailers SHALL not be used over the MTS.

Byte Order

   As described in Appendix B of the Internet Protocol specification
   [1], the IP datagram is transmitted over the MT Service as a series
   of 8-bit bytes (octets).  The network byte order of the IP datagram 
   shall be mapped directly onto the native MT byte order.

MAC Sublayer Details

Packet Size

   [11] defines a a minimum maximum service data unit size of 65536
   octets.  This leaves about 65000 octets for user data after the
   RFC-822 and MIME headers are taken into account.  Individual MTSes
   may define higher limits, and many do.

   Transmission of large IP datagrams may require use of IP fragmentation
   or MIME Multipart/partial.  The choice between the use of these two
   options is at the option of the sender.  It should be noted, however,
   that use of link-level fragmentation techniques, as long as they
   permit in-order reassembly of the data, have the benefit of increased
   efficiency, due to reduced memory and bandwidth requirements, since they
   do not result in the presence of the IP header in each fragment.

Brown & Crocker                                                      [Page 6]
RFC ipovermts                    IP over MTS                       April 1992

   There is no minimum packet size restriction defined for the MTS.


   It should be noted that proposed enhancements to TCP are designed to
   increase throughput over high-delay channels.  It is expected the IP 
   over MTS will provide a rich opportunity for use of these enhancements.

Other MAC Sublayer Issues

   The MTS requires that the publicly administered host name plus mailbox
   name SHALL be used in both source and destination address fields of
   the RFC-822 header [2].


    1. Postel, J., "Internet Protocol", RFC 791, USC/Information
       Sciences Institute, September 1981.

    2. Crocker, D. "ARPA Internet Text Messages", RFC 822, Univ of Delaware,
       August 1982.

    3. Piscitello, D., and J. Lawrence, "The Transmission of IP Datagrams
       over the SMDS Service", RFC 1209, Bell Communications Research,
       March 1991.

    4. Postel, J., and J. Reynolds, "A Standard for the Transmission of
       IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information
       Sciences Institute, February 1988.

    5. Katz, D., "A Proposed Standard for the Transmission of IP
       Datagrams over FDDI Networks", RFC 1188, Merit/NSFNET, October

    6. Postel, Jonathan, "Simple Mail Transfer Protocol", RFC 821,
       USC/Information Sciences Institute, August 1982.

    7. Horton, Mark, "UUCP Mail Interchange Format Standard", RFC 976, Bell
       Laboratories, February 1986.

    8. Borenstein, N. and Freed, N., "MIME (Multipurpose Internet Mail 
       Extensions):  Mechanisms for Specifying and Describing the Format
       of Internet Message Bodies", Internet Draft, USC/Information
       Sciences Institute, February 1992.

    9. Allman, Eric, "Mail Systems and Addressing in 4.2bsd",
       USENIX Proceedings, January 1983.

   10. Mockapetris, P.V.  "Domain names - implementation and specification",
       USC/Information Sciences Institute, November 1987.

   11. Braden, R.T., "Requirements for Internet hosts - application and
       support", RFC 1123, USC/Information Sciences Institute,  October 1989.

Brown & Crocker                                                      [Page 7]
RFC ipovermts                    IP over MTS                       April 1992

   12. Reynolds, J.K.  "Helminthiasis of the Internet", RFC 1135,
       USC/Information Sciences Institute, December 1989.

   13. Linn, J.  "Privacy enhancement for Internet electronic mail: Part 
       III - algorithms, modes, and identifiers [Draft]", RFC 1115,  
       August 1989.

   14. Kent, S.T.; Linn, J.  "Privacy enhancement for Internet electronic 
       mail:  Part II - certificate-based key management [Draft]", RFC 1114,
       August 1989.

   15. Linn, J.  "Privacy enhancement for Internet electronic mail: Part I - 
       message encipherment and authentication procedures [Draft]", RFC 1113,
       August 1989.

   16. This citation intentionally left blank.

   17. This citation intentionally left blank.

   18. Horton, M.R. and R. Adams, "Standard for interchange of USENET
       messages", RFC 1036, December 1987.

   19. Kantor, B. and Lapsley, P.  "Network News Transfer Protocol", RFC
       977, February 1986.

   20. Schicker, Pietro, "Message Handling Systems, X.400", Message
       Handling Systems and Distributed Applications, E. Stefferud,
       O-j. Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp.3-41.

Security Considerations

   As the insecurity of MTSes is well-known [12], this should be considered
   to be an insecure transport service.  Additional layers [13,14,15] can be
   interposed, however, to substantially improve the situation.  The details
   of such extensions are not discussed in this memo.

Authors' Addresses

   Jordan Brown
   Quarterdeck Office Systems
   150 Pico Blvd
   Santa Monica, CA 90405

   Phone: +1 310 314 4260
   EMail: jbrown(_at_)qdeck(_dot_)com

   David H. Crocker
   The Branch Office
   675 Spruce Dr.
   Sunnyvale, CA

   Phone: +1 408 246 8253
   EMail: dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu

Brown & Crocker                                                      [Page 8]

<Prev in Thread] Current Thread [Next in Thread>
  • Delayed in the mail, Dave Crocker <=