doc: Add RFC documents

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]
+