この文書はRFC3572の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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)
ＭＡＰＯＳ上のインターネット・プロトコルバージョン６
（ＳＯＮＥＴ／ＳＤＨ上の多数アクセスプロトコル）
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
ＩＥＳＧメモ
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.
このメモはＭＡＰＯＳネットワーク上でＩＰｖ６パケットを運ぶ方法を文書
化します。この文書はＩＥＴＦ作業グループの成果ではなく、標準化中の文
書ではない。これは必ずしも広範囲にわたる利益はなく、そして深い標準化
手順の共同体の文書評価を受ける必要がありません。
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).
ＳＯＮＥＴ／ＳＨＤ（ＭＡＰＯＳ）上の多数アクセスプロトコルは同期光学
式ネットワーク／同期デジタル階層（ＳＯＮＥＴ／ＳＤＨ）上に多数アクセ
ス能力を供給する高速のリンクレイヤプロトコルです。
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.
この文書はＭＡＰＯＳフレームにＩＰｖ６データグラムを入れるフレーム
フォーマットを指定します。これは同じくＩＰｖ６インタフェース識別子を
形成する方法と、重複アドレス発見方法と、ＩＰｖ６近隣探索メッセージで
使うソース／目標リンクレイヤアドレスオプションフィールドのフォーマッ
トを検出する方法を指定します。
Table of Contents
目次
1. Introduction
1. はじめに
2. Frame Format for Encapsulating IPv6 Datagrams
2. ＩＰｖ６データグラムをカプセル化するためのフレームフォーマット
2.1. Frame Format
2.1. フレームフォーマット
2.2. Maximum Transmission Unit (MTU)
2.2. 最大限伝達ユニット（ＭＴＵ）
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.
ＳＯＮＥＴ／ＳＤＨ（ＭＡＰＯＳ）[1][2]上の多数アクセスプロトコルはＳ
ＯＮＥＴ／ＳＤＨ上で多数のアクセス能力を供給する高速リンクレイヤプロ
トコルです。このフレームフォーマットはＰＰＰのためのＨＤＬＣ（上位レ
ベルデータリンク制御）のようなフレーム[3]に基づいています。「フレーム
スイッチ」[1]と呼ばれるコンポーネントが多数のノード（ホストとルータ）
がＬＡＮを形成するためにスタートポロジーで結ばれることを可能にします。
長距離ＳＯＮＥＴ／ＳＤＨリンクを使って、このような「ＳＯＮＥＴ−ＬＡ
Ｎ」上のノードは広域エリをつなぐことができます。
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.
この文書はＭＡＰＯＳフレームにインターネットプロトコルバージョン６
（ＩＰｖ６）[4]データグラムをカプセル化するフレームフォーマットと、
ＩＰｖ６インタフェース識別子を生成する方法と、重複アドレスを検出する
方法と、ルータ要請とルータ広告と近隣要請と近隣広告とリダイレクトメッ
セージで使うのような近隣探索メッセージで使うソース／目標リンクレイヤ
アドレスオプションフィールドのフォーマットを指定します。
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.
この文書の残りで、ＭＡＰＯＳバージョン１[1]とＭＡＰＯＳ１６[2]の間の
区別が必要ないなら、用語「ＭＡＰＯＳ」が使われます。
2. Frame Format for Encapsulating IPv6 Datagrams
2. ＩＰｖ６データグラムをカプセル化するためのフレームフォーマット
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].
ＭＡＰＯＳはＳＯＮＥＴ上のＰＰＰと同じＨＤＬＣのような[3]で記述された
フレームを用います。ＭＡＰＯＳフレームは01111110(0x7E)のフラグ列で開
始と終了し、ＭＡＰＯＳフレームヘッダはアドレスと制御とプロトコルフィー
ルドを含んでいます。アドレスフィールドは宛先ＨＤＬＣアドレスを含んで
います。ＭＡＰＯＳ１６で、アドレスフィールドは１６ビットに拡張されま
す、そしてＭＡＰＯＳバージョン１の制御フィールドは除かれます。フレー
ムチェックシーケンス（ＦＣＳ）フィールドはデフォルトで長さ１６ビット
ですが、３２ビットのＦＣＳがオプションで使われるかもしれません。ＭＡ
ＰＯＳフレームフォーマットの詳細は[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.
ＩＰｖ６データグラムがＭＡＰＯＳフレームでカプセル化されます。ＩＰｖ
６データグラムをカプセル化する場合に、プロトコルフィールドは値
０x００５７（１６進数）を含んでいなくてはなりません。ＩＰｖ６データグ
ラムはプロトコルフィールドのすぐ後に次に続く情報フィールドに設定され
ます。すなわち、このフィールドはＩＰｖ６ヘッダと続くペイロードを含ん
でいます。図１がフレームフォーマットを示します。フィールドは右から左
に伝達されます。
+----------+----------+----------+----------+
| | | 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.
図１． フレームフォーマット
2.2. Maximum Transmission Unit (MTU)
2.2. 最大限伝達ユニット（ＭＴＵ）
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.
ＭＡＰＯＳフレームの情報フィールドの長さが変化するかもしれません、し
かし６５，２８０（６４Ｋ−２５６）オクテット[1][2]を超えるべきではあ
りません。デフォルト最大限伝達ユニット（ＭＴＵ）は６５，２８０オクテッ
トです。
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.
しかしながら、ＭＴＵサイズはより小さいＭＴＵを指定するＭＴＵオプショ
ンを含んでいるルータ広告[5]によって、あるいはそれぞれのノードの手動設
定によって減らされるかもしれません。もしＭＡＰＯＳインタフェース上で
受け取ったルータ広告が６５，２８０あるいは手動設定で設定した値より大
きいＭＴＵを指定するＭＴＵオプションを含むなら、ＭＴＵオプションはシ
ステム管理のためにログファイルに書かれるかもしれませんが、無視されな
くてはなりません。
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.
この章はＩＰｖ６宛先アドレスをＭＡＰＯＳフレームヘッダのアドレスフィー
ルドにマッピングする方法を指定します。
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.
ユニキャストすることにおいて、ＭＡＰＯＳフレームのアドレスフィールド
はＮＳＰ（ノードスイッチプロトコル）[6]を通してＭＡＰＯＳインタフェー
スに割り当てられたＨＤＬＣアドレスを含み、これはＩＰｖ６ユニキャスト
宛先アドレスを持ちます。
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].
ＩＰｖ６ユニキャスト宛先アドレスに対応する宛先ＨＤＬＣアドレスを決定
するために、送り主は[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.
アドレス解決は決してＩＰｖ６マルチキャストアドレス上で行われません。
ＭＡＰＯＳバージョン１とＭＡＰＯＳ１６で、下に記述されるように、ＩＰ
ｖ６マルチキャスト宛先アドレスがＭＡＰＯＳフレームヘッダのアドレス
フィールドにマップされます。
MAPOS version 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.
ＭＡＰＯＳバージョン１フレームヘッダのアドレスフィールドは８ビット幅
の宛先ＨＤＬＣアドレス[1]を含んでいます。フィールドの最下位ビット（Ｌ
ＳＢ）はフィールドの終わりを示すために常に１であるに違いありません。
最上位ビット（ＭＳＢ）はフレームがユニキャストフレームかマルチキャス
トフレームかを示すために使われます。
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).
ＩＰｖ６マルチキャストの場合、アドレスフィールドのＭＳＢはフレームが
マルチキャストであることを示すために１です。上記のように、アドレス
フィールドのＬＳＢは１です。他の６ビットのアドレスフィールドはＩＰｖ
６マルチキャストアドレスの最下位６ビットを含んでいなくてはなりません。
図２がＩＰｖ６マルチキャストの場合のＭＡＰＯＳバージョン１フレーム
ヘッダのアドレスフィールドを示し、そしてD(1)からD(6)がＩＰｖ６マルチ
キャストアドレスの最も最下位６ビットを表します。例外は、これらの６ビッ
トがすべてのゼロか１の時です。これらの場合、ビット列は１１１１１０に
変えられるべきです。すなわち、アドレスフィールドは０ｘＤＦ（１６進数）
であるべきです。
MSB LSB
+-+-+-+-+-+-+-+-+
| | | |
|1|D(6) - D(1)|1|
| | | |
+-+-+-+-+-+-+-+-+
^ ^
| |
| EA bit (always 1)
1 (multicast)
Figure 2. Address mapping in multicasting (MAPOS version 1).
図２．マルチキャストのアドレスマッピング（ＭＡＰＯＳバージョン１）
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.
ＭＡＰＯＳ１６のフレームヘッダのアドレスフィールドは１６ビット幅の宛
先ＨＤＬＣアドレス[2]を含んでいます。最初のオクテットのＬＳＢはこの
フィールドの継続を示すために常に０に違いありません、そして２番目のオ
クテットのＬＳＢはこのフィールドの終わりを示すために常に１であるに違
いありません。最初のオクテットのＭＳＢはフレームがユニキャストフレー
ムかマルチキャストフレームかを示すために使われます。
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).
ＩＰｖ６マルチキャストの場合、最初のオクテットのＭＳＢはフレームがマ
ルチキャストであることを示すために１です。上記のように、最初のオクテッ
トのＬＳＢは０で、２番目のオクテットのＬＳＢは１です。他の１３ビット
のアドレスフィールドはＩＰｖ６マルチキャストアドレスの最下位１３ビッ
トを含んでいなくてはなりません。図３がＩＰｖ６マルチキャストの場合の
ＭＡＰＯＳ１６のフレームヘッダのアドレスフィールドを示し、ここでD(1)
からD(13)がＩＰｖ６マルチキャストアドレスの最下位１３ビットを表します。
例外は、１３ビットがすべてのゼロか１の場合です。これらの場合、アドレ
スフィールドは０ｘＦＥＦＤ（１６進数）であるべきです。
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. 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.
１つ以上のＭＡＰＯＳインタフェースを持っているノードが１つ以上のＥＵ
Ｉ６４[8]に基づくインタフェース識別子を作らなければなりません。ここで、
ＭＡＰＯＳインタフェースのＨＤＬＣアドレスからインタフェース識別子を
得ることは次の理由で望ましくないことを指摘します。
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. ノードがフレームスイッチに接続している時、ＨＤＬＣアドレスがＮＳＰ
[6]によってフレームスイッチからノードのインタフェースに割り当てら
れます。（この文書の残りで、用語「ＭＡＰＯＳアドレス」はアドレスを
参照するために使われます）。インタフェースに割り当てられたＭＡＰＯ
Ｓアドレスの値はフレームスイッチのスイッチ番号とインタフェースが接
続されているフレームスイッチのポート番号の組合せに依存します。スイッ
チ番号はＭＡＰＯＳマルチスイッチ環境[6]の中でだけ一意であるように
要求されます；すなわち、ＩＰルータで分割された異なったＭＡＰＯＳマ
ルチスイッチ環境に同じスイッチ番号を持つフレームスイッチがあり得ま
す。それ故に、ＭＡＰＯＳアドレスの一意さはＭＡＰＯＳマルチスイッチ
環境の中でだけ保証されます。
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.
さらに、もし実装がノードインタフェースとフレームスイッチのポートの
間のリンクを電源オンのまま交換可能であることを保証するなら、フレー
ムスイッチあるいはノードインタフェースに接続したフレームスイッチの
ポート番号は変化可能で、それでインタフェースに割り当てられたＭＡＰ
ＯＳアドレスは同じくノードのシステム再スタートを行わないで変化可能
です。
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].
要するに、ＭＡＰＯＳアドレスのグローバルな一意さは保証されず、そし
てＭＡＰＯＳアドレスは組み込みアドレスではなく、システム再スタート
を行わないで変更できます。それで、もしインタフェース識別子がＭＡＰ
ＯＳアドレスから得られたなら、システム再スタート無しで変更できます。
これは[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. ２つのノードの間のポイントポイントの接続の場合、同じＭＡＰＯＳアド
レスが各インタフェースに割り当てられます。特に、ＭＡＰＯＳバージョ
ン１の場合に割り当てられたアドレスは０ｘ０３[6]で、ＭＡＰＯＳ１６
の場合に割り当てられたアドレスは０ｘ０００３[2]です。同じリンクレ
イヤアドレスを使用して決定的な方法でインタフェース識別子のリンク生
成をすることは容易ではありません。
For the above reasons, nodes with MAPOS interfaces must not derive
their interface identifiers from their MAPOS addresses.
上記の理由のために、ＭＡＰＯＳインタフェースを持つノードがＭＡＰＯ
Ｓアドレスからインタフェース識別子を得てはなりません。
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.
以下は、インタフェース識別子を生成する方法の優先順位です。ＩＥＥＥ
グローバル識別子が利用可能でない時、ユニークさの源としてＭＡＰＯＳ
アドレスが利用できないい外、ほとんど[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) もしＩＥＥＥグローバル識別子（ＥＵＩ−４８あるいはＥＵＩ−６４）が
ノードのどこかで利用可能なら、そのユニークさのためにインタフェース
識別子を生成する際に使われるべきです。ノードの他のデバイスからＩＥ
ＥＥグローバル識別子を取り出すとき、取り出した識別子が標準順序[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:
唯一のＥＵＩ−６４識別子からの変換は「ｕ」ビット（ＩＥＥＥ−６４の
用語で共通／ローカルビット）を反転する事です。例えば、図４で示され
る世界的規模で一意なＥＵＩ−６４識別子で：
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.
図４． 世界的規模で一意なＥＵＩ−６４識別子
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"は企業ＩＤに割り当てられたビットで、"0"がグローバルな範囲
を示す共通／ローカルなビットの値で、"g"がグループ／個別ビットで、
"e"が拡張子識別子ビットです、ＩＰｖ６インタフェース識別子が図５に
示されるとおりでしょう。唯一の変更は共通／ローカルビットの価の反転
です。
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.
図５．世界的規模で一意なＥＵＩ−６４識別子から生じたＩＰｖ６インタ
フェース識別子。
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).
ＥＵＩ−４８識別子の場合、最初に４８ビットのＭＡＣの真ん中に（企
業ＩＤとＥＵＩ−４８値の拡張識別子部の間に）、０ｘＦＦと０ｘＦＥ
の１６進法値を持つ２つのオクテットを挿入することによって、ＥＵＩ−
６４フォーマットに変換します。
For example, for a globally unique 48-bit EUI-48 identifier as
shown in Figure 6:
例えば、図６に示される世界的規模で一意な４８ビットのＥＵＩ−４８
識別子で：
MSB LSB
|0 1|1 3|3 4|
|0 5|6 1|2 7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+
Figure 6. Globally unique EUI-48 identifier.
図６． 世界的規模で一意なＥＵＩ−４８識別子
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"は企業ＩＤに割り当てられたビットで、"0"がグローバルな範囲
を示す共通／ローカルなビットの値で、"g"がグループ／個別ビットで、
"e"が拡張子識別子ビットです、ＩＰｖ６インタフェース識別子が図７に
示されるとおりでしょう。
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.
図５．世界的規模で一意なＥＵＩ−４８識別子から生じたＩＰｖ６インタ
フェース識別子。
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) もしＩＥＥＥグローバル識別子が利用可能でないなら、一意である異なっ
た情報源が使われるべきです。提案される一意な情報源は、機械のシリア
ル番号などを含みます。ＭＡＰＯＳアドレスを使ってはなりません。
In this case, the "u" bit of the interface identifier must be set
to 0.
この場合、インタフェース識別子の"u"ビットは０を設定しなくてはなり
ません。
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"ビットは０を設定し
なくてはなりません。
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.
システムの起動の直後は、ＭＡＰＯＳアドレスはまだＭＡＰＯＳインタフェー
スに割り当てられません。割当ては、隣接したフレームスイッチか、２つの
ノード間のポイントポイント接続の場合は隣接したノードが、ＮＳＰ[6]によっ
てインタフェースにＭＡＰＯＳアドレスを届けるまで、完了しません。その
時まで、データ伝送がインタフェース上で行えません。そしてノードはＭＡ
ＰＯＳアドレス割当がＮＳＰによって完了された後、すべてのＭＡＰＯＳイ
ンタフェースのユニキャストアドレス上に重複アドレス検出[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]で指定されるように、ソース／目標リンクレイヤアドレスオプションは近
隣探索メッセージに含められるオプションの１つです。[5]で、ソース／目標
リンクレイヤアドレスオプションフィールドの長さは８オクテット単位で指
定されます。しかしながら、ＭＡＰＯＳの場合に、アドレスフィールドの長
さは２オクテット（ＭＡＰＯＳ１６）あるいは１オクテット（ＭＡＰＯＳバー
ジョン１）[1][2]です。それで、もしアドレスフィールドの正確な形式がソー
ス／目標リンクレイヤアドレスオプションフィールドのリンクレイヤアドレ
スフィールドに設定されるなら、オプションフィールドの全体の長さは４オ
クテット（ＭＡＰＯＳ１６）あるいは３オクテット（ＭＡＰＯＳバージョン
１）で、両方ともが８オクテットより短いです。
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 version 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 （８オクテット単位）
Address: MAPOS version 1 8-bit address.
アドレス： ＭＡＰＯＳバージョン１ ８ビットアドレス
Figure 8. Format of the Source/Target Link-layer Address option
field (MAPOS version 1).
図８．ソース／目標リンクレイヤアドレスオプションフィールド
（ＭＡＰＯＳバージョン１）のフォーマット。
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.
タイプ： 1 ソースリンク層アドレス
2 for Target link-layer address.
2 目標リンク層アドレス
Length: 1 (in units of 8 octets).
長さ： 1 （８オクテット単位）
Link-layer Address: MAPOS 16 16-bit address.
アドレス： ＭＡＰＯＳ１６ １６ビットアドレス
Figure 9. Format of the Source/Target Link-layer Address option
field (MAPOS 16).
図９．ソース／目標リンクレイヤアドレスオプションフィールド
（ＭＡＰＯＳ１６）のフォーマット。
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.
ＭＡＰＯＳで、リンクレイヤアドレス（ＭＡＰＯＳアドレス）が、ＮＳＰを
使ってフレームスイッチによりネットワークインタフェースに割り当てられ
ます；ネットワークインタフェース上の組み込みのアドレスを使うイーサネッ
トのような他のリンクレイヤプロトコルと異なります。これから得られたセ
キュリティの考察が６.１と６.２で記述されます。ＭＡＰＯＳにリンクレイ
ヤセキュリティがないから、他のリンクレイヤプロトコルと同じセキュリティ
の考察が他のポイントに適用されるでしょう。
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.
ＭＡＰＯＳで、ＭＡＰＯＳアドレスがフレームスイッチにより割り当てられ
ます、これはスイッチ番号とネットワークインタフェースが接続されている
スイッチのポート番号から成り立ちます。（ポイントポイント接続の場合、
２つのノード間で固定したアドレスがネットワークインタフェースに割り当
てられます）。これは次の利点をもたらします。
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. ＭＡＰＯＳネットワークインタフェースのＭＡＰＯＳアドレスの値はＭＡ
ＰＯＳネットワークのインタフェースの場所を示します。換言すれば、Ｍ
ＡＰＯＳフレームの宛先アドレスの値それ自身がフレームが最終的に配達
されるべきネットワークインタフェースの実際の場所を定義します。それ
故に、適切な管理上の処理を通してネットワークに接続していたノードの
ネットワークインタフェースのＭＡＰＯＳアドレスが維持され、そしてフ
レームがそれらのアドレスにだけ配達される限り、管理されたノードのネッ
トワークインタフェースが接続されているのと正確に同じフレームスイッ
チのポートに、他のノードのネットワークインタフェースが接続していな
いなら、他のノードがフレームを受け取ることができません。これは偽ト
ラフィックの受信を難しくします。
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. ＭＡＰＯＳアドレスが上記の通り管理されない場合で、悪意があるノード
がＩＰｖ６近隣探索に対する回答で、そのＩＰｖ６アドレスを偽アドレス
で送ることによってトラフィックを乗っ取ることが可能です。この場合で
さえ、続くフレームを受信できるように、ノードは回答でそのネットワー
クインタフェースの本当のＭＡＰＯＳアドレスを広告しなくてはなりませ
ん。これはホストの場所を正確に示すことを容易にします。
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).
ＭＡＰＯＳフレームは送信者のアドレスを含むフィールドを持っていません。
それ故に、ノードが悪意をもって、あるいは偶然に一方向の不正トラフィッ
クを送る場合で、トラフィックから送信者のＭＡＰＯＳアドレスを得る方法
がありません、そしてこれは、（ソースＩＰアドレスが偽造されるかもしれ
ないから）、ノードを識別することを困難にします。
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.
困難さを軽減する簡単な方法はＭＡＰＯＳマルチスイッチ環境[6]サイズを加
減することです。普通の方法はＩＰルータを使って切り離すことです。これ
は不正トラフィックをマルチスイッチ環境内に送っているノードを識別する
ことを容易にします。外からの不正トラフィックに対して環境を安全に保つ
ために、境界線ＩＰルータがＩＰレイヤ情報に基づいてパケットフィルタリ
ングを使って防ぐ必要があります。
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.
ＭＡＰＯＳアドレスのグローバルな一意さが保証されません、そしてＭＡＰ
ＯＳアドレスはもし実装がノードのネットワークインタフェースとフレーム
スイッチのポートの間のリンクがホットスワップ可能であることを保証する
なら、組み込みのアドレスではなく、システム再起動を行わないで変えるこ
とができます。それで、インタフェース識別子がシステム再起動無しで変化
しないことを保証するために、インタフェース識別子をＭＡＰＯＳアドレス
から得てはなりません。
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.
結果として、ＩＰバージョン６上のＭＡＰＯＳで、アドレスの基になるＩＥ
ＥＥグローバルな識別子を持つＭＡＰＯＳ以外のネットワークインタフェー
スの存在はインタフェース識別子を作る際に重要です。しかしながら、この
ようなインターフェースがノードにない場合でもこれは共通で、一意さの異
なった情報源が使われなくてはなりません。従って、十分な注意がインタ
フェース識別子の複製を妨げるためにとられるべきです。目下、事故あるい
は偽物を通しての複製に対して保護がありません。
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.
著作権（Ｃ）インターネット学会（２００３）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。