Network Working Group K. Fujisawa
Request for Comments: 3146 A. Onoe
Category: Standards Track Sony Corporation
October 2001
Network Working Group K. Fujisawa
Request for Comments: 3146 A. Onoe
Category: Standards Track Sony Corporation
October 2001
Transmission of IPv6 Packets over IEEE 1394 Networks
在IEEE 1394网络上传输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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks.
本文档描述了IPv6数据包传输的帧格式以及在IEEE1394网络上形成IPv6链路本地地址和无状态自动配置地址的方法。
IEEE Std 1394-1995 (and its amendment) is a standard for a High Performance Serial Bus. IETF IP1394 Working Group has standardized the method to carry IPv4 datagrams and ARP packets over IEEE1394 subnetwork [IP1394].
IEEE标准1394-1995（及其修订版）是高性能串行总线的标准。IETF IP1394工作组已对通过IEEE1394子网[IP1394]传输IPv4数据报和ARP数据包的方法进行了标准化。
This document describes the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. It also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on an IEEE1394 network.
本文档描述了IPv6[IPv6]数据包传输的帧格式以及在IEEE1394网络上形成IPv6链路本地地址和无状态自动配置地址的方法。它还描述了在IEEE1394网络上传输消息时，邻居发现[DISC]中使用的源/目标链路层地址选项的内容。
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中的说明进行解释。
An IPv6-capable node MUST fulfill the following minimum requirements:
支持IPv6的节点必须满足以下最低要求：
- it MUST implement configuration ROM in the general format specified by ISO/IEC 13213:1994 and MUST implement the bus information block specified by IEEE Std 1394a-2000 [1394a] and a unit directory specified by this document;
- 它必须以ISO/IEC 13213:1994规定的通用格式实现配置ROM，并且必须实现IEEE Std 1394a-2000[1394a]规定的总线信息块和本文件规定的单元目录；
- the max_rec field in its bus information block MUST be at least 8; this indicates an ability to accept block write requests and asynchronous stream packets with data payload of 512 octets. The same ability MUST also apply to read requests; that is, the node MUST be able to transmit a block response packet with a data payload of 512 octets;
- 其总线信息块中的max_rec字段必须至少为8；这表示能够接受数据负载为512个八位字节的块写入请求和异步流数据包。同样的能力也必须适用于读取请求；也就是说，节点必须能够发送数据有效载荷为512个八位字节的块响应分组；
- it MUST be isochronous resource manager capable, as specified by IEEE Std 1394a-2000;
- 按照IEEE标准1394a-2000的规定，它必须具有同步资源管理功能；
- it MUST support both reception and transmission of asynchronous streams as specified by IEEE Std 1394a-2000.
- 它必须支持IEEE标准1394a-2000规定的异步流的接收和传输。
The encapsulation and fragmentation mechanism MUST be the same as "4. LINK ENCAPSULATION AND FRAGMENTATION" of [IP1394].
封装和分段机制必须与[IP1394]的“4.链路封装和分段”相同。
Note: Since there is an ether_type field to discriminate protocols and MCAP (multicast channel allocation protocol) is used for both IPv4 and IPv6, the version field in GASP (global asynchronous stream packet) header of IPv6 datagrams is the same value (one) as [IP1394].
注意：由于存在用于区分协议的ether_类型字段，并且IPv4和IPv6都使用MCAP（多播信道分配协议），因此IPv6数据报的GASP（全局异步流数据包）头中的版本字段与[IP1394]的值相同（一）。
The ether_type value for IPv6 is 0x86dd.
IPv6的以太网类型值为0x86dd。
The default MTU size for IPv6 packets on an IEEE1394 network is 1500 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 each node. If a Router Advertisement received on an IEEE1394 interface has an MTU option specifying an MTU larger than 1500, or larger than a manually configured value, that MTU option may be logged to system management but MUST be otherwise ignored. The mechanism to extend MTU size between particular two nodes is for further study.
IEEE1394网络上IPv6数据包的默认MTU大小为1500个八位字节。可通过包含指定较小MTU的MTU选项的路由器广告[光盘]或通过手动配置每个节点来减小该尺寸。如果在IEEE1394接口上接收到的路由器公告具有MTU选项，该MTU选项指定的MTU大于1500或大于手动配置的值，则该MTU选项可能会记录到系统管理中，但必须以其他方式忽略。在特定的两个节点之间扩展MTU大小的机制有待进一步研究。
Configuration ROM for IPv6-capable nodes MUST contain a unit directory in the format specified by [IP1394] except following rules.
支持IPv6的节点的配置ROM必须包含[IP1394]指定格式的单元目录，以下规则除外。
- The value for Unit_SW_Version is 0x000002.
- 单元软件版本的值为0x000002。
- The textual descriptor for the Unit_SW_Version MUST be "IPv6".
- 单元软件版本的文本描述符必须为“IPv6”。
Note: A dual-stack (IPv4 and IPv6) node will have two unit directories for IPv4 and IPv6 respectively.
注意：双堆栈（IPv4和IPv6）节点将分别具有IPv4和IPv6的两个单元目录。
The Interface Identifier [AARCH] for an IEEE1394 interface is formed from the interface's built-in EUI-64 identifier by complementing the "Universal/Local" (U/L) bit, which is the next-to-lowest order bit of the first octet of the EUI-64 identifier. Complementing this bit will generally change a 0 value to a 1, since an interface's built-in EUI-64 identifier is expected to be from a universally administered address space and hence have a globally unique value. A universally administered EUI-64 identifier 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].
IEEE1394接口的接口标识符[AARCH]是通过补充“通用/本地”（U/L）位，从接口的内置EUI-64标识符形成的，该位是EUI-64标识符的第一个八位组的次低位。补充该位通常会将0值更改为1，因为接口的内置EUI-64标识符预期来自通用管理的地址空间，因此具有全局唯一值。通用管理的EUI-64标识符由U/L位的0表示，而全局唯一的IPv6接口标识符由相应位置的1表示。关于这一点的进一步讨论，请参见[AARCH]。
An IPv6 address prefix used for stateless autoconfiguration [ACONF] of an IEEE1394 interface MUST have a length of 64 bits.
用于IEEE1394接口的无状态自动配置[ACONF]的IPv6地址前缀的长度必须为64位。
The IPv6 link-local address [AARCH] for an IEEE1394 interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64.
IEEE1394接口的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 IEEE1394 link-layer addresses uses the Neighbor Discovery [DISC]. Since 1394 link address (node_ID) will not be constant across a 1394 bridge, we have chosen not to put it in the Link-layer Address option. The recipient of the Neighbor Discovery SHOULD use the source_ID (obtained from either the asynchronous packet header or the GASP header) in
将IPv6单播地址映射到IEEE1394链路层地址的过程使用邻居发现[DISC]。由于1394链路地址（node_ID）在1394网桥上不是常数，因此我们选择不将其置于链路层地址选项中。邻居发现的接收者应在中使用源_ID（从异步数据包头或GASP头获得）
conjunction with the content of the Source link-layer address. An implementation MAY use some other methods to obtain a node_ID of the sender utilizing a mapping table between node_unique_ID (EUI-64 identifier) and node_ID. The mechanism to make such mapping table is out of scope of this document.
与源链接层地址的内容结合。一个实现可以使用一些其他方法来获得发送方的节点ID，该方法使用节点ID（EUI-64标识符）和节点ID之间的映射表。生成这种映射表的机制不在本文档的范围内。
The recipient of an Neighbor Discovery packet MUST ignore it unless the most significant ten bits of the source_ID are equal to either 0x3FF or the most significant ten bits of the recipient's NODE_IDS register.
邻居发现数据包的接收者必须忽略它，除非源_ID的最高有效十位等于0x3FF或接收者节点_ID寄存器的最高有效十位。
The Source/Target Link-layer Address option has the following form when the link layer is IEEE1394.
当链路层为IEEE1394时，源/目标链路层地址选项具有以下形式。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 3 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| node_unique_ID (EUI-64 identifier) |
+--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | max_rec | spd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unicast_FIFO |
+--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 3 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| node_unique_ID (EUI-64 identifier) |
+--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | max_rec | spd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unicast_FIFO |
+--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1 for Source Link-layer address. 2 for Target Link-layer address. Length 3 (in units of 8 octets).
为源链路层地址键入1。2表示目标链路层地址。长度3（以8个八位字节为单位）。
node_unique_ID This field contains the node unique ID of the node and MUST be equal to that specified in the node's configuration ROM.
node_unique_ID此字段包含节点的节点唯一ID，并且必须等于节点的配置ROM中指定的ID。
max_rec This field MUST be equal to the value of max_rec in the node's configuration ROM.
max_rec此字段必须等于节点配置ROM中max_rec的值。
spd This field MUST be set to the lesser of the node's link speed and PHY speed. The link speed is the maximum speed at which the link may send or receive packets; the PHY speed is the maximum speed at which the PHY may send, receive or repeat packets. The encoding used for spd is specified in the Table 2 of [IP1394].
spd此字段必须设置为节点的链路速度和物理层速度中的较小值。链路速度是链路可以发送或接收分组的最大速度；PHY速度是PHY可以发送、接收或重复数据包的最大速度。[IP1394]的表2中规定了用于spd的编码。
unicast_FIFO This field MUST specify the 48-bit offset of the node's FIFO available for the receipt of IPv6 datagrams. The offset of a node's unicast FIFO MUST NOT change, except as the result of a power reset.
单播FIFO此字段必须指定可用于接收IPv6数据报的节点FIFO的48位偏移量。节点单播FIFO的偏移量不得改变，除非由于电源重置。
reserved This field MUST be set to all zeros by the sender and ignored by the receiver.
保留此字段必须由发送方设置为全零，并由接收方忽略。
Note that node_ID may change when 1394 bus-reset occurs. The mapping cache held in the node SHOULD be cleared on 1394 bus-reset.
注意，当1394总线复位发生时，节点ID可能会改变。应在1394总线重置时清除节点中的映射缓存。
According to [1394], the maximum data payload and the transmission speed SHOULD be determined based on the sender's capability, the recipient's capability, and the PHYs of all intervening nodes.
根据[1394]，最大数据有效载荷和传输速度应根据发送方的能力、接收方的能力和所有介入节点的物理量来确定。
By default, all best-effort IPv6 multicast MUST use asynchronous stream packets whose channel number is equal to the channel field from the BROADCAST_CHANNEL register. In particular, datagrams addressed to all-nodes multicast addresses, all-routers multicast addresses, and solicited-node multicast addresses [AARCH] MUST use the default channel specified by the BROADCAST_CHANNEL register.
默认情况下，所有尽力而为的IPv6多播必须使用异步流数据包，其信道号等于广播信道寄存器中的信道字段。特别是，发往所有节点多播地址、所有路由器多播地址和请求节点多播地址[AARCH]的数据报必须使用广播信道寄存器指定的默认信道。
Best-effort IPv6 multicast for other multicast group addresses may utilize a different channel number if such a channel number is allocated and advertised prior to use, by the multicast channel allocation protocol (MCAP), as described in [IP1394].
如[IP1394]中所述，如果在使用之前通过多播信道分配协议（MCAP）分配和公布了一个不同的信道号，则用于其他多播组地址的尽力而为IPv6多播可以使用该信道号。
When a node wishes to receive multicast data addressed to other than all-nodes multicast addresses, all-routers multicast addresses, and solicited-node multicast addresses, it MUST confirm if the channel mapping between a multicast group address and a channel number exists using MCAP, as described in "9.3 Multicast Receive" in [IP1394].
当一个节点希望接收地址不是所有节点多播地址、所有路由器多播地址和请求的节点多播地址的多播数据时，它必须使用MCAP确认多播组地址和信道号之间的信道映射是否存在，如[IP1394]中的“9.3多播接收”所述。
The implementation of MCAP is optional for send-only nodes. A node MAY transmit multicast data addressed to any multicast addresses into the default broadcast channel regardless of the existing allocation of the channel. If a node wishes to transmit multicast data on other than the default channel, it MUST first confirm by MCAP whether or not a channel number for the group address has been already allocated. The implementors are encouraged to use this protocol when transmitting high-rate multicast streams.
MCAP的实现对于仅发送节点是可选的。节点可以将寻址到任何多播地址的多播数据发送到默认广播信道中，而不考虑信道的现有分配。如果节点希望在非默认通道上传输多播数据，则必须首先通过MCAP确认是否已为组地址分配了通道号。鼓励实现者在传输高速多播流时使用该协议。
The MCAP 'type' value for IPv6 group address descriptor is 2.
IPv6组地址描述符的MCAP“type”值为2。
IANA has assigned a value of 0x000002 for "Unit_SW_Version for IPv6 over IEEE1394" out of the "CSR Protocol Identifiers" name space, as described in section 5. The details of the "CSR Protocol Identifiers" namespace is described in "10. IANA CONSIDERATIONS" of [IP1394].
IANA已在“CSR协议标识符”名称空间中为“IEEE1394上IPv6的单元软件版本”分配了0x000002的值，如第5节所述。[IP1394]的“10.IANA注意事项”中描述了“CSR协议标识符”名称空间的详细信息。
Section 9.1 of [IP1394] defines MCAP group address descriptors, which include an 8-bit type name space. This document requests that IANA maintain a name space to manage MCAP group address descriptors. The initial assignments for that table are:
[IP1394]第9.1节定义了MCAP组地址描述符，其中包括一个8位类型的名称空间。本文档要求IANA维护一个名称空间来管理MCAP组地址描述符。该表的初始分配为：
Value Usage 0 reserved 1 IPv4 Multicast Address 2 IPv6 Multicast Address 255 reserved
值用法0保留1 IPv4多播地址2 IPv6多播地址255保留
Additional values from the range 3-254 can be assigned through Standards Action [RFC 2434].
范围3-254的附加值可通过标准行动[RFC 2434]分配。
IPv6 over IEEE1394 does not introduce any additional security considerations over [IP1394]. The security concerns described in "11. SECURITY CONSIDERATIONS" in [IP1394] apply here as well.
IEEE1394上的IPv6没有引入任何超过[IP1394]的额外安全注意事项。[IP1394]中“11.安全注意事项”中描述的安全问题也适用于此处。
The authors would like to acknowledge the authors of [IP1394] and [ETHER] since some part of this document has been derived from them.
作者要感谢[IP1394]和[ETHER]的作者，因为本文件的某些部分是从他们那里衍生出来的。
[1394] IEEE Std 1394-1995, Standard for a High Performance Serial Bus
[1394]IEEE标准1394-1995，高性能串行总线标准
[1394a] IEEE Std 1394a-2000, Standard for a High Performance Serial Bus - Amendment 1
[1394a]IEEE标准1394a-2000，高性能串行总线标准-修改件1
[IP1394] Johansson, P., "IPv4 over IEEE 1394", RFC 2734, December 1999.
[IP1394]Johansson，P.，“IEEE 1394上的IPv4”，RFC 27341999年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月。
[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373 December 1998.
[AARCH]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 2373，1998年12月。
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[ACONF]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年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月。
Kenji Fujisawa Network & Software Technology Center, Sony Corporation 6-7-35 Kitashinagawa, Shinagawa-ku, Tokyo 141-0001, JAPAN
日本东京新川区北川6-7-35号索尼公司藤泽健二网络与软件技术中心141-0001
Phone: +81-3-5795-8507
Fax: +81-3-5795-8977
EMail: fujisawa@sm.sony.co.jp
Phone: +81-3-5795-8507
Fax: +81-3-5795-8977
EMail: fujisawa@sm.sony.co.jp
Atsushi Onoe Internet Systems Laboratory, Internet Laboratories, Sony Corporation 6-7-35 Kitashinagawa, Shinagawa-ku, Tokyo 141-0001, JAPAN
日本东京新川区北川6-7-35号索尼公司互联网实验室大野Atsushi互联网系统实验室141-0001
Phone: +81-3-5448-4620
Fax: +81-3-5448-4622
EMail: onoe@sm.sony.co.jp
Phone: +81-3-5448-4620
Fax: +81-3-5448-4622
EMail: onoe@sm.sony.co.jp
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。