Folks,
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.
Dave
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.
Abstract
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.
Acknowledgment
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.
Conventions
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.
Introduction
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
activity.
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
reliability.
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
specification.
Advantages
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
Internet.
The following fields are required: To, From, and Date.
To:
From:
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 qdeck.com;
for
ipovermtslink(_at_)mordor(_dot_)stanford(_dot_)edu;
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
address.
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.
Performance
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].
REFERENCES
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
1990.
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]