[要約] RFC 4489は、リンクスコープIPv6マルチキャストアドレスを生成するための方法を提案している。このRFCの目的は、IPv6ネットワークでのマルチキャスト通信の効率とセキュリティを向上させることである。
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
リンクスコープのIPv6マルチキャストアドレスを生成する方法
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
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.
このドキュメントでは、IPv6プロトコルのマルチキャストアドレッシングアーキテクチャの拡張について説明します。拡張により、インターフェイス識別子（IID）を使用してマルチキャストアドレスを割り当てることができます。リンクローカルユニキャストアドレスがノードの各インターフェイスで構成されている場合、IIDは一意に決定されます。その後、各ノードは競合することなく、独自のマルチキャストアドレスを自動的に生成できます。このドキュメントで提案されているリンクローカルマルチキャストアドレスを作成する代替方法は、ユニキャストプレフィックスベースのIPv6マルチキャストアドレスなどの既知の方法よりも優れています。このメモはRFC 3306を更新します。
Table of Contents:
目次：
1. Introduction ....................................................2
2. Applicability ...................................................2
3. Link-Scoped Multicast Address Format ............................3
4. Example .........................................................3
5. Consideration of Lifetime .......................................4
6. Security Considerations .........................................4
7. Acknowledgements ................................................4
8. References ......................................................5
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.
このドキュメントは、IPv6アドレス指定アーキテクチャ[RFC4291]のマルチキャスト部分への拡張を定義します。現在のアーキテクチャには、動的アドレス割り当ての組み込みサポートは含まれていません。この拡張により、IIDを使用してマルチキャストアドレスを割り当てることができます。リンクローカルユニキャストアドレスがノードの各インターフェイスで構成されている場合、IIDは一意に決定されます。その後、各ノードは競合することなく、独自のマルチキャストアドレスを自動的に生成できます。つまり、これらのアドレスは、重複アドレス検出（DAD）が完了した後であればいつでも安全に構成できます。
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.
リンクローカルスコープのこの方法は、ユニキャストプレフィックスベースのIPv6マルチキャストアドレス[RFC3306]よりも優先されます。これは、IIDを使用してマルチキャストアドレスを委任することにより、各ノードが割り当てサーバーなしで自動的にマルチキャストアドレスを生成できるためです。この方法は、アドホックやネットワークモビリティなどのサーバーレス環境のアプリケーションで、ユニキャストプレフィックスベースの方法よりも適切に機能します。このドキュメントは、[RFC3306]のscop、plen、ネットワークプレフィックスフィールドなどの定義済みフィールドの使用を制限します。したがって、このドキュメントでは、リンクローカルスコープのエンコードされた情報をマルチキャストアドレスで指定します。
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」は、 [RFC2119]で説明されているように解釈されます。
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].
このドキュメントの割り当て手法は、リンクローカルスコープのIPv6マルチキャストアドレスが割り当てられるか選択されるすべての環境で使用できるように設計されています。この方法は、zeroconf / serverless環境でマルチキャストサービスを提供するノードに特に適しています。たとえば、リンクローカルスコープ以下のマルチキャストアドレス自体は、競合することなくマルチキャストサービスを提供するノードによって生成されます。また、マルチキャストサーバーからマルチキャストサービスを提供されるホストは、ND（アドレス解決）と既知のグループID [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].
したがって、この手法は、リンクスコープのマルチキャストアドレスに対してのみ使用する必要があります。リンクローカルスコープより大きいマルチキャストアドレスを使用する場合は、[RFC3306]で説明されている他の方法を使用する必要があります。
This document specifies a new format that incorporates IID in the link-local scope multicast addresses.
このドキュメントでは、リンクローカルスコープのマルチキャストアドレスにIIDを組み込む新しい形式を指定しています。
Figure 1 illustrates the new format for link-scoped multicast addresses.
図1は、リンクスコープのマルチキャストアドレスの新しい形式を示しています。
| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+--------+----------------+----------+
|11111111|flgs|scop|reserved| plen | IID | group ID |
+--------+----+----+--------+--------+----------------+----------+
Figure 1. Link-Scoped Multicast IPv6 Address Format
図1.リンクスコープのマルチキャストIPv6アドレス形式
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」でなければなりません。
2. scop MUST be <= 2.
2. スコープは2以下でなければなりません。
3. The reserved field MUST be zero.
3. 予約フィールドはゼロでなければなりません。
4. The "plen" field is a special value, "1111 1111" (decimal 255).
4. 「plen」フィールドは特別な値「1111 1111」（10進数の255）です。
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.
IIDフィールド（[RFC3306]の64ビットプレフィックスフィールドを置き換える）は、各ノードを他のノードと区別するために使用されます。リンクローカルスコープにこのメソッドを使用する場合、マルチキャストアドレスに埋め込まれたIIDは、DADが完了した後のインターフェイス上のリンクローカルユニキャストアドレスのIIDからのみ取得する必要があります。つまり、マルチキャストアドレスの作成は、自動構成プロセスの一部としてDADが完了した後にのみ発生する必要があります。
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].
グループIDは、マルチキャストアプリケーションを示すために生成され、ホスト内でのみその一意性を保証するために使用されます。また、[RFC3307]で概説されているガイドラインに基づいて設定することもできます。
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です。
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.
一般に、リンクローカルユニキャストアドレスにも有効期間がないため、リンクスコープのマルチキャストアドレスには有効期間がありません。ただし、これはモバイル環境では当てはまりません。マルチキャストアドレスはユニキャストアドレスの一意のIIDから作成されますが、それらの有効期間は、IIDが一意であることがわかっている期間にリンクされています。したがって、給電されたノードと同じIIDを使用するマージ済みネットワークの新しいノードが原因で、IID間で競合が発生する可能性があります。
In this scenario, DAD also fails to guarantee uniqueness of the unicast address, but this document does not try to address this issue.
このシナリオでは、DADはユニキャストアドレスの一意性も保証できませんが、このドキュメントではこの問題に対処することは試みていません。
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.
この方法を使用するマルチキャストアドレスの一意性は、DADプロセスによって保証されます。したがって、この方法を安定させるには、安全なDADプロセスが必要です。このドキュメントは、この目的のために[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]は、非リンクローカルスコープのユニキャストアドレスのIIDを構成するためのIPv6ステートレスアドレス自動構成へのプライバシー拡張について説明しています。 [RFC3041]はリンクローカルユニキャストアドレスの作成には使用できないため、リンクスコープのマルチキャストアドレスのIIDの作成には使用できません。ただし、[RFC3041]はリンクローカルユニキャストアドレスのプライバシーを保護しないため、IIDベースのリンクローカルマルチキャストアドレスのプライバシーを保護する必要はないようです。
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に特に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998..ti 3
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「Neighbor Discovery for IP Version 6（IPv6）」、RFC 2461、1998年12月..ti 3
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten、T。およびR. Draves、「IPv6におけるステートレスアドレス自動構成のプライバシー拡張」、RFC 3041、2001年1月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306] Haberman、B。およびD. Thaler、「Unicast-Prefix-based IPv6 Multicast Addresses」、RFC 3306、2002年8月。
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[RFC3307] Haberman、B。、「IPv6マルチキャストアドレスの割り当てガイドライン」、RFC 3307、2002年8月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
Authors' Addresses
著者のアドレス
Jung-Soo Park ETRI PEC 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
Jung-Soo Park ETRI PEC 161-305、Cajeong-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
Myung-Ki Shin ETRI PEC 161 Kajeong-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
キムヒョンジュンETRI PEC 305-350大田市ユソン区ガジョンドン161ガジョンドン
Phone: +82 42 860 6576
EMail: khj@etri.re.kr
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
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.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
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.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78および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.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンライン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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。