Proposed Standard for the Transmission of IP Datagrams over FDDI Networks
RFC 1188
| Document | Type |
RFC
- Draft Standard
(October 1990)
Obsoletes RFC 1103
|
|
|---|---|---|---|
| Author | Dave Katz | ||
| Last updated | 2013-03-02 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| IESG | Responsible AD | (None) | |
| Send notices to | (None) |
RFC 1188
Network Working Group D. Katz
Request for Comments: 1188 Merit/NSFNET
Obsoletes: RFC 1103 October 1990
A Proposed Standard for the Transmission of
IP Datagrams over FDDI Networks
Status of this Memo
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 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
networks. The encapsulation method used is described, as well as
various media-specific issues.
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.
Katz [Page 1]
RFC 1188 IP and ARP on FDDI Networks October 1990
"May" or "Optional"--the item is truly optional and may be
followed or ignored according to the needs of the implementor.
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.
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. Operation on dual MAC stations
will be described in a forthcoming document.
Katz [Page 2]
RFC 1188 IP and ARP on FDDI Networks October 1990
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
use ARP to translate Internet addresses to FDDI addresses when
Katz [Page 3]
RFC 1188 IP and ARP on FDDI Networks October 1990
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. Furthermore, ARP packets shall be accepted if received
with hardware type codes of either 1 or 6.
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]).
Multicast Support
A method of supporting IP multicasting is specified in [15]. This
Katz [Page 4]
RFC 1188 IP and ARP on FDDI Networks October 1990
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&Internet-Draft HIPv2 September 2014
HIP_SIGNATURE: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters for the packet that is
being calculated with Type values from 1 to (HIP_SIGNATURE's Type
value - 1).
During signature calculation, the following applies:
o In the HIP header, the Checksum field is set to zero.
o In the HIP header, the Header Length field value is calculated to
the beginning of the HIP_SIGNATURE parameter.
The parameter order is described in Section 5.2.1.
HIP_SIGNATURE_2: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters for the packet that is
being calculated with Type values ranging from 1 to
(HIP_SIGNATURE_2's Type value - 1).
During signature calculation, the following apply:
o In the HIP header, the Initiator's HIT field and Checksum fields
are set to zero.
o In the HIP header, the Header Length field value is calculated to
the beginning of the HIP_SIGNATURE_2 parameter.
o PUZZLE parameter's Opaque and Random #I fields are set to zero.
Parameter order is described in Section 5.2.1.
The signature calculation and verification process (the process
applies both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in the case
where HIP_SIGNATURE_2 is separately mentioned) is as follows:
Packet sender:
1. Create the HIP packet without the HIP_SIGNATURE parameter or any
other parameters that follow the HIP_SIGNATURE parameter.
2. Calculate the Length field and zero the Checksum field in the HIP
header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in
the HIP header as well as PUZZLE parameter's Opaque and Random #I
fields to zero.
Moskowitz, et al. Expires March 26, 2015 [Page 86]
Internet-Draft HIPv2 September 2014
3. Compute the signature using the private key corresponding to the
Host Identifier (public key).
4. Add the HIP_SIGNATURE parameter to the packet.
5. Add any parameters that follow the HIP_SIGNATURE parameter.
6. Recalculate the Length field in the HIP header, and calculate the
Checksum field.
Packet receiver:
1. Verify the HIP header Length field and checksum.
2. Save the contents of the HIP_SIGNATURE parameter and any other
parameters following the HIP_SIGNATURE parameter and remove them
from the packet.
3. Recalculate the HIP packet Length in the HIP header and clear the
Checksum field (set it to all zeros). In case of
HIP_SIGNATURE_2, set Initiator's HIT field in the HIP header as
well as PUZZLE parameter's Opaque and Random #I fields to zero.
4. Compute the signature and verify it against the received
signature using the packet sender's Host Identity (public key).
5. Restore the original packet by adding removed parameters (in step
2) and resetting the values that were set to zero (in step 3).
The verification can use either the HI received from a HIP packet,
the HI from a DNS query, if the FQDN has been received in the HOST_ID
packet or one received by some other means.
6.5. HIP KEYMAT Generation
HIP keying material is derived from the Diffie-Hellman session key,
Kij, produced during the HIP base exchange (see Section 4.1.3). The
Initiator has Kij during the creation of the I2 packet, and the
Responder has Kij once it receives the I2 packet. This is why I2 can
already contain encrypted information.
The KEYMAT is derived by feeding Kij into the key derivation function
defined by the DH Group ID. Currently the only key derivation
function defined in this document is the Hash-based Key Derivation
Function (HKDF) [RFC5869] using the RHASH hash function. Other
documents may define new DH Group IDs and corresponding key
distribution functions.
Moskowitz, et al. Expires March 26, 2015 [Page 87]
Internet-Draft HIPv2 September 2014
In the following we provide the details for deriving the keying
material using HKDF.
where
info = sort(HIT-I | HIT-R)
salt = #I | #J
Sort(HIT-I | HIT-R) is defined as the network byte order
concatenation of the two HITs, with the smaller HIT preceding the
larger HIT, resulting from the numeric comparison of the two HITs
interpreted as positive (unsigned) 128-bit integers in network byte
order. The #I and #J values are from the puzzle and its solution
that were exchanged in R1 and I2 messages when this HIP association
was set up. Both hosts have to store #I and #J values for the HIP
association for future use.
The initial keys are drawn sequentially in the order that is
determined by the numeric comparison of the two HITs, with comparison
method described in the previous paragraph. HOST_g denotes the host
with the greater HIT value, and HOST_l the host with the lower HIT
value.
The drawing order for the four initial keys is as follows:
HIP-gl encryption key for HOST_g's ENCRYPTED parameter
HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets
HIP-lg encryption key for HOST_l's ENCRYPTED parameter
HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets
The number of bits drawn for a given algorithm is the "natural" size
of the keys. For the mandatory algorithms, the following sizes
apply:
AES 128 or 256 bits
SHA-1 160 bits
SHA-256 256 bits
SHA-384 384 bits
NULL 0 bits
Moskowitz, et al. Expires March 26, 2015 [Page 88]
Internet-Draft HIPv2 September 2014
If other key sizes are used, they MUST be treated as different
encryption algorithms and defined separately.
6.6. Initiation of a HIP Base Exchange
An implementation may originate a HIP base exchange to another host
based on a local policy decision, usually triggered by an application
datagram, in much the same way that an IPsec IKE key exchange can
dynamically create a Security Association. Alternatively, a system
may initiate a HIP exchange if it has rebooted or timed out, or
otherwise lost its HIP state, as described in Section 4.5.4.
The implementation prepares an I1 packet and sends it to the IP
address that corresponds to the peer host. The IP address of the
peer host may be obtained via conventional mechanisms, such as DNS
lookup. The I1 packet contents are specified in Section 5.3.1. The
selection of which source or destination Host Identity to use, if a
Initiator or Responder has more than one to choose from, is typically
a policy decision.
The following steps define the conceptual processing rules for
initiating a HIP base exchange:
1. The Initiator receives one or more of the Responder's HITs and
one or more addresses either from a DNS lookup of the Responder's
FQDN, from some other repository, or from a local database. If
the Initiator does not know the Responder's HIT, it may attempt
opportunistic mode by using NULL (all zeros) as the Responder's
HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the
Initiator can choose from multiple Responder HITs, it selects a
HIT for which the Initiator supports the HIT Suite.
2. The Initiator sends an I1 packet to one of the Responder's
addresses. The selection of which address to use is a local
policy decision.
3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The
selection and order of DH Group IDs in the DH_GROUP_LIST MUST be
stored by the Initiator because this list is needed for later R1
processing. In most cases, the preferences regarding the DH
Groups will be static, so no per-association storage is
necessary.
4. Upon sending an I1 packet, the sender transitions to state
I1-SENT, starts a timer for which the timeout value SHOULD be
larger than the worst-case anticipated RTT. The sender SHOULD
also increment the trial counter associated with the I1.
Moskowitz, et al. Expires March 26, 2015 [Page 89]
Internet-Draft HIPv2 September 2014
5. Upon timeout, the sender SHOULD retransmit the I1 packet and
restart the timer, up to a maximum of I1_RETRIES_MAX tries.
6.6.1. Sending Multiple I1 Packets in Parallel
For the sake of minimizing the association establishment latency, an
implementation MAY send the same I1 packet to more than one of the
Responder's addresses. However, it MUST NOT send to more than three
(3) Responder addresses in parallel. Furthermore, upon timeout, the
implementation MUST refrain from sending the same I1 packet to
multiple addresses. That is, if it retries to initialize the
connection after a timeout, it MUST NOT send the I1 packet to more
than one destination address. These limitations are placed in order
to avoid congestion of the network, and potential DoS attacks that
might occur, e.g., because someone's claim to have hundreds or
thousands of addresses could generate a huge number of I1 packets
from the Initiator.
As the Responder is not guaranteed to distinguish the duplicate I1
packets it receives at several of its addresses (because it avoids
storing states when it answers back an R1 packet), the Initiator may
receive several duplicate R1 packets.
The Initiator SHOULD then select the initial preferred destination
address using the source address of the selected received R1, and use
the preferred address as a source address for the I2 packet.
Processing rules for received R1s are discussed in Section 6.8.
6.6.2. Processing Incoming ICMP Protocol Unreachable Messages
A host may receive an ICMP 'Destination Protocol Unreachable' message
as a response to sending a HIP I1 packet. Such a packet may be an
indication that the peer does not support HIP, or it may be an
attempt to launch an attack by making the Initiator believe that the
Responder does not support HIP.
When a system receives an ICMP 'Destination Protocol Unreachable'
message while it is waiting for an R1 packet, it MUST NOT terminate
waiting. It MAY continue as if it had not received the ICMP message,
and send a few more I1 packets. Alternatively, it MAY take the ICMP
message as a hint that the peer most probably does not support HIP,
and return to state UNASSOCIATED earlier than otherwise. However, at
minimum, it MUST continue waiting for an R1 packet for a reasonable
time before returning to UNASSOCIATED.
Moskowitz, et al. Expires March 26, 2015 [Page 90]
Internet-Draft HIPv2 September 2014
6.7. Processing Incoming I1 Packets
An implementation SHOULD reply to an I1 with an R1 packet, unless the
implementation is unable or unwilling to set up a HIP association.
If the implementation is unable to set up a HIP association, the host
SHOULD send an ICMP Destination Protocol Unreachable,
Administratively Prohibited, message to the I1 packet source IP
address. If the implementation is unwilling to set up a HIP
association, the host MAY ignore the I1 packet. This latter case may
occur during a DoS attack such as an I1 packet flood.
The implementation SHOULD be able to handle a storm of received I1
packets, discarding those with common content that arrive within a
small time delta.
A spoofed I1 packet can result in an R1 attack on a system. An R1
packet sender MUST have a mechanism to rate-limit R1 packets sent to
an address.
It is RECOMMENDED that the HIP state machine does not transition upon
sending an R1 packet.
The following steps define the conceptual processing rules for
responding to an I1 packet:
1. The Responder MUST check that the Responder's HIT in the received
I1 packet is either one of its own HITs or NULL. Otherwise it
must drop the packet.
2. If the Responder is in ESTABLISHED state, the Responder MAY
respond to this with an R1 packet, prepare to drop an existing
HIP security association with the peer, and stay at ESTABLISHED
state.
3. If the Responder is in I1-SENT state, it MUST make a comparison
between the sender's HIT and its own (i.e., the receiver's) HIT.
If the sender's HIT is greater than its own HIT, it should drop
the I1 packet and stay at I1-SENT. If the sender's HIT is
smaller than its own HIT, it SHOULD send the R1 packet and stay
at I1-SENT. The HIT comparison is performed as defined in
Section 6.5.
4. If the implementation chooses to respond to the I1 packet with an
R1 packet, it creates a new R1 or selects a precomputed R1
according to the format described in Section 5.3.2. It creates
or chooses an R1 that contains its most preferred DH public value
that is also contained in the DH_GROUP_LIST in the I1 packet. If
Moskowitz, et al. Expires March 26, 2015 [Page 91]
Internet-Draft HIPv2 September 2014
no suitable DH Group ID was contained in the DH_GROUP_LIST in the
I1 packet, it sends an R1 with any suitable DH public key.
5. If the received Responder's HIT in the I1 is NULL, the Responder
selects a HIT with a the same HIT Suite as the Initiator's HIT.
If this HIT Suite is not supported by the Responder, it SHOULD
select a REQUIRED HIT Suite from Section 5.2.10, which is
currently RSA/DSA/SHA-256. Other than that, selecting the HIT is
a local policy matter.
6. The responder expresses its supported HIP transport formats in
the TRANSPORT_FORMAT_LIST as described in Section 5.2.11. The
Responder MUST at least provide one payload transport format
type.
7. The Responder sends the R1 packet to the source IP address of the
I1 packet.
6.7.1. R1 Management
All compliant implementations MUST be able to produce R1 packets;
even if a device is configured by policy to only initiate
associations, it must be able to process I1s in case of recovery from
loss of state or key exhaustion. An R1 packet MAY be precomputed.
An R1 packet MAY be reused for time Delta T, which is implementation
dependent, and SHOULD be deprecated and not used once a valid
response I2 packet has been received from an Initiator. During an I1
message storm, an R1 packet MAY be re-used beyond this limit. R1
information MUST NOT be discarded until Delta S after T. Time S is
the delay needed for the last I2 packet to arrive back to the
Responder.
Implementations that support multiple DH groups MAY pre-compute R1
packets for each supported group so that incoming I1 packets with
different DH Group IDs in the DH_GROUP_LIST can be served quickly.
An implementation MAY keep state about received I1 packets and match
the received I2 packets against the state, as discussed in
Section 4.1.1.
6.7.2. Handling Malformed Messages
If an implementation receives a malformed I1 packet, it SHOULD NOT
respond with a NOTIFY message, as such practice could open up a
potential denial-of-service threat. Instead, it MAY respond with an
ICMP packet, as defined in Section 5.4.
Moskowitz, et al. Expires March 26, 2015 [Page 92]
Internet-Draft HIPv2 September 2014
6.8. Processing Incoming R1 Packets
A system receiving an R1 packet MUST first check to see if it has
sent an I1 packet to the originator of the R1 packet (i.e., it is in
state I1-SENT). If so, it SHOULD process the R1 as described below,
send an I2 packet, and transition to state I2-SENT, setting a timer
to protect the I2 packet. If the system is in state I2-SENT, it MAY
respond to the R1 packet if the R1 packet has a larger R1 generation
counter; if so, it should drop its state due to processing the
previous R1 packet and start over from state I1-SENT. If the system
is in any other state with respect to that host, the system SHOULD
silently drop the R1 packet.
When sending multiple I1 packets, an Initiator SHOULD wait for a
small amount of time after the first R1 reception to allow possibly
multiple R1 packets to arrive, and it SHOULD respond to an R1 packet
among the set with the largest R1 generation counter.
The following steps define the conceptual processing rules for
responding to an R1 packet:
1. A system receiving an R1 MUST first check to see if it has sent
an I1 packet to the originator of the R1 packet (i.e., it has a
HIP association that is in state I1-SENT and that is associated
with the HITs in the R1). Unless the I1 packet was sent in
opportunistic mode (see Section 4.1.8), the IP addresses in the
received R1 packet SHOULD be ignored by the R1 processing and,
when looking up the right HIP association, the received R1
packet SHOULD be matched against the associations using only the
HITs. If a match exists, the system should process the R1
packet as described below.
2. Otherwise, if the system is in any other state than I1-SENT or
I2-SENT with respect to the HITs included in the R1 packet, it
SHOULD silently drop the R1 packet and remain in the current
state.
3. If the HIP association state is I1-SENT or I2-SENT, the received
Initiator's HIT MUST correspond to the HIT used in the original
I1. Also, the Responder's HIT MUST correspond to the one used
in the I1, unless the I1 packet contained a NULL HIT.
4. The system SHOULD validate the R1 signature before applying
further packet processing, according to Section 5.2.15.
5. If the HIP association state is I1-SENT, and multiple valid R1
packets are present, the system MUST select from among the R1
packets with the largest R1 generation counter.
Moskowitz, et al. Expires March 26, 2015 [Page 93]
Internet-Draft HIPv2 September 2014
quot; order).
[See 13, page 20.]
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].
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
Katz [Page 5]
RFC 1188 IP and ARP on FDDI Networks October 1990
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-
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.
Katz [Page 6]
RFC 1188 IP and ARP on FDDI Networks October 1990
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.
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.
Katz [Page 7]
RFC 1188 IP and ARP on FDDI Networks October 1990
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 1188 IP and ARP on FDDI Networks October 1990
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
References
[1] Postel, J., "Internet Protocol", 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.
[3] Postel, J., and Reynolds, J., "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 6.0, 1990.
Katz [Page 9]
RFC 1188 IP and ARP on FDDI Networks October 1990
[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.K., and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
[14] Braden, R., and J. Postel, "Requirements for Internet Gateways",
RFC 1009, USC/Information Sciences Institute, June 1987.
[15] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
Stanford University, August 1989.
[16] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,
October 1981.
[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
Merit/NSFNET
1075 Beal Ave.
Ann Arbor, MI 48109
Phone: (313) 763-4898
EMail: dkatz@merit.edu
Katz [Page 10]
RFC 1188 IP and ARP on FDDI Networks October 1990
Katz [Page 11]