summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2467.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2467.txt')
-rw-r--r--doc/rfc/rfc2467.txt507
1 files changed, 507 insertions, 0 deletions
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]
+