rfc1042.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 843 行 · 第 1/3 页

Network Working Group                                          J. Postel
Request for Comments:  1042                                  J. Reynolds
                                                                     ISI
Obsoletes: RFC-948                                         February 1988



 A Standard for the Transmission of IP Datagrams over IEEE 802 Networks


Status of this Memo

   This RFC specifies a standard method of encapsulating the Internet
   Protocol (IP) [1] datagrams and Address Resolution Protocol (ARP) [2]
   requests and replies on IEEE 802 Networks.  This RFC specifies a
   protocol standard for the Internet community.  Distribution of this
   memo is unlimited.

Acknowledgment

   This memo would not exist with out the very significant contributions
   of Drew Perkins of Carnegie Mellon University, Jacob Rekhter of the
   T.J. Watson Research Center, IBM Corporation, and Joseph Cimmino of
   the University of Maryland.

Introduction

   The goal of this specification is to allow compatible and
   interoperable implementations for transmitting IP datagrams and ARP
   requests and replies.  To achieve this it may be necessary in a few
   cases to limit the use that IP and ARP make of the capabilities of a
   particular IEEE 802 standard.

   The IEEE 802 specifications define a family of standards for Local
   Area Networks (LANs) that deal 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) [3,4,5] and one Data Link Layer Standard (802.2) [6] 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.

   This memo describes the use of IP and ARP on the three types of
   networks.  At this time, it is not necessary that the use of IP and
   ARP be consistent across all three types of networks, only that it be
   consistent within each type.  This may change in the future as new
   IEEE 802 standards are defined and the existing standards are revised



Postel & Reynolds                                               [Page 1]

RFC 1042            IP and ARP on IEEE 802 Networks        February 1988


   allowing for interoperability at the Data Link Layer.

   It is the goal of this memo to specify enough about the use of IP and
   ARP on each type of network to ensure that:

      (1) all equipment using IP or ARP on 802.3 networks will
      interoperate,

      (2) all equipment using IP or ARP on 802.4 networks will
      interoperate,

      (3) all equipment using IP or ARP on 802.5 networks will
      interoperate.

   Of course, the goal of IP is interoperability between computers
   attached to different networks, when those networks are
   interconnected via an IP gateway [8].  The use of IEEE 802.1
   compatible Transparent Bridges to allow interoperability across
   different networks is not fully described pending completion of that
   standard.

Description

   IEEE 802 networks may be used as IP networks of any class (A, B, or
   C).  These systems use two Link Service Access Point (LSAP) fields of
   the LLC header in much the same way the ARPANET uses the "link"
   field.  Further, there is an extension of the LLC header called the
   Sub-Network Access Protocol (SNAP).

   IP datagrams are sent on IEEE 802 networks encapsulated within the
   802.2 LLC and SNAP data link layers, and the 802.3, 802.4, or 802.5
   physical networks layers.  The SNAP is used with an Organization Code
   indicating that the following 16 bits specify the EtherType code (as
   listed in Assigned Numbers [7]).

   Normally, all communication is performed using 802.2 type 1
   communication.  Consenting systems on the same IEEE 802 network may
   use 802.2 type 2 communication after verifying that it is supported
   by both nodes.  This is accomplished using the 802.2 XID mechanism.
   However, type 1 communication is the recommended method at this time
   and must be supported by all implementations.  The rest of this
   specification assumes the use of type 1 communication.

   The IEEE 802 networks may have 16-bit or 48-bit physical addresses.
   This specification allows the use of either size of address within a
   given IEEE 802 network.

   Note that the 802.3 standard specifies a transmission rate of from 1



Postel & Reynolds                                               [Page 2]

RFC 1042            IP and ARP on IEEE 802 Networks        February 1988


   to 20 megabit/second, the 802.4 standard specifies 1, 5, and 10
   megabit/second, and the 802.5 standard specifies 1 and 4
   megabit/second.  The typical transmission rates used are 10
   megabit/second for 802.3, 10 megabit/second for 802.4, and 4
   megabit/second for 802.5.  However, this specification for the
   transmission of IP Datagrams does not depend on the transmission
   rate.

Header Format
                                                                  Header

   ...--------+--------+--------+
              MAC Header        |                        802.{3/4/5} MAC
   ...--------+--------+--------+

   +--------+--------+--------+
   | DSAP=K1| SSAP=K1| Control|                                802.2 LLC
   +--------+--------+--------+

   +--------+--------+---------+--------+--------+
   |Protocol Id or Org Code =K2|    EtherType    |            802.2 SNAP
   +--------+--------+---------+--------+--------+

   The total length of the LLC Header and the SNAP header is 8-octets,
   making the 802.2 protocol overhead come out on an nice boundary.

   The K1 value is 170 (decimal).

   The K2 value is 0 (zero).

   The control value is 3 (Unnumbered Information).

Address Mappings

   The mapping of 32-bit Internet addresses to 16-bit or 48-bit IEEE 802
   addresses must be done via the dynamic discovery procedure of the
   Address Resolution Protocol (ARP) [2].

   Internet addresses are assigned arbitrarily on Internet networks.
   Each host's implementation must know its own Internet address and
   respond to Address Resolution requests appropriately.  It must also
   use ARP to translate Internet addresses to IEEE 802 addresses when
   needed.

   The ARP Details

      The ARP protocol has several fields that parameterize its use in
      any specific context [2].  These fields are:



Postel & Reynolds                                               [Page 3]

RFC 1042            IP and ARP on IEEE 802 Networks        February 1988


         hrd     16 - bits       The Hardware Type Code
         pro     16 - bits       The Protocol Type Code
         hln      8 - bits       Octets in each hardware address
         pln      8 - bits       Octets in each protocol address
         op      16 - bits       Operation Code

      The hardware type code assigned for the IEEE 802 networks (of all
      kinds) is 6 (see [7] page 16).

      The protocol type code for IP is 2048 (see [7] page 14).

      The hardware address length is 2 for 16-bit IEEE 802 addresses, or
      6 for 48-bit IEEE 802 addresses.

      The protocol address length (for IP) is 4.

      The operation code is 1 for request and 2 for reply.

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 IEEE
   802 address (of all binary ones) (see [8] page 14).

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.  Consenting systems on the same IEEE 802 network may
   use this format between themselves.  Details of the trailer
   encapsulation method may be found in [9].  However, all hosts must be
   able to communicate using the standard (non-trailer) method.

Byte Order

   As described in Appendix B of the Internet Protocol specification
   [1], the IP datagram is transmitted over IEEE 802 networks as a
   series of 8-bit bytes.  This byte transmission order has been called
   "big-endian" [11].

Maximum Transmission Unit

   The Maximum Transmission Unit (MTU) differs on the different types of
   IEEE 802 networks.  In the following there are comments on the MTU
   for each type of IEEE 802 network.  However, on any particular
   network all hosts must use the same MTU.  In the following, the terms
   "maximum packet size" and "maximum transmission unit" are equivalent.




Postel & Reynolds                                               [Page 4]

RFC 1042            IP and ARP on IEEE 802 Networks        February 1988


Frame Format and MAC Level Issues

   For all hardware types

      IP datagrams and ARP requests and replies are transmitted in
      standard 802.2 LLC Type 1 Unnumbered Information format, control
      code 3, with the DSAP and the SSAP fields of the 802.2 header set
      to 170, the assigned global SAP value for SNAP [6].  The 24-bit
      Organization Code in the SNAP is zero, and the remaining 16 bits
      are the EtherType from Assigned Numbers [7] (IP = 2048, ARP =
      2054).

      IEEE 802 packets may have a minimum size restriction.  When
      necessary, the data field should be padded (with octets of zero)
      to meet the IEEE 802 minimum frame size requirements.  This
      padding is not part of the IP datagram and is not included in the
      total length field of the IP header.

      For compatibility (and common sense) the minimum packet size used
      with IP datagrams is 28 octets, which is 20 (minimum IP header) +
      8 (LLC+SNAP header) = 28 octets (not including the MAC header).

      The minimum packet size used with ARP is 24 octets, which is 20
      (ARP with 2 octet hardware addresses and 4 octet protocol
      addresses) + 8 (LLC+SNAP header) = 24 octets (not including the
      MAC header).

      In typical situations, the packet size used with ARP is 32 octets,
      which is 28 (ARP with 6 octet hardware addresses and 4 octet
      protocol addresses) + 8 (LLC+SNAP header) = 32 octets (not
      including the MAC header).

      IEEE 802 packets may have a maximum size restriction.
      Implementations are encouraged to support full-length packets.

      For compatibility purposes, the maximum packet size used with IP
      datagrams or ARP requests and replies must be consistent on a
      particular network.

      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 [10].