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/rfc2467.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc2467.txt (limited to 'doc/rfc/rfc2467.txt') diff --git a/doc/rfc/rfc2467.txt b/doc/rfc/rfc2467.txt new file mode 100644 index 0000000..0b88298 --- /dev/null +++ b/doc/rfc/rfc2467.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group M. Crawford +Request for Comments: 2467 Fermilab +Obsoletes: 2019 December 1998 +Category: Standards Track + + + 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. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +1. Introduction + + This document specifies the frame format for transmission of IPv6 + packets and the method of forming IPv6 link-local addresses and + statelessly autoconfigured addresses on FDDI networks. It also + specifies the content of the Source/Target Link-layer Address option + used in Router Solicitation, Router Advertisement, Neighbor + Solicitation, Neighbor Advertisement and Redirect messages when those + messages are transmitted on an FDDI network. + + This document replaces RFC 2019, "Transmission of IPv6 Packets Over + FDDI", which will become historic. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. + +2. 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 [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 of 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 + + + +Crawford Standards Track [Page 1] + +RFC 2467 IPv6 over FDDI December 1998 + + + which specifies a smaller MTU, or by manual configuration of each + node. If a Router Advertisement received on an FDDI interface has an + MTU option specifying an MTU larger than 4352, or larger than a + 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" and the term FDDI includes CDDI. + +3. 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crawford Standards Track [Page 2] + +RFC 2467 IPv6 over FDDI December 1998 + + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+ + | FC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination | + +- -+ + | FDDI | + +- -+ + | Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source | + +- -+ + | FDDI | + +- -+ + | Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DSAP | SSAP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CTL | OUI ... | + +-+-+-+-+-+-+-+-+ + + | ... OUI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ethertype | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 | + +- -+ + | header | + +- -+ + | and | + +- -+ + / payload ... / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + (Each tic mark represents one bit.) + + 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. + + DSAP, SSAP Both the DSAP and SSAP fields shall contain the value AA + hexadecimal, indicating SNAP encapsulation. + + CTL The Control field shall be set to 03 hexadecimal, + indicating Unnumbered Information. + + + + +Crawford Standards Track [Page 3] + +RFC 2467 IPv6 over FDDI December 1998 + + + OUI The Organizationally Unique Identifier shall be set to + 000000 hexadecimal. + + Ethertype The Ethernet protocol type ("ethertype") shall be set to + the value 86DD hexadecimal. + +4. 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 [RFC + 1981], many others do not, or do so incorrectly. Use of IPv6 in a + bridged mixed-media environment must not depend on support from MAC + bridges, unless those bridges are known to correctly implement IPv6 + Path MTU Discovery [RFC 1981, ICMPV6]. + + For correct operation when mixed media are bridged together by + bridges which do not support IPv6 Path MTU Discovery, 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 a default MTU larger + than the smallest MTU. + +5. Stateless Autoconfiguration + + The Interface Identifier [AARCH] for an FDDI interface is based on + the EUI-64 identifier [EUI64] derived from the interface's built-in + 48-bit IEEE 802 address. The EUI-64 is formed as follows. + (Canonical bit order is assumed throughout. See [CANON] for a + caution on bit-order effects in LAN interfaces.) + + The OUI of the FDDI MAC address (the first three octets) becomes the + company_id of the EUI-64 (the first three octets). The fourth and + fifth octets of the EUI are set to the fixed value FFFE hexadecimal. + The last three octets of the FDDI MAC address become the last three + octets of the EUI-64. + + The Interface Identifier is then formed from the EUI-64 by + complementing the "Universal/Local" (U/L) bit, which is the next-to- + lowest order bit of the first octet of the EUI-64. For further + discussion on this point, see [ETHER] and [AARCH]. + + + + + + + + + + +Crawford Standards Track [Page 4] + +RFC 2467 IPv6 over FDDI December 1998 + + + For example, the Interface Identifier for an FDDI interface whose + built-in address is, in hexadecimal, + + 34-56-78-9A-BC-DE + + would be + + 36-56-78-FF-FE-9A-BC-DE. + + A different MAC address set manually or by software should not be + used to derive the Interface Identifier. If such a MAC address must + be used, its global uniqueness property should be reflected in the + value of the U/L bit. + + An IPv6 address prefix used for stateless autoconfiguration [ACONF] + of an FDDI interface must have a length of 64 bits. + +6. Link-Local Addresses + + The IPv6 link-local address [AARCH] for an FDDI interface is formed + by appending the Interface Identifier, as defined above, to the + prefix FE80::/64. + + 10 bits 54 bits 64 bits + +----------+-----------------------+----------------------------+ + |1111111010| (zeros) | Interface Identifier | + +----------+-----------------------+----------------------------+ + +7. Address Mapping -- Unicast + + The procedure for mapping IPv6 unicast 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. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +- FDDI -+ + | | + +- Address -+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Crawford Standards Track [Page 5] + +RFC 2467 IPv6 over FDDI December 1998 + + + 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 to + derive the Interface Identifier. + +8. Address Mapping -- Multicast + + An IPv6 packet with a multicast destination address DST, consisting + of the sixteen octets DST[1] through DST[16], 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. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DST[13] | DST[14] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DST[15] | DST[16] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +9. Differences From RFC 2019 + + The following are the functional differences between this + specification and RFC 2019. + + "FDDI adjacency detection" has been removed, due to recent work + in IEEE 802.1p. + + The Address Token, which was a node's 48-bit MAC address, is + replaced with the Interface Identifier, which is 64 bits in + length and based on the EUI-64 format [EUI64]. An IEEE-defined + mapping exists from 48-bit MAC addresses to EUI-64 form. + + A prefix used for stateless autoconfiguration must now be 64 bits + long rather than 80. The link-local prefix is also shortened to + 64 bits. + + + + + + +Crawford Standards Track [Page 6] + +RFC 2467 IPv6 over FDDI December 1998 + + +10. Security Considerations + + The method of derivation of Interface Identifiers from MAC addresses + is intended to preserve global uniqueness when possible. However, + there is no protection from duplication through accident or forgery. + +11. References + + [AARCH] Hinden, R. and S. Deering "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [CANON] Narten, T. and C. Burton, "A Caution On The Canonical + Ordering Of Link-Layer Addresses", RFC 2469, December 1998. + + [DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery + for IP Version 6 (IPv6)", RFC 2461, December 1998. + + [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet + Networks", RFC 2464, December 1998. + + [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", + http://standards.ieee.org/db/oui/tutorials/EUI64.html. + + [ICMPV6] Conta, A. and S. Deering, "Internet Control Message + Protocol (ICMPv6) for the Internet Protocol Version 6 + (IPv6) Specification", RFC 2463, December 1998. + + [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC 1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery + for IP version 6", RFC 1981, August 1996. + + [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + + + + + + +Crawford Standards Track [Page 7] + +RFC 2467 IPv6 over FDDI December 1998 + + +12. Author's Address + + Matt Crawford + Fermilab MS 368 + PO Box 500 + Batavia, IL 60510 + USA + + Phone: +1 630 840-3461 + EMail: crawdad@fnal.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crawford Standards Track [Page 8] + +RFC 2467 IPv6 over FDDI December 1998 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Crawford Standards Track [Page 9] + -- cgit v1.2.3