Network Working Group M. Crawford
Request for Comments: 2467 Fermilab
Obsoletes: 2019 December 1998
Category: Standards Track
Network Working Group M. Crawford
Request for Comments: 2467 Fermilab
Obsoletes: 2019 December 1998
Category: Standards Track
Transmission of IPv6 Packets over FDDI Networks
通过FDDI网络传输IPv6数据包
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件规定了IPv6数据包传输的帧格式以及在FDDI网络上形成IPv6链路本地地址和无状态自动配置地址的方法。它还指定在FDDI网络上传输路由器请求、路由器通告、邻居请求、邻居通告和重定向消息时使用的源/目标链路层地址选项的内容。
This document replaces RFC 2019, "Transmission of IPv6 Packets Over FDDI", which will become historic.
本文件取代RFC 2019，“通过FDDI传输IPv6数据包”，这将成为历史。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC 2119]中所述进行解释。
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
当使用长格式地址时，FDDI允许4500个八位字节（9000个符号）的帧长，包括至少22个八位字节（44个符号）的数据链路封装。减去LLC/SNAP头的8个八位字节，原则上，这将允许信息字段中的IPv6[IPv6]数据包最多为4470个八位字节。然而，期望允许MAC报头和帧状态字段的可变大小和可能的未来扩展。因此，FDDI网络上IPv6数据包的默认MTU大小为4352个八位字节。此大小可以通过包含MTU选项的路由器广告[光盘]来减小
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.
指定较小的MTU，或通过手动配置每个节点。如果在FDDI接口上接收的路由器播发具有MTU选项，该MTU选项指定的MTU大于4352或大于手动配置的值，则该MTU选项可以记录到系统管理中，但必须以其他方式忽略。
For purposes of this document, information received from DHCP is considered "manually configured" and the term FDDI includes CDDI.
在本文档中，从DHCP接收的信息被视为“手动配置”，术语FDDI包括CDDI。
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.
FDDI提供同步和异步传输，后者通过使用受限和非受限令牌进一步细分。FDDI互操作性只需要具有不受限制令牌的异步传输。因此，应使用不受限制的令牌在异步帧中发送IPv6数据包。健壮性原则规定节点应该能够接收使用受限令牌发送的同步帧和异步帧。
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.
IPv6数据包在LLC/SNAP帧中传输，使用长格式（48位）地址。数据字段包含IPv6标头和有效负载，后面是FDDI帧检查序列、结束分隔符和帧状态符号。
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 ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.)
（每个tic标记代表一位。）
FDDI Header Fields:
FDDI头字段：
FC The Frame Code must be in the range 50 to 57 hexadecimal, inclusive, with the three low order bits indicating the frame priority.
FC帧代码必须在50到57个十六进制（含）范围内，三个低阶位表示帧优先级。
DSAP, SSAP Both the DSAP and SSAP fields shall contain the value AA hexadecimal, indicating SNAP encapsulation.
DSAP、SSAP DSAP和SSAP字段均应包含值AA十六进制，表示快照封装。
CTL The Control field shall be set to 03 hexadecimal, indicating Unnumbered Information.
CTL控制字段应设置为03十六进制，表示未编号的信息。
OUI The Organizationally Unique Identifier shall be set to 000000 hexadecimal.
OUI组织唯一标识符应设置为000000十六进制。
Ethertype The Ethernet protocol type ("ethertype") shall be set to the value 86DD hexadecimal.
Ethertype以太网协议类型（“Ethertype”）应设置为86DD十六进制值。
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].
连接不同媒体（如以太网和FDDI）的802.1d MAC网桥已经非常广泛。其中一些不支持IPv4数据包碎片和/或支持IPv4路径MTU发现[RFC 1981]，其他许多不支持或不正确。在桥接混合媒体环境中使用IPv6不得依赖于MAC网桥的支持，除非已知这些网桥能够正确实现IPv6路径MTU发现[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.
当混合介质通过不支持IPv6路径MTU发现的网桥连接在一起时，为了正确操作，所有介质中最小的MTU必须由路由器在MTU选项中公布。如果没有路由器，则必须在连接到默认MTU大于最小MTU的介质的每个节点中手动配置此MTU。
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.)
FDDI接口的接口标识符[AARCH]基于源自接口内置48位IEEE 802地址的EUI-64标识符[EUI64]。EUI-64的组成如下。（自始至终都采用规范的位顺序。有关LAN接口中位顺序影响的注意事项，请参见[CANON]）
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.
FDDI MAC地址的OUI（前三个八位字节）成为EUI-64（前三个八位字节）的公司id。EUI的第四和第五个八位字节设置为固定值FFFE十六进制。FDDI MAC地址的最后三个八位字节成为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].
然后，通过补充“通用/本地”（U/L）位，从EUI-64形成接口标识符，该位是EUI-64的第一个八位组的下一个最低阶位。关于这一点的进一步讨论，请参见[ETHER]和[AARCH]。
For example, the Interface Identifier for an FDDI interface whose built-in address is, in hexadecimal,
例如，内置地址为十六进制的FDDI接口的接口标识符，
34-56-78-9A-BC-DE
34-56-78-9A-BC-DE
would be
会是
36-56-78-FF-FE-9A-BC-DE.
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.
不应使用手动或软件设置的不同MAC地址来推导接口标识符。如果必须使用这样的MAC地址，则其全局唯一性属性应反映在U/L位的值中。
An IPv6 address prefix used for stateless autoconfiguration [ACONF] of an FDDI interface must have a length of 64 bits.
用于FDDI接口的无状态自动配置[ACONF]的IPv6地址前缀的长度必须为64位。
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.
FDDI接口的IPv6链路本地地址[AARCH]是通过将接口标识符（如上所述）附加到前缀FE80:：/64来形成的。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
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.
[DISC]中描述了将IPv6单播地址映射到FDDI链路层地址的过程。当链路层为FDDI时，源/目标链路层地址选项具有以下形式。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- FDDI -+
| |
+- Address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- FDDI -+
| |
+- Address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option fields:
选项字段：
Type 1 for Source Link-layer address. 2 for Target Link-layer address.
为源链路层地址键入1。2表示目标链路层地址。
Length 1 (in units of 8 octets).
长度1（以8个八位字节为单位）。
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.
FDDI地址48位FDDI IEEE 802地址，按规范位顺序排列。这是接口当前响应的地址，可能与用于派生接口标识符的内置地址不同。
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.
具有多播目标地址DST（由16个八位字节DST[1]到DST[16]组成）的IPv6数据包被传输到FDDI多播地址，其前两个八位字节为3333十六进制值，其后四个八位字节为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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST[13] | DST[14] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST[15] | DST[16] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following are the functional differences between this specification and RFC 2019.
以下是本规范与RFC 2019之间的功能差异。
"FDDI adjacency detection" has been removed, due to recent work in IEEE 802.1p.
由于IEEE 802.1p最近的工作，“FDDI邻接检测”已被删除。
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.
地址令牌是节点的48位MAC地址，替换为接口标识符，接口标识符长度为64位，基于EUI-64格式[EUI64]。IEEE定义的从48位MAC地址到EUI-64格式的映射。
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.
用于无状态自动配置的前缀现在必须为64位，而不是80位。链路本地前缀也缩短为64位。
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.
从MAC地址派生接口标识符的方法旨在尽可能保持全局唯一性。但是，由于意外或伪造，无法防止复制。
[AARCH] Hinden, R. and S. Deering "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[AARCH]Hinden，R.和S.Deering“IP版本6寻址体系结构”，RFC 23731998年7月。
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[ACONF]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
[CANON] Narten, T. and C. Burton, "A Caution On The Canonical Ordering Of Link-Layer Addresses", RFC 2469, December 1998.
[CANON]Narten，T.和C.Burton，“链路层地址规范排序的注意事项”，RFC 24692998年12月。
[DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[DISC]Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 246112998年12月。
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[Ethernet]Crawford，M.，“通过以太网传输IPv6数据包”，RFC 2464，1998年12月。
[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", http://standards.ieee.org/db/oui/tutorials/EUI64.html.
[EUI64]“64位全局标识符（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.
[ICMPV6]Conta，A.和S.Deering，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPV6）”，RFC 2463，1998年12月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]Deering，S.和R.Hinden，“互联网协议，第6版（IPV6）规范”，RFC 2460，1998年12月。
[RFC 1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC 1981]McCann，J.，Deering，S.和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA
Matt Crawford Fermilab MS 368美国伊利诺伊州巴达维亚500号邮政信箱60510
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。