From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1390.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc1390.txt (limited to 'doc/rfc/rfc1390.txt') 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 -- cgit v1.2.3