|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
||||||
|
IETF RFC 895
Standard for the transmission of IP datagrams over experimental Ethernet networks Last modified on Wednesday, September 23rd, 1992 Permanent link to RFC 895 Search GitHub Wiki for RFC 895 Show other RFCs mentioning RFC 895 Network Working Group Jon Postel Request for Comments: 895 ISI April 1984 A Standard for the Transmission of IP Datagrams over Experimental Ethernet Networks Status of this Memo This RFC specifies a standard method of encapsulating Internet Protocol (IP) [1] datagrams on an Experimental Ethernet [2]. This RFC specifies a standard protocol for the ARPA Internet community. Introduction This memo applies to the Experimental Ethernet (3-megabit/second, 8-bit addresses). The procedure for transmission of IP datagrams on the Ethernet (10-megabit/second, 48-bit addresses) is described in [3]. Frame Format IP datagrams are transmitted in standard Experimental Ethernet frames. The type field of the Ethernet frame must contain the value 513 (1001 octal). The data field contains the IP header followed immediately by the IP data. If necessary, the data field should be padded to meet the Experimental 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 maximum length of an IP datagram sent over an Experimental Ethernet is 1536 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. Postel PAGE 1 |