この文書はRFC 4489の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group J-S. Park
Request for Comments: 4489 M-K. Shin
Updates: 3306 H-J. Kim
Category: Standards Track ETRI
April 2006
A Method for Generating Link-Scoped IPv6 Multicast Addresses
リンク範囲ＩＰｖ６マルチキャストアドレスを生成するための方法
Status of This Memo
この文書の状態
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化中のプロトコ
ルを指定し、そして改良のために議論と提案を求めます。このプロトコルと標
準化状態と状況は「インターネット公式プロトコル標準」（ＳＴＤ１）の最新
版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Abstract
概要
This document specifies an extension to the multicast addressing
architecture of the IPv6 protocol. The extension allows the use of
Interface Identifiers (IIDs) to allocate multicast addresses. When a
link-local unicast address is configured at each interface of a node,
an IID is uniquely determined. After that, each node can generate
its unique multicast addresses automatically without conflicts. The
alternative method for creating link-local multicast addresses
proposed in this document is better than known methods like unicast-
prefix-based IPv6 multicast addresses. This memo updates RFC 3306.
この文書はＩＰｖ６プロトコルのマルチキャストアドレス体系への拡張を指
定します。拡張はインタフェース識別子（IID）を使用してマルチキャスト
アドレスを割り当てることを可能にします。リンクローカルユニキャストア
ドレスがノードのそれぞれのインタフェースで設定されるとき、ＩＩＤが一
意に決定されます。その後に、それぞれのノードが衝突なしで自動的に一意
なマルチキャストアドレスを生成することができます。この文書で提案され
たリンクローカルマルチキャストアドレスを作成する方法はユニキャストプ
レフィックスベースのＩＰｖ６マルチキャストアドレスのような周知の方法
より良いです。この文書はＲＦＣ３３０６を更新します。
Table of Contents:
目次
1. Introduction
1. はじめに
2. Applicability
2. 適用性
3. Link-Scoped Multicast Address Format
3. リンク範囲マルチキャストアドレスフォーマット
4. Example
4. 例
5. Consideration of Lifetime
5. 寿命の考慮
6. Security Considerations
6. セキュリティの考察
7. Acknowledgements
7. 謝辞
8. References
8. 参考文献
1. Introduction
1. はじめに
This document defines an extension to the multicast portion of the
IPv6 addressing architecture [RFC4291]. The current architecture
does not contain any built-in support for dynamic address allocation.
The extension allows for use of IIDs to allocate multicast addresses.
When a link-local unicast address is configured at each interface of
a node, an IID is uniquely determined. After that, each node can
generate its unique multicast addresses automatically without
conflicts. That is, these addresses could safely be configured at
any time after Duplicate Address Detection (DAD) has completed.
この文書はＩＰｖ６アドレス体系[RFC4291]のマルチキャスト部への拡張を定
義します。現在の体系は動的アドレス割り当てに対する組み込みのサポート
を含みません。拡張はＩＩＤを使用してマルチキャストアドレスを割り当て
ることを許します。ノードのそれぞれのインタフェースにおいてリンクロー
カルユニキャストアドレスが設定されるとき、ＩＩＤが一意に決定されます。
その後に、それぞれのノードが衝突なしで自動的に一意なマルチキャストア
ドレスを生成することができます。すなわち、重複アドレス発見（ＤＡＤ）
が完了した後、これらのアドレスは安全にいつでも設定ができます。
This method for the link-local scope is preferred over unicast-
prefix-based IPv6 multicast addresses [RFC3306], since by delegating
multicast addresses using the IID, each node can generate its
multicast addresses automatically without allocation servers. This
method works better than the unicast-prefix-based method with
applications in serverless environments such as ad-hoc and network
mobility. This document restricts the usage of defined fields such
as the scop, plen, and network prefix fields of [RFC3306].
Therefore, this document specifies encoded information for link-local
scope in multicast addresses.
ＩＩＤを使ってマルチキャストアドレスを割当ることで、それぞれのノード
が割当サーバなしで自動的にマルチキャストアドレスを生成することができ
るので、リンクローカル範囲のためのこの方法はユニキャストプレフィック
スベースのＩＰｖ６マルチキャストアドレス[RFC3306]より好まれます。この
方法はアドホックやネットワーク移動のようなサーバレス環境のアプリケー
ションでユニキャストプレフィックスベースの方法より良く機能します。こ
の文書は[RFC3306]のscopやplenやnetwork prefixのような定義されたフィー
ルドの使用を限定します。そのために、この文書はマルチキャストアドレス
のリンクローカル範囲のコード化された情報を指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
[RFC-2119]で記述されるように解釈されます。
2. Applicability
2. 適用性
The allocation technique in this document is designed to be used in
any environment in which link-local scope IPv6 multicast addresses
are assigned or selected. This method goes especially well with
nodes supplying multicast services in a zeroconf/serverless
environment. For example, multicast addresses less than or equal to
link-local scope are themselves generated by nodes supplying
multicast services without conflicts. Also, hosts that are supplied
multicast services from multicast servers then make multicast
addresses of multicast servers using ND (address resolution) and
well-known group IDs [RFC2461].
この文書中の割当技術はリンクローカル範囲ＩＰｖ６マルチキャストアドレ
スが割り当てられるか、あるいは選択される全ての環境で使えるよう意図さ
れます。この方法は特に、設定なし／サーバなし環境で、ノードがマルチキャ
ストサービスを供給する状態でうまくいきます。例えば、リンクローカル範
囲かそれ以下のマルチキャストアドレスが競合なしでマルチキャストサービ
スを供給しているノード自身で生成できます。同じく、マルチキャストサー
バからマルチキャストサービスを与えられるホストがＮＤ（アドレス解決）
と既知グループ識別子[RFC2461]を使ってマルチキャストサーバのマルチキャ
ストアドレスを作ります。
Consequently, this technique MUST only be used for link scoped
multicast addresses. If you want to use multicast addresses greater
than link-local scope, you need to use other methods as described in
[RFC3306].
従って、この技術はリンク範囲マルチキャストアドレスのためだけに使われ
なくてはなりません(MUST)。もしリンクローカル範囲より大きいマルチキャ
ストアドレスを使うことを望むなら、[RFC3306]で記述されるように、他の方
法を使う必要があります。
3. Link-Scoped Multicast Address Format
3. リンク範囲マルチキャストアドレスフォーマット
This document specifies a new format that incorporates IID in the
link-local scope multicast addresses.
この文書はリンクローカル範囲マルチキャストアドレスでＩＩＤを取り入れ
る新しいフォーマットを指定します。
Figure 1 illustrates the new format for link-scoped multicast
addresses.
図１がリンク範囲マルチキャストアドレスのために新しいフォーマットを示
します。
| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+--------+----------------+----------+
|11111111|flgs|scop|reserved| plen | IID | group ID |
+--------+----+----+--------+--------+----------------+----------+
Figure 1. Link-Scoped Multicast IPv6 Address Format
図１．リンク範囲マルチキャストＩＰｖ６アドレスフォーマット
The flgs, scop, and plen fields are used to identify whether an
address is a multicast address, as follows:
flgsとscopとplenフィールドは、次のようにアドレスがマルチキャストアド
レスを明らかにするために使われます：
1. flgs MUST be "0011".
1. flgsは"0011"です（MUST)。
2. scop MUST be <= 2.
2. scopは≦２です(MUST)。
3. The reserved field MUST be zero.
3. 予約フィールドはゼロです(MUST)。
4. The "plen" field is a special value, "1111 1111" (decimal 255).
4. "plen"フィールドは特別な値"1111 1111"（１０進数の２５５）です。
The IID field (replacing the 64-bit prefix field from [RFC3306]) is
used to distinguish each node from others. Given the use of this
method for link-local scope, the IID embedded in the multicast
address MUST only come from the IID of the link-local unicast address
on the interface after DAD has completed. That is, the creation of
the multicast address MUST only occur after DAD has completed as part
of the auto-configuration process.
ＩＩＤフィールド（[RFC3306]から６４ビットのプレフィックス欄を除いた
もの）はそれぞれのノードを他から区別するために使われます。リンクロー
カル範囲でこの方法を使用うという条件で、マルチキャストアドレスに埋め
込まれたＩＩＤはインタフェースの、ＤＡＤが完了した、リンクローカルユ
ニキャストアドレスのＩＩＤでなくてはなりません。すなわち、ＤＡＤが自
動設定処理の一部として完了した後で、マルチキャストアドレスの生成が起
こるに違いありません。
Group ID is generated to indicate a multicast application and is used
to guarantee its uniqueness only in the host. It may also be set on
the basis of the guidelines outlined in [RFC3307].
グループ識別子がマルチキャストアプリケーションを示すために生成されて、
ホストでその一意さを保証するために使われます。これは同じく[RFC3307]で
概説されたガイドラインをベースにして設定されるかもしれません。
4. Example
4. 例
In an Ethernet environment, if the link-local unicast address is
FE80::A12:34FF:FE56:7890, the link-scoped multicast prefix of the
node is FF32:00FF:A12:34FF:FE56:7890::/96.
イーサネット環境で、もしリンクローカルユニキャストアドレスが
FE80::A12:34FF:FE56:7890であるなら、ノードのリンク範囲マルチキャス
トプレフィックスはFF32:00FF:A12:34FF:FE56:7890::/96です。
5. Consideration of Lifetime
5. 寿命の考慮
Generally, link-scoped multicast addresses have no lifetime, because
link-local unicast addresses also have no lifetime. However, this is
not true in the mobile environment. Even though multicast addresses
are created from the unique IIDs of unicast addresses, their useful
lifetime is linked to the period during which the IID is known to be
unique. Thus, conflict is possible between IIDs, due to a new node
in merged network that uses the same IID as a powered node.
一般に、リンクローカルユニキャストアドレスが同じく寿命を持たないから、
リンク範囲マルチキャストアドレスが寿命を持ちません。しかしながら、こ
れは移動環境で真実ではありません。マルチキャストアドレスがユニキャス
トアドレスの一意なＩＩＤから作られので、その有効寿命はＩＩＤが一意で
あると知られている期間に関連づけられます。それで、ネットワークの合併
により同じＩＩＤを持つノードによって、ＩＩＤの競合はありえます。
In this scenario, DAD also fails to guarantee uniqueness of the
unicast address, but this document does not try to address this
issue.
この場合で、ＤＡＤはユニキャストアドレスの一意さを保証し損ねますが、
この文書はこの問題を扱いません。
6. Security Considerations
6. セキュリティの考察
The uniqueness of multicast addresses using this method is guaranteed
by the DAD process. So, a secure DAD process is needed for stability
of this method. This document proposes the mechanism in [RFC3041]
for this purpose.
この方法で生成したマルチキャストアドレスの一意さはＤＡＤ手順によって
保証されます。それで、安全なＤＡＤ手順がこの方法の安定性のために必要
です。この文書はこの目的に対して[RFC3041]のメカニズムを提案します。
[RFC3041] describes the privacy extension to IPv6 stateless address
autoconfiguration to configure the IID of non-link-local scope
unicast addresses. [RFC3041] cannot be used for making a link-local
unicast address, and hence it cannot be used to create an IID for
link-scoped multicast address. However, as [RFC3041] does not
protect the privacy of link-local unicast addresses, it does not seem
to be required to protect the privacy of IID-based link-local
multicast addresses.
[RFC3041]が非リンクローカル範囲のユニキャストアドレスのＩＩＤの構成を
設定するためにＩＰｖ６ステートレスアドレス自動設定へのプライバシー拡
張を記述します。[RFC3041]はリンクローカルユニキャストアドレスを作るた
めに使うことができません、それ故にそれはリンク範囲マルチキャストアド
レスのためのＩＩＤを作るために使うことができません。しかしながら、
[RFC3041]がリンクローカルユニキャストアドレスのプライバシーを守らない
から、ＩＩＤベースのリンクローカルマルチキャストアドレスのプライバシー
を守ることが必要とされるように思われません。
7. Acknowledgements
7. 謝辞
We would like to thank Dave Thaler and Brian Haberman for their
comments related to the consistency between the unicast prefix-based
multicast document and this one. Special thanks are due to Erik
Nordmark and Pekka Savola for valuable comments.
我々はユニキャストプレフィックスベースのマルチキャスト文書とこの文書
の間の一貫性に関係するコメントに対してDave ThalerとBrian Habermanに感
謝します。貴重なコメントのためにErik NordmarkとPekka Savolaに特に感謝
します。
8. References
8. 参考文献
8.1. Normative References
8.1. 参照する参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998..ti 3
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Authors' Addresses
著者のアドレス
Jung-Soo Park
ETRI PEC
161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
Phone: +82 42 860 6514
EMail: pjs@etri.re.kr
Myung-Ki Shin
ETRI PEC
161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
Phone: +82 42 860 4847
EMail: myungki.shin@gmail.com
Hyoung-Jun Kim
ETRI PEC
161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
Phone: +82 42 860 6576
EMail: khj@etri.re.kr
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2006).
著作権（Ｃ）インターネット学会（２００６）。
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/iprにあるＩＥＴＦオンラインＩＰＲ
貯蔵庫で得られます。
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかietf-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。