doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc1390.txt b/doc/rfc/rfc1390.txt
new file mode 100644
index 0000000..41465eb
--- /dev/null
+++ b/doc/rfc/rfc1390.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                           D. Katz
+Request for Comments: 1390                          cisco Systems, Inc.
+STD: 36                                                    January 1993
+
+
+             Transmission of IP and ARP over FDDI Networks
+
+Status of this Memo
+
+   This RFC specifies an IAB standards track protocol for the Internet
+   community, and requests discussion and suggestions for improvements.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" for the standardization state and status of this protocol.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo defines a method of encapsulating the Internet Protocol
+   (IP) datagrams and Address Resolution Protocol (ARP) requests and
+   replies on Fiber Distributed Data Interface (FDDI) Networks.
+
+   This RFC is the product of the IP over FDDI Working Group of the
+   Internet Engineering Task Force (IETF).
+
+Acknowledgments
+
+   This memo draws heavily in both concept and text from RFC 1042 [3],
+   written by Jon Postel and Joyce K. Reynolds of USC/Information
+   Sciences Institute.  The author would also like to acknowledge the
+   contributions of the IP Over FDDI Working Group of the IETF, members
+   of ANSI ASC X3T9.5, and others in the FDDI community.
+
+Conventions
+
+   The following language conventions are used in the items of
+   specification in this document:
+
+      "Must," "Shall," or "Mandatory"--the item is an absolute
+      requirement of the specification.
+
+      "Should" or "Recommended"--the item should generally be followed
+      for all but exceptional circumstances.
+
+      "May" or "Optional"--the item is truly optional and may be
+      followed or ignored according to the needs of the implementor.
+
+
+
+
+
+
+Katz                                                            [Page 1]
+
+RFC 1390                      IP Over FDDI                  January 1993
+
+
+Introduction
+
+   The goal of this specification is to allow compatible and
+   interoperable implementations for transmitting IP datagrams [1] and
+   ARP requests and replies [2].
+
+   The Fiber Distributed Data Interface (FDDI) specifications define a
+   family of standards for Local Area Networks (LANs) that provides the
+   Physical Layer and Media Access Control Sublayer of the Data Link
+   Layer as defined by the ISO Open System Interconnection Reference
+   Model (ISO/OSI).  Documents are in various stages of progression
+   toward International Standardization for Media Access Control (MAC)
+   [4], Physical Layer Protocol (PHY) [5], Physical Layer Medium
+   Dependent (PMD) [6], and Station Management (SMT) [7].  The family of
+   FDDI standards corresponds to the IEEE 802 MAC layer standards [8, 9,
+   10].
+
+   The remainder of the Data Link Service is provided by the IEEE 802.2
+   Logical Link Control (LLC) service [11].  The resulting stack of
+   services appears as follows:
+
+        +-------------+
+        |   IP/ARP    |
+        +-------------+
+        |  802.2 LLC  |
+        +-------------+-----+
+        |  FDDI MAC   | F   |
+        +-------------+ D S |
+        |  FDDI PHY   | D M |
+        +-------------+ I T |
+        |  FDDI PMD   |     |
+        +-------------+-----+
+
+   This memo describes the use of IP and ARP in this environment.  At
+   this time, it is not necessary that the use of IP and ARP be
+   consistent between FDDI and IEEE 802 networks, but it is the intent
+   of this memo not to preclude Data Link Layer interoperability at such
+   time as the standards define it.
+
+   It is the explicit intent of this memo to allow the interoperability
+   of IP and ARP between stations on FDDI networks and stations on
+   Ethernet networks via translational bridges.
+
+   The FDDI standards define both single and dual MAC stations.  This
+   document describes the use of IP and ARP on single MAC stations
+   (single-attach or dual-attach) only.
+
+
+
+
+
+Katz                                                            [Page 2]
+
+RFC 1390                      IP Over FDDI                  January 1993
+
+
+Packet Format
+
+   IP datagrams and ARP requests and replies sent on FDDI networks shall
+   be encapsulated within the 802.2 LLC and Sub-Network Access Protocol
+   (SNAP) [12] data link layers and the FDDI MAC and physical layers.
+   The SNAP must be used with an Organization Code indicating that the
+   SNAP header contains the EtherType code (as listed in Assigned
+   Numbers [13]).
+
+   802.2 LLC Type 1 communication (which must be implemented by all
+   conforming 802.2 stations) is used exclusively.  All frames must be
+   transmitted in standard 802.2 LLC Type 1 Unnumbered Information
+   format, with the DSAP and the SSAP fields of the 802.2 header set to
+   the assigned global SAP value for SNAP [11].  The 24-bit Organization
+   Code in the SNAP must be zero, and the remaining 16 bits are the
+   EtherType from Assigned Numbers [13] (IP = 2048, ARP = 2054).
+
+
+      ...--------+--------+--------+
+                 MAC Header        |                           FDDI 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.
+
+      The K1 value is 170 (decimal).
+
+      The K2 value is 0 (zero).
+
+      The control value is 3 (Unnumbered Information).
+
+Address Resolution
+
+   The mapping of 32-bit Internet addresses to 48-bit FDDI addresses
+   shall 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
+
+
+
+Katz                                                            [Page 3]
+
+RFC 1390                      IP Over FDDI                  January 1993
+
+
+   use ARP to translate Internet addresses to FDDI addresses when
+   needed.
+
+   The ARP protocol has several fields that parameterize its use in any
+   specific context [2].  These fields are:
+
+      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 IEEE 802 networks is 6 [13].  The
+   hardware type code assigned for Ethernet networks is 1 [13].
+   Unfortunately, differing values between Ethernet and IEEE 802
+   networks cause interoperability problems in bridged environments.  In
+   order to not preclude interoperability with Ethernets in a bridged
+   environment, ARP packets shall be transmitted with a hardware type
+   code of 1.  ARP packets shall be accepted if received with a hardware
+   type code of 1.
+
+   The protocol type code for IP is 2048 [13].
+
+   The hardware address length is 6.
+
+   The protocol address length (for IP) is 4.
+
+   The operation code is 1 for request and 2 for reply.
+
+   In order to not preclude interoperability in a bridged environment,
+   the hardware addresses in ARP packets (ar$sha, ar$tha) must be
+   carried in "canonical" bit order, with the Group bit positioned as
+   the low order bit of the first octet.  As FDDI addresses are normally
+   expressed with the Group bit in the high order bit position, the
+   addresses must be bit-reversed within each octet.
+
+   Although outside the scope of this document, it is recommended that
+   MAC addresses be represented in canonical order in all Network Layer
+   protocols carried within the information field of an FDDI frame.
+
+Broadcast Address
+
+   The broadcast Internet address (the address on that network with a
+   host part of all binary ones) must be mapped to the broadcast FDDI
+   address (of all binary ones) (see [14]).
+
+
+
+
+
+
+Katz                                                            [Page 4]
+
+RFC 1390                      IP Over FDDI                  January 1993
+
+
+Multicast Support
+
+   A method of supporting IP multicasting is specified in [15].  This
+   method shall be used in FDDI networks if IP multicasting is to be
+   supported.  The use of this method may require the ability to copy
+   frames addressed to any one of an arbitrary number of multicast
+   (group) addresses.
+
+   An IP multicast address is mapped to an FDDI group address by placing
+   the low order 23 bits of the IP address into the low order 23 bits of
+   the FDDI group address 01-00-5E-00-00-00 (in "canonical" order).
+   [See 13, page 29.]
+
+   For example, the IP multicast address:
+
+            224.255.0.2
+
+   maps to the FDDI group address:
+
+            01-00-5E-7F-00-02
+
+   in which the multicast (group) bit is the low order bit of the first
+   octet (canonical order).  When bit-reversed for transmission in the
+   destination MAC address field of an FDDI frame (native order), it
+   becomes:
+
+            80-00-7A-FE-00-40
+
+   that is, with the multicast (group) bit as the high order bit of the
+   first octet, that being the first bit transmitted on the medium.
+
+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.  Hosts directly connected to FDDI networks shall not
+   use trailers.
+
+Byte Order
+
+   As described in Appendix B of the Internet Protocol specification
+   [1], the IP datagram is transmitted over FDDI networks as a series of
+   8-bit bytes.  This byte transmission order has been called "big-
+   endian" [16].
+
+
+
+
+
+
+
+Katz                                                            [Page 5]
+
+RFC 1390                      IP Over FDDI                  January 1993
+
+
+MAC Layer Details
+
+   Packet Size
+
+      The FDDI MAC specification [4] defines a maximum frame size of
+      9000 symbols (4500 octets) for all frame fields, including four
+      symbols (two octets) of preamble.  This leaves roughly 4470 octets
+      for data after the LLC/SNAP header is taken into account.
+
+      However, in order to allow future extensions to the MAC header and
+      frame status fields, it is desirable to reserve additional space
+      for MAC overhead.
+
+      Therefore, the MTU of FDDI networks shall be 4352 octets.  This
+      provides for 4096 octets of data and 256 octets of headers at the
+      network layer and above.  Implementations must not send packets
+      larger than the MTU.
+
+      Gateway implementations must be prepared to accept packets as
+      large as the MTU and fragment them when necessary.  Gateway
+      implementations should be able to accept packets as large as can
+      be carried within a maximum size FDDI frame and fragment them.
+
+      Host implementations should be prepared to accept packets as large
+      as the MTU; however, hosts must not send datagrams longer than 576
+      octets unless they have explicit knowledge that the destination is
+      prepared to accept them.  Host implementations may accept packets
+      as large as can be carried within a maximum size FDDI frame.  A
+      host may communicate its size preference in TCP-based applications
+      via the TCP Maximum Segment Size option [17].
+
+      Datagrams on FDDI networks may be longer than the general Internet
+      default maximum packet size of 576 octets.  Hosts connected to an
+      FDDI network should keep this in mind when sending datagrams to
+      hosts that are not on the same local network.  It may be
+      appropriate to send smaller datagrams to avoid unnecessary
+      fragmentation at intermediate gateways.  Please see [17] for
+      further information.
+
+      There is no minimum packet size restriction on FDDI networks.
+
+      In order to not preclude interoperability with Ethernet in a
+      bridged environment, FDDI implementations must be prepared to
+      receive (and ignore) trailing pad octets.
+
+   Other MAC Layer Issues
+
+      The FDDI MAC specification does not require that 16-bit and 48-
+
+
+
+Katz                                                            [Page 6]
+
+RFC 1390                      IP Over FDDI                  January 1993
+
+
+      bit address stations be able to interwork fully.  It does,
+      however, require that 16-bit stations have full 48-bit
+      functionality, and that both types of stations be able to receive
+      frames sent to either size broadcast address.  In order to avoid
+      interoperability problems, only 48-bit addresses shall be used
+      with IP and ARP.
+
+      The FDDI MAC specification defines two classes of LLC frames,
+      Asynchronous and Synchronous.  Asynchronous frames are further
+      controlled by a priority mechanism and two classes of token,
+      Restricted and Unrestricted.  Only the use of Unrestricted tokens
+      and Asynchronous frames are required by the standard for FDDI
+      interoperability.
+
+      All IP and ARP frames shall be transmitted as Asynchronous LLC
+      frames using Unrestricted tokens, and the Priority value is a
+      matter of local convention.  Implementations should make the
+      priority a tunable parameter for future use.  It is recommended
+      that implementations provide for the reception of IP and ARP
+      packets in Synchronous frames, as well as Restricted Asynchronous
+      frames.
+
+      After packet transmission, FDDI provides Frame Copied (C) and
+      Address Recognized (A) indicators.  The use of these indicators is
+      a local implementation decision.  Implementations may choose to
+      perform link-level retransmission, ARP cache entry invalidation,
+      etc., based on the values of these indicators and other
+      information.  The semantics of these indicators, especially in the
+      presence of bridges, are not well defined as of this writing.
+      Implementors are urged to follow the work of ANSI ASC X3T9.5 in
+      regard to this issue in order to avoid interoperability problems.
+
+IEEE 802.2 Details
+
+   While not necessary for supporting IP and ARP, all implementations
+   must support IEEE 802.2 standard Class I service in order to be
+   compliant with 802.2.  Described below is the minimum functionality
+   necessary for a conformant station.  Some of the functions are not
+   related directly to the support of the SNAP SAP (e.g., responding to
+   XID and TEST commands directed to the null or global SAP addresses),
+   but are part of a general LLC implementation.  Implementors should
+   consult IEEE Std. 802.2 [11] for details.
+
+   802.2 Class I LLC requires the support of Unnumbered Information (UI)
+   Commands, eXchange IDentification (XID) Commands and Responses, and
+   TEST link (TEST) Commands and Responses.  Stations need not be able
+   to transmit XID and TEST commands, but must be able to transmit
+   responses.
+
+
+
+Katz                                                            [Page 7]
+
+RFC 1390                      IP Over FDDI                  January 1993
+
+
+   Encodings
+
+      Command frames are identified by having the low order bit of the
+      SSAP address reset to zero.  Response frames have the low order
+      bit of the SSAP address set to one.
+
+      The UI command has an LLC control field value of 3.
+
+      The XID command/response has an LLC control field value of 175
+      (decimal) if the Poll/Final bit is off or 191 (decimal) if the
+      Poll/Final bit is on.
+
+      The TEST command/response has an LLC control field value of 227
+      (decimal) if the Poll/Final bit is off or 243 (decimal) if the
+      Poll/Final bit is on.
+
+   Elements of Procedure
+
+      UI responses and UI commands with the Poll bit set shall be
+      ignored.  UI commands having other than the SNAP SAP in the DSAP
+      or SSAP fields shall not be processed as IP or ARP packets.
+
+      When an XID or TEST command is received, an appropriate response
+      must be returned.  XID and TEST commands must be responded to only
+      if the DSAP is the SNAP SAP (170 decimal), the Null SAP (0
+      decimal), or the Global SAP (255 decimal).  XID and TEST commands
+      received with other DSAP values must not be responded to unless
+      the station supports the addressed service.  Responses to XID and
+      TEST frames shall be constructed as follows:
+
+         Destination MAC:  Copied from Source MAC of the command
+         Source MAC:  Set to the address of the MAC receiving the
+                command
+         DSAP:  Copied from SSAP of the command
+         SSAP:  Set to 171 decimal (SNAP SAP + Response bit) if the
+                DSAP in the command was the SNAP SAP or the Global SAP;
+                set to 1 decimal (Null SAP + Response bit) if the DSAP
+                in the command was the Null SAP
+
+      When responding to an XID or a TEST command, the value of the
+      Final bit in the response must be copied from the value of the
+      Poll bit in the command.
+
+      XID response frames must include an 802.2 XID Information field of
+      129.1.0 indicating Class I (connectionless) service.
+
+      TEST response frames must echo the information field received in
+      the corresponding TEST command frame.
+
+
+
+Katz                                                            [Page 8]
+
+RFC 1390                      IP Over FDDI                  January 1993
+
+
+Appendix on Numbers
+
+   The IEEE specifies numbers as bit strings with the least significant
+   bit first, or bit-wise little-endian order.  The Internet protocols
+   are documented in bit-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.
+
+       Number           IEEE        Internet    Internet
+                        Binary      Binary      Decimal
+
+       UI               11000000    00000011    3
+       SAP for SNAP     01010101    10101010    170
+       Global SAP       11111111    11111111    255
+       Null SAP         00000000    00000000    0
+       XID              11110101    10101111    175
+       XID Poll/Final   11111101    10111111    191
+       XID Info                                 129.1.0
+       TEST             11000111    11100011    227
+       TEST Poll/Final  11001111    11110011    243
+
+Differences between this document and RFC 1188
+
+   The following is a summary of the differences between RFC 1188 and
+   this document:
+
+      A reference to a future dual-MAC document has been removed.
+
+      A statement of explicit intent to support FDDI/Ethernet
+      interoperability has been added.
+
+      The acceptance of ARP frames bearing hardware type code 6 (IEEE
+      802) has been removed.
+
+      The references have been updated.
+
+      The author's address has been updated.
+
+References
+
+   [1] Postel, J., "Internet Protocol", STD 5, 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.
+
+
+
+
+Katz                                                            [Page 9]
+
+RFC 1390                      IP Over FDDI                  January 1993
+
+
+   [3] Postel, J., and J. Reynolds, "A Standard for the Transmission of
+       IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information
+       Sciences Institute, February 1988.
+
+   [4] ISO, "Fiber Distributed Data Interface (FDDI) - Media Access
+       Control", ISO 9314-2, 1989.  See also ANSI X3.139-1987.
+
+   [5] ISO, "Fiber Distributed Data Interface (FDDI) - Token Ring
+       Physical Layer Protocol", ISO 9314-1, 1989.  See also ANSI
+       X3.148-1988.
+
+   [6] ISO, "Fiber Distributed Data Interface (FDDI) - Physical Layer
+       Medium Dependent", ISO DIS 9314-3, 1989.  See also ANSI X3.166-
+       199x.
+
+   [7] ANSI, "FDDI Station Management", ANSI X3T9.5/84-49 Rev 7.1, 1992.
+
+   [8] 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.
+
+   [9] IEEE, "IEEE Standards for Local Area Networks: Token-Passing Bus
+       Access Method and Physical Layer Specification", IEEE, New York,
+       New York, 1985.
+
+  [10] IEEE, "IEEE Standards for Local Area Networks: Token Ring Access
+       Method and Physical Layer Specifications", IEEE, New York, New
+       York, 1985.
+
+  [11] IEEE, "IEEE Standards for Local Area Networks: Logical Link
+       Control", IEEE, New York, New York, 1985.
+
+  [12] IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.
+
+  [13] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
+       USC/Information Sciences Institute, July 1992.
+
+  [14] Braden, R., and J. Postel, "Requirements for Internet Gateways",
+       STD 4, RFC 1009, USC/Information Sciences Institute, June 1987.
+
+  [15] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
+       1112, Stanford University, August 1989.
+
+  [16] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,
+       October 1981.
+
+
+
+
+
+Katz                                                           [Page 10]
+
+RFC 1390                      IP Over FDDI                  January 1993
+
+
+  [17] Postel, J., "The TCP Maximum Segment Size Option and Related
+       Topics", RFC 879, USC/Information Sciences Institute, November
+       1983.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   Dave Katz
+   cisco Systems, Inc.
+   1525 O'Brien Dr.
+   Menlo Park, CA  94025
+
+   Phone: (415) 688-8284
+   EMail: dkatz@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Katz                                                           [Page 11]
+
\ No newline at end of file