summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2470.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2470.txt')
-rw-r--r--doc/rfc/rfc2470.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc2470.txt b/doc/rfc/rfc2470.txt
new file mode 100644
index 0000000..209e4fe
--- /dev/null
+++ b/doc/rfc/rfc2470.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group M. Crawford
+Request for Comments: 2470 Fermilab
+Category: Standards Track T. Narten
+ IBM
+ S. Thomas
+ TransNexus
+ December 1998
+
+
+ Transmission of IPv6 Packets over Token Ring 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 memo specifies the MTU and frame format for transmission of IPv6
+ packets on Token Ring networks. It also specifies the method of
+ forming IPv6 link-local addresses on Token Ring networks and the
+ content of the Source/Target Link-layer Address option used the
+ Router Solicitation, Router Advertisement, Redirect, Neighbor
+ Solicitation and Neighbor Advertisement messages when those messages
+ are transmitted on a Token Ring network.
+
+ Implementors should be careful to note that Token Ring adaptors
+ assume addresses are in non-canonical rather than canonical format,
+ requiring that special care be taken to insure that addresses are
+ processed correctly. See [CANON] for more details.
+
+ 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 [KWORD].
+
+2. Maximum Transmission Unit
+
+ IEEE 802.5 networks have a maximum frame size based on the maximum
+ time a node may hold the token. This time depends on many factors
+ including the data signaling rate and the number of nodes on the
+ ring. Because the maximum frame size varies, implementations must
+
+
+
+Crawford, et. al. Standards Track [Page 1]
+
+RFC 2470 IPv6 over Token Ring December 1998
+
+
+ rely on manual configuration or router advertisements [DISC] to
+ determine actual MTU sizes. Common default values include
+ approximately 2000, 4000, and 8000 octets.
+
+ In the absence of any other information, an implementation should use
+ a default MTU of 1500 octets. This size offers compatibility with all
+ common 802.5 defaults, as well as with Ethernet LANs in an
+ environment using transparent bridging.
+
+ In an environment using source route bridging, the process of
+ discovering the MAC-level path to a neighbor can yield the MTU for
+ the path to that neighbor. The information is contained in the
+ largest frame (LF) subfield of the routing information field. This
+ field limits the size of the information field of frames to that
+ destination, and that information field includes both the LLC [LLC]
+ header and the IPv6 datagram. Since, for IPv6, the LLC header is
+ always 8 octets in length, the IPv6 MTU can be found by subtracting 8
+ from the maximum frame size defined by the LF subfield. If an
+ implementation uses this information to determine MTU sizes, it must
+ maintain separate MTU values for each neighbor.
+
+ A detailed list of the LF values and the resulting maximum frame size
+ can be found in [BRIDGE]. To illustrate the calculation of IPv6 MTU,
+ the following table lists several common values. Note that some of
+ the 802.1D LF values would result in an IP MTU less than 1280 bytes.
+ This size is less than the IPv6 minimum, and communication across
+ paths with those MTUs is generally not possible using IPv6.
+
+ LF (base) LF (extension) MAC MTU IP MTU
+ 001 000 1470 1462
+ 010 000 2052 2044
+ 011 000 4399 4391
+ 100 000 8130 8122
+ 101 000 11407 11399
+ 110 000 17749 17741
+ 111 000 41600 41592
+
+ When presented with conflicting MTU values from several sources, an
+ implementation should choose from those sources according to the
+ following priorities:
+
+ 1. Largest Frame values from source route bridging
+ (only for specific, unicast destinations), but only if not
+ greater than value from any router advertisements
+
+ 2. Router advertisements, but only if not greater than any manual
+ configuration (including DHCP)
+
+
+
+
+Crawford, et. al. Standards Track [Page 2]
+
+RFC 2470 IPv6 over Token Ring December 1998
+
+
+ 3. Manual configuration (including DHCP)
+
+ 4. Default of 1500
+
+3. Frame Format
+
+ IPv6 packets are transmitted in LLC/SNAP frames. The data field
+ contains the IPv6 header and payload. The following figure shows a
+ complete 802.5 frame containing an IPv6 datagram.
+
+ +-------+-------+-------+-------+
+ | SD | AC | FC | |
+ +-----------------------+ |
+ | Destination Address |
+ | +-----------------------+
+ | | Source |
+ +-------+ Address +-------+
+ | | DSAP |
+ +-------+-------+-------+-------+
+ | SSAP | CTL | OUI |
+ +-------+-------+-------+-------+
+ | OUI | EtherType | |
+ +-------+---------------+ |
+ | |
+ ~ IPv6 header and payload... ~
+ | |
+ +-------------------------------+
+ | FCS |
+ +-------+-------+---------------+
+ | ED | FS |
+ +-------+-------+
+
+ Token Ring Header Fields
+
+ SD: Starting Delimiter
+
+ AC: Access Control
+
+ FC: Frame Control
+
+ Destination Address: 48-bit IEEE address of destination
+ station
+
+ Source Address: 48-bit IEEE address of source station
+
+ DSAP: Destination Service Access Point (for LLC/SNAP
+ format, shall always contain the value 0xAA)
+
+
+
+
+Crawford, et. al. Standards Track [Page 3]
+
+RFC 2470 IPv6 over Token Ring December 1998
+
+
+ SSAP: Source Service Access Point (for LLC/SNAP format,
+ shall always contain the value 0xAA)
+
+ CTL: Control Field (for Unnumbered Information, shall
+ always contain the value 0x03)
+
+ OUI: Organizationally Unique Identifier (for EtherType
+ encoding, shall always contain the value 0x000000)
+
+ EtherType: Protocol type of encapsulated payload (for
+ IPv6, shall always contain the value 0x86DD)
+
+ FCS: Frame Check Sequence
+
+ ED: Ending Delimiter
+
+ FS: Frame Status
+
+ In the presence of source route bridges, a routing information field
+ (RIF) may appear immediately after the source address. A RIF is
+ present in frames when the most significant bit of the source address
+ is set to one. (This is the bit whose position corresponds to that of
+ the Individual/Group bit in the Destination Address.)
+
+ The RIF is a variable-length field that (when present) contains a
+ two-octet Routing Control (RC) header, followed by zero or more two-
+ octet Route Designator fields:
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Routing Control: |Bcast| Length |D| LF |rsvd |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Route Designator 1: | Segment 1 |Bridge1|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ... ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Route Designator N: | Segment N |BridgeN|
+ (0 <= N <= 7) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Route Designator Fields:
+
+ Bcast: Broadcast Indicator, Defined values:
+
+ 10x: All Routes Explorer
+ 11x: Spanning Tree Explorer
+ 0xx: Specifically Routed Frame
+
+
+
+Crawford, et. al. Standards Track [Page 4]
+
+RFC 2470 IPv6 over Token Ring December 1998
+
+
+
+ Length: Total length of RIF field in octets
+
+ D: Direction of source route. A value of 0 means that
+ the left-to-right sequence of Route Designators
+ provides the path from the sender to recipient. A
+ value of 0 indicates the sequence goes from
+ recipient to sender.
+
+ LF: Largest Frame
+
+ rsvd: Reserved
+
+ On transmission, the Route Designator fields give the sequence of
+ (bridge, LAN segment) numbers the packet is to traverse. It is the
+ responsibility of the sender to provide this sequence for
+ Specifically Routed Frames, i.e., unicast IP datagrams.
+
+4. Stateless Autoconfiguration
+
+ The Interface Identifier [AARCH] for a Token Ring interface is based
+ on the EUI-64 identifier [EUI64] derived from the interface's built-
+ in 48-bit IEEE 802 address. The OUI of the Token Ring 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 Token Ring
+ 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. Complementing
+ this bit will generally change a 0 value to a 1, since an interface's
+ built-in address is expected to be from a universally administered
+ address space and hence have a globally unique value. A universally
+ administered IEEE 802 address or an EUI-64 is signified by a 0 in the
+ U/L bit position, while a globally unique IPv6 Interface Identifier
+ is signified by a 1 in the corresponding position. For further
+ discussion on this point, see [AARCH].
+
+ For example, the Interface Identifier for a Token Ring interface
+ whose built-in address is, in hexadecimal and in canonical bit order,
+
+ 34-56-78-9A-BC-DE
+
+ would be
+
+ 36-56-78-FF-FE-9A-BC-DE.
+
+
+
+
+Crawford, et. al. Standards Track [Page 5]
+
+RFC 2470 IPv6 over Token Ring December 1998
+
+
+ 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 of a
+ Token Ring interface must have a length of 64 bits.
+
+5. Link-Local Address
+
+ The IPv6 link-local address [AARCH] for a Token Ring interface is
+ formed by appending the Interface Identifer, as defined above, to the
+ prefix FE80::/64.
+
+ 10 bits 54 bits 64 bits
+ +----------+-----------------------+----------------------------+
+ |1111111010| (zeros) | Interface Identifier |
+ +----------+-----------------------+----------------------------+
+
+6. Address Mapping -- Unicast
+
+ The procedure for mapping unicast IPv6 addresses into Token Ring
+ link-layer addresses is described in [DISC]. The Source/Target Link-
+ layer Address option has the following form when the link layer is
+ Token Ring.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +- Token Ring -+
+ | |
+ +- Address -+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Option fields:
+
+ Type: 1 for Source Link-layer address.
+ 2 for Target Link-layer address.
+
+ Length: 1 (in units of 8 octets).
+
+
+
+
+
+
+
+Crawford, et. al. Standards Track [Page 6]
+
+RFC 2470 IPv6 over Token Ring December 1998
+
+
+ Token Ring Address: The 48 bit Token Ring 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.
+
+ When source routing bridges are used, the source route for
+ the path to a destination can be extracted from the RIF
+ field of received Neighbor Advertisement messages. Note that
+ the RIF field of received packets can be reversed into a
+ source route suitable for transmitting return traffic by
+ toggling the value of the 'D' bit and insuring that the
+ Bcast field is set to indicate a Specifically Routed Frame.
+
+7. Address Mapping -- Multicast
+
+ All IPv6 packets with multicast destination addresses are transmitted
+ to Token Ring functional addresses. The following table shows the
+ specific mapping between the IPv6 addresses and Token Ring functional
+ addresses (in canonical form). Note that protocols other than IPv6
+ may use these same functional addresses, so all Token Ring frames
+ destined to these functional addresses are not guaranteed to be IPv6
+ datagrams.
+
+ MAC Addr (canonical) IPv6 Multicast Addresses
+
+ 03-00-80-00-00-00 All-Nodes (FF01::1 and FF02::1) and
+ solicited node (FF02:0:0:0:0:1:FFXX:XXXX)
+ addresses
+
+ 03-00-40-00-00-00 All-Routers addresses (FF0X::2)
+
+ 03-00-00-80-00-00 any other multicast address with three
+ least significant bits = 000
+
+ 03-00-00-40-00-00 any other multicast address with three
+ least significant bits = 001
+
+ 03-00-00-20-00-00 any other multicast address with three
+ least significant bits = 010
+
+ 03-00-00-10-00-00 any other multicast address with three
+ least significant bits = 011
+
+ 03-00-00-08-00-00 any other multicast address with three
+ least significant bits = 100
+
+
+
+
+
+Crawford, et. al. Standards Track [Page 7]
+
+RFC 2470 IPv6 over Token Ring December 1998
+
+
+ 03-00-00-04-00-00 any other multicast address with three
+ least significant bits = 101
+
+ 03-00-00-02-00-00 any other multicast address with three
+ least significant bits = 110
+
+ 03-00-00-01-00-00 any other multicast address with three
+ least significant bits = 111
+
+ In a bridged token ring network, all multicast packets SHOULD be sent
+ with a RIF header specifying the use of the Spanning Tree Explorer.
+
+ Note: it is believed that some (very) old bridge implementations do
+ not properly support the Spanning Tree Explorer mechanism. In such
+ environments, multicast traffic sent through bridges must use a RIF
+ with the All Routes Explorer. Consequently, an implementation MAY
+ wish to allow the sending of IP multicast traffic using an All Routes
+ Explorer. However, such an ability must be configurable by a system
+ administrator and the default setting of the switch MUST be to use
+ the Spanning Tree Explorer.
+
+8. Security Considerations
+
+ Token Ring, like most broadcast LAN technologies, has inherent
+ security vulnerabilities. For example, any sender can claim the
+ identity of another and forge traffic. It is the responsibility of
+ higher layers to take appropriate steps in those environments where
+ such vulnerabilities are unacceptable.
+
+9. Acknowledgments
+
+ Several members of the IEEE 802.5 Working Group contributed their
+ knowledge and experience to the drafting of this specification,
+ including Jim, Andrew Draper, George Lin, John Messenger, Kirk
+ Preiss, and Trevor Warwick. The author would also like to thank many
+ members of the IPng working group for their advice and suggestions,
+ including Ran Atkinson, Scott Bradner, Steve Deering, Francis Dupont,
+ Robert Elz, and Matt Thomas. A special thanks is due Steve Wise, who
+ gave the most relevant advice of all by actually trying to implement
+ this specification while it was in progress.
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et. al. Standards Track [Page 8]
+
+RFC 2470 IPv6 over Token Ring December 1998
+
+
+10. References
+
+ [802.5] 8802-5 : 1995 (ISO/IEC) [ANSI/IEEE 802.5, 1995
+ Edition] Information technology--Telecommunications and
+ information exchange between systems--Local and
+ metropolitan area networks--Specific requirements-- Part 5:
+ Token ring access method and physical layer specification.
+
+ [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.
+
+ [BRIDGE] 10038: 1993 (ISO/IEC) [ANSI/IEEE Std 802.1D, 1993 Edition]
+ Information technology--Telecommunications and information
+ exchange between systems--Local area networks--Media access
+ control (MAC) bridges.
+
+ [CANON] Narten, T. and C. Burton, "A Caution on Canonical Bit Order
+ Of Link-Layer Addresses", RFC 2469, December 1998.
+
+ [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 2461, December
+ 1998.
+
+ [EUI64] "64-Bit Global Identifier Format Tutorial", http:
+ //standards.ieee.org/db/oui/tutorials/EUI64.html.
+
+ [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [KWORD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels," BCP 14, RFC 2119, March 1997.
+
+ [LLC] 8802-2 : 1994 (ISO/IEC) [ANSI/IEEE 802.2, 1994 Edition]
+ Information technology--Telecommunications and information
+ exchange between systems--Local and Metropolitan area
+ networks--Specific requirements-- Part 2: Logical link
+ control.
+
+
+
+
+
+
+
+
+Crawford, et. al. Standards Track [Page 9]
+
+RFC 2470 IPv6 over Token Ring December 1998
+
+
+11. Authors' Addresses
+
+ Matt Crawford
+ Fermilab MS 368
+ PO Box 500
+ Batavia, IL 60510 USA
+
+ Phone: +1 630 840 3461
+ EMail: crawdad@fnal.gov
+
+
+ Thomas Narten
+ IBM Corporation
+ P.O. Box 12195
+ Research Triangle Park, NC 27709-2195 USA
+
+ Phone: +1 919 254 7798
+ EMail: narten@raleigh.ibm.com
+
+
+ Stephen Thomas
+ TransNexus
+ 430 Tenth Street NW Suite N204
+ Atlanta, GA 30318 USA
+
+ Phone: +1 404 872 4745
+ EMail: stephen.thomas@transnexus.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et. al. Standards Track [Page 10]
+
+RFC 2470 IPv6 over Token Ring December 1998
+
+
+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, et. al. Standards Track [Page 11]
+