summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc894.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc894.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc894.txt')
-rw-r--r--doc/rfc/rfc894.txt171
1 files changed, 171 insertions, 0 deletions
diff --git a/doc/rfc/rfc894.txt b/doc/rfc/rfc894.txt
new file mode 100644
index 0000000..d5cd5eb
--- /dev/null
+++ b/doc/rfc/rfc894.txt
@@ -0,0 +1,171 @@
+
+
+Network Working Group Charles Hornig
+Request for Comments: 894 Symbolics Cambridge Research Center
+ April 1984
+
+ A Standard for the Transmission of IP Datagrams over Ethernet Networks
+
+
+Status of this Memo
+
+ This RFC specifies a standard method of encapsulating Internet
+ Protocol (IP) [1] datagrams on an Ethernet [2]. This RFC specifies a
+ standard protocol for the ARPA-Internet community.
+
+Introduction
+
+ This memo applies to the Ethernet (10-megabit/second, 48-bit
+ addresses). The procedure for transmission of IP datagrams on the
+ Experimental Ethernet (3-megabit/second, 8-bit addresses) is
+ described in [3].
+
+Frame Format
+
+ IP datagrams are transmitted in standard Ethernet frames. The type
+ field of the Ethernet frame must contain the value hexadecimal 0800.
+ The data field contains the IP header followed immediately by the IP
+ data.
+
+ The minimum length of the data field of a packet sent over an
+ Ethernet is 46 octets. If necessary, the data field should be padded
+ (with octets of zero) to meet the Ethernet minimum frame size. This
+ padding is not part of the IP packet and is not included in the total
+ length field of the IP header.
+
+ The minimum length of the data field of a packet sent over an
+ Ethernet is 1500 octets, thus the maximum length of an IP datagram
+ sent over an Ethernet is 1500 octets. Implementations are encouraged
+ to support full-length packets. Gateway implementations MUST be
+ prepared to accept full-length packets and fragment them if
+ necessary. If a system cannot receive full-length packets, it should
+ take steps to discourage others from sending them, such as using the
+ TCP Maximum Segment Size option [4].
+
+ Note: Datagrams on the Ethernet may be longer than the general
+ Internet default maximum packet size of 576 octets. Hosts connected
+ to an Ethernet should keep this in mind when sending datagrams to
+ hosts not on the same Ethernet. It may be appropriate to send
+ smaller datagrams to avoid unnecessary fragmentation at intermediate
+ gateways. Please see [4] for further information on this point.
+
+
+
+
+
+Hornig [Page 1]
+
+
+
+RFC 894 April 1984
+
+
+Address Mappings
+
+ The mapping of 32-bit Internet addresses to 48-bit Ethernet addresses
+ can be done 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 Ethernet and Internet addresses.
+
+ Dynamic Discovery
+
+ Mappings between 32-bit Internet addresses and 48-bit Ethernet
+ addresses could be accomplished through the Address Resolution
+ Protocol (ARP) [5]. Internet addresses are assigned arbitrarily
+ on some Internet network. Each host's implementation must know
+ its own Internet address and respond to Ethernet Address
+ Resolution packets appropriately. It should also use ARP to
+ translate Internet addresses to Ethernet 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
+ Ethernet address (of all binary ones, FF-FF-FF-FF-FF-FF hex).
+
+ 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 Ethernet may use this
+ format between themselves.
+
+ No host is required to implement it, and no datagrams in this format
+ should be sent to any host unless the sender has positive knowledge
+ that the recipient will be able to interpret them. Details of the
+ trailer encapsulation may be found in [6].
+
+ (Note: At the present time Unix 4.2bsd will either always use
+ trailers or never use them (per interface), depending on a boot-time
+ option. This is expected to be changed in the future. Unix 4.2bsd
+ also uses a non-standard Internet broadcast address with a host part
+ of all zeroes, this may also be changed in the future.)
+
+
+
+Hornig [Page 2]
+
+
+
+RFC 894 April 1984
+
+
+Byte Order
+
+ As described in Appendix B of the Internet Protocol
+ specification [1], the IP datagram is transmitted over the Ethernet
+ as a series of 8-bit bytes.
+
+References
+
+ [1] Postel, J., "Internet Protocol", RFC-791, USC/Information
+ Sciences Institute, September 1981.
+
+ [2] "The Ethernet - A Local Area Network", Version 1.0, Digital
+ Equipment Corporation, Intel Corporation, Xerox Corporation,
+ September 1980.
+
+ [3] Postel, J., "A Standard for the Transmission of IP Datagrams
+ over Experimental Ethernet Networks", RFC-895, USC/Information
+ Sciences Institute, April 1984.
+
+ [4] Postel, J., "The TCP Maximum Segment Size Option and Related
+ Topics", RFC-879, USC/Information Sciences Institute, November 1983.
+
+ [5] Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826,
+ Symbolics Cambridge Research Center, November 1982.
+
+ [6] Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893,
+ University of California at Berkeley, April 1984.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornig [Page 3]
+