[要約] 要約：RFC 2467は、FDDIネットワーク上でIPv6パケットを転送するための手順と要件を提供しています。 目的：このRFCの目的は、FDDIネットワーク上でIPv6をサポートするための標準化とガイドラインを提供することです。
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.
Copyright（C）The Internet Society（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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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オプションを含むルーターアドバタイズ[DISC]によって削減される場合があります。
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インターフェイスで受信したルーターアドバタイズメントに、4352より大きい、または手動で構成した値より大きいMTUを指定するMTUオプションがある場合、その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パケットは、ロングフォーマット（48ビット）アドレスを使用して、LLC / SNAPフレームで送信されます。データフィールドには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 ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Each tic mark represents one bit.)
（各目盛りは1ビットを表します。）
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までの16進数で、フレームの優先順位を示す下位3ビットである必要があります。
DSAP, SSAP Both the DSAP and SSAP fields shall contain the value AA hexadecimal, indicating SNAP encapsulation.
DSAP、SSAP DSAPとSSAPの両方のフィールドには、16進数のAAが含まれ、SNAPカプセル化を示します。
CTL The Control field shall be set to 03 hexadecimal, indicating Unnumbered Information.
CTL制御フィールドは、番号なしの情報を示す03 16進数に設定されます。
OUI The Organizationally Unique Identifier shall be set to 000000 hexadecimal.
OUI組織的に一意の識別子は000000 16進数に設定されます。
Ethertype The Ethernet protocol type ("ethertype") shall be set to the value 86DD hexadecimal.
Ethertypeイーサネットプロトコルタイプ（「ethertype」）は、16進数の値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の使用は、それらのブリッジがIPv6パスMTUディスカバリ[RFC 1981、ICMPV6]を正しく実装することがわかっている場合を除き、MACブリッジからのサポートに依存してはなりません。
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（最初の3オクテット）は、EUI-64（最初の3オクテット）のcompany_idになります。 EUIの4番目と5番目のオクテットは、16進数の固定値FFFEに設定されます。 FDDI MACアドレスの最後の3オクテットは、EUI-64の最後の3オクテットになります。
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].
次に、EUI-64の最初のオクテットの2番目に低いビットである「ユニバーサル/ローカル」（U / L）ビットを補完することにより、EUI-64からインターフェイス識別子が形成されます。この点の詳細については、[ETHER]および[AARCH]を参照してください。
For example, the Interface Identifier for an FDDI interface whose built-in address is, in hexadecimal,
たとえば、組み込みアドレスが16進数である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アドレスを使用して、インターフェイスIDを取得しないでください。このような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 |
+----------+-----------------------+----------------------------+
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.
IPv6ユニキャストアドレスをFDDIリンク層アドレスにマッピングする手順は、[DISC]で説明されています。リンク層がFDDIの場合、Source / Target Link-layer 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アドレス。これは、インターフェースが現在応答しているアドレスであり、インターフェースIDの導出に使用される組み込みアドレスとは異なる場合があります。
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.
16オクテットDST [1]〜DST [16]で構成されるマルチキャスト宛先アドレスDSTのIPv6パケットは、FDDIマルチキャストアドレスに送信されます。FDDIマルチキャストアドレスは、最初の2オクテットが3333 16進数で、最後の4オクテットが最後の4オクテットです。 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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
「FDDI隣接検出」は、IEEE 802.1pでの最近の作業により削除されました。
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アドレスであったアドレストークンは、EUI-64形式[EUI64]に基づく長さ64ビットのインターフェイス識別子に置き換えられます。 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.
ステートレス自動構成に使用されるプレフィックスは、80ビットではなく64ビット長である必要があります。リンクローカルプレフィックスも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 2373、1998年7月。
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[ACONF] Thomson、S.およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、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 2469、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、「Neighbor Discovery for IP Version 6（IPv6）」、RFC 2461、1998年12月。
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[ETHER] Crawford、M。、「Transmission of IPv6 Packets over Ethernet Networks」、RFC 2464、1998年12月。
[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", http://standards.ieee.org/db/oui/tutorials/EUI64.html.
[EUI64]「64ビットグローバルID（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、「インターネット制御メッセージプロトコル（ICMPv6）、インターネットプロトコルバージョン6（IPv6）仕様」、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 PO Box 500 Batavia、IL 60510 USA
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。