home *** CD-ROM | disk | FTP | other *** search
/ Amiga ISO Collection / AmigaDemoCD2.iso / ASCII / TEXTE / TheInternet / MoreTechnical / rfc0894.txt < prev    next >
Encoding:
Text File  |  1994-06-09  |  5.6 KB  |  172 lines
  1.  
  2.  
  3. Network Working Group                                     Charles Hornig
  4. Request for Comments: 894            Symbolics Cambridge Research Center
  5.                                                               April 1984
  6.  
  7.  A Standard for the Transmission of IP Datagrams over Ethernet Networks
  8.  
  9.  
  10. Status of this Memo
  11.  
  12.    This RFC specifies a standard method of encapsulating Internet
  13.    Protocol (IP) [1] datagrams on an Ethernet [2].  This RFC specifies a
  14.    standard protocol for the ARPA-Internet community.
  15.  
  16. Introduction
  17.  
  18.    This memo applies to the Ethernet (10-megabit/second, 48-bit
  19.    addresses).  The procedure for transmission of IP datagrams on the
  20.    Experimental Ethernet (3-megabit/second, 8-bit addresses) is
  21.    described in [3].
  22.  
  23. Frame Format
  24.  
  25.    IP datagrams are transmitted in standard Ethernet frames.  The type
  26.    field of the Ethernet frame must contain the value hexadecimal 0800.
  27.    The data field contains the IP header followed immediately by the IP
  28.    data.
  29.  
  30.    The minimum length of the data field of a packet sent over an
  31.    Ethernet is 46 octets.  If necessary, the data field should be padded
  32.    (with octets of zero) to meet the Ethernet minimum frame size.  This
  33.    padding is not part of the IP packet and is not included in the total
  34.    length field of the IP header.
  35.  
  36.    The minimum length of the data field of a packet sent over an
  37.    Ethernet is 1500 octets, thus the maximum length of an IP datagram
  38.    sent over an Ethernet is 1500 octets.  Implementations are encouraged
  39.    to support full-length packets.  Gateway implementations MUST be
  40.    prepared to accept full-length packets and fragment them if
  41.    necessary.  If a system cannot receive full-length packets, it should
  42.    take steps to discourage others from sending them, such as using the
  43.    TCP Maximum Segment Size option [4].
  44.  
  45.    Note:  Datagrams on the Ethernet may be longer than the general
  46.    Internet default maximum packet size of 576 octets.  Hosts connected
  47.    to an Ethernet should keep this in mind when sending datagrams to
  48.    hosts not on the same Ethernet.  It may be appropriate to send
  49.    smaller datagrams to avoid unnecessary fragmentation at intermediate
  50.    gateways.  Please see [4] for further information on this point.
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Hornig                                                          [Page 1]
  57.  
  58.  
  59.  
  60. RFC 894                                                       April 1984
  61.  
  62.  
  63. Address Mappings
  64.  
  65.    The mapping of 32-bit Internet addresses to 48-bit Ethernet addresses
  66.    can be done several ways.  A static table could be used, or a dynamic
  67.    discovery procedure could be used.
  68.  
  69.    Static Table
  70.  
  71.       Each host could be provided with a table of all other hosts on the
  72.       local network with both their Ethernet and Internet addresses.
  73.  
  74.    Dynamic Discovery
  75.  
  76.       Mappings between 32-bit Internet addresses and 48-bit Ethernet
  77.       addresses could be accomplished through the Address Resolution
  78.       Protocol (ARP) [5].  Internet addresses are assigned arbitrarily
  79.       on some Internet network.  Each host's implementation must know
  80.       its own Internet address and respond to Ethernet Address
  81.       Resolution packets appropriately.  It should also use ARP to
  82.       translate Internet addresses to Ethernet addresses when needed.
  83.  
  84.    Broadcast Address
  85.  
  86.       The broadcast Internet address (the address on that network with a
  87.       host part of all binary ones) should be mapped to the broadcast
  88.       Ethernet address (of all binary ones, FF-FF-FF-FF-FF-FF hex).
  89.  
  90.    The use of the ARP dynamic discovery procedure is strongly
  91.    recommended.
  92.  
  93. Trailer Formats
  94.  
  95.    Some versions of Unix 4.2bsd use a different encapsulation method in
  96.    order to get better network performance with the VAX virtual memory
  97.    architecture.  Consenting systems on the same Ethernet may use this
  98.    format between themselves.
  99.  
  100.    No host is required to implement it, and no datagrams in this format
  101.    should be sent to any host unless the sender has positive knowledge
  102.    that the recipient will be able to interpret them.  Details of the
  103.    trailer encapsulation may be found in [6].
  104.  
  105.    (Note:  At the present time Unix 4.2bsd will either always use
  106.    trailers or never use them (per interface), depending on a boot-time
  107.    option.  This is expected to be changed in the future.  Unix 4.2bsd
  108.    also uses a non-standard Internet broadcast address with a host part
  109.    of all zeroes, this may also be changed in the future.)
  110.  
  111.  
  112.  
  113. Hornig                                                          [Page 2]
  114.  
  115.  
  116.  
  117. RFC 894                                                       April 1984
  118.  
  119.  
  120. Byte Order
  121.  
  122.    As described in Appendix B of the Internet Protocol
  123.    specification [1], the IP datagram is transmitted over the Ethernet
  124.    as a series of 8-bit bytes.
  125.  
  126. References
  127.  
  128.    [1]  Postel, J., "Internet Protocol", RFC-791, USC/Information
  129.    Sciences Institute, September 1981.
  130.  
  131.    [2]  "The Ethernet - A Local Area Network", Version 1.0, Digital
  132.    Equipment Corporation, Intel Corporation, Xerox Corporation,
  133.    September 1980.
  134.  
  135.    [3]  Postel, J., "A Standard for the Transmission of IP Datagrams
  136.    over Experimental Ethernet Networks", RFC-895, USC/Information
  137.    Sciences Institute, April 1984.
  138.  
  139.    [4]  Postel, J., "The TCP Maximum Segment Size Option and Related
  140.    Topics", RFC-879, USC/Information Sciences Institute, November 1983.
  141.  
  142.    [5]  Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826,
  143.    Symbolics Cambridge Research Center, November 1982.
  144.  
  145.    [6]  Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893,
  146.    University of California at Berkeley, April 1984.
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Hornig                                                          [Page 3]
  171.  
  172.