[要約] RFC 2470は、トークンリングネットワーク上でIPv6パケットを転送するための仕様を提供しています。このRFCの目的は、IPv6をサポートするトークンリングネットワークの実装と相互運用性を向上させることです。
Network Working Group M. Crawford
Request for Comments: 2470 Fermilab
Category: Standards Track T. Narten
IBM
S. Thomas
TransNexus
December 1998
Transmission of IPv6 Packets over Token Ring Networks
トークンリングネットワークを介した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 memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Redirect, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network.
このメモは、トークンリングネットワークでIPv6パケットを送信するためのMTUおよびフレーム形式を指定します。また、トークンリングネットワーク上でIPv6リンクローカルアドレスを形成する方法と、これらのメッセージが送信されるときにルーター要請、ルーターアドバタイズ、リダイレクト、ネイバー要請、ネイバーアドバタイズメッセージを使用するソース/ターゲットリンク層アドレスオプションの内容を指定します。トークンリングネットワーク上。
Implementors should be careful to note that Token Ring adaptors assume addresses are in non-canonical rather than canonical format, requiring that special care be taken to insure that addresses are processed correctly. See [CANON] for more details.
トークンリングアダプターは、アドレスが正規の形式ではなく非正規の形式であると想定し、アドレスが正しく処理されるように特別な注意を払う必要があることに注意して実装者は注意する必要があります。詳細については、[CANON]を参照してください。
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 [KWORD].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [KWORD]の説明に従って解釈されます。
IEEE 802.5 networks have a maximum frame size based on the maximum time a node may hold the token. This time depends on many factors including the data signaling rate and the number of nodes on the ring. Because the maximum frame size varies, implementations must rely on manual configuration or router advertisements [DISC] to determine actual MTU sizes. Common default values include approximately 2000, 4000, and 8000 octets.
IEEE 802.5ネットワークには、ノードがトークンを保持できる最大時間に基づいた最大フレームサイズがあります。この時間は、データシグナリングレートやリング上のノード数など、多くの要因に依存します。最大フレームサイズはさまざまであるため、実装は実際のMTUサイズを決定するために、手動構成またはルーターアドバタイズ[DISC]に依存する必要があります。一般的なデフォルト値には、約2000、4000、および8000オクテットが含まれます。
In the absence of any other information, an implementation should use a default MTU of 1500 octets. This size offers compatibility with all common 802.5 defaults, as well as with Ethernet LANs in an environment using transparent bridging.
他の情報がない場合、実装は1500オクテットのデフォルトMTUを使用する必要があります。このサイズは、すべての一般的な802.5デフォルトとの互換性、およびトランスペアレントブリッジングを使用する環境でのイーサネットLANとの互換性を提供します。
In an environment using source route bridging, the process of discovering the MAC-level path to a neighbor can yield the MTU for the path to that neighbor. The information is contained in the largest frame (LF) subfield of the routing information field. This field limits the size of the information field of frames to that destination, and that information field includes both the LLC [LLC] header and the IPv6 datagram. Since, for IPv6, the LLC header is always 8 octets in length, the IPv6 MTU can be found by subtracting 8 from the maximum frame size defined by the LF subfield. If an implementation uses this information to determine MTU sizes, it must maintain separate MTU values for each neighbor.
ソースルートブリッジを使用する環境では、ネイバーへのMACレベルのパスを検出するプロセスにより、そのネイバーへのパスのMTUが生成される場合があります。この情報は、ルーティング情報フィールドの最大フレーム（LF）サブフィールドに含まれています。このフィールドはフレームの情報フィールドのサイズをその宛先に制限し、その情報フィールドにはLLC [LLC]ヘッダーとIPv6データグラムの両方が含まれます。 IPv6の場合、LLCヘッダーの長さは常に8オクテットであるため、LFサブフィールドで定義された最大フレームサイズから8を引くと、IPv6 MTUを見つけることができます。実装がこの情報を使用してMTUサイズを決定する場合、実装はネイバーごとに個別のMTU値を維持する必要があります。
A detailed list of the LF values and the resulting maximum frame size can be found in [BRIDGE]. To illustrate the calculation of IPv6 MTU, the following table lists several common values. Note that some of the 802.1D LF values would result in an IP MTU less than 1280 bytes. This size is less than the IPv6 minimum, and communication across paths with those MTUs is generally not possible using IPv6.
LF値とその結果の最大フレームサイズの詳細なリストは、[BRIDGE]にあります。 IPv6 MTUの計算を説明するために、次の表にいくつかの一般的な値を示します。 802.1D LF値の一部は、IP MTUが1280バイト未満になることに注意してください。このサイズはIPv6の最小値よりも小さく、これらのMTUを使用したパスを介した通信は、通常IPv6を使用して行うことはできません。
LF (base) LF (extension) MAC MTU IP MTU 001 000 1470 1462 010 000 2052 2044 011 000 4399 4391 100 000 8130 8122 101 000 11407 11399 110 000 17749 17741 111 000 41600 41592
LF（ベース）LF（拡張）MAC MTU IP MTU 001 000 1470 1462 010 000 2052 2044 011 000 4399 4391 100 000 8130 8122 101 000 11407 11399 110 000 17749 17741 111 000 41600 41592
When presented with conflicting MTU values from several sources, an implementation should choose from those sources according to the following priorities:
複数のソースからの矛盾するMTU値が提示された場合、実装は次の優先順位に従ってそれらのソースから選択する必要があります。
1. Largest Frame values from source route bridging (only for specific, unicast destinations), but only if not greater than value from any router advertisements
1. ソースルートブリッジングからの最大フレーム値（特定のユニキャスト宛先の場合のみ）。ただし、ルーターアドバタイズメントの値より大きくない場合のみ
2. Router advertisements, but only if not greater than any manual configuration (including DHCP)
2. ルーター通知（ただし、手動構成（DHCPを含む）以下）
3. Manual configuration (including DHCP)
3. 手動構成（DHCPを含む）
4. Default of 1500
4. デフォルトは1500
IPv6 packets are transmitted in LLC/SNAP frames. The data field contains the IPv6 header and payload. The following figure shows a complete 802.5 frame containing an IPv6 datagram.
IPv6パケットはLLC / SNAPフレームで送信されます。データフィールドには、IPv6ヘッダーとペイロードが含まれます。次の図は、IPv6データグラムを含む完全な802.5フレームを示しています。
+-------+-------+-------+-------+
| SD | AC | FC | |
+-----------------------+ |
| Destination Address |
| +-----------------------+
| | Source |
+-------+ Address +-------+
| | DSAP |
+-------+-------+-------+-------+
| SSAP | CTL | OUI |
+-------+-------+-------+-------+
| OUI | EtherType | |
+-------+---------------+ |
| |
~ IPv6 header and payload... ~
| |
+-------------------------------+
| FCS |
+-------+-------+---------------+
| ED | FS |
+-------+-------+
Token Ring Header Fields
トークンリングヘッダーフィールド
SD: Starting Delimiter
SD：開始区切り文字
AC: Access Control
AC：アクセス制御
FC: Frame Control
FC：フレーム制御
Destination Address: 48-bit IEEE address of destination station
宛先アドレス：宛先ステーションの48ビットIEEEアドレス
Source Address: 48-bit IEEE address of source station
送信元アドレス：送信元ステーションの48ビットIEEEアドレス
DSAP: Destination Service Access Point (for LLC/SNAP format, shall always contain the value 0xAA)
DSAP：宛先サービスアクセスポイント（LLC / SNAP形式の場合、常に値0xAAが含まれます）
SSAP: Source Service Access Point (for LLC/SNAP format, shall always contain the value 0xAA)
SSAP：ソースサービスアクセスポイント（LLC / SNAP形式の場合、常に値0xAAが含まれます）
CTL: Control Field (for Unnumbered Information, shall always contain the value 0x03)
CTL：制御フィールド（番号なし情報の場合、常に値0x03が含まれる）
OUI: Organizationally Unique Identifier (for EtherType encoding, shall always contain the value 0x000000)
OUI：組織的に一意の識別子（EtherTypeエンコーディングの場合、常に値0x000000が含まれます）
EtherType: Protocol type of encapsulated payload (for IPv6, shall always contain the value 0x86DD)
EtherType：カプセル化されたペイロードのプロトコルタイプ（IPv6の場合、常に値0x86DDが含まれます）
FCS: Frame Check Sequence
FCS：フレームチェックシーケンス
ED: Ending Delimiter
ED：終了デリミタ
FS: Frame Status
FS：フレームステータス
In the presence of source route bridges, a routing information field (RIF) may appear immediately after the source address. A RIF is present in frames when the most significant bit of the source address is set to one. (This is the bit whose position corresponds to that of the Individual/Group bit in the Destination Address.)
ソースルートブリッジが存在する場合、ルーティング情報フィールド（RIF）がソースアドレスの直後に表示されることがあります。送信元アドレスの最上位ビットが1に設定されている場合、RIFはフレームに存在します。 （これは、宛先アドレスの個別/グループビットの位置に対応するビットです。）
The RIF is a variable-length field that (when present) contains a two-octet Routing Control (RC) header, followed by zero or more two-octet Route Designator fields:
RIFは可変長フィールドであり（存在する場合）、2オクテットのルーティング制御（RC）ヘッダーが含まれ、その後に0個以上の2オクテットルート指定子フィールドが続きます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Control: |Bcast| Length |D| LF |rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Designator 1: | Segment 1 |Bridge1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Designator N: | Segment N |BridgeN|
(0 <= N <= 7) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Designator Fields:
ルート指定フィールド：
Bcast: Broadcast Indicator, Defined values:
Bcast：ブロードキャストインジケーター、定義済みの値：
10x: All Routes Explorer 11x: Spanning Tree Explorer 0xx: Specifically Routed Frame
10x：すべてのルートエクスプローラー11x：スパニングツリーエクスプローラー0xx：特にルーティングされたフレーム
Length: Total length of RIF field in octets
長さ：オクテットのRIFフィールドの全長
D: Direction of source route. A value of 0 means that the left-to-right sequence of Route Designators provides the path from the sender to recipient. A value of 0 indicates the sequence goes from recipient to sender.
D：ソースルートの方向。値0は、ルート指定子の左から右へのシーケンスが送信者から受信者へのパスを提供することを意味します。値0は、シーケンスが受信者から送信者に進むことを示します。
LF: Largest Frame
LF：最大のフレーム
rsvd: Reserved
rsvd：予約済み
On transmission, the Route Designator fields give the sequence of (bridge, LAN segment) numbers the packet is to traverse. It is the responsibility of the sender to provide this sequence for Specifically Routed Frames, i.e., unicast IP datagrams.
送信時に、Route Designatorフィールドは、パケットが通過する（ブリッジ、LANセグメント）番号のシーケンスを提供します。具体的にルーティングされるフレーム、つまりユニキャストIPデータグラムにこのシーケンスを提供するのは送信者の責任です。
The Interface Identifier [AARCH] for a Token Ring interface is based on the EUI-64 identifier [EUI64] derived from the interface's built-in 48-bit IEEE 802 address. The OUI of the Token Ring 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 Token Ring address become the last three octets of the EUI-64.
トークンリングインターフェイスのインターフェイス識別子[AARCH]は、インターフェイスの組み込み48ビットIEEE 802アドレスから派生したEUI-64識別子[EUI64]に基づいています。トークンリングアドレスのOUI（最初の3つのオクテット）は、EUI-64（最初の3つのオクテット）のcompany_idになります。 EUIの4番目と5番目のオクテットは、16進数の固定値FFFEに設定されます。トークンリングアドレスの最後の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. Complementing this bit will generally change a 0 value to a 1, since an interface's built-in address is expected to be from a universally administered address space and hence have a globally unique value. A universally administered IEEE 802 address or an EUI-64 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].
次に、EUI-64の最初のオクテットの2番目に低いビットである「ユニバーサル/ローカル」（U / L）ビットを補完することにより、EUI-64からインターフェイス識別子が形成されます。このビットを補完すると、一般に0の値が1に変更されます。これは、インターフェイスの組み込みアドレスは、汎用的に管理されるアドレススペースからのものであり、グローバルに一意の値を持つためです。汎用的に管理されるIEEE 802アドレスまたはEUI-64は、U / Lビット位置の0によって示され、グローバルに一意のIPv6インターフェース識別子は、対応する位置の1によって示されます。この点の詳細については、[AARCH]を参照してください。
For example, the Interface Identifier for a Token Ring interface whose built-in address is, in hexadecimal and in canonical bit order,
たとえば、組み込みアドレスが16進数で正規のビット順であるトークンリングインターフェースのインターフェース識別子
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 of a Token Ring interface must have a length of 64 bits.
トークンリングインターフェイスのステートレス自動設定に使用されるIPv6アドレスプレフィックスは、64ビットの長さである必要があります。
The IPv6 link-local address [AARCH] for a Token Ring interface is formed by appending the Interface Identifer, as defined above, to the prefix FE80::/64.
トークンリングインターフェースのIPv6リンクローカルアドレス[AARCH]は、上で定義されたインターフェースIDをプレフィックスFE80 :: / 64に追加することによって形成されます。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
The procedure for mapping unicast IPv6 addresses into Token Ring link-layer addresses is described in [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is Token Ring.
ユニキャストIPv6アドレスをトークンリングリンク層アドレスにマッピングする手順は、[DISC]で説明されています。リンク層がトークンリングの場合、ソース/ターゲットリンク層アドレスオプションは次の形式になります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Token Ring -+
| |
+- 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オクテット単位）。
Token Ring Address: The 48 bit Token Ring 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.
トークンリングアドレス：48ビットのトークンリングIEEE 802アドレス。正規のビット順。これは、インターフェースが現在応答しているアドレスであり、インターフェースIDの導出に使用される組み込みアドレスとは異なる場合があります。
When source routing bridges are used, the source route for the path to a destination can be extracted from the RIF field of received Neighbor Advertisement messages. Note that the RIF field of received packets can be reversed into a source route suitable for transmitting return traffic by toggling the value of the 'D' bit and insuring that the Bcast field is set to indicate a Specifically Routed Frame.
ソースルーティングブリッジが使用されている場合、宛先へのパスのソースルートは、受信したネイバーアドバタイズメッセージのRIFフィールドから抽出できます。受信したパケットのRIFフィールドは、「D」ビットの値をトグルし、Bcastフィールドが特定のルーティングフレームを示すように設定されていることを確認することにより、リターントラフィックの送信に適したソースルートに戻すことができます。
All IPv6 packets with multicast destination addresses are transmitted to Token Ring functional addresses. The following table shows the specific mapping between the IPv6 addresses and Token Ring functional addresses (in canonical form). Note that protocols other than IPv6 may use these same functional addresses, so all Token Ring frames destined to these functional addresses are not guaranteed to be IPv6 datagrams.
マルチキャスト宛先アドレスを持つすべてのIPv6パケットは、トークンリング機能アドレスに送信されます。次の表は、IPv6アドレスとトークンリング機能アドレス（標準形式）の間の具体的なマッピングを示しています。 IPv6以外のプロトコルがこれらの同じ機能アドレスを使用する場合があるため、これらの機能アドレス宛てのすべてのトークンリングフレームがIPv6データグラムであるとは限りません。
MAC Addr (canonical) IPv6 Multicast Addresses
MACアドレス（正規）IPv6マルチキャストアドレス
03-00-80-00-00-00 All-Nodes (FF01::1 and FF02::1) and
solicited node (FF02:0:0:0:0:1:FFXX:XXXX)
addresses
03-00-40-00-00-00 All-Routers addresses (FF0X::2)
03-00-40-00-00-00 All-Routersアドレス（FF0X :: 2）
03-00-00-80-00-00 any other multicast address with three least significant bits = 000
03-00-00-80-00-00最下位3ビットが000のその他のマルチキャストアドレス= 000
03-00-00-40-00-00 any other multicast address with three least significant bits = 001
03-00-00-40-00-00最下位3ビットが001のその他のマルチキャストアドレス= 001
03-00-00-20-00-00 any other multicast address with three least significant bits = 010
03-00-00-20-00-00 3つの最下位ビット= 010を持つその他のマルチキャストアドレス
03-00-00-10-00-00 any other multicast address with three least significant bits = 011
03-00-00-10-00-00 3つの最下位ビット= 011を持つその他のマルチキャストアドレス
03-00-00-08-00-00 any other multicast address with three least significant bits = 100
03-00-00-08-00-00最下位3ビットが100のその他のマルチキャストアドレス= 100
03-00-00-04-00-00 any other multicast address with three least significant bits = 101
03-00-00-04-00-00最下位3ビットが101のその他のマルチキャストアドレス= 101
03-00-00-02-00-00 any other multicast address with three least significant bits = 110
03-00-00-02-00-00 3つの最下位ビット= 110の他のマルチキャストアドレス
03-00-00-01-00-00 any other multicast address with three least significant bits = 111
03-00-00-01-00-00最下位3ビットが111のその他のマルチキャストアドレス= 111
In a bridged token ring network, all multicast packets SHOULD be sent with a RIF header specifying the use of the Spanning Tree Explorer.
ブリッジトークンリングネットワークでは、すべてのマルチキャストパケットは、スパニングツリーエクスプローラーの使用を指定するRIFヘッダーと共に送信する必要があります（SHOULD）。
Note: it is believed that some (very) old bridge implementations do not properly support the Spanning Tree Explorer mechanism. In such environments, multicast traffic sent through bridges must use a RIF with the All Routes Explorer. Consequently, an implementation MAY wish to allow the sending of IP multicast traffic using an All Routes Explorer. However, such an ability must be configurable by a system administrator and the default setting of the switch MUST be to use the Spanning Tree Explorer.
注：一部の（非常に）古いブリッジ実装は、スパニングツリーエクスプローラーメカニズムを適切にサポートしていないと考えられています。このような環境では、ブリッジを介して送信されるマルチキャストトラフィックは、All Routes ExplorerでRIFを使用する必要があります。したがって、実装では、All Routes Explorerを使用してIPマルチキャストトラフィックを送信できるようにする必要があります。ただし、そのような機能はシステム管理者が構成可能でなければならず、スイッチのデフォルト設定はスパニングツリーエクスプローラーを使用する必要があります。
Token Ring, like most broadcast LAN technologies, has inherent security vulnerabilities. For example, any sender can claim the identity of another and forge traffic. It is the responsibility of higher layers to take appropriate steps in those environments where such vulnerabilities are unacceptable.
トークンリングは、ほとんどのブロードキャストLANテクノロジーと同様に、セキュリティに脆弱性が内在しています。たとえば、すべての送信者が別の送信者のIDを要求し、トラフィックを偽造できます。このような脆弱性が許容できない環境で適切な手順を実行するのは、上位層の責任です。
Several members of the IEEE 802.5 Working Group contributed their knowledge and experience to the drafting of this specification, including Jim, Andrew Draper, George Lin, John Messenger, Kirk Preiss, and Trevor Warwick. The author would also like to thank many members of the IPng working group for their advice and suggestions, including Ran Atkinson, Scott Bradner, Steve Deering, Francis Dupont, Robert Elz, and Matt Thomas. A special thanks is due Steve Wise, who gave the most relevant advice of all by actually trying to implement this specification while it was in progress.
IEEE 802.5ワーキンググループのいくつかのメンバーは、ジム、アンドリュードレイパー、ジョージリン、ジョンメッセンジャー、カークプレイス、トレバーワーウィックなど、この仕様の草案作成に知識と経験を提供しました。著者はまた、ランアトキンソン、スコットブラドナー、スティーブディアリング、フランシスデュポン、ロバートエルツ、マットトーマスなど、IPngワーキンググループの多くのメンバーに助言と提案をしてくれたことに感謝します。特に仕様の進行中に実際にこの仕様を実装しようとすることで、最も適切なアドバイスをしてくれたSteve Wiseに感謝します。
[802.5] 8802-5 : 1995 (ISO/IEC) [ANSI/IEEE 802.5, 1995 Edition] Information technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements-- Part 5: Token ring access method and physical layer specification.
[802.5] 8802-5：1995（ISO / IEC）[ANSI / IEEE 802.5、1995 Edition]情報技術-システム間の通信および情報交換-ローカルおよびメトロポリタンエリアネットワーク-特定の要件-パート5：トークンリングアクセス方法と物理層の仕様。
[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月。
[BRIDGE] 10038: 1993 (ISO/IEC) [ANSI/IEEE Std 802.1D, 1993 Edition] Information technology--Telecommunications and information exchange between systems--Local area networks--Media access control (MAC) bridges.
[BRIDGE] 10038：1993（ISO / IEC）[ANSI / IEEE Std 802.1D、1993 Edition]情報技術-システム間の通信と情報交換-ローカルエリアネットワーク-メディアアクセス制御（MAC）ブリッジ。
[CANON] Narten, T. and C. Burton, "A Caution on Canonical Bit Order Of Link-Layer Addresses", RFC 2469, December 1998.
[CANON] Narten、T。およびC. Burton、「リンク層アドレスの正規ビット順序に関する注意」、RFC 2469、1998年12月。
[CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971, August 1996.
[CONF] Thomson、S.およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 1971、1996年8月。
[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月。
[EUI64] "64-Bit Global Identifier Format Tutorial", http: //standards.ieee.org/db/oui/tutorials/EUI64.html.
[EUI64]「64ビットグローバル識別子形式のチュートリアル」、http：//standards.ieee.org/db/oui/tutorials/EUI64.html。
[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月。
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.
[KWORD] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[LLC] 8802-2 : 1994 (ISO/IEC) [ANSI/IEEE 802.2, 1994 Edition] Information technology--Telecommunications and information exchange between systems--Local and Metropolitan area networks--Specific requirements-- Part 2: Logical link control.
[LLC] 8802-2：1994（ISO / IEC）[ANSI / IEEE 802.2、1994 Edition]情報技術-システム間の通信と情報交換-ローカルおよびメトロポリタンエリアネットワーク-特定の要件-パート2：論理リンクコントロール。
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
Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA
Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park、NC 27709-2195 USA
Phone: +1 919 254 7798
EMail: narten@raleigh.ibm.com
Stephen Thomas TransNexus 430 Tenth Street NW Suite N204 Atlanta, GA 30318 USA
Stephen Thomas TransNexus 430 Tenth Street NW Suite N204 Atlanta、GA 30318 USA
Phone: +1 404 872 4745
EMail: stephen.thomas@transnexus.com
Full Copyright Statement
完全な著作権表示
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。