1 files changed, 349 insertions, 0 deletions
diff --git a/doc/rfc/rfc948.txt b/doc/rfc/rfc948.txt
new file mode 100644
index 0000000..e8da5d9
--- /dev/null
+++ b/doc/rfc/rfc948.txt
@@ -0,0 +1,349 @@
+
+
+
+
+
+---------
+
+
+
+< INC-PROJECT, WINSTON-RFC.NLS.6, >, 11-Jun-85 21:31-PDT JBP ;;;;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winston                                                         [Page 0]
+
+
+
+Network Working Group                                        Ira Winston
+Request for Comments: 948                     University of Pennsylvania
+                                                               June 1985
+
+         TWO METHODS FOR THE TRANSMISSION OF IP DATAGRAMS OVER
+                          IEEE 802.3 NETWORKS
+
+
+Status of this Memo
+
+   This memo describes two methods of encapsulating Internet
+   Protocol (IP) [1] datagrams on an IEEE 802.3 network [2].  This RFC
+   suggests a proposed protocol for the ARPA-Internet community, and
+   requests discussion and suggestions for improvements.  Distribution
+   of this memo is unlimited.
+
+Introduction
+
+   The IEEE 802 project has defined a family of standards for Local Area
+   Networks (LANs) that deals with the Physical and Data Link Layers as
+   defined by the ISO Open System Interconnection Reference Model
+   (ISO/OSI).  Several Physical Layer standards (802.3, 802.4, and
+   802.5) [2, 3, 4] and one Data Link Layer Standard (802.2) [5] have
+   been defined.  The IEEE Physical Layer standards specify the ISO/OSI
+   Physical Layer and the Media Access Control Sublayer of the ISO/OSI
+   Data Link Layer.  The 802.2 Data Link Layer standard specifies the
+   Logical Link Control Sublayer of the ISO/OSI Data Link Layer.
+
+   The 802.3 standard is based on the Ethernet Version 2.0 standard [6].
+   The Ethernet Physical Layer and the 802.3 Physical Layer are
+   compatible for all practical purposes however, the Ethernet Data Link
+   Layer and the 802.3/802.2 Data Link Layer are incompatible.
+
+   There are many existing Ethernet network installations that transmit
+   IP datagrams using the Ethernet compatible standard described in [7].
+   IEEE 802.3 Physical Layer compatible connections can be added to
+   these networks using an an Ethernet Data Link Layer compatible method
+   for transmitting IP datagrams without violating the 802.3 standard.
+   Alternatively, an 802.2/802.3 Data Link Layer compatible method for
+   transmitting IP datagrams can be used.
+
+Ethernet Compatible Method
+
+   IEEE 802.3 networks must use 48-bit physical addresses and 10
+   megabit/second bandwidth in order to be Ethernet compatible.
+
+   The IEEE 802.3 packet header is identical to Ethernet packet header
+   except for the meaning assigned to one of the fields in the header.
+   In an Ethernet packet header this field is used as a protocol type
+   field and in an 802.3 packet header the field is used as a length
+   field.  The maximum allowed length field value on a 10 megabit/second
+
+
+Winston                                                         [Page 1]
+
+
+
+RFC 948                                                        June 1985
+Transmission of IP Datagrams Over IEEE 802.3 Networks
+
+
+   802.3 network is 1500.  The 802.3 standard states that packets with a
+   length field greater than the maximum allowed length field may be
+   ignored, discarded, or used in a private manner.  Therefore, the
+   length field can be used in a private manner as a protocol type field
+   as long as the protocol types being used are greater than 1500.  The
+   protocol type for IP, ARP and trailer encapsulation are all greater
+   than 1500.  Using this technique, the method for transmitting IP
+   datagrams on Ethernet networks described in [7] can be used to
+   transmit IP datagrams on IEEE 802.3 networks in an Ethernet
+   compatible manner.
+
+IEEE 802.2/802.3 Compatible Method
+
+   Frame Format
+
+      IP datagrams are transmitted in standard 802.2/802.3 LLC Type 1
+      Unnumbered Information format with the DSAP and SSAP fields of the
+      802.2 header set to 96, the IEEE assigned global SAP value for
+      IP [8].  The data field contains the IP header followed
+      immediately by the IP data.
+
+      IEEE 802.3 packets have minimum size restrictions based on network
+      bandwidth.  When necessary, the data field should be padded (with
+      octets of zero) to meet the 802.3 minimum frame size requirements.
+      This padding is not part of the IP packet and is not included in
+      the total length field of the IP header.
+
+      IEEE 802.3 packets have maximum size restrictions based on the
+      network bandwidth.  Implementations are encouraged to support
+      full-length packets.
+
+         Gateway implementations MUST be prepared to accept full-length
+         packets and fragment them when necessary.
+
+         Host implementations should be prepared to accept full-length
+         packets, however hosts MUST NOT send datagrams longer than 576
+         octets unless they have explicit knowledge that the destination
+         is prepared to accept them.  A host may communicate its size
+         preference in TCP based applications via the TCP Maximum
+         Segment Size option [9].
+
+      Note:  Datagrams on 802.3 networks may be longer than the general
+      Internet default maximum packet size of 576 octets.  Hosts
+      connected to an 802.3 network should keep this in mind when
+      sending datagrams to hosts not on the same 802.3 network.  It may
+
+
+
+
+Winston                                                         [Page 2]
+
+
+
+RFC 948                                                        June 1985
+Transmission of IP Datagrams Over IEEE 802.3 Networks
+
+
+      be appropriate to send smaller datagrams to avoid unnecessary
+      fragmentation at intermediate gateways.  Please see [9] for
+      further information on this point.
+
+   Address Mappings
+
+      The mapping of 32-bit Internet addresses to 16-bit or 48-bit 802.3
+      addresses can be done in several ways.  A static table could be
+      used, or a dynamic discovery procedure could be used.
+
+      Static Table
+
+         Each host could be provided with a table of all other hosts on
+         the local network with both their 802.3 and Internet addresses.
+
+      Dynamic Discovery
+
+         Mappings between 32-bit Internet addresses and 802.3 addresses
+         could be accomplished through a protocol similar to the
+         Ethernet Address Resolution Protocol (ARP) [10].  Internet
+         addresses are assigned arbitrarily on some Internet networks.
+         Each host's implementation must know its own Internet address
+         and respond to 802.3 Address Resolution packets appropriately.
+         It should also use ARP to translate Internet addresses to 802.3
+         addresses when needed.
+
+      Broadcast Address
+
+         The broadcast Internet address (the address on that network
+         with a host part of all binary ones) should be mapped to the
+         broadcast 802.3 address (of all binary ones).
+
+         The use of the ARP dynamic discovery procedure is strongly
+         recommended.
+
+   Trailer Formats
+
+      Some versions of Unix 4.2bsd use a different encapsulation method
+      in order to get better network performance with the VAX virtual
+      memory architecture.  Consenting systems on the same 802.3 network
+      may use this format between themselves.  Details of the trailer
+      encapsulation method may be found in [11].
+
+
+
+
+
+
+
+Winston                                                         [Page 3]
+
+
+
+RFC 948                                                        June 1985
+Transmission of IP Datagrams Over IEEE 802.3 Networks
+
+
+   Byte Order
+
+      As described in Appendix B of the Internet Protocol specification
+      [1], the IP datagram is transmitted over 802.2/802.3 networks as a
+      series of 8-bit bytes.
+
+Conclusion
+
+   The two encapsulation methods presented can be mixed on the same
+   local area network; however, this would partition the network into
+   two incompatible subnetworks.  One host on a network could support
+   both methods and act as a gateway between the two subnetworks;
+   however, this would introduce a significant performance penalty and
+   should be avoided.
+
+   The IEEE 802.2/802.3 compatible encapsulation method is preferable to
+   the Ethernet compatible method because the IEEE 802.2 and IEEE 802.3
+   standards have been accepted both nationally and internationally and
+   because the same encapsulation method could be used on other IEEE 802
+   Physical Layer implementations.  However, there are many existing
+   installations that are using IP on Ethernet and a controlled
+   transition from Ethernet to IEEE 802.2/802.3 is necessary.
+
+   To this end, all new implementations should allow for a static choice
+   of encapsulation methods and all existing implementations should be
+   modified to provide this static choice as well.  During the
+   transition, all hosts on the same network would use the Ethernet
+   compatible method.  After 802.2/802.3 support has been added to all
+   existing implementations, the IEEE 802.2/802.3 method would be used
+   and the transition would be complete.
+
+References
+
+   [1]  Postel, J.  "Internet Protocol".  RFC-791, USC/Information
+        Sciences Institute, September 1981.
+
+   [2]  The Institute of Electronics and Electronics Engineers, Inc.
+        "IEEE Standards for Local Area Networks: Carrier Sense Multiple
+        Access with Collision Detection (CSMA/CD) Access Method and
+        Physical Layer Specifications".  The Institute of Electronics
+        and Electronics Engineers, Inc., New York, New York, 1985.
+
+   [3]  The Institute of Electronics and Electronics Engineers, Inc.
+        "IEEE Standards for Local Area Networks: Token-Passing Bus
+        Access Method and Physical Layer Specifications".  The Institute
+        of Electronics and Electronics Engineers, Inc., New York, New
+        York, 1985.
+
+
+Winston                                                         [Page 4]
+
+
+
+RFC 948                                                        June 1985
+Transmission of IP Datagrams Over IEEE 802.3 Networks
+
+
+   [4]  The Institute of Electronics and Electronics Engineers, Inc.
+        "IEEE Standards for Local Area Networks: Token Ring Access
+        Method and Physical Layer Specifications".  The Institute of
+        Electronics and Electronics Engineers, Inc., New York, New York,
+        1985.
+
+   [5]  The Institute of Electronics and Electronics Engineers, Inc.
+        "IEEE Standards for Local Area Networks: Logical Link Control".
+        The Institute of Electronics and Electronics Engineers, Inc.,
+        New York, New York, 1985.
+
+   [6]  "The Ethernet, Physical and Data Link Layer Specifications,
+        Version 2.0".  Digital Equipment Corporation, Intel Corporation,
+        and Xerox Corporation, 1982.
+
+   [7]  Hornig, C.  "A Standard for the Transmission of IP Datagrams
+        over Ethernet Networks".  RFC-894, Symbolics Cambridge Research
+        Center, April 1984.
+
+   [8]  Reynolds, J., and Postel, J.  "Assigned Numbers".  RFC-943,
+        USC/Information Sciences Institute, April 1985.
+
+   [9]  Postel, J.  "The TCP Maximum Segment Size Option and Related
+        Topics".  RFC-879, USC/Information Sciences Institute,
+        November 1983.
+
+   [10] Plummer, D.  "An Ethernet Address Resolution Protocol".
+        RFC-826, Symbolics Cambridge Research Center, November 1982.
+
+   [11] Leffler, S., and Karels, M.  "Trailer Encapsulations".  RFC-893,
+        University of California at Berkeley, April 1984.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winston                                                         [Page 5]
+
+\ No newline at end of file