rfc1201.txt

RFC 的详细文档！

   acknowledged.  Consequently, retransmission by the datalink
   implementation can cause duplicate packets or duplicate fragments.
   Duplicate packets are not a problem for IP or ARP.  As mentioned in
   the previous section, ARCNET reassembly support should ignore any
   redundant fragments.

3.  Transmitting IP and ARP Datagrams

   IP and ARP datagrams are carried in the client data area of ARCNET
   packets.  Datalink support places each datagram in an appropriate
   size ARCNET frame, fragmenting IP datagrams larger than 504 octets
   into multiple frames as described in the previous section.

4.  IP Address Mappings

   This section explains how each of the three basic 32-bit internet
   address types are mapped to 8-bit ARCNET addresses.

4.1.  Unicast Addresses

   A unicast IP address is mapped to an 8-bit ARCNET address using ARP
   as specified in [2].  A later section covers the specific values
   which should be used in ARP packets sent on ARCNET networks.




Provan                                                          [Page 4]

RFC 1201                      IP on ARCNET                 February 1991


      It is possible to assign IP addresses such that the last eight
      bits are the same as the 8-bit ARCNET address.  This would allow
      direct mapping of IP address to ARCNET address without using a
      discovery protocol.  Some implementations might provide this as an
      option, but it is not recommended practice.  Although such hard-
      wired mapping is initially appealing, experience shows that ARP is
      a much more flexible and convenient approach which has a very
      small cost.

4.2.  Broadcast Addresses

   All IP broadcast addresses must be mapped to the ARCNET broadcast
   address of 0.

      Unlike unicast packets, ARCNET does not attempt to insure delivery
      of broadcast packets, so they may be lost.  This will not have a
      major impact on IP since neither IP nor ARP expect all packets to
      be delivered.

4.3.  Multicast Addresses

   Since ARCNET provides no support for multicasts, all IP multicast
   addresses must be mapped to the ARCNET broadcast address of 0.

5.  ARP

   The hardware address length is 1 octet for ARP packets sent over
   ARCNET networks.  The ARP hardware type for ARCNET is 7.  ARP request
   packets are broadcast by directing them to ARCNET broadcast address,
   which is 0.

6.  RARP

   Reverse Address Resolution Protocol [6] packets can also be
   transmitted over ARCNET.  For the purposes of datalink transmission
   and reception, RARP is identical to ARP and can be handled the same
   way.  There are a few differences to notice, however, between RARP
   when running over ARCNET, which has a one octet hardware address, and
   Ethernet, which has a six octet hardware address.

   First, there are only 255 different hardware addresses for any given
   ARCNET while there's an very large number of possible Ethernet
   addresses.  Second, ARCNET hardware addresses are more likely to be
   duplicated on different ARCNET networks; Ethernet hardware addresses
   will normally be globally unique.  Third, an ARCNET hardware address
   is not as constant as an Ethernet address:  ARCNET hardware addresses
   are set by switches, not fixed in ROM as they are on Ethernet.




Provan                                                          [Page 5]

RFC 1201                      IP on ARCNET                 February 1991


7.  Maximum Transmission Unit

   The maximum IP packet length possible using this encapsulation method
   is 60,480 octets.  Since this length is impractical, all ARCNET
   implementations on a given ARCNET network will need to agree on a
   smaller value.  Therefore, the maximum packet size MUST be
   configurable in implementations of this specification.

   In any case, implementations must be able to send and receive IP
   datagrams up to 576 octets in length, and are strongly encouraged to
   handle IP datagrams up to 1500 octets in length.

   Implementations may accept arriving IP datagrams which are larger
   than their configured maximum transmission unit.  They are not
   required to discard such datagrams.

   To minimize the amount of ARCNET fragmentation, implementations may
   want to aim at an optimum IP packet size of 504 bytes.  This avoids
   the overhead of datalink fragmentation, but at the expense of
   increasing the number of IP packets which must be handled by each
   node in the path.  In addition to encouraging local applications to
   generate smaller packets, an implementation might also use the TCP
   maximum segment size option to indicate a desire for 464 octet TCP
   segments [7], or it might  announce an IP MTU of 504 octets through
   an MTU discovery mechanism such as [8].  These would inform non-
   ARCNET nodes of the smaller optimum packet size.

8.  Assigned Numbers

   Datapoint Corporation assigns ARCNET protocol IDs to identify
   different protocols running on the same ARCNET medium.  For
   implementations of this specification, Datapoint has assigned 212
   decimal to IP, 213 decimal to ARP, and 214 decimal to RARP.  These
   are not the numbers assigned to the IP encapsulation defined by RFC
   1051 [5].  Implementations of RFC 1051 can exist on the same ARCNET
   as implementations of this specification, although the two would not
   be able to communicate with each other.

   The Internet Assigned Numbers Authority (IANA) assigns ARP hardware
   type values.  It has assigned ARCNET the ARP hardware type of 7 [9].

Acknowledgements

   Several people have reviewed this specification and provided useful
   input.  I'd like to thank Wesley Hardell at Datapoint and Troy Thomas
   at Novell's Provo office for helping me figure out ARCNET.  In
   addition, I particularly appreciate the effort by James VanBokkelen
   at FTP Software who picked on me until all the fuzzy edges were



Provan                                                          [Page 6]

RFC 1201                      IP on ARCNET                 February 1991


   smoothed out.

   The pioneering work in transmitting IP traffic on ARCNET networks was
   done by Philippe Prindeville.

References

   [1] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981.

   [2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826,
       MIT, November 1982.

   [3] Datapoint, Corp., "ARCNET Designer's Handbook", Document Number
       61610, 2nd Edition, Datapoint Corporation, 1988.

   [4] Novell, Inc., "ARCNET Packet Header Definition Standard", Novell,
       Inc., November 1989.

   [5] Prindeville, P., "A Standard for the Transmission of IP Datagrams
       and ARP Packets over ARCNET Networks", RFC 1051, McGill
       University, March 1988.

   [6] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
       Address Resolution Protocol", RFC 903, Stanford, June 1984.

   [7] Postel, J., "Transmission Control Protocol", RFC 793, DARPA,
       September 1981.

   [8] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU
       Discovery Options", RFC 1063, DEC, BBN, TWG, July 1988.

   [9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
       USC/Information Sciences Institute, March 1990.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Don Provan
   Novell, Inc.
   2180 Fortune Drive
   San Jose, California, 95131

   Phone: [phone]
   EMail: [e-mail]




Provan                                                          [Page 7]