home *** CD-ROM | disk | FTP | other *** search
/ Internet Access: To the Information Highway / InternetAccessToTheInformationHighway1994.disc1of1.iso / internet / rfc4 / rfc1390.txt < prev    next >
Text File  |  1994-05-29  |  23KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           D. Katz
  8. Request for Comments: 1390                          cisco Systems, Inc.
  9. STD: 36                                                    January 1993
  10.  
  11.  
  12.              Transmission of IP and ARP over FDDI Networks
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC specifies an IAB standards track protocol for the Internet
  17.    community, and requests discussion and suggestions for improvements.
  18.    Please refer to the current edition of the "IAB Official Protocol
  19.    Standards" for the standardization state and status of this protocol.
  20.    Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This memo defines a method of encapsulating the Internet Protocol
  25.    (IP) datagrams and Address Resolution Protocol (ARP) requests and
  26.    replies on Fiber Distributed Data Interface (FDDI) Networks.
  27.  
  28.    This RFC is the product of the IP over FDDI Working Group of the
  29.    Internet Engineering Task Force (IETF).
  30.  
  31. Acknowledgments
  32.  
  33.    This memo draws heavily in both concept and text from RFC 1042 [3],
  34.    written by Jon Postel and Joyce K. Reynolds of USC/Information
  35.    Sciences Institute.  The author would also like to acknowledge the
  36.    contributions of the IP Over FDDI Working Group of the IETF, members
  37.    of ANSI ASC X3T9.5, and others in the FDDI community.
  38.  
  39. Conventions
  40.  
  41.    The following language conventions are used in the items of
  42.    specification in this document:
  43.  
  44.       "Must," "Shall," or "Mandatory"--the item is an absolute
  45.       requirement of the specification.
  46.  
  47.       "Should" or "Recommended"--the item should generally be followed
  48.       for all but exceptional circumstances.
  49.  
  50.       "May" or "Optional"--the item is truly optional and may be
  51.       followed or ignored according to the needs of the implementor.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Katz                                                            [Page 1]
  59.  
  60. RFC 1390                      IP Over FDDI                  January 1993
  61.  
  62.  
  63. Introduction
  64.  
  65.    The goal of this specification is to allow compatible and
  66.    interoperable implementations for transmitting IP datagrams [1] and
  67.    ARP requests and replies [2].
  68.  
  69.    The Fiber Distributed Data Interface (FDDI) specifications define a
  70.    family of standards for Local Area Networks (LANs) that provides the
  71.    Physical Layer and Media Access Control Sublayer of the Data Link
  72.    Layer as defined by the ISO Open System Interconnection Reference
  73.    Model (ISO/OSI).  Documents are in various stages of progression
  74.    toward International Standardization for Media Access Control (MAC)
  75.    [4], Physical Layer Protocol (PHY) [5], Physical Layer Medium
  76.    Dependent (PMD) [6], and Station Management (SMT) [7].  The family of
  77.    FDDI standards corresponds to the IEEE 802 MAC layer standards [8, 9,
  78.    10].
  79.  
  80.    The remainder of the Data Link Service is provided by the IEEE 802.2
  81.    Logical Link Control (LLC) service [11].  The resulting stack of
  82.    services appears as follows:
  83.  
  84.         +-------------+
  85.         |   IP/ARP    |
  86.         +-------------+
  87.         |  802.2 LLC  |
  88.         +-------------+-----+
  89.         |  FDDI MAC   | F   |
  90.         +-------------+ D S |
  91.         |  FDDI PHY   | D M |
  92.         +-------------+ I T |
  93.         |  FDDI PMD   |     |
  94.         +-------------+-----+
  95.  
  96.    This memo describes the use of IP and ARP in this environment.  At
  97.    this time, it is not necessary that the use of IP and ARP be
  98.    consistent between FDDI and IEEE 802 networks, but it is the intent
  99.    of this memo not to preclude Data Link Layer interoperability at such
  100.    time as the standards define it.
  101.  
  102.    It is the explicit intent of this memo to allow the interoperability
  103.    of IP and ARP between stations on FDDI networks and stations on
  104.    Ethernet networks via translational bridges.
  105.  
  106.    The FDDI standards define both single and dual MAC stations.  This
  107.    document describes the use of IP and ARP on single MAC stations
  108.    (single-attach or dual-attach) only.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Katz                                                            [Page 2]
  115.  
  116. RFC 1390                      IP Over FDDI                  January 1993
  117.  
  118.  
  119. Packet Format
  120.  
  121.    IP datagrams and ARP requests and replies sent on FDDI networks shall
  122.    be encapsulated within the 802.2 LLC and Sub-Network Access Protocol
  123.    (SNAP) [12] data link layers and the FDDI MAC and physical layers.
  124.    The SNAP must be used with an Organization Code indicating that the
  125.    SNAP header contains the EtherType code (as listed in Assigned
  126.    Numbers [13]).
  127.  
  128.    802.2 LLC Type 1 communication (which must be implemented by all
  129.    conforming 802.2 stations) is used exclusively.  All frames must be
  130.    transmitted in standard 802.2 LLC Type 1 Unnumbered Information
  131.    format, with the DSAP and the SSAP fields of the 802.2 header set to
  132.    the assigned global SAP value for SNAP [11].  The 24-bit Organization
  133.    Code in the SNAP must be zero, and the remaining 16 bits are the
  134.    EtherType from Assigned Numbers [13] (IP = 2048, ARP = 2054).
  135.  
  136.  
  137.       ...--------+--------+--------+
  138.                  MAC Header        |                           FDDI MAC
  139.       ...--------+--------+--------+
  140.  
  141.       +--------+--------+--------+
  142.       | DSAP=K1| SSAP=K1| Control|                            802.2 LLC
  143.       +--------+--------+--------+
  144.  
  145.       +--------+--------+---------+--------+--------+
  146.       |Protocol Id or Org Code =K2|    EtherType    |        802.2 SNAP
  147.       +--------+--------+---------+--------+--------+
  148.  
  149.       The total length of the LLC Header and the SNAP header is 8
  150.       octets.
  151.  
  152.       The K1 value is 170 (decimal).
  153.  
  154.       The K2 value is 0 (zero).
  155.  
  156.       The control value is 3 (Unnumbered Information).
  157.  
  158. Address Resolution
  159.  
  160.    The mapping of 32-bit Internet addresses to 48-bit FDDI addresses
  161.    shall be done via the dynamic discovery procedure of the Address
  162.    Resolution Protocol (ARP) [2].
  163.  
  164.    Internet addresses are assigned arbitrarily on Internet networks.
  165.    Each host's implementation must know its own Internet address and
  166.    respond to Address Resolution requests appropriately.  It must also
  167.  
  168.  
  169.  
  170. Katz                                                            [Page 3]
  171.  
  172. RFC 1390                      IP Over FDDI                  January 1993
  173.  
  174.  
  175.    use ARP to translate Internet addresses to FDDI addresses when
  176.    needed.
  177.  
  178.    The ARP protocol has several fields that parameterize its use in any
  179.    specific context [2].  These fields are:
  180.  
  181.       hrd   16 - bits     The Hardware Type Code
  182.       pro   16 - bits     The Protocol Type Code
  183.       hln    8 - bits     Octets in each hardware address
  184.       pln    8 - bits     Octets in each protocol address
  185.       op    16 - bits     Operation Code
  186.  
  187.    The hardware type code assigned for IEEE 802 networks is 6 [13].  The
  188.    hardware type code assigned for Ethernet networks is 1 [13].
  189.    Unfortunately, differing values between Ethernet and IEEE 802
  190.    networks cause interoperability problems in bridged environments.  In
  191.    order to not preclude interoperability with Ethernets in a bridged
  192.    environment, ARP packets shall be transmitted with a hardware type
  193.    code of 1.  ARP packets shall be accepted if received with a hardware
  194.    type code of 1.
  195.  
  196.    The protocol type code for IP is 2048 [13].
  197.  
  198.    The hardware address length is 6.
  199.  
  200.    The protocol address length (for IP) is 4.
  201.  
  202.    The operation code is 1 for request and 2 for reply.
  203.  
  204.    In order to not preclude interoperability in a bridged environment,
  205.    the hardware addresses in ARP packets (ar$sha, ar$tha) must be
  206.    carried in "canonical" bit order, with the Group bit positioned as
  207.    the low order bit of the first octet.  As FDDI addresses are normally
  208.    expressed with the Group bit in the high order bit position, the
  209.    addresses must be bit-reversed within each octet.
  210.  
  211.    Although outside the scope of this document, it is recommended that
  212.    MAC addresses be represented in canonical order in all Network Layer
  213.    protocols carried within the information field of an FDDI frame.
  214.  
  215. Broadcast Address
  216.  
  217.    The broadcast Internet address (the address on that network with a
  218.    host part of all binary ones) must be mapped to the broadcast FDDI
  219.    address (of all binary ones) (see [14]).
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Katz                                                            [Page 4]
  227.  
  228. RFC 1390                      IP Over FDDI                  January 1993
  229.  
  230.  
  231. Multicast Support
  232.  
  233.    A method of supporting IP multicasting is specified in [15].  This
  234.    method shall be used in FDDI networks if IP multicasting is to be
  235.    supported.  The use of this method may require the ability to copy
  236.    frames addressed to any one of an arbitrary number of multicast
  237.    (group) addresses.
  238.  
  239.    An IP multicast address is mapped to an FDDI group address by placing
  240.    the low order 23 bits of the IP address into the low order 23 bits of
  241.    the FDDI group address 01-00-5E-00-00-00 (in "canonical" order).
  242.    [See 13, page 29.]
  243.  
  244.    For example, the IP multicast address:
  245.  
  246.             224.255.0.2
  247.  
  248.    maps to the FDDI group address:
  249.  
  250.             01-00-5E-7F-00-02
  251.  
  252.    in which the multicast (group) bit is the low order bit of the first
  253.    octet (canonical order).  When bit-reversed for transmission in the
  254.    destination MAC address field of an FDDI frame (native order), it
  255.    becomes:
  256.  
  257.             80-00-7A-FE-00-40
  258.  
  259.    that is, with the multicast (group) bit as the high order bit of the
  260.    first octet, that being the first bit transmitted on the medium.
  261.  
  262. Trailer Formats
  263.  
  264.    Some versions of Unix 4.x bsd use a different encapsulation method in
  265.    order to get better network performance with the VAX virtual memory
  266.    architecture.  Hosts directly connected to FDDI networks shall not
  267.    use trailers.
  268.  
  269. Byte Order
  270.  
  271.    As described in Appendix B of the Internet Protocol specification
  272.    [1], the IP datagram is transmitted over FDDI networks as a series of
  273.    8-bit bytes.  This byte transmission order has been called "big-
  274.    endian" [16].
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Katz                                                            [Page 5]
  283.  
  284. RFC 1390                      IP Over FDDI                  January 1993
  285.  
  286.  
  287. MAC Layer Details
  288.  
  289.    Packet Size
  290.  
  291.       The FDDI MAC specification [4] defines a maximum frame size of
  292.       9000 symbols (4500 octets) for all frame fields, including four
  293.       symbols (two octets) of preamble.  This leaves roughly 4470 octets
  294.       for data after the LLC/SNAP header is taken into account.
  295.  
  296.       However, in order to allow future extensions to the MAC header and
  297.       frame status fields, it is desirable to reserve additional space
  298.       for MAC overhead.
  299.  
  300.       Therefore, the MTU of FDDI networks shall be 4352 octets.  This
  301.       provides for 4096 octets of data and 256 octets of headers at the
  302.       network layer and above.  Implementations must not send packets
  303.       larger than the MTU.
  304.  
  305.       Gateway implementations must be prepared to accept packets as
  306.       large as the MTU and fragment them when necessary.  Gateway
  307.       implementations should be able to accept packets as large as can
  308.       be carried within a maximum size FDDI frame and fragment them.
  309.  
  310.       Host implementations should be prepared to accept packets as large
  311.       as the MTU; however, hosts must not send datagrams longer than 576
  312.       octets unless they have explicit knowledge that the destination is
  313.       prepared to accept them.  Host implementations may accept packets
  314.       as large as can be carried within a maximum size FDDI frame.  A
  315.       host may communicate its size preference in TCP-based applications
  316.       via the TCP Maximum Segment Size option [17].
  317.  
  318.       Datagrams on FDDI networks may be longer than the general Internet
  319.       default maximum packet size of 576 octets.  Hosts connected to an
  320.       FDDI network should keep this in mind when sending datagrams to
  321.       hosts that are not on the same local network.  It may be
  322.       appropriate to send smaller datagrams to avoid unnecessary
  323.       fragmentation at intermediate gateways.  Please see [17] for
  324.       further information.
  325.  
  326.       There is no minimum packet size restriction on FDDI networks.
  327.  
  328.       In order to not preclude interoperability with Ethernet in a
  329.       bridged environment, FDDI implementations must be prepared to
  330.       receive (and ignore) trailing pad octets.
  331.  
  332.    Other MAC Layer Issues
  333.  
  334.       The FDDI MAC specification does not require that 16-bit and 48-
  335.  
  336.  
  337.  
  338. Katz                                                            [Page 6]
  339.  
  340. RFC 1390                      IP Over FDDI                  January 1993
  341.  
  342.  
  343.       bit address stations be able to interwork fully.  It does,
  344.       however, require that 16-bit stations have full 48-bit
  345.       functionality, and that both types of stations be able to receive
  346.       frames sent to either size broadcast address.  In order to avoid
  347.       interoperability problems, only 48-bit addresses shall be used
  348.       with IP and ARP.
  349.  
  350.       The FDDI MAC specification defines two classes of LLC frames,
  351.       Asynchronous and Synchronous.  Asynchronous frames are further
  352.       controlled by a priority mechanism and two classes of token,
  353.       Restricted and Unrestricted.  Only the use of Unrestricted tokens
  354.       and Asynchronous frames are required by the standard for FDDI
  355.       interoperability.
  356.  
  357.       All IP and ARP frames shall be transmitted as Asynchronous LLC
  358.       frames using Unrestricted tokens, and the Priority value is a
  359.       matter of local convention.  Implementations should make the
  360.       priority a tunable parameter for future use.  It is recommended
  361.       that implementations provide for the reception of IP and ARP
  362.       packets in Synchronous frames, as well as Restricted Asynchronous
  363.       frames.
  364.  
  365.       After packet transmission, FDDI provides Frame Copied (C) and
  366.       Address Recognized (A) indicators.  The use of these indicators is
  367.       a local implementation decision.  Implementations may choose to
  368.       perform link-level retransmission, ARP cache entry invalidation,
  369.       etc., based on the values of these indicators and other
  370.       information.  The semantics of these indicators, especially in the
  371.       presence of bridges, are not well defined as of this writing.
  372.       Implementors are urged to follow the work of ANSI ASC X3T9.5 in
  373.       regard to this issue in order to avoid interoperability problems.
  374.  
  375. IEEE 802.2 Details
  376.  
  377.    While not necessary for supporting IP and ARP, all implementations
  378.    must support IEEE 802.2 standard Class I service in order to be
  379.    compliant with 802.2.  Described below is the minimum functionality
  380.    necessary for a conformant station.  Some of the functions are not
  381.    related directly to the support of the SNAP SAP (e.g., responding to
  382.    XID and TEST commands directed to the null or global SAP addresses),
  383.    but are part of a general LLC implementation.  Implementors should
  384.    consult IEEE Std. 802.2 [11] for details.
  385.  
  386.    802.2 Class I LLC requires the support of Unnumbered Information (UI)
  387.    Commands, eXchange IDentification (XID) Commands and Responses, and
  388.    TEST link (TEST) Commands and Responses.  Stations need not be able
  389.    to transmit XID and TEST commands, but must be able to transmit
  390.    responses.
  391.  
  392.  
  393.  
  394. Katz                                                            [Page 7]
  395.  
  396. RFC 1390                      IP Over FDDI                  January 1993
  397.  
  398.  
  399.    Encodings
  400.  
  401.       Command frames are identified by having the low order bit of the
  402.       SSAP address reset to zero.  Response frames have the low order
  403.       bit of the SSAP address set to one.
  404.  
  405.       The UI command has an LLC control field value of 3.
  406.  
  407.       The XID command/response has an LLC control field value of 175
  408.       (decimal) if the Poll/Final bit is off or 191 (decimal) if the
  409.       Poll/Final bit is on.
  410.  
  411.       The TEST command/response has an LLC control field value of 227
  412.       (decimal) if the Poll/Final bit is off or 243 (decimal) if the
  413.       Poll/Final bit is on.
  414.  
  415.    Elements of Procedure
  416.  
  417.       UI responses and UI commands with the Poll bit set shall be
  418.       ignored.  UI commands having other than the SNAP SAP in the DSAP
  419.       or SSAP fields shall not be processed as IP or ARP packets.
  420.  
  421.       When an XID or TEST command is received, an appropriate response
  422.       must be returned.  XID and TEST commands must be responded to only
  423.       if the DSAP is the SNAP SAP (170 decimal), the Null SAP (0
  424.       decimal), or the Global SAP (255 decimal).  XID and TEST commands
  425.       received with other DSAP values must not be responded to unless
  426.       the station supports the addressed service.  Responses to XID and
  427.       TEST frames shall be constructed as follows:
  428.  
  429.          Destination MAC:  Copied from Source MAC of the command
  430.          Source MAC:  Set to the address of the MAC receiving the
  431.                 command
  432.          DSAP:  Copied from SSAP of the command
  433.          SSAP:  Set to 171 decimal (SNAP SAP + Response bit) if the
  434.                 DSAP in the command was the SNAP SAP or the Global SAP;
  435.                 set to 1 decimal (Null SAP + Response bit) if the DSAP
  436.                 in the command was the Null SAP
  437.  
  438.       When responding to an XID or a TEST command, the value of the
  439.       Final bit in the response must be copied from the value of the
  440.       Poll bit in the command.
  441.  
  442.       XID response frames must include an 802.2 XID Information field of
  443.       129.1.0 indicating Class I (connectionless) service.
  444.  
  445.       TEST response frames must echo the information field received in
  446.       the corresponding TEST command frame.
  447.  
  448.  
  449.  
  450. Katz                                                            [Page 8]
  451.  
  452. RFC 1390                      IP Over FDDI                  January 1993
  453.  
  454.  
  455. Appendix on Numbers
  456.  
  457.    The IEEE specifies numbers as bit strings with the least significant
  458.    bit first, or bit-wise little-endian order.  The Internet protocols
  459.    are documented in bit-wise big-endian order.  This may cause some
  460.    confusion about the proper values to use for numbers.  Here are the
  461.    conversions for some numbers of interest.
  462.  
  463.        Number           IEEE        Internet    Internet
  464.                         Binary      Binary      Decimal
  465.  
  466.        UI               11000000    00000011    3
  467.        SAP for SNAP     01010101    10101010    170
  468.        Global SAP       11111111    11111111    255
  469.        Null SAP         00000000    00000000    0
  470.        XID              11110101    10101111    175
  471.        XID Poll/Final   11111101    10111111    191
  472.        XID Info                                 129.1.0
  473.        TEST             11000111    11100011    227
  474.        TEST Poll/Final  11001111    11110011    243
  475.  
  476. Differences between this document and RFC 1188
  477.  
  478.    The following is a summary of the differences between RFC 1188 and
  479.    this document:
  480.  
  481.       A reference to a future dual-MAC document has been removed.
  482.  
  483.       A statement of explicit intent to support FDDI/Ethernet
  484.       interoperability has been added.
  485.  
  486.       The acceptance of ARP frames bearing hardware type code 6 (IEEE
  487.       802) has been removed.
  488.  
  489.       The references have been updated.
  490.  
  491.       The author's address has been updated.
  492.  
  493. References
  494.  
  495.    [1] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
  496.        Sciences Institute, September 1981.
  497.  
  498.    [2] Plummer, D., "An Ethernet Address Resolution Protocol - or -
  499.        Converting Network Protocol Addresses to 48.bit Ethernet Address
  500.        for Transmission on Ethernet Hardware", RFC 826, MIT, November
  501.        1982.
  502.  
  503.  
  504.  
  505.  
  506. Katz                                                            [Page 9]
  507.  
  508. RFC 1390                      IP Over FDDI                  January 1993
  509.  
  510.  
  511.    [3] Postel, J., and J. Reynolds, "A Standard for the Transmission of
  512.        IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information
  513.        Sciences Institute, February 1988.
  514.  
  515.    [4] ISO, "Fiber Distributed Data Interface (FDDI) - Media Access
  516.        Control", ISO 9314-2, 1989.  See also ANSI X3.139-1987.
  517.  
  518.    [5] ISO, "Fiber Distributed Data Interface (FDDI) - Token Ring
  519.        Physical Layer Protocol", ISO 9314-1, 1989.  See also ANSI
  520.        X3.148-1988.
  521.  
  522.    [6] ISO, "Fiber Distributed Data Interface (FDDI) - Physical Layer
  523.        Medium Dependent", ISO DIS 9314-3, 1989.  See also ANSI X3.166-
  524.        199x.
  525.  
  526.    [7] ANSI, "FDDI Station Management", ANSI X3T9.5/84-49 Rev 7.1, 1992.
  527.  
  528.    [8] IEEE, "IEEE Standards for Local Area Networks: Carrier Sense
  529.        Multiple Access with Collision Detection (CSMA/CD) Access Method
  530.        and Physical Layer Specifications", IEEE, New York, New York,
  531.        1985.
  532.  
  533.    [9] IEEE, "IEEE Standards for Local Area Networks: Token-Passing Bus
  534.        Access Method and Physical Layer Specification", IEEE, New York,
  535.        New York, 1985.
  536.  
  537.   [10] IEEE, "IEEE Standards for Local Area Networks: Token Ring Access
  538.        Method and Physical Layer Specifications", IEEE, New York, New
  539.        York, 1985.
  540.  
  541.   [11] IEEE, "IEEE Standards for Local Area Networks: Logical Link
  542.        Control", IEEE, New York, New York, 1985.
  543.  
  544.   [12] IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.
  545.  
  546.   [13] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
  547.        USC/Information Sciences Institute, July 1992.
  548.  
  549.   [14] Braden, R., and J. Postel, "Requirements for Internet Gateways",
  550.        STD 4, RFC 1009, USC/Information Sciences Institute, June 1987.
  551.  
  552.   [15] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
  553.        1112, Stanford University, August 1989.
  554.  
  555.   [16] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,
  556.        October 1981.
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Katz                                                           [Page 10]
  563.  
  564. RFC 1390                      IP Over FDDI                  January 1993
  565.  
  566.  
  567.   [17] Postel, J., "The TCP Maximum Segment Size Option and Related
  568.        Topics", RFC 879, USC/Information Sciences Institute, November
  569.        1983.
  570.  
  571. Security Considerations
  572.  
  573.    Security issues are not discussed in this memo.
  574.  
  575. Author's Address
  576.  
  577.    Dave Katz
  578.    cisco Systems, Inc.
  579.    1525 O'Brien Dr.
  580.    Menlo Park, CA  94025
  581.  
  582.    Phone: (415) 688-8284
  583.    EMail: dkatz@cisco.com
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Katz                                                           [Page 11]
  619.  
  620.