この文書はRFC3572の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
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. 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/SHD(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 1. はじめに 2. Frame Format for Encapsulating IPv6 Datagrams 2. IPv6データグラムをカプセル化するためのフレームフォーマット 2.1. Frame Format 2.1. フレームフォーマット 2.2. Maximum Transmission Unit (MTU) 2.2. 最大限伝達ユニット(MTU) 2.3. Destination Address Mapping 2.3. 宛先アドレスマッピング 2.3.1. Unicast 2.3.1. ユニキャスト 2.3.2. Multicast 2.3.2. マルチキャスト 3. Interface Identifier 3. インタフェース識別子 4. Duplicate Address Detection 4. 重複アドレス発見 5. Source/Target Link-layer Address Option 5. ソース/目標リンクレイヤアドレスオプション 6. Security Considerations 6. セキュリティの考察 6.1. Issues concerning Link-layer Addresses 6.1. リンクレイヤアドレスに関係する問題 6.1.1. Protection against fraudulent reception of traffic 6.1.1. 偽トラフィックの受信に対しての保護 6.1.2. Protection against improper traffic 6.1.2. 不正トラフィックに対しての保護 6.2. Uniqueness of Interface Identifiers 6.2. インタフェース識別子の一意さ 7. References 7. 参考文献 8. Authors' Addresses 8. 著者のアドレス 9. Full Copyright Statement 9. 著作権表示全文 1. Introduction 1. はじめに 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]上の多数アクセスプロトコルはS ONET/SDH上で多数のアクセス能力を供給する高速リンクレイヤプロ トコルです。このフレームフォーマットはPPPのためのHDLC(上位レ ベルデータリンク制御)のようなフレーム[3]に基づいています。「フレーム スイッチ」[1]と呼ばれるコンポーネントが多数のノード(ホストとルータ) がLANを形成するためにスタートポロジーで結ばれることを可能にします。 長距離SONET/SDHリンクを使って、このような「SONET−LA N」上のノードは広域エリをつなぐことができます。 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. この文書はMAPOSフレームにインターネットプロトコルバージョン6 (IPv6)[4]データグラムをカプセル化するフレームフォーマットと、 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]とMAPOS16[2]の間の 区別が必要ないなら、用語「MAPOS」が使われます。 2. Frame Format for Encapsulating IPv6 Datagrams 2. IPv6データグラムをカプセル化するためのフレームフォーマット 2.1. Frame Format 2.1. フレームフォーマット 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はSONET上のPPPと同じHDLCのような[3]で記述された フレームを用います。MAPOSフレームは01111110(0x7E)のフラグ列で開 始と終了し、MAPOSフレームヘッダはアドレスと制御とプロトコルフィー ルドを含んでいます。アドレスフィールドは宛先HDLCアドレスを含んで います。MAPOS16で、アドレスフィールドは16ビットに拡張されま す、そしてMAPOSバージョン1の制御フィールドは除かれます。フレー ムチェックシーケンス(FCS)フィールドはデフォルトで長さ16ビット ですが、32ビットのFCSがオプションで使われるかもしれません。MA POSフレームフォーマットの詳細は[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フレームでカプセル化されます。IPv 6データグラムをカプセル化する場合に、プロトコルフィールドは値 0x0057(16進数)を含んでいなくてはなりません。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. フレームフォーマット 2.2. Maximum Transmission Unit (MTU) 2.2. 最大限伝達ユニット(MTU) 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オプションはシ ステム管理のためにログファイルに書かれるかもしれませんが、無視されな くてはなりません。 2.3. Destination Address Mapping 2.3. 宛先アドレスマッピング This section specifies the method of mapping an IPv6 destination address to the address field in the MAPOS frame header. この章はIPv6宛先アドレスをMAPOSフレームヘッダのアドレスフィー ルドにマッピングする方法を指定します。 2.3.1. Unicast 2.3.1. ユニキャスト 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]を通してMAPOSインタフェー スに割り当てられたHDLCアドレスを含み、これはIPv6ユニキャスト 宛先アドレスを持ちます。 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]で記述されたリンク層アドレス解決を使います。 2.3.2. Multicast 2.3.2. マルチキャスト 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マルチキャストアドレス上で行われません。 MAPOSバージョン1とMAPOS16で、下に記述されるように、IP v6マルチキャスト宛先アドレスが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]を含んでいます。フィールドの最下位ビット(L SB)はフィールドの終わりを示すために常に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ビットのアドレスフィールドはIPv 6マルチキャストアドレスの最下位6ビットを含んでいなくてはなりません。 図2がIPv6マルチキャストの場合のMAPOSバージョン1フレーム ヘッダのアドレスフィールドを示し、そしてD(1)からD(6)がIPv6マルチ キャストアドレスの最も最下位6ビットを表します。例外は、これらの6ビッ トがすべてのゼロか1の時です。これらの場合、ビット列は111110に 変えられるべきです。すなわち、アドレスフィールドは0xDF(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: MAPOS16: 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. MAPOS16のフレームヘッダのアドレスフィールドは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マルチキャストの場合の MAPOS16のフレームヘッダのアドレスフィールドを示し、ここでD(1) からD(13)がIPv6マルチキャストアドレスの最下位13ビットを表します。 例外は、13ビットがすべてのゼロか1の場合です。これらの場合、アドレ スフィールドは0xFEFD(16進数)であるべきです。 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.マルチキャストのアドレスマッピング(MAPOS16) 3. Interface Identifier 3. インタフェース識別子 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つ以上のEU I64[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. ノードがフレームスイッチに接続している時、HDLCアドレスがNSP [6]によってフレームスイッチからノードのインタフェースに割り当てら れます。(この文書の残りで、用語「MAPOSアドレス」はアドレスを 参照するために使われます)。インタフェースに割り当てられたMAPO Sアドレスの値はフレームスイッチのスイッチ番号とインタフェースが接 続されているフレームスイッチのポート番号の組合せに依存します。スイッ チ番号はMAPOSマルチスイッチ環境[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. さらに、もし実装がノードインタフェースとフレームスイッチのポートの 間のリンクを電源オンのまま交換可能であることを保証するなら、フレー ムスイッチあるいはノードインタフェースに接続したフレームスイッチの ポート番号は変化可能で、それでインタフェースに割り当てられたMAP OSアドレスは同じくノードのシステム再スタートを行わないで変化可能 です。 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アドレスは組み込みアドレスではなく、システム再スタート を行わないで変更できます。それで、もしインタフェース識別子がMAP OSアドレスから得られたなら、システム再スタート無しで変更できます。 これは[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]で、MAPOS16 の場合に割り当てられたアドレスは0x0003[2]です。同じリンクレ イヤアドレスを使用して決定的な方法でインタフェース識別子のリンク生 成をすることは容易ではありません。 For the above reasons, nodes with MAPOS interfaces must not derive their interface identifiers from their MAPOS addresses. 上記の理由のために、MAPOSインタフェースを持つノードがMAPO Sアドレスからインタフェース識別子を得てはなりません。 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)が ノードのどこかで利用可能なら、そのユニークさのためにインタフェース 識別子を生成する際に使われるべきです。ノードの他のデバイスからIE EEグローバル識別子を取り出すとき、取り出した識別子が標準順序[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−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"は企業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の真ん中に(企 業IDとEUI−48値の拡張識別子部の間に)、0xFFと0xFE の16進法値を持つ2つのオクテットを挿入することによって、EUI− 64フォーマットに変換します。 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"は企業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. 図5.世界的規模で一意な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を設定し なくてはなりません。 4. Duplicate Address Detection 4. 重複アドレス発見 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[6]によっ てインタフェースにMAPOSアドレスを届けるまで、完了しません。その 時まで、データ伝送がインタフェース上で行えません。そしてノードはMA POSアドレス割当がNSPによって完了された後、すべてのMAPOSイ ンタフェースのユニキャストアドレス上に重複アドレス検出[11]を行わなく てはなりません。 5. Source/Target Link-layer Address Option 5. ソース/目標リンクレイヤアドレスオプション 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オクテット(MAPOS16)あるいは1オクテット(MAPOSバー ジョン1)[1][2]です。それで、もしアドレスフィールドの正確な形式がソー ス/目標リンクレイヤアドレスオプションフィールドのリンクレイヤアドレ スフィールドに設定されるなら、オプションフィールドの全体の長さは4オ クテット(MAPOS16)あるいは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. タイプ: 1 ソースリンク層アドレス 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: MAPOS16 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. タイプ: 1 ソースリンク層アドレス 2 for Target link-layer address. 2 目標リンク層アドレス Length: 1 (in units of 8 octets). 長さ: 1 (8オクテット単位) Link-layer Address: MAPOS 16 16-bit address. アドレス: MAPOS16 16ビットアドレス Figure 9. Format of the Source/Target Link-layer Address option field (MAPOS 16). 図9.ソース/目標リンクレイヤアドレスオプションフィールド (MAPOS16)のフォーマット。 6. Security Considerations 6. セキュリティの考察 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で、リンクレイヤアドレス(MAPOSアドレス)が、NSPを 使ってフレームスイッチによりネットワークインタフェースに割り当てられ ます;ネットワークインタフェース上の組み込みのアドレスを使うイーサネッ トのような他のリンクレイヤプロトコルと異なります。これから得られたセ キュリティの考察が6.1と6.2で記述されます。MAPOSにリンクレイ ヤセキュリティがないから、他のリンクレイヤプロトコルと同じセキュリティ の考察が他のポイントに適用されるでしょう。 6.1. Issues concerning Link-layer Addresses 6.1. リンクレイヤアドレスに関係する問題 6.1.1. Protection against fraudulent reception of traffic 6.1.1. 偽トラフィックの受信に対しての保護 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アドレスの値はMA POSネットワークのインタフェースの場所を示します。換言すれば、M APOSフレームの宛先アドレスの値それ自身がフレームが最終的に配達 されるべきネットワークインタフェースの実際の場所を定義します。それ 故に、適切な管理上の処理を通してネットワークに接続していたノードの ネットワークインタフェースの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アドレスを広告しなくてはなりませ ん。これはホストの場所を正確に示すことを容易にします。 6.1.2. Protection against improper traffic 6.1.2. 不正トラフィックに対しての保護 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ルータを使って切り離すことです。これ は不正トラフィックをマルチスイッチ環境内に送っているノードを識別する ことを容易にします。外からの不正トラフィックに対して環境を安全に保つ ために、境界線IPルータがIPレイヤ情報に基づいてパケットフィルタリ ングを使って防ぐ必要があります。 6.2. Uniqueness of Interface Identifiers 6.2. インタフェース識別子の一意さ 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アドレスのグローバルな一意さが保証されません、そしてMAP OSアドレスはもし実装がノードのネットワークインタフェースとフレーム スイッチのポートの間のリンクがホットスワップ可能であることを保証する なら、組み込みのアドレスではなく、システム再起動を行わないで変えるこ とができます。それで、インタフェース識別子がシステム再起動無しで変化 しないことを保証するために、インタフェース識別子を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. 結果として、IPバージョン6上のMAPOSで、アドレスの基になるIE EEグローバルな識別子を持つMAPOS以外のネットワークインタフェー スの存在はインタフェース識別子を作る際に重要です。しかしながら、この ようなインターフェースがノードにない場合でもこれは共通で、一意さの異 なった情報源が使われなくてはなりません。従って、十分な注意がインタ フェース識別子の複製を妨げるためにとられるべきです。目下、事故あるい は偽物を通しての複製に対して保護がありません。 7. References 7. 参考文献 [1] Murakami, K. and M. Maruyama, "MAPOS - Multiple Access protocol over SONET/SDH Version 1", RFC 2171, June 1997. [2] Murakami, K. and M. Maruyama, "MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing", RFC 2175, June 1997. [3] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994. [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [6] Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension - Node Switch Protocol", RFC 2173, June 1997. [7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [8] IEEE, "Guidelines of 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997. [9] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. [10] Narten, T. and C. Burton, "A Caution On The Canonical Ordering Of Link-Layer Addresses", RFC 2469, December 1998. [11] Thompson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. 8. Authors' Addresses 8. 著者のアドレス Tsuyoshi Ogura NTT Network Innovation Laboratories 3-9-11, Midori-cho Musashino-shi Tokyo 180-8585, Japan EMail: ogura@core.ecl.net Mitsuru Maruyama NTT Network Innovation Laboratories 3-9-11, Midori-cho Musashino-shi Tokyo 180-8585, Japan EMail: mitsuru@core.ecl.net Toshiaki Yoshida Werk Mikro Systems 250-1, Mikajiri Kumagaya Saitama 360-0843, Japan EMail: yoshida@peta.arch.ecl.net 9. Full Copyright Statement 9. 著作権表示全文 Copyright (C) The Internet Society (2003). All Rights Reserved. 著作権(C)インターネット学会(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エディタ機能のための資金供給が現在インターネット学会によって 供給されます。