summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2019.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2019.txt')
-rw-r--r--doc/rfc/rfc2019.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc2019.txt b/doc/rfc/rfc2019.txt
new file mode 100644
index 0000000..03ce51e
--- /dev/null
+++ b/doc/rfc/rfc2019.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group M. Crawford
+Request for Comments: 2019 Fermilab
+Category: Standards Track October 1996
+
+
+
+ A Method for the Transmission of IPv6 Packets over FDDI Networks
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Introduction
+
+ This memo specifies the MTU and frame format for transmission of IPv6
+ [IPV6] packets on FDDI networks, including a method for MTU
+ determination in the presence of 802.1d bridges to other media. It
+ also specifies the method of forming IPv6 link-local addresses on
+ FDDI networks and the content of the Source/Target Link-layer Address
+ option used the the Router Solicitation, Router Advertisement,
+ Neighbor Solicitation, and Neighbor Advertisement messages described
+ in [DISC], when those messages are transmitted on an FDDI network.
+
+Maximum Transmission Unit
+
+ FDDI permits a frame length of 4500 octets (9000 symbols), including
+ at least 22 octets (44 symbols) of Data Link encapsulation when
+ long-format addresses are used. Subtracting 8 octets of LLC/SNAP
+ header, this would, in principle, allow the IPv6 packet in the
+ Information field to be up to 4470 octets. However, it is desirable
+ to allow for the variable sizes and possible future extensions to the
+ MAC header and frame status fields. The default MTU size for IPv6
+ packets on an FDDI network is therefore 4352 octets. This size may
+ be reduced by a Router Advertisement [DISC] containing an MTU option
+ which specifies a smaller MTU, or by manual configuration of a
+ smaller value on each node. If a Router Advertisement is received
+ with an MTU option specifying an MTU larger than the default or the
+ manually configured value, that MTU option may be logged to system
+ management but must be otherwise ignored.
+
+ For purposes of this document, information received from DHCP is
+ considered "manually configured".
+
+
+
+
+
+Crawford Standards Track [Page 1]
+
+RFC 2019 Transmission of IPv6 Packets Over FDDI October 1996
+
+
+Frame Format
+
+ FDDI provides both synchronous and asynchronous transmission, with
+ the latter class further subdivided by the use of restricted and
+ unrestricted tokens. Only asynchronous transmission with
+ unrestricted tokens is required for FDDI interoperability.
+ Accordingly, IPv6 packets shall be sent in asynchronous frames using
+ unrestricted tokens. The robustness principle dictates that nodes
+ should be able to receive synchronous frames and asynchronous frames
+ sent using restricted tokens.
+
+ IPv6 packets are transmitted in LLC/SNAP frames, using long-format
+ (48 bit) addresses. The data field contains the IPv6 header and
+ payload and is followed by the FDDI Frame Check Sequence, Ending
+ Delimiter, and Frame Status symbols.
+
+ +-------+ ^
+ | FC | |
+ +-------+-------+-------+-------+-------+-------+ |
+ | Destination FDDI address | |
+ +-------+-------+-------+-------+-------+-------+ FDDI
+ | Source FDDI address | header
+ +-------+-------+-------+-------+-------+-------+ |
+ | DSAP | SSAP | CTL | OUI | |
+ +-------+-------+-------+-------+-------+-------+ |
+ | Ethertype | v
+ +-------+-------+-------+-------+-------+------+------+
+ | IPv6 header and payload ... /
+ +-------+-------+-------+-------+-------+------+------+
+
+FDDI Header Fields:
+
+FC The Frame Code must be in the range 50 to 57 hexadecimal,
+ inclusive, with the three low order bits indicating the
+ frame priority. The Frame Code should be in the range 51 to
+ 57 hexadecimal, inclusive, for reasons given in the next
+ section.
+
+DSAP, SSAP Both the DSAP and SSAP fields shall contain the value AA
+ hexadecimal, indictating SNAP encapsulation.
+
+CTL The Control field shall be set to 03 hexadecimal, indicating
+ Unnumbered Information.
+
+OUI The Organizationally Unique Identifier shall be set to
+ 000000 hexadecimal.
+
+
+
+
+
+Crawford Standards Track [Page 2]
+
+RFC 2019 Transmission of IPv6 Packets Over FDDI October 1996
+
+
+Ethertype The ethernet protocol type ("ethertype") shall be set to the
+ value 86DD hexadecimal.
+
+Interaction with Bridges
+
+ 802.1d MAC bridges which connect different media, for example
+ Ethernet and FDDI, have become very widespread. Some of them do IPv4
+ packet fragmentation and/or support IPv4 Path MTU discovery [PMTU],
+ many others do not, or do so incorrectly. Use of IPv6 in a bridged
+ mixed-media environment should not depend on support from MAC
+ bridges.
+
+ For correct operation when mixed media are bridged together, the
+ smallest MTU of all the media must be advertised by routers in an MTU
+ option. If there are no routers present, this MTU must be manually
+ configured in each node which is connected to a medium with larger
+ default MTU. Multicast packets on such a bridged network must not be
+ larger than the smallest MTU of any of the bridged media. Often, the
+ subnetwork topology will support larger unicast packets to be
+ exchanged between certain pairs of nodes. To take advantage of
+ high-MTU paths when possible, nodes transmitting IPv6 on FDDI should
+ implement the following simple mechanism for "FDDI adjacency
+ detection".
+
+ A node which implements FDDI adjacency detection and has it enabled
+ on an FDDI interface must set a non-zero LLC priority in all Neighbor
+ Advertisement, Neighbor Solicitation and, if applicable, Router
+ Advertisement frames transmitted on that interface. (In IEEE 802
+ language, the user_priority parameter of the M_UNITDATA.request
+ primitive must not be zero.) If FDDI adjacency detection has been
+ disabled on an FDDI interface, the priority field of those frames
+ must be zero.
+
+ Note that an IPv6 frame which originated on an Ethernet, or traversed
+ an Ethernet, before being translated by an 802.1d bridge and
+ delivered to a node's FDDI interface will have zero in the priority
+ field, as required by [BRIDGE]. (There's a fine point here: a
+ conforming bridge may provide a management-settable Outbound User
+ Priority parameter for each port. However, the author is unaware of
+ any product that provides this optional capability and, in any case,
+ the default value for the parameter is zero.)
+
+
+
+
+
+
+
+
+
+
+Crawford Standards Track [Page 3]
+
+RFC 2019 Transmission of IPv6 Packets Over FDDI October 1996
+
+
+ If a node N1 receives, in an FDDI frame with a non-zero LLC priority,
+ a valid Router Advertisement, Neighbor Advertisement, or Neighbor
+ Solicitation from a node N2, then N1 may send unicast IPv6 packets to
+ N2 with sizes up to the default IPv6 FDDI MTU (4352 octets),
+ regardless of any smaller MTU configured manually or received in a
+ Router Advertisement MTU option. N2 may be the IPv6 destination or
+ the next hop router to the destination.
+
+ Nodes implementing FDDI adjacency detection must provide a
+ configuration option to disable the mechanism. This option may be
+ used when a smaller MTU is desired for reasons other than mixed-media
+ bridging. By default, FDDI adjacency detection should be enabled.
+
+ The only contemplated use of the LLC priority field of the FC octet
+ is to aid in per-destination MTU determination. It would be
+ sufficient for that purpose to require only that Router
+ Advertisements, Neighbor Advertisements, and Neighbor Solicitations
+ sent on FDDI always have non-zero priority. However, it may be
+ simpler or more useful to transmit all IPv6 packets on FDDI with
+ non-zero priority.
+
+Stateless Autoconfiguration and Link-Local Addresses
+
+ The address token [CONF] for an FDDI interface is the interface's
+ built-in 48-bit IEEE 802 address, in canonical bit order and with the
+ octet in the same order in which they would appear in the header of
+ an ethernet frame. (The individual/group bit is in the first octet
+ and the OUI is in the first three octets.) A different MAC address
+ set manually or by software should not be used as the address token.
+
+ An IPv6 address prefix used for stateless autoconfiguration of an
+ FDDI interface must be 80 bits in length.
+
+ The IPv6 Link-local address [AARCH] for an FDDI interface is formed
+ by appending the interface's IEEE 802 address to the 80-bit prefix
+ FE80::.
+
+ +-------+-------+-------+-------+-------+-------+------+------+
+ | FE 80 00 00 00 00 00 00 |
+ +-------+-------+-------+-------+-------+-------+------+------+
+ | 00 00 | FDDI Address |
+ +-------+-------+-------+-------+-------+-------+------+------+
+
+
+
+
+
+
+
+
+
+Crawford Standards Track [Page 4]
+
+RFC 2019 Transmission of IPv6 Packets Over FDDI October 1996
+
+
+Address Mapping -- Unicast
+
+ The procedure for mapping IPv6 addresses into FDDI link-layer
+ addresses is described in [DISC]. The Source/Target Link-layer
+ Address option has the following form when the link layer is FDDI.
+
+ +-------+-------+-------+-------+-------+-------+------+------+
+ | Type |Length | FDDI Address |
+ +-------+-------+-------+-------+-------+-------+------+------+
+
+Option fields:
+
+Type 1 for Source Link-layer address.
+ 2 for Target Link-layer address.
+
+Length 1 (in units of 8 octets).
+
+FDDI Address
+ The 48 bit FDDI IEEE 802 address, in canonical bit order.
+ This is the address the interface currently responds to, and
+ may be different from the built-in address used as the
+ address token.
+
+Address Mapping -- Multicast
+
+ An IPv6 packet with a multicast destination address DST is
+ transmitted to the FDDI multicast address whose first two octets are
+ the value 3333 hexadecimal and whose last four octets are the last
+ four octets of DST, ordered from more to least significant.
+
+ +-------+-------+-------+-------+-------+-------+
+ | 33 | 33 | DST13 | DST14 | DST15 | DST16 |
+ +-------+-------+-------+-------+-------+-------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford Standards Track [Page 5]
+
+RFC 2019 Transmission of IPv6 Packets Over FDDI October 1996
+
+
+Security Considerations
+
+ Security considerations are not addressed in this memo.
+
+Acknowledgments
+
+ Erik Nordmark contributed to the method for interaction with bridges.
+
+References
+
+ [AARCH] Hinden, and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 1884, December 1995.
+
+ [BRIDGE]ISO/IEC 10038 : 1993 [ANSI/IEEE Std 802.1D] Media access
+ control (MAC) bridges.
+
+ [CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 1971, August 1996.
+
+ [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
+ for IP Version 6 (IPv6), RFC 1970, August 1996.
+
+ [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 1883, August 1996.
+
+ [PMTU] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
+ November 1990.
+
+Author's Address
+
+ Matt Crawford
+ Fermilab MS 368
+ PO Box 500
+ Batavia, IL 60510
+ USA
+
+ Phone: +1 708 840-3461
+
+ EMail: crawdad@fnal.gov
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford Standards Track [Page 6]
+