rfc1042.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 843 行 · 第 1/3 页


RFC 1042            IP and ARP on IEEE 802 Networks        February 1988


      limit the size of packets forwarded to 552 octets, with a MAC
      header+trailer of 36 octets and the LLC+SNAP of 8 octets, the IP
      datagram (including the IP header) may be limited to 508 octets.
      This is less that the default IP MTU of 576 octets, and may cause
      significant performance problems due to excessive datagram
      fragmentation.  An implementation is not required to support an
      MTU of less than 576 octets, although it is suggest that the MTU
      be a user-configurable parameter to allow for it.

      IEEE 802.5 networks support three different types of broadcasts.
      All-Stations broadcasts are sent with no RIF or with the Broadcast
      Indicators set to 0 and no Routing Designators, and are copied
      once by all stations on the local ring.  All-Routes broadcasts are
      sent with the corresponding Broadcast Indicators and result in
      multiple copies equal to the number of distinct non-repeating
      routes a packet may follow to a particular ring.  Single-Route
      broadcasts result in exactly one copy of a frame being received by
      all stations on the multi-ring network.

      The dynamic address discovery procedure is to broadcast an ARP
      request.  To limit the number of all rings broadcasts to a
      minimum, it is desirable (though not required) that an ARP request
      first be sent as an all-stations broadcast, without a Routing
      Information Field (RIF).  If the all-stations (local ring)
      broadcast is not supported or if the all-stations broadcast is
      unsuccessful after some reasonable time has elapsed, then send the
      ARP request as an all-routes or single-route broadcast with an
      empty RIF (no routing designators).  An all-routes broadcast is
      preferable since it yields an amount of fault tolerance.  In an
      environment with multiple redundant bridges, all-routes broadcast
      allows operation in spite of spanning-tree bridge failures.
      However, single-route broadcasts may be used if IP and ARP must
      use the same broadcast method.

      When an ARP request or reply is received, all implementations are
      required to understand frames with no RIF (local ring) and frames
      with an empty RIF (also from the local ring).  If the
      implementation supports multi-ring source routing, then a non-
      empty RIF is stored for future transmissions to the host
      originating the ARP request or reply.  If source routing is not
      supported them all packets with non-empty RIFs should be
      gracefully ignored.  This policy will allow all implementations in
      a single ring environment, to interoperate, whether or not they
      support the multi-ring extensions.

      It is possible that when sending an ARP request via an all-routes
      broadcast that multiple copies of the request will arrive at the
      destination as a result of the request being forwarded by several



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


      bridges.  However, these "copies" will have taken different routes
      so the contents of the RIF will differ.  An implementation of ARP
      in this context must determine which of these "copies" to use and
      to ignore the others.  There are three obvious and legal
      strategies: (1) take the first and ignore the rest (that is, once
      you have an entry in the ARP cache don't change it), (2) take the
      last, (that is, always up date the ARP cache with the latest ARP
      message), or (3) take the one with the shortest path, (that is,
      replace the ARP cache information with the latest ARP message data
      if it is a shorter route).  Since there is no problem of
      incompatibility for interworking of different implementations if
      different strategies are chosen, the choice is up to each
      implementor.  The recipient of the ARP request must send an ARP
      reply as a point to point message using the RIF information.

      The RIF information should be kept distinct from the ARP table.
      That is, there is, in principle, the ARP table to map from IP
      addresses to 802 48-bit addresses, and the RIF table to map from
      those to 802.5 source routes, if necessary.  In practical
      implementations it may be convenient to store the ARP and RIF
      information together.

         Storing the information together may speed up access to the
         information when it is used.  On the other hand, in a
         generalized implementation for all types of 802 networks a
         significant amount of memory might be wasted in an ARP cache if
         space for the RIF information were always reserved.

      IP broadcasts (datagrams with a IP broadcast address) must be sent
      as 802.5 single-route broadcasts.  Unlike ARP, all-routes
      broadcasts are not desirable for IP.  Receiving multiple copies of
      IP broadcasts would have undesirable effects on many protocols
      using IP.  As with ARP, when an IP packet is received, all
      implementations are required to understand frames with no RIF and
      frames with an empty RIF.

      Since current interface hardware allows only one group address,
      and since the functional addresses are not globally unique, IP and
      ARP do not use either of these features.  Further, in the IBM
      style 802.5 networks there are only 31 functional addresses
      available for user definition.

      IP precedence should not be mapped to 802.5 priority.  All IP and
      ARP packets should be sent at the default 802.5 priority.  The
      default priority is 3.

      After packet transmission, 802.5 provides frame not copied and
      address not recognized indicators.  Implementations may use these



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


      indicators to provide some amount of error detection and
      correction.  If the frame not copied bit is set but the address
      not recognized bit is reset, receiver congestion has occurred.  It
      is suggested, though not required, that hosts should retransmit
      the offending packet a small number of times (4) or until
      congestion no longer occurs.  If the address not recognized bit is
      set, an implementation has 3 options: (1) ignore the error and
      throw the packet away, (2) return an ICMP destination unreachable
      message to the source, or (3) delete the ARP entry which was used
      to send this packet and send a new ARP request to the destination
      address.  The latter option is the preferred approach since it
      will allow graceful recovery from first hop bridge and router
      failures and changed hardware addresses.

Interoperation with Ethernet

   It is possible to use the Ethernet link level protocol [12] on the
   same physical cable with the IEEE 802.3 link level protocol.  A
   computer interfaced to a physical cable used in this way could
   potentially read both Ethernet and 802.3 packets from the network.
   If a computer does read both types of packets, it must keep track of
   which link protocol was used with each other computer on the network
   and use the proper link protocol when sending packets.

   One should note that in such an environment, link level broadcast
   packets will not reach all the computers attached to the network, but
   only those using the link level protocol used for the broadcast.

   Since it must be assumed that most computers will read and send using
   only one type of link protocol, it is recommended that if such an
   environment (a network with both link protocols) is necessary, an IP
   gateway be used as if there were two distinct networks.

   Note that the MTU for the Ethernet allows a 1500 octet IP datagram,
   with the MTU for the 802.3 network allows only a 1492 octet IP
   datagram.


Appendix on Numbers

   The IEEE likes to specify numbers in bit transmission order, or bit-
   wise little-endian order.  The Internet protocols are documented in
   byte-wise big-endian order.  This may cause some confusion about the
   proper values to use for numbers.  Here are the conversions for some
   numbers of interest.






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


   Number          IEEE    IEEE            Internet        Internet
                   HEX     Binary          Binary          Decimal

   UI Op Code      C0      11000000        00000011          3
   SAP for SNAP    55      01010101        10101010        170
   XID             F5      11110101        10101111        175
   XID             FD      11111101        10111111        191
   TEST            C7      11000111        11100011        227
   TEST            CF      11001111        11110011        243
   Info            818000                                  129.1.0

References

   [1]   Postel, J., "Internet Protocol", RFC-791, USC/Information
         Sciences Institute, September 1981.

   [2]   Plummer, D., "An Ethernet Address Resolution Protocol - or -
         Converting Network Protocol Addresses to 48.bit Ethernet
         Address for Transmission on Ethernet Hardware", RFC-826, MIT,
         November 1982.

   [3]   IEEE, "IEEE Standards for Local Area Networks: Carrier Sense
         Multiple Access with Collision Detection (CSMA/CD) Access
         Method and Physical Layer Specifications", IEEE, New York, New
         York, 1985.

   [4]   IEEE, "IEEE Standards for Local Area Networks: Token-Passing
         Bus Access Method and Physical Layer Specification", IEEE, New
         York, New York, 1985.

   [5]   IEEE, "IEEE Standards for Local Area Networks: Token Ring
         Access Method and Physical Layer Specifications", IEEE, New
         York, New York, 1985.

   [6]   IEEE, "IEEE Standards for Local Area Networks: Logical Link
         Control", IEEE, New York, New York, 1985.

   [7]   Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC-1010,
         USC/Information Sciences Institute, May 1987.

   [8]   Braden, R., and J. Postel, "Requirements for Internet
         Gateways", RFC-1009, USC/Information Sciences Institute, June
         1987.

   [9]   Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893,
         University of California at Berkeley, April 1984.

   [10]  Postel, J., "The TCP Maximum Segment Size Option and Related



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


         Topics", RFC-879, USC/Information Sciences Institute, November
         1983.

   [11]  Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,
         October 1981.

   [12]  D-I-X, "The Ethernet - A Local Area Network: Data Link Layer
         and Physical Layer Specifications", Digital, Intel, and Xerox,
         November 1982.

   [13]  IBM, "Token-Ring Network Architecture Reference", Second
         Edition, SC30-3374-01, August 1987.







































Postel & Reynolds                                              [Page 15]