RFC 2469 - A Caution On The Canonical Ordering Of Link-Layer Addresses 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc2469
タイトル : RFC 2469 - リンク層アドレスの正規の順序に関する注意
翻訳編集 : 自動生成

[要約] リンク層アドレス（MACアドレス等）の正規順序（ビット順序）に関する注意点を論じています。トークンリングやFDDIなど、ビットの送り順が異なるネットワーク間でのアドレス表現の不一致による問題を指摘します。相互接続時に発生し得るトラブルを回避するための技術的な洞察を提供します。

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.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。

著作権表示

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

   1.  はじめに ....................................................2

   2.  Canonical Form...........................................    2

   2.  正規形 ......................................................2

   3.  Implementors Beware: Potential Trouble Spots.............    3

   3.  実装者は注意してください：潜在的な問題点 ....................3

      3.1.  Neighbor Discovery in IPv6..........................    3

      3.1.  IPv6での近隣探索 .......................................3

      3.2.  IPv4 and ARP........................................    3

      3.2.  IPv4とARP ..............................................3

   4.  Security Considerations..................................    3

   4.  セキュリティに関する考慮事項 ................................3

   5.  References...............................................    4

   5.  参考文献 ....................................................4

   6.  Authors' Addresses.......................................    4

   6.  著者のアドレス ..............................................4

   7.  Full Copyright Statement.................................    5

   7.  完全な著作権表示 ............................................5

1. Introduction

1. はじめに

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アダプターが正規形式の使用に一貫性があるわけではなく、実装では、正しい形式を取得するために、個々のバイトを明示的にビットスワップする必要がある場合があります。

2. Canonical Form

2. 正規形

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

1st bit appearing on LAN (group address indicator) | On LAN: 01001000 00101100 01101010 00011110 01011001 00111101

LANに現れる最初のビット（グループアドレスインジケーター）| LAN上：01001000 00101100 01101010 00011110 01011001 00111101

In memory, MSB format: 01001000 00101100 01101010 00011110 01011001 00111101 48 2C 6A 1E 59 3D

メモリ内、MSB形式：01001000 00101100 01101010 00011110 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.

この不整合の含意は、アダプターから抽出された、アダプターに割り当てられた、またはアダプターから取得したリンク層パケットヘッダーから抽出されたアドレスをビットスワップして、正規の形式にする必要がある場合があることです。同様に、アダプターに渡される正規形式のアドレス（たとえば、アドレスを設定する、リンク層ヘッダーで宛先アドレスを指定するなど）は、アダプターが要求を処理するためにビットスワップする必要がある場合があります。予想通り。

3. Implementors Beware: Potential Trouble Spots

3. 実装者は注意してください：潜在的な問題点

3.1. Neighbor Discovery in IPv6

3.1. IPv6での近隣探索

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-TOKEN]。著者の知る限り、すべてのイーサネットLANアダプターは標準的な順序を使用しており、実装による特別な処理は必要ありません。対照的に、一部のFDDIおよびすべてのトークンリングアダプターは、非標準形式を使用しているように見えます。実装者は、近隣探索[DISCOVERY]メッセージのリンク層アドレスオプションに表示されるアドレスがすべて正規の順序で送信され、NDパケットから抽出されたリンク層アドレスがローカルマシンとそのアダプターで正しく解釈されることを保証する必要があります。

3.2. IPv4 and ARP

3.2. IPv4とARP

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パケットのアドレスフィールドでアドレスのビットスワップを実行します。

4. Security Considerations

4. セキュリティに関する考慮事項

There are no known security issues raised by this document.

このドキュメントによって引き起こされる既知のセキュリティ問題はありません。

5. References

5. 参考文献

[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.

[DISCOVERY] Narten, T., Nordmark, E., and W. Simpson、「Neighbor Discovery for IP Version 6（IPv6）」、RFC 2461、1998年12月。

[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.

[IPv6-ETHER] Crawford, M.、「Transmission of IPv6 Packets over Ethernet Networks」、RFC 2464、1998年12月。

[IPv6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998.

[IPv6-FDDI] Crawford, M.、「Transmission of IPv6 Packets over FDDI Networks」、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-TOKEN] Crawford, M., Narten, T. and S. Thomas、「Token Ring Networks over IPv6 Packets over Token Ring Networks」、RFC 2470、1998年12月。

6. Authors' Addresses

6. 著者のアドレス

Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park, NC 27709-2195

Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park、NC 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

Charles F. Burton、III IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park、NC 27709-2195

Phone: 919-254-4355 EMail: burton@rtp.vnet.ibm.com

電話：919-254-4355メール：burton@rtp.vnet.ibm.com

7. Full Copyright Statement

7. 完全な著作権表示

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.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。