draft-ietf-fddi-ipoverfddi-00.txt   rfc1390.txt 
Network Working Group D. Katz Network Working Group D. Katz
Internet Draft cisco Systems, Inc. Request for Comments: 1390 cisco Systems, Inc.
September 14, 1992 STD: 36 January 1993
Transmission of IP and ARP over FDDI Networks Transmission of IP and ARP over FDDI Networks
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This RFC specifies an IAB standards track protocol for the Internet
documents of the Internet Engineering Task Force (IETF), its Areas, community, and requests discussion and suggestions for improvements.
and its Working Groups. Note that other groups may also distribute Please refer to the current edition of the "IAB Official Protocol
working documents as Internet Drafts. Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Internet Drafts are draft documents valid for a maximum of six Abstract
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.'' Please check the 1id-
abstracts.txt listing contained in the internet-drafts Shadow
Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any
Internet Draft.
This memo defines a method of encapsulating the Internet Protocol This memo defines a method of encapsulating the Internet Protocol
(IP) datagrams and Address Resolution Protocol (ARP) requests and (IP) datagrams and Address Resolution Protocol (ARP) requests and
replies on Fiber Distributed Data Interface (FDDI) Networks. This replies on Fiber Distributed Data Interface (FDDI) Networks.
document specifies a protocol on the IAB Standards Track 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.
This proposal is the product of the IP over FDDI Working Group of the
Internet Engineering Task Force (IETF). Comments on this memo should
be submitted to the IETF IP over FDDI Working Group Chair.
Distribution of this memo is unlimited.
Abstract
This document specifies a method for the use of IP and ARP on FDDI This RFC is the product of the IP over FDDI Working Group of the
networks. The encapsulation method used is described, as well as Internet Engineering Task Force (IETF).
various media-specific issues.
Acknowledgments Acknowledgments
This memo draws heavily in both concept and text from RFC 1042 [3], This memo draws heavily in both concept and text from RFC 1042 [3],
written by Jon Postel and Joyce K. Reynolds of USC/Information written by Jon Postel and Joyce K. Reynolds of USC/Information
Sciences Institute. The author would also like to acknowledge the Sciences Institute. The author would also like to acknowledge the
contributions of the IP Over FDDI Working Group of the IETF, members contributions of the IP Over FDDI Working Group of the IETF, members
of ANSI ASC X3T9.5, and others in the FDDI community. of ANSI ASC X3T9.5, and others in the FDDI community.
Conventions Conventions
skipping to change at page 2, line 36 skipping to change at page 2, line 18
interoperable implementations for transmitting IP datagrams [1] and interoperable implementations for transmitting IP datagrams [1] and
ARP requests and replies [2]. ARP requests and replies [2].
The Fiber Distributed Data Interface (FDDI) specifications define a The Fiber Distributed Data Interface (FDDI) specifications define a
family of standards for Local Area Networks (LANs) that provides the family of standards for Local Area Networks (LANs) that provides the
Physical Layer and Media Access Control Sublayer of the Data Link Physical Layer and Media Access Control Sublayer of the Data Link
Layer as defined by the ISO Open System Interconnection Reference Layer as defined by the ISO Open System Interconnection Reference
Model (ISO/OSI). Documents are in various stages of progression Model (ISO/OSI). Documents are in various stages of progression
toward International Standardization for Media Access Control (MAC) toward International Standardization for Media Access Control (MAC)
[4], Physical Layer Protocol (PHY) [5], Physical Layer Medium [4], Physical Layer Protocol (PHY) [5], Physical Layer Medium
Dependent (PMD) [6], and Station Management (SMT) [7]. The family Dependent (PMD) [6], and Station Management (SMT) [7]. The family of
of FDDI standards corresponds to the IEEE 802 MAC layer standards FDDI standards corresponds to the IEEE 802 MAC layer standards [8, 9,
[8, 9, 10]. 10].
The remainder of the Data Link Service is provided by the IEEE 802.2 The remainder of the Data Link Service is provided by the IEEE 802.2
Logical Link Control (LLC) service [11]. The resulting stack of Logical Link Control (LLC) service [11]. The resulting stack of
services appears as follows: services appears as follows:
+-------------+ +-------------+
| IP/ARP | | IP/ARP |
+-------------+ +-------------+
| 802.2 LLC | | 802.2 LLC |
+-------------+-----+ +-------------+-----+
skipping to change at page 5, line 43 skipping to change at page 5, line 16
A method of supporting IP multicasting is specified in [15]. This A method of supporting IP multicasting is specified in [15]. This
method shall be used in FDDI networks if IP multicasting is to be 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 supported. The use of this method may require the ability to copy
frames addressed to any one of an arbitrary number of multicast frames addressed to any one of an arbitrary number of multicast
(group) addresses. (group) addresses.
An IP multicast address is mapped to an FDDI group address by placing 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 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). the FDDI group address 01-00-5E-00-00-00 (in "canonical" order).
[See 13, page 20.] [See 13, page 29.]
For example, the IP multicast address: For example, the IP multicast address:
224.255.0.2 224.255.0.2
maps to the FDDI group address: maps to the FDDI group address:
01-00-5E-7F-00-02 01-00-5E-7F-00-02
in which the multicast (group) bit is the low order bit of the first in which the multicast (group) bit is the low order bit of the first
octet (canonical order). When bit-reversed for transmission in the octet (canonical order). When bit-reversed for transmission in the
destination MAC address field of an FDDI frame (native order), it destination MAC address field of an FDDI frame (native order), it
becomes: becomes:
80-00-7A-FE-00-40 80-00-7A-FE-00-40
that is, with the multicast (group) bit as the high order bit of the 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. first octet, that being the first bit transmitted on the medium.
Trailer Formats Trailer Formats
Some versions of Unix 4.x bsd use a different encapsulation method in Some versions of Unix 4.x bsd use a different encapsulation method in
order to get better network performance with the VAX virtual memory order to get better network performance with the VAX virtual memory
architecture. Hosts directly connected to FDDI networks shall not architecture. Hosts directly connected to FDDI networks shall not
use trailers. use trailers.
skipping to change at page 7, line 10 skipping to change at page 6, line 33
Gateway implementations must be prepared to accept packets as Gateway implementations must be prepared to accept packets as
large as the MTU and fragment them when necessary. Gateway large as the MTU and fragment them when necessary. Gateway
implementations should be able to accept packets as large as can implementations should be able to accept packets as large as can
be carried within a maximum size FDDI frame and fragment them. be carried within a maximum size FDDI frame and fragment them.
Host implementations should be prepared to accept packets as large Host implementations should be prepared to accept packets as large
as the MTU; however, hosts must not send datagrams longer than 576 as the MTU; however, hosts must not send datagrams longer than 576
octets unless they have explicit knowledge that the destination is octets unless they have explicit knowledge that the destination is
prepared to accept them. Host implementations may accept packets prepared to accept them. Host implementations may accept packets
as large as can be carried within a maximum size FDDI frame. A as large as can be carried within a maximum size FDDI frame. A
host may communicate its size preference in TCP- based host may communicate its size preference in TCP-based applications
applications via the TCP Maximum Segment Size option [17]. via the TCP Maximum Segment Size option [17].
Datagrams on FDDI networks may be longer than the general Internet Datagrams on FDDI networks may be longer than the general Internet
default maximum packet size of 576 octets. Hosts connected to an default maximum packet size of 576 octets. Hosts connected to an
FDDI network should keep this in mind when sending datagrams to FDDI network should keep this in mind when sending datagrams to
hosts that are not on the same local network. It may be hosts that are not on the same local network. It may be
appropriate to send smaller datagrams to avoid unnecessary appropriate to send smaller datagrams to avoid unnecessary
fragmentation at intermediate gateways. Please see [17] for fragmentation at intermediate gateways. Please see [17] for
further information. further information.
There is no minimum packet size restriction on FDDI networks. There is no minimum packet size restriction on FDDI networks.
skipping to change at page 10, line 10 skipping to change at page 9, line 31
XID Poll/Final 11111101 10111111 191 XID Poll/Final 11111101 10111111 191
XID Info 129.1.0 XID Info 129.1.0
TEST 11000111 11100011 227 TEST 11000111 11100011 227
TEST Poll/Final 11001111 11110011 243 TEST Poll/Final 11001111 11110011 243
Differences between this document and RFC 1188 Differences between this document and RFC 1188
The following is a summary of the differences between RFC 1188 and The following is a summary of the differences between RFC 1188 and
this document: this document:
A reference to a future dual-MAC document has been removed. A reference to a future dual-MAC document has been removed.
A statement of explicit intent to support FDDI/Ethernet A statement of explicit intent to support FDDI/Ethernet
interoperability has been added. interoperability has been added.
The acceptance of ARP frames bearing hardware type code 6 (IEEE The acceptance of ARP frames bearing hardware type code 6 (IEEE
802) has been removed. 802) has been removed.
The references have been updated. The references have been updated.
The author's address has been updated. The author's address has been updated.
References References
[1] Postel, J., "Internet Protocol", RFC 791, USC/Information [1] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
Sciences Institute, September 1981. Sciences Institute, September 1981.
[2] Plummer, D., "An Ethernet Address Resolution Protocol - or - [2] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet Address Converting Network Protocol Addresses to 48.bit Ethernet Address
for Transmission on Ethernet Hardware", RFC 826, MIT, November for Transmission on Ethernet Hardware", RFC 826, MIT, November
1982. 1982.
[3] Postel, J., and Reynolds, J., "A Standard for the Transmission of [3] Postel, J., and J. Reynolds, "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information
Sciences Institute, February 1988. Sciences Institute, February 1988.
[4] ISO, "Fiber Distributed Data Interface (FDDI) - Media Access [4] ISO, "Fiber Distributed Data Interface (FDDI) - Media Access
Control", ISO 9314-2, 1989. See also ANSI X3.139-1987. Control", ISO 9314-2, 1989. See also ANSI X3.139-1987.
[5] ISO, "Fiber Distributed Data Interface (FDDI) - Token Ring [5] ISO, "Fiber Distributed Data Interface (FDDI) - Token Ring
Physical Layer Protocol", ISO 9314-1, 1989. See also ANSI Physical Layer Protocol", ISO 9314-1, 1989. See also ANSI
X3.148-1988. X3.148-1988.
skipping to change at page 11, line 19 skipping to change at page 10, line 40
[10] IEEE, "IEEE Standards for Local Area Networks: Token Ring Access [10] IEEE, "IEEE Standards for Local Area Networks: Token Ring Access
Method and Physical Layer Specifications", IEEE, New York, New Method and Physical Layer Specifications", IEEE, New York, New
York, 1985. York, 1985.
[11] IEEE, "IEEE Standards for Local Area Networks: Logical Link [11] IEEE, "IEEE Standards for Local Area Networks: Logical Link
Control", IEEE, New York, New York, 1985. Control", IEEE, New York, New York, 1985.
[12] IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989. [12] IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.
[13] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC 1340, [13] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992. USC/Information Sciences Institute, July 1992.
[14] Braden, R., and J. Postel, "Requirements for Internet Gateways", [14] Braden, R., and J. Postel, "Requirements for Internet Gateways",
RFC 1009, USC/Information Sciences Institute, June 1987. STD 4, RFC 1009, USC/Information Sciences Institute, June 1987.
[15] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, [15] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
Stanford University, August 1989. 1112, Stanford University, August 1989.
[16] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE, [16] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,
October 1981. October 1981.
[17] Postel, J., "The TCP Maximum Segment Size Option and Related [17] Postel, J., "The TCP Maximum Segment Size Option and Related
Topics", RFC 879, USC/Information Sciences Institute, November Topics", RFC 879, USC/Information Sciences Institute, November
1983. 1983.
Security Considerations Security Considerations
 End of changes. 21 change blocks. 
55 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/