[要約] RFC 3572は、SONET/SDH上のMAPOS（Multiple Access Protocol Over SONET/SDH）を介したIPv6の実装に関する技術仕様です。このRFCの目的は、MAPOSを使用してIPv6を効果的に伝送するためのガイドラインを提供することです。
Network Working Group T. Ogura
Request for Comments: 3572 M. Maruyama
Category: Informational NTT Network Innovation Labs
T. Yoshida
Werk Mikro Systems
July 2003
Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)
MAPOS上のインターネットプロトコルバージョン6（SONET/SDH上の複数のアクセスプロトコル）
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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
IESG Note
IESGノート
This memo documents a way of carrying IPv6 packets over MAPOS networks. This document is NOT the product of an IETF working group nor is it a standards track document. It has not necessarily benefited from the widespread and in-depth community review that standards track documents receive.
このメモは、Maposネットワーク上にIPv6パケットを運ぶ方法を文書化しています。このドキュメントは、IETFワーキンググループの製品ではなく、標準トラックドキュメントでもありません。標準がドキュメントを受け取る広範囲で詳細なコミュニティレビューから必ずしも恩恵を受けているわけではありません。
Abstract
概要
Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link-layer protocol that provides multiple access capability over a Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH).
SONET/SDH（MAPOS）を介したマルチアクセスプロトコルは、同期光ネットワーク/同期デジタル階層（SONET/SDH）で複数のアクセス機能を提供する高速リンク層プロトコルです。
This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages.
このドキュメントは、MapOSフレームにIPv6データグラムをカプセル化するためのフレーム形式を指定します。また、IPv6インターフェイス識別子を形成する方法、重複アドレスを検出する方法、およびIPv6ネイバーディスカバリーメッセージで使用されるソース/ターゲットリンクレイヤーアドレスオプションフィールドの形式を指定します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Frame Format for Encapsulating IPv6 Datagrams. . . . . . . . . 3
2.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Maximum Transmission Unit (MTU). . . . . . . . . . . . . 3
2.3. Destination Address Mapping. . . . . . . . . . . . . . . 4
2.3.1. Unicast. . . . . . . . . . . . . . . . . . . . . 4
2.3.2. Multicast . . . . . . . . . . . . . . . . . . . . 4
3. Interface Identifier . . . . . . . . . . . . . . . . . . . . . 6
4. Duplicate Address Detection. . . . . . . . . . . . . . . . . . 8
5. Source/Target Link-layer Address Option. . . . . . . . . . . . 9
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 10
6.1. Issues concerning Link-layer Addresses . . . . . . . . . 10
6.1.1. Protection against fraudulent reception
of traffic . . . . . . . . . . . . . . . . . . . 10
6.1.2. Protection against improper traffic. . . . . . . 11
6.2. Uniqueness of Interface Identifiers. . . . . . . . . . . 11
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
Multiple Access Protocol over SONET/SDH (MAPOS) [1][2] is a high-speed link-layer protocol that provides multiple access capability over SONET/SDH. Its frame format is based on the HDLC-like (High Level Data Link Control) framing [3] for PPP. A component called a "Frame Switch" [1] allows multiple nodes (hosts and routers) to be connected together in a star topology to form a LAN. Using long-haul SONET/SDH links, the nodes on such a "SONET-LAN" can span a wide geographical area.
SONET/SDH（MAPOS）[1] [2]を介したマルチアクセスプロトコルは、SONET/SDHを介して複数のアクセス機能を提供する高速リンク層プロトコルです。そのフレーム形式は、PPPのHDLCのような（高レベルのデータリンクコントロール）フレーミング[3]に基づいています。「フレームスイッチ」[1]と呼ばれるコンポーネントを使用すると、複数のノード（ホストとルーター）を星トポロジーで接続してLANを形成できます。長距離SONET/SDHリンクを使用して、このような「ソネットラン」のノードは、広い地理的領域に及ぶ可能性があります。
This document specifies the frame format for encapsulating an Internet Protocol version 6 (IPv6) [4] datagram in a MAPOS frame, the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in Neighbor Discovery messages such as Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement, and Redirect messages.
このドキュメントは、インターネットプロトコルバージョン6（IPv6）[4] MAPOSフレームのデータグラムをカプセル化するためのフレーム形式、IPv6インターフェイス識別子を形成する方法、重複アドレスを検出する方法、およびソース/ターゲットリンクの形式 - レイヤーアドレスは、ルーターの勧誘、ルーター広告、近隣の勧誘、隣接広告、リダイレクトメッセージなどの近隣ディスカバリーメッセージで使用されるオプションフィールドをアドレス指定します。
In the remainder of this document, the term "MAPOS" is used unless the distinction between MAPOS version 1 [1] and MAPOS 16 [2] is required.
このドキュメントの残りの部分では、Maposバージョン1 [1]とMapos 16 [2]の区別が必要でない限り、「Mapos」という用語が使用されます。
MAPOS uses the same HDLC-like framing as PPP-over-SONET, described in [3]. The MAPOS frame begins and ends with a flag sequence 01111110 (0x7E), and the MAPOS frame header contains address, control, and protocol fields. The address field contains a destination HDLC address. In MAPOS 16, the address field is extended to 16 bits, and the control field of MAPOS version 1 is omitted. The frame check sequence (FCS) field is 16 bits long by default, but a 32-bit FCS may be used optionally. Details of the MAPOS frame format are described in [1][2].
Maposは、[3]で説明されているPPPオーバーソネットと同じHDLCのようなフレーミングを使用します。Maposフレームは、フラグシーケンス01111110（0x7e）で始まり、終了し、Maposフレームヘッダーにはアドレス、コントロール、およびプロトコルフィールドが含まれています。アドレスフィールドには、宛先HDLCアドレスが含まれています。Mapos 16では、アドレスフィールドは16ビットに拡張され、Maposバージョン1の制御フィールドは省略されています。フレームチェックシーケンス（FCS）フィールドはデフォルトでは16ビットですが、32ビットFCSをオプションで使用できます。Maposフレーム形式の詳細は[1] [2]で説明されています。
An IPv6 datagram is encapsulated in the MAPOS frame. In the case of encapsulating an IPv6 datagram, the protocol field must contain the value 0x0057 (hexadecimal). The IPv6 datagram is stored in the information field which follows immediately after the protocol field. That is, this field contains the IPv6 header followed immediately by the payload. Figure 1 shows the frame format. The fields are transmitted from left to right.
IPv6データグラムは、Maposフレームにカプセル化されています。IPv6データグラムをカプセル化する場合、プロトコルフィールドには値0x0057（hexadecimal）が含まれている必要があります。IPv6データグラムは、プロトコルフィールドの直後に続く情報フィールドに保存されます。つまり、このフィールドには、IPv6ヘッダーがすぐにペイロードが続きます。図1は、フレーム形式を示しています。フィールドは左から右に送信されます。
+----------+----------+----------+----------+
| | | Control/ | Protocol |
| Flag | Address | Address | 16 bits |
| 01111110 | 8 bits | 8 bits | (0x0057) |
+----------+----------+----------+----------+
+-------------+------------+----------+-----------
| | | | Inter-frame
| IPv6 header | FCS | Flag | fill or next
| and payload | 16/32 bits | 01111110 | address
+-------------+------------+----------+------------
Figure 1. Frame format.
図1.フレーム形式。
The length of the information field of the MAPOS frame may vary, but shall not exceed 65,280 (64K - 256) octets [1][2]. The default maximum transmission unit (MTU) is 65,280 octets.
Maposフレームの情報フィールドの長さは異なる場合がありますが、65,280（64K -256）オクテット[1] [2]を超えてはなりません。デフォルトの最大透過ユニット（MTU）は65,280オクテットです。
However, the MTU size may be reduced by a Router Advertisement [5] containing an MTU option that specifies a smaller MTU, or by manual configuration of each node. If a Router Advertisement received on a MAPOS interface has an MTU option specifying an MTU larger than 65,280, or larger than a manually configured value, that MTU option may be logged for the system management but must be otherwise ignored.
ただし、MTUサイズは、小さいMTUを指定するMTUオプションを含むルーター広告[5]によって、または各ノードの手動構成によって縮小される場合があります。MAPOSインターフェイスで受信したルーター広告には、65,280を超えるMTUを指定するMTUオプションがある場合、または手動で構成された値よりも大きい場合、そのMTUオプションはシステム管理用にログに記録される可能性がありますが、それ以外の場合は無視する必要があります。
This section specifies the method of mapping an IPv6 destination address to the address field in the MAPOS frame header.
このセクションでは、MAPOSフレームヘッダーのアドレスフィールドにIPv6宛先アドレスをマッピングする方法を指定します。
In unicasting, the address field of a MAPOS frame contains the HDLC address that has been assigned via NSP (Node Switch Protocol) [6] to the MAPOS interface, which has the IPv6 unicast destination address.
ユニキャストでは、MAPOSフレームのアドレスフィールドには、NSP（ノードスイッチプロトコル）[6]を介してIPv6ユニキャスト宛先アドレスを備えたMapoSインターフェイスに割り当てられたHDLCアドレスが含まれています。
In order to determine the destination HDLC address that corresponds to an IPv6 unicast destination address, the sender uses Link-layer Address Resolution described in [5].
IPv6ユニキャスト宛先アドレスに対応する宛先HDLCアドレスを決定するために、送信者は[5]で説明されているリンク層アドレス解像度を使用します。
Address resolution is never performed on IPv6 multicast addresses. An IPv6 multicast destination address is mapped to the address field in the MAPOS frame header as described below for MAPOS version 1 and MAPOS 16.
アドレス解像度は、IPv6マルチキャストアドレスでは決して実行されません。IPv6マルチキャスト宛先アドレスは、Maposバージョン1およびMapos 16について以下に説明するように、Maposフレームヘッダーのアドレスフィールドにマッピングされます。
MAPOS version 1:
Maposバージョン1：
The address field of the MAPOS version 1 frame header contains an 8- bit-wide destination HDLC address [1]. The least significant bit (LSB) of the field must always be 1 to indicate the end of the field. The most significant bit (MSB) is used to indicate whether the frame is a unicast or a multicast frame.
MAPOSバージョン1フレームヘッダーのアドレスフィールドには、8ビット幅の宛先HDLCアドレスが含まれています[1]。フィールドの最小ビット（LSB）は、フィールドの終了を示すために常に1でなければなりません。最も重要なビット（MSB）は、フレームがユニキャストかマルチキャストフレームかを示すために使用されます。
In the case of an IPv6 multicast, the MSB of the address field is 1 to indicate that the frame is multicast. As described above, the LSB of the address field is 1. The other six bits of the address field must contain the lowest-order six bits of the IPv6 multicast address. Figure 2 shows the address field of the MAPOS version 1 frame header in the case of an IPv6 multicast, where D(1) through D(6) represent the lowest-order six bits of the IPv6 multicast address. Exceptions arise when these six bits are either all zeros or all ones. In these cases, they should be altered to the bit sequence 111110. That is, the address field should be 0xFD (hexadecimal).
IPv6マルチキャストの場合、アドレスフィールドのMSBは1で、フレームがマルチキャストであることを示します。上記のように、アドレスフィールドのLSBは1です。アドレスフィールドの他の6ビットには、IPv6マルチキャストアドレスの最低6ビットが含まれている必要があります。図2は、IPv6マルチキャストの場合のMAPOSバージョン1フレームヘッダーのアドレスフィールドを示しています。D（1）からD（6）は、IPv6マルチキャストアドレスの最低6ビットを表しています。これらの6つのビットがすべてのゼロまたはすべてのビットである場合、例外が発生します。これらの場合、それらはビットシーケンス111110に変更する必要があります。つまり、アドレスフィールドは0xfd（16進数）でなければなりません。
MSB LSB
+-+-+-+-+-+-+-+-+
| | | |
|1|D(6) - D(1)|1|
| | | |
+-+-+-+-+-+-+-+-+
^ ^
| |
| EA bit (always 1)
1 (multicast)
Figure 2. Address mapping in multicasting (MAPOS version 1).
図2.マルチキャストのアドレスマッピング（Maposバージョン1）。
MAPOS 16:
Mapos 16：
The address field of the MAPOS 16 frame header contains the 16-bit-wide destination HDLC address [2]. The LSB of the first octet must always be 0 to indicate the continuation of this field, and the LSB of the second octet must always be 1 to indicate the end of this field. The MSB of the first octet is used to indicate whether the frame is a unicast or a multicast frame.
MAPOS 16フレームヘッダーのアドレスフィールドには、16ビット幅の宛先HDLCアドレスが含まれています[2]。このフィールドの継続を示すために、最初のオクテットのLSBは常に0でなければなりません。2番目のオクテットのLSBは、このフィールドの終了を示すために常に1でなければなりません。最初のオクテットのMSBは、フレームがユニキャストかマルチキャストフレームかを示すために使用されます。
In the case of an IPv6 multicast, the MSB of the first octet is 1 to indicate that the frame is multicast. As described above, the LSB of the first octet is 0 and the LSB of the second octet is 1. The other 13 bits of the address field must contain the lowest-order 13 bits of the IPv6 multicast address. Figure 3 shows the address field of the MAPOS 16 frame header in the case of an IPv6 multicast, where D(1) through D(13) represent the lowest-order 13 bits of the IPv6 multicast address. Exceptions arise when these 13 bits are either all zeros or all ones. In these cases, the address field should be 0xFEFD (hexadecimal).
IPv6マルチキャストの場合、最初のオクテットのMSBは1で、フレームがマルチキャストであることを示します。上記のように、最初のオクテットのLSBは0で、2番目のオクテットのLSBは1です。アドレスフィールドの他の13ビットには、IPv6マルチキャストアドレスの最低13ビットが含まれている必要があります。図3は、IPv6マルチキャストの場合のMAPOS 16フレームヘッダーのアドレスフィールドを示しています。D（1）からD（13）は、IPv6マルチキャストアドレスの最低13ビットを表しています。これらの13ビットがすべてのゼロまたはすべてのビットのいずれかである場合、例外が発生します。これらの場合、アドレスフィールドは0xfefd（hexadecimal）でなければなりません。
MSB LSB
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
|1|D(13)-D(8) |0| D(7)-D(1) |1|
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^
| | |
| | +-- EA bit (always 1)
| +-- EA bit (always 0)
1 (multicast)
Figure 3. Address mapping in multicasting (MAPOS 16).
図3.マルチキャストのアドレスマッピング（Mapos 16）。
This section specifies the method of forming the interface identifier [7].
このセクションでは、界面識別子を形成する方法を指定します[7]。
A node that has one or more MAPOS interfaces must create one or more EUI-64 [8] based interface identifiers. Here, it should be noted that deriving interface identifiers from HDLC addresses of MAPOS interfaces is undesirable for the following reasons.
1つ以上のMAPOSインターフェイスを持つノードは、1つ以上のEUI-64 [8]ベースのインターフェイス識別子を作成する必要があります。ここでは、MAPOSインターフェイスのHDLCアドレスから派生インターフェイス識別子が以下の理由で望ましくないことに注意する必要があります。
1. When a node is connected to a frame switch, an HDLC address is assigned to the interface of the node from the frame switch via NSP [6]. (In the remainder of this document, the term "MAPOS address" is used to refer to the address.) The value of the MAPOS address assigned to the interface depends on the combination of the switch number of the frame switch and the port number of the frame switch to which the interface is connected. The switch number is required to be unique only within a MAPOS multi-switch environment [6]; that is, there can be frame switches that have the same switch number in different MAPOS multi-switch environment separated by IP routers. Therefore, the uniqueness of a MAPOS address is guaranteed only within a MAPOS multi-switch environment.
1. ノードがフレームスイッチに接続されている場合、NSPを介してフレームスイッチからノードのインターフェイスにHDLCアドレスが割り当てられます[6]。（このドキュメントの残りの部分では、「Maposアドレス」という用語は、アドレスを参照するために使用されます。）インターフェイスに割り当てられたMaposアドレスの値は、フレームスイッチのスイッチ番号とポート番号の組み合わせに依存します。インターフェイスが接続されているフレームスイッチ。スイッチ番号は、Mapos Multi-Switch環境内でのみ一意である必要があります[6]。つまり、IPルーターで区切られた異なるMAPOSマルチスイッチ環境に同じスイッチ番号を持つフレームスイッチがある場合があります。したがって、Maposアドレスの一意性は、Maposマルチスイッチ環境内でのみ保証されます。
Furthermore, if an implementation ensures that the link between the interface of the node and the port of the frame switch is hot-swappable, the port number of the frame switch or the frame switch connected to the interface of the node can be changed, so the MAPOS address assigned to the interface can also be changed without performing a system re-start of the node.
さらに、実装により、ノードのインターフェイスとフレームスイッチのポート間のリンクがホットスワップ可能であることを保証すると、フレームスイッチのポート番号またはノードのインターフェイスに接続されたフレームスイッチを変更できるため、変更できます。インターフェイスに割り当てられたMAPOSアドレスは、ノードのシステムを再起動することなく変更することもできます。
In short, the global uniqueness of a MAPOS address is not guaranteed, and a MAPOS address is not a built-in address but can be changed without performing a system re-start. Thus, if an interface identifier were derived from a MAPOS address, it could also be changed without a system re-start. This would not follow the recommendation in [7].
要するに、Maposアドレスのグローバルな一意性は保証されておらず、Maposアドレスは組み込みのアドレスではありませんが、システムを再起動せずに変更できます。したがって、インターフェイス識別子がMAPOSアドレスから派生した場合、システムの再起動なしで変更することもできます。これは[7]の推奨に従いません。
2. In the case of a point-to-point connection between two nodes, the same MAPOS address is assigned to each interface. Specifically, in the case of MAPOS version 1, the assigned address is 0x03 [6], and in the case of MAPOS 16, the assigned address is 0x0003 [2]. It is not easy to achieve link-locality of the interface identifier in a strict manner using the same Link-layer address.
2. 2つのノード間のポイントツーポイント接続の場合、同じMAPOSアドレスが各インターフェイスに割り当てられます。具体的には、Maposバージョン1の場合、割り当てられたアドレスは0x03 [6]であり、Mapos 16の場合、割り当てられたアドレスは0x0003 [2]です。同じリンク層アドレスを使用して、厳密な方法でインターフェイス識別子のリンクローカリティを実現するのは容易ではありません。
For the above reasons, nodes with MAPOS interfaces must not derive their interface identifiers from their MAPOS addresses.
上記の理由により、MAPOSインターフェイスを備えたノードは、MAPOSアドレスからインターフェイス識別子を導き出してはなりません。
The following are methods of forming an interface identifier in the order of preference. These are almost the same as the methods described in [9] except that a MAPOS address must not be used as a source of uniqueness when an IEEE global identifier is unavailable.
以下は、設定の順にインターフェイス識別子を形成する方法です。これらは、IEEEグローバル識別子が利用できない場合、MAPOSアドレスを一意性のソースとして使用してはならないことを除いて、[9]で説明されている方法とほぼ同じです。
1) If an IEEE global identifier (EUI-48 or EUI-64) is available anywhere on the node, it should be used to construct the interface identifier due to its uniqueness. When extracting an IEEE global identifier from another device on the node, care should be taken to ensure that the extracted identifier is presented in canonical ordering [10].
1) IEEEグローバル識別子（EUI-48またはEUI-64）がノードのどこでも利用可能である場合、その独自性のためにインターフェイス識別子を構築するために使用する必要があります。ノード上の別のデバイスからIEEEグローバル識別子を抽出する場合、抽出された識別子が標準的な順序で提示されるように注意する必要があります[10]。
The only transformation from an EUI-64 identifier is to invert the "u" bit (universal/local bit in IEEE EUI-64 terminology). For example, for a globally unique EUI-64 identifier as shown in Figure 4:
EUI-64識別子からの唯一の変換は、「U」ビット（IEEE EUI-64用語でユニバーサル/ローカルビット）を反転することです。たとえば、図4に示すように、グローバルに一意のEUI-64識別子の場合：
MSB LSB
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
Figure 4. Globally unique EUI-64 identifier.
図4.グローバルに一意のEUI-64識別子。
where "c" are the bits of the assigned company_id, "0" is the value of the universal/local bit to indicate global scope, "g" is the group/individual bit, and "e" are the bits of the extension identifier, the IPv6 interface identifier would be as shown in Figure 5. The only change is inverting the value of the universal/local bit.
ここで、「C」は割り当てられたcompany_idのビットであり、「0」はグローバルスコープを示すユニバーサル/ローカルビットの値であり、「g」はグループ/個人ビット、「e」は拡張識別子のビットです、IPv6インターフェイス識別子は、図5に示すようになります。唯一の変更は、ユニバーサル/ローカルビットの値を反転することです。
MSB LSB
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
Figure 5. IPv6 interface identifier derived from a globally unique EUI-64 identifier.
図5.グローバルに一意のEUI-64識別子から派生したIPv6インターフェイス識別子。
In the case of an EUI-48 identifier, it is first converted to the EUI-64 format by inserting two octets, with hexadecimal values of 0xFF and 0xFE, in the middle of the 48-bit MAC (between the company_id and extension-identifier portions of the EUI-48 value).
EUI-48識別子の場合、48ビットMACの中央（Company_idと拡張Indectidifierの間に、2つのオクテットを挿入することにより、最初にEUI-64形式に変換されます。EUI-48値の一部）。
For example, for a globally unique 48-bit EUI-48 identifier as shown in Figure 6:
たとえば、図6に示すように、グローバルに一意の48ビットEUI-48識別子の場合：
MSB LSB
|0 1|1 3|3 4|
|0 5|6 1|2 7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+
Figure 6. Globally unique EUI-48 identifier.
図6.グローバルに一意のEUI-48識別子。
where "c" are the bits of the assigned company_id, "0" is the value of the universal/local bit to indicate global scope, "g" is the group/individual bit, and "e" are the bits of the extension identifier, the IPv6 interface identifier would be as shown in Figure 7.
ここで、「C」は割り当てられたcompany_idのビットであり、「0」はグローバルスコープを示すユニバーサル/ローカルビットの値であり、「g」はグループ/個人ビット、「e」は拡張識別子のビットです、IPv6インターフェイス識別子は、図7に示すとおりです。
MSB LSB
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
Figure 7. IPv6 interface identifier derived from a globally unique EUI-48 identifier.
図7.グローバルに一意のEUI-48識別子から派生したIPv6インターフェイス識別子。
2) If an IEEE global identifier is not available, a different source of uniqueness should be used. Suggested sources of uniqueness include machine serial numbers, etc. MAPOS addresses must not be used.
2) IEEEグローバル識別子が利用できない場合、別の一意性ソースを使用する必要があります。一意性の提案されたソースには、マシンのシリアル番号などが含まれます。Maposアドレスは使用してはなりません。
In this case, the "u" bit of the interface identifier must be set to 0.
この場合、インターフェイス識別子の「u」ビットを0に設定する必要があります。
3) If a good source of uniqueness cannot be found, it is recommended that a random number be generated. In this case the "u" bit of the interface identifier must be set to 0.
3) ユニークさの良い源を見つけることができない場合は、乱数を生成することをお勧めします。この場合、インターフェイス識別子の「u」ビットを0に設定する必要があります。
Immediately after the system start-up, the MAPOS address has not yet been assigned to a MAPOS interface. The assignment is not completed until the adjacent frame switch, or adjacent node in the case of a point-to-point connection between two nodes, has delivered the MAPOS address to the interface via NSP [6]. Until then, no data transmission can be performed on the interface. Thus, a node must conduct duplicate address detection [11] on all unicast addresses of MAPOS interfaces after the MAPOS address assignment has been completed by NSP.
システムの起動直後、MaposアドレスはまだMaposインターフェイスに割り当てられていません。割り当ては、2つのノード間のポイントツーポイント接続の場合の隣接するフレームスイッチ、または隣接するノードがNSPを介してインターフェイスにMAPOSアドレスを配信するまで完了しません[6]。それまでは、インターフェイスでデータ送信を実行することはできませんでした。したがって、NSPによってMAPOSアドレスの割り当てが完了した後、ノードはMAPOSインターフェイスのすべてのユニキャストアドレスで重複するアドレス検出[11]を実行する必要があります。
As specified in [5], the Source/Target Link-layer Address option is one of the options included in Neighbor Discovery messages. In [5], the length of the Source/Target Link-layer Address option field is specified in units of 8 octets. However, in the case of MAPOS, the length of the address field is 2 octets (MAPOS 16) or 1 octet (MAPOS version 1)[1][2]. Thus, if the exact form of the address field is embedded in the Link-layer Address field of the Source/Target Link-layer Address option field, the total length of the option field is 4 octets (MAPOS 16) or 3 octets (MAPOS version 1), both of which are shorter than 8 octets.
[5]で指定されているように、ソース/ターゲットリンク層アドレスオプションは、近隣発見メッセージに含まれるオプションの1つです。[5]では、ソース/ターゲットリンク層アドレスオプションの長さは、8オクテットの単位で指定されています。ただし、Maposの場合、アドレスフィールドの長さは2オクテット（Mapos 16）または1オクテット（Maposバージョン1）[1] [2]です。したがって、アドレスフィールドの正確なフォームがソース/ターゲットリンクレイヤーアドレスオプションフィールドのリンク層アドレスフィールドに埋め込まれている場合、オプションフィールドの合計長さは4オクテット（MAPOS 16）または3オクテット（MapOSバージョン1）、どちらも8オクテットよりも短い。
For the above reason, in the case of MAPOS, the Link-layer Address field of the Source/Target Link-layer Address option must be extended with zeros in order to extend the length of the option field to 8 octets, and the Length field must be set to 1 as shown below.
上記の理由で、MAPOSの場合、オプションフィールドの長さを8オクテット、長さフィールドに拡張するには、ソース/ターゲットリンク層アドレスのリンク層アドレスフィールドをゼロで拡張する必要があります。以下に示すように、1に設定する必要があります。
MAPOS version 1:
Maposバージョン1：
0 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 | All 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All 0 | Address | All 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type: 1 for Source link-layer address. 2 for Target link-layer address.
タイプ：ソースリンク層アドレスの場合。2ターゲットリンク層アドレスの場合。
Length: 1 (in units of 8 octets).
長さ：1（8オクテットの単位）。
Address: MAPOS version 1 8-bit address.
アドレス：Maposバージョン1 8ビットアドレス。
Figure 8. Format of the Source/Target Link-layer Address option field (MAPOS version 1).
図8.ソース/ターゲットリンクレイヤーアドレスオプションフィールドの形式（Maposバージョン1）。
MAPOS 16:
Mapos 16：
0 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 | All 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-layer Address | All 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type: 1 for Source link-layer address. 2 for Target link-layer address.
タイプ：ソースリンク層アドレスの場合。2ターゲットリンク層アドレスの場合。
Length: 1 (in units of 8 octets).
長さ：1（8オクテットの単位）。
Link-layer Address: MAPOS 16 16-bit address.
リンク層アドレス：Mapos 16 16ビットアドレス。
Figure 9. Format of the Source/Target Link-layer Address option field (MAPOS 16).
図9.ソース/ターゲットリンクレイヤーアドレスオプションフィールドの形式（Mapos 16）。
In MAPOS, a link-layer address (MAPOS address) is assigned to a network interface by a frame switch via NSP; unlike other link-layer protocols such as Ethernet that use a built-in address on a network interface. Security considerations derived from this are described in 6.1 and 6.2. Because there is no link-layer security in MAPOS, the same security considerations as those of other link-layer protocols would be applied to other points.
Maposでは、NSPを介したフレームスイッチによってリンク層アドレス（Maposアドレス）がネットワークインターフェイスに割り当てられます。ネットワークインターフェイスに組み込みアドレスを使用するイーサネットなどの他のリンク層プロトコルとは異なります。これから導き出されたセキュリティ上の考慮事項は、6.1および6.2で説明されています。Maposにはリンク層セキュリティがないため、他のリンク層プロトコルと同じセキュリティ上の考慮事項が他のポイントに適用されます。
In MAPOS, a MAPOS address is assigned by a frame switch, and it consists of the switch number and the port number of the switch to which the network interface is connected. (In the case of a point-to-point connection between two nodes, a fixed address is assigned to their network interfaces.) This brings the following advantages.
Maposでは、Maposアドレスがフレームスイッチによって割り当てられ、ネットワークインターフェイスが接続されているスイッチ番号とポート番号で構成されています。（2つのノード間のポイントツーポイント接続の場合、固定アドレスがネットワークインターフェイスに割り当てられます。）これは、次の利点をもたらします。
1. The value of the MAPOS address of a MAPOS network interface indicates the location of the interface in the MAPOS network. In other words, the value itself of the destination address of a MAPOS frame defines the actual location of the network interface to which the frame should be finally delivered. Therefore, as long as MAPOS addresses of network interfaces of nodes that have been connected to the network through proper administrative process are held and frames are delivered only to those addresses, other nodes cannot receive frames unless their network interfaces are connected to the same ports of frame switches as those to which network interfaces of properly administered nodes are connected. This makes fraudulent reception of traffic difficult.
1. MAPOSネットワークインターフェイスのMAPOSアドレスの値は、MAPOSネットワーク内のインターフェイスの位置を示しています。言い換えれば、Maposフレームの宛先アドレスの値自体は、フレームを最終的に配信するネットワークインターフェイスの実際の位置を定義します。したがって、適切な管理プロセスを介してネットワークに接続されたノードのネットワークインターフェイスのMAPOSアドレスが保持され、フレームがそれらのアドレスにのみ配信される限り、他のノードはネットワークインターフェイスが同じポートに接続されていない限りフレームを受信できません適切に管理されたノードのネットワークインターフェイスが接続されているものとしてフレームスイッチ。これにより、トラフィックの不正な受容が困難になります。
2. In the case where MAPOS addresses are not administered as mentioned above, it is possible that a malicious node could hijack traffic by spoofing its IPv6 address in a response to an IPv6 Neighbor Discovery. Even in this case, the node must advertise the true MAPOS address of its network interface in the response so that it can receive successive frames. This makes it easy to pinpoint the location of the host.
2. Maposアドレスが上記のように管理されていない場合、悪意のあるノードは、IPv6近隣発見への応答でIPv6アドレスをスプーフィングすることによりトラフィックをハイジャックできる可能性があります。この場合でも、ノードは、連続したフレームを受信できるように、応答内のネットワークインターフェイスの真のMAPOSアドレスを宣伝する必要があります。これにより、ホストの場所を簡単に特定できます。
A MAPOS frame does not have a field for including its sender's address. Therefore, in the case where a node sends one-way improper traffic maliciously or accidentally, there is no way to obtain the sender's MAPOS address from the traffic and this leads to difficulty in identifying the node (because source IP addresses might be forged).
Maposフレームには、送信者のアドレスを含めるためのフィールドがありません。したがって、ノードが一方向の不適切なトラフィックを悪意を持ってまたは誤って送信する場合、トラフィックから送信者のMAPOSアドレスを取得する方法はなく、これによりノードの識別が困難になります（ソースIPアドレスが偽造される可能性があるため）。
An effective way to alleviate the difficulty is to moderate the size of MAPOS multi-switch environment [6]. A common approach is to separate it using IP routers. This makes it easy to identify the node sending improper traffic within the multi-switch environment. To secure the environment against improper traffic from outside it, boundary IP routers need to block it using packet filtering based on IP layer information.
困難を軽減する効果的な方法は、Maposマルチスイッチ環境のサイズを緩和することです[6]。一般的なアプローチは、IPルーターを使用して分離することです。これにより、マルチスイッチ環境内で不適切なトラフィックを送信するノードを簡単に識別できます。ITの外部からの不適切なトラフィックから環境を保護するには、IPレイヤー情報に基づいてパケットフィルタリングを使用して境界IPルーターをブロックする必要があります。
Global uniqueness of a MAPOS address is not guaranteed, and a MAPOS address is not a built-in address but can be changed without performing a system re-start if an implementation ensures that the link between the network interface of the node and the port of the frame switch is hot-swappable. Thus, an interface identifier must not be derived from a MAPOS address in order to ensure that the interface identifier is not changed without a system re-start.
Maposアドレスのグローバルな一意性は保証されておらず、Maposアドレスは組み込みのアドレスではありませんが、実装がノードのネットワークインターフェイスとポートのネットワークインターフェイス間のリンクが保証された場合、システムを再起動せずに変更できます。フレームスイッチはホットスワップ可能です。したがって、システムの再起動なしにインターフェイス識別子が変更されないようにするために、インターフェイス識別子をMAPOSアドレスから導き出す必要はありません。
As a consequence, in IP Version 6 over MAPOS, the existence of network interfaces other than MAPOS that have IEEE global identifier based addresses has great importance in creating interface identifiers. However, it may be common for there to be no such interfaces on a node, so a different source of uniqueness must be used. Therefore, sufficient care should be taken to prevent duplication of interface identifiers. At present, there is no protection against duplication through accident or forgery.
結果として、MAPOSを介したIPバージョン6では、IEEEグローバル識別子ベースのアドレスを持つMAPOS以外のネットワークインターフェイスの存在は、インターフェイス識別子を作成する上で非常に重要です。ただし、ノードにそのようなインターフェイスがないことは一般的かもしれません。したがって、異なるユニーク性のソースを使用する必要があります。したがって、インターフェイス識別子の重複を防ぐために十分な注意を払う必要があります。現在、事故や偽造による重複に対する保護はありません。
[1] Murakami, K. and M. Maruyama, "MAPOS - Multiple Access protocol over SONET/SDH Version 1", RFC 2171, June 1997.
[1] 村上、K。およびM.マルヤマ、「Mapos -SONET/SDHバージョン1を介した複数アクセスプロトコル」、RFC 2171、1997年6月。
[2] Murakami, K. and M. Maruyama, "MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing", RFC 2175, June 1997.
[2] 村上、K。およびM.マルヤマ、「Mapos 16- 16ビットアドレス指定でSONET/SDHを介した複数のアクセスプロトコル」、RFC 2175、1997年6月。
[3] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[3] Simpson、W.、ed。、「HDLCのようなフレーミングのPPP」、STD 51、RFC 1662、1994年7月。
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[5] Narten、T.、Nordmark、E。およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[6] Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension - Node Switch Protocol", RFC 2173, June 1997.
[6] Murakami、K。およびM. Maruyama、「A Maposバージョン1拡張機能 - ノードスイッチプロトコル」、RFC 2173、1997年6月。
[7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[7] Hinden、R。and S. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[8] IEEE, "Guidelines of 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997.
[8] IEEE、「64ビットグローバル識別子（EUI-64）登録局のガイドライン」、http：//standards.ieee.org/db/oui/tutorials/eui64.html、1997年3月。
[9] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[9] Haskin、D.およびE. Allen、「PPP上のIPバージョン6」、RFC 2472、1998年12月。
[10] Narten, T. and C. Burton, "A Caution On The Canonical Ordering Of Link-Layer Addresses", RFC 2469, December 1998.
[10] Narten、T。およびC. Burton、「リンク層アドレスの標準的な順序付けに関する注意」、RFC 2469、1998年12月。
[11] Thompson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[11] Thompson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
Tsuyoshi Ogura NTT Network Innovation Laboratories 3-9-11, Midori-cho Musashino-shi Tokyo 180-8585, Japan
Tsuyoshi ogura ntt Network Innovation Laboratories 3-9-11、Midori-Cho Musashino-Shi Tokyo 180-8585、日本
EMail: ogura@core.ecl.net
Mitsuru Maruyama NTT Network Innovation Laboratories 3-9-11, Midori-cho Musashino-shi Tokyo 180-8585, Japan
丸山mttネットワークイノベーション研究所3-9-11、ミドリチョムサシノシートキオ180-8585、日本
EMail: mitsuru@core.ecl.net
Toshiaki Yoshida Werk Mikro Systems 250-1, Mikajiri Kumagaya Saitama 360-0843, Japan
トシアキヨシダヴェルクミクロシステム250-1、ミカジリクマガヤザイタマ360-0843、日本
EMail: yoshida@peta.arch.ecl.net
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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 assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
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エディター機能の資金は現在、インターネット協会によって提供されています。