Network Working Group T. Narten
Request for Comments: 2469 C. Burton
Category: Informational IBM
December 1998
Network Working Group T. Narten
Request for Comments: 2469 C. Burton
Category: Informational IBM
December 1998
A Caution On The Canonical Ordering Of Link-Layer Addresses
链路层地址规范排序的注意事项
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
Protocols such as ARP and Neighbor Discovery have data fields that contain link-layer addresses. In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly. In most cases, such fields must be in "canonical form". Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format. This document provides information to implementors to help them avoid the pitfall of using non-canonical forms when canonical forms are required.
ARP和邻居发现等协议具有包含链路层地址的数据字段。为了正确地进行互操作，发送方设置这样的字段必须确保接收方提取这些位并正确地解释它们。在大多数情况下，这些字段必须是“规范形式”。不幸的是，并非所有LAN适配器在使用规范形式时都是一致的，实现可能需要显式地对单个字节进行位交换，以获得正确的格式。本文档向实现者提供信息，以帮助他们避免在需要规范形式时使用非规范形式的陷阱。
Table of Contents
目录
1. Introduction............................................. 2
2. Canonical Form........................................... 2
3. Implementors Beware: Potential Trouble Spots............. 3
3.1. Neighbor Discovery in IPv6.......................... 3
3.2. IPv4 and ARP........................................ 3
4. Security Considerations.................................. 3
5. References............................................... 4
6. Authors' Addresses....................................... 4
7. Full Copyright Statement................................. 5
1. Introduction............................................. 2
2. Canonical Form........................................... 2
3. Implementors Beware: Potential Trouble Spots............. 3
3.1. Neighbor Discovery in IPv6.......................... 3
3.2. IPv4 and ARP........................................ 3
4. Security Considerations.................................. 3
5. References............................................... 4
6. Authors' Addresses....................................... 4
7. Full Copyright Statement................................. 5
Protocols such as ARP [ARP] and ND [DISCOVERY] have data fields that contain link-layer addresses. In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly. In most cases, such fields must be in "canonical form". Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format.
ARP[ARP]和ND[DISCOVERY]等协议具有包含链路层地址的数据字段。为了正确地进行互操作，发送方设置这样的字段必须确保接收方提取这些位并正确地解释它们。在大多数情况下，这些字段必须是“规范形式”。不幸的是，并非所有LAN适配器在使用规范形式时都是一致的，实现可能需要显式地对单个字节进行位交换，以获得正确的格式。
Canonical form (also known as "LSB format" and "Ethernet format") is the name given to the format of a LAN adapter address as it should be presented to the user according to the 802 LAN standard. It is best defined as how the bit order of an adapter address on the LAN media maps to the bit order of an adapter address in memory: The first bit of each byte that appears on the LAN maps to the least significant (i.e., right-most) bit of each byte in memory (the figure below illustrates this). This puts the group address indicator (i.e., the bit that defines whether an address is unicast or multicast) in the least significant bit of the first byte. Ethernet and 802.3 hardware behave consistently with this definition.
规范格式（也称为“LSB格式”和“以太网格式”）是根据802 LAN标准向用户提供的LAN适配器地址格式的名称。它最好定义为LAN介质上适配器地址的位顺序如何映射到内存中适配器地址的位顺序：LAN上出现的每个字节的第一位映射到内存中每个字节的最低有效位（即最右边的位）（下图说明了这一点）。这将组地址指示符（即，定义地址是单播还是多播的位）置于第一个字节的最低有效位。以太网和802.3硬件的行为与此定义一致。
Unfortunately, Token Ring (and some FDDI) hardware does not behave consistently with this definition; it maps the first bit of each byte of the adapter address to the most significant (i.e., left-most) bit of each byte in memory, which puts the group address indicator in the most significant bit of the first byte. This mapping is variously called "MSB format", "IBM format", "Token-Ring format", and "non-canonical form". The figure below illustrates the difference between canonical and non-canonical form using the canonical form address 12-34-56-78-9A-BC as an example:
不幸的是，令牌环（和一些FDDI）硬件的行为与此定义不一致；它将适配器地址的每个字节的第一位映射到内存中每个字节的最高有效位（即最左侧），从而将组地址指示符置于第一个字节的最高有效位。这种映射被称为“MSB格式”、“IBM格式”、“令牌环格式”和“非规范格式”。下图以规范格式地址12-34-56-78-9A-BC为例说明了规范格式和非规范格式之间的差异：
In memory, 12 34 56 78 9A BC canonical: 00010010 00110100 01010110 01111000 10011010 10111100
内存中，12 34 56 78 9A BC规范：00010010 00110100 01010110 0111000 10011010 10111100
1st bit appearing on LAN (group address indicator) | On LAN: 01001000 00101100 01101010 00011110 01011001 00111101
LAN上出现的第一位（组地址指示器）| LAN上：01001000 00101100 011010 00011110 01011001 00111101
In memory, MSB format: 01001000 00101100 01101010 00011110 01011001 00111101 48 2C 6A 1E 59 3D
内存中，MSB格式：01001000 00101100 011010 0001110 01011001 00111101 48 2C 6A 1E 59 3D
The implication of this inconsistency is that addresses extracted from adaptors, assigned to adaptors, or extracted from link-layer packet headers obtained from adaptors may need to be bit-swapped to put them into canonical form. Likewise, addresses in canonical form that are handed to adaptors (e.g., to set an address, to specify a destination address in a link-layer header, etc.) may need to be bit-swapped in order for the adaptor to process the request as expected.
这种不一致性的含义是，从适配器提取的地址、分配给适配器的地址或从适配器获取的链路层数据包头提取的地址可能需要进行位交换，以将其转换为规范形式。类似地，为了使适配器按预期处理请求，可能需要对交给适配器的规范格式的地址（例如，设置地址、在链路层头中指定目的地地址等）进行位交换。
All of the IPv6 over specific link layers documents specify that link-layer addresses must be transmitted in canonical order [IPv6- ETHER, IPv6-FDDI, IPv6-TOKEN]. As far as the authors can tell, all Ethernet LAN adaptors use canonical order and no special processing by implementations is needed. In contrast, some FDDI and all Token Ring adaptors appear to use non-canonical format. Implementors must insure that any addresses that appear in link-layer address options of Neighbor Discovery [DISCOVERY] messages are sent in canonical order and that any link-layer addresses extracted from ND packets are interpreted correctly on the local machine and its adaptors.
所有特定链路层上的IPv6文档都指定链路层地址必须按规范顺序传输[IPv6-ETHER、IPv6 FDDI、IPv6令牌]。据作者所知，所有以太网LAN适配器都使用规范顺序，不需要按实现进行特殊处理。相反，一些FDDI和所有令牌环适配器似乎使用非规范格式。实施者必须确保邻居发现[发现]消息的链路层地址选项中出现的任何地址都按规范顺序发送，并且从ND数据包提取的任何链路层地址都在本地计算机及其适配器上得到正确解释。
Ethernet addresses that appear in ARP packets are in canonical order. In contrast, when running ARP over Token Ring, the de facto practice is to transmit addresses in non-canonical order. Because all Token Ring adaptors assume non-canonical ordering, no interoperability problems result between communicating nodes attached to the same Token Ring.
ARP数据包中出现的以太网地址按规范顺序排列。相反，当在令牌环上运行ARP时，事实上的做法是以非规范顺序传输地址。由于所有令牌环适配器均采用非规范顺序，因此连接到同一令牌环的通信节点之间不会产生互操作性问题。
In some environments, however, Token Rings and Ethernets are connected via a bridge. When a node on the Token Ring attempts to communicate with a node on the Ethernet, communication would normally fail, since the Ethernet will misinterpret the Token Ring address (and vice versa). To get around this problem, bridges that forward packets between dissimilar network types perform bit swaps of the addresses in the address fields of ARP packets that are forwarded from a network of one type to one of the other.
然而，在某些环境中，令牌环和以太网通过网桥连接。当令牌环上的节点尝试与以太网上的节点通信时，通信通常会失败，因为以太网会误解令牌环地址（反之亦然）。为了解决这个问题，在不同网络类型之间转发数据包的网桥对从一种类型的网络转发到另一种类型的网络的ARP数据包的地址字段中的地址执行位交换。
There are no known security issues raised by this document.
本文档未提出任何已知的安全问题。
[ARP] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, November 1982.
[ARP]Plummer，D.，“以太网地址解析协议”，STD 37，RFC 826，1982年11月。
[DISCOVERY] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[发现]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 246112998年12月。
[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[IPv6以太]Crawford，M.，“通过以太网传输IPv6数据包”，RFC 2464，1998年12月。
[IPv6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998.
[IPv6 FDDI]Crawford，M.，“通过FDDI网络传输IPv6数据包”，RFC 2467，1998年12月。
[IPv6-TOKEN] Crawford, M., Narten, T. and S. Thomas, "Transmission of IPv6 Packets over Token Ring Networks", RFC 2470, December 1998.
[IPv6令牌]Crawford，M.，Narten，T.和S.Thomas，“通过令牌环网络传输IPv6数据包”，RFC 24701998年12月。
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park, NC 27709-2195
Thomas Narten IBM Corporation北卡罗来纳州研究三角公园康沃利斯大道3039号邮政信箱12195号，邮编27709-2195
Phone: 919-254-7798 EMail: narten@raleigh.ibm.com
电话：919-254-7798电子邮件：narten@raleigh.ibm.com
Charles F. Burton, III IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park, NC 27709-2195
查尔斯·F·伯顿三世IBM公司美国北卡罗来纳州研究三角公园康沃利斯大道3039号邮政信箱12195号，邮编27709-2195
Phone: 919-254-4355 EMail: burton@rtp.vnet.ibm.com
电话：919-254-4355电子邮件：burton@rtp.vnet.ibm.com
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。