Network Working Group B. Haberman
Request for Comments: 3307 Consultant
Category: Standards Track August 2002
Allocation Guidelines for 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document specifies guidelines that must be implemented by any entity responsible for allocating IPv6 multicast addresses. This includes, but is not limited to, any documents or entities wishing to assign permanent IPv6 multicast addresses, allocate dynamic IPv6 multicast addresses, and define permanent IPv6 multicast group identifiers. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the MAC layer address.
この文書は、IPv6マルチキャストアドレスを割り当てるための責任を負う任意のエンティティによって実装されなければならないガイドラインを指定します。これには、任意の文書や、永久IPv6マルチキャストアドレスを割り当てる動的IPv6マルチキャストアドレスを割り当て、永久IPv6マルチキャストグループ識別子を定義することを望むエンティティに限定されるものではありません。これらのガイドラインの目的は、IPv6のレイヤではなく、MAC層アドレスにIP層アドレスの部分をコードするメディアのリンク層ではないだけで、IPv6マルチキャストアドレスの衝突の確率を減らすことです。
Table of Contents
目次
1. Terminology.....................................................2
2. Introduction....................................................2
3. Applicability...................................................3
4. Group ID Selection Guidelines...................................3
4.1 Permanent IPv6 Multicast Addresses............................4
4.2 Permanent IPv6 Multicast Group Identifiers....................4
4.3 Dynamic IPv6 Multicast Addresses..............................4
4.3.1 Server Allocation............................................5
4.3.2 Host Allocation..............................................5
5. IANA Considerations.............................................5
6. Security Considerations.........................................6
7. Acknowledgements................................................6
8. References......................................................6
Author's Address...................................................7
Full Copyright Statement...........................................8
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 [RFC 2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC 2119]に記載されているように解釈されます。
The term "group ID", throughout this document, conforms to the definition contained in [UNIMCAST], that is, the low-order 32 bits of the IPv6 multicast address.
本明細書を通して、用語「グループID」は、[UNIMCAST]に含まれる定義に準拠し、それは、IPv6マルチキャストアドレスの下位32ビットです。
This document specifies guidelines that MUST be implemented by any entity responsible for allocating IPv6 multicast addresses. This includes, but is not limited to, any documents or entities wishing to assign permanent IPv6 multicast addresses, allocate dynamic IPv6 multicast addresses, and define permanent IPv6 multicast group identifiers. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the link-layer address.
この文書は、IPv6マルチキャストアドレスを割り当てるための責任を負う任意のエンティティによって実装されなければならないガイドラインを指定します。これには、任意の文書や、永久IPv6マルチキャストアドレスを割り当てる動的IPv6マルチキャストアドレスを割り当て、永久IPv6マルチキャストグループ識別子を定義することを望むエンティティに限定されるものではありません。これらのガイドラインの目的は、IPv6のレイヤではなく、リンク層アドレスにIP層アドレスの部分をコードするメディアのリンク層ではないだけでIPv6マルチキャストアドレスの衝突の確率を減らすことです。
With the current IPv6 address architecture [ADDRARCH] and the extension to the multicast address architecture specified in [UNIMCAST], a set of guidelines is needed for entities assigning any flavor of IPv6 multicast addresses.
現在のIPv6アドレスアーキテクチャ[ADDRARCH]と[UNIMCAST]で指定されたマルチキャストアドレスアーキテクチャに拡張して、ガイドラインのセットは、IPv6マルチキャストアドレスのいずれかの味を割り当てるエンティティのために必要とされます。
The current approach of several physical media [RFC 2464][RFC 2467] is to map a portion of the IPv6 multicast address into a link-layer destination address. This is accomplished by taking the low order 32 bits (henceforth called the group ID) of the IPv6 multicast address and including them in the link-layer destination address. Group IDs, less than or equal to, 32 bits long will generate unique link-layer addresses within a given multicast scope.
いくつかの物理的媒体[RFC 2464]、[RFC 2467]の現在のアプローチは、リンク層の宛先アドレスにIPv6マルチキャストアドレスの一部をマッピングすることです。これは、下位32ビットを取ることによって達成されるIPv6マルチキャストアドレス（以下、グループIDと呼ぶ）とリンク層の宛先アドレスに含めます。グループIDは、以下でに、32ビットが長い所与のマルチキャストスコープ内で一意のリンクレイヤアドレスを生成します。
These guidelines specify how the group ID of the IPv6 multicast address are chosen and assigned. The guidelines specify several mechanisms that can be used to determine the group ID of the multicast address, based on the type of allocation being done.
これらのガイドラインは、IPv6マルチキャストアドレスのグループIDを選択して割り当てられている方法を指定します。ガイドラインが行われる割り当てのタイプに基づいて、マルチキャストアドレスのグループIDを決定するために使用できるいくつかのメカニズムを指定します。
These guidelines are designed to be used in any environment in which IPv6 multicast addresses are delegated, assigned, or selected. These guidelines are not limited to use by MADCAP [RFC 2730] servers. The following is a non-exhaustive list of applications of these guidelines:
これらのガイドラインは、IPv6マルチキャストアドレスは、委任割り当てられた、または選択される任意の環境で使用されるように設計されています。これらのガイドラインはMADCAP [RFC 2730]のサーバでの使用に限定されません。以下では、これらのガイドラインのアプリケーションの非網羅的なリストであります：
- Source-specific multicast application servers can generate an SSM group address by generating a 96-bit multicast prefix, as defined in [UNIMCAST] (i.e. FF3x::/96) and concatenating that with a group ID, as defined in this document.
- ソース固有マルチキャストアプリケーションサーバは、（:: / 96すなわちFF3x）UNIMCAST]で定義されるように、96ビットのマルチキャストプレフィックスを生成し、この文書で定義されているグループIDとそれを連結することによって、SSMグループアドレスを生成することができます。
- A MADCAP server allocates IPv6 multicast addresses conforming to section 2.7 of [ADDRARCH], creating the group ID using the rules defined in this document.
- MADCAPサーバは、この文書で定義された規則を使用してグループIDを作成し、[ADDRARCH]のセクション2.7に準拠したIPv6マルチキャストアドレスを割り当てます。
- Nodes supplying multicast services in a zeroconf environment generate multicast addresses without the need of centralized control.
- ゼロ設定環境でのマルチキャストサービスを提供するノードは集中制御を必要とせずにマルチキャストアドレスを生成します。
- IANA can assign permanent multicast addresses to fulfill requests via the protocol standardization process.
- IANAは、プロトコル標準化プロセスを経由して要求を満たすために永久的なマルチキャストアドレスを割り当てることができます。
The Group ID selection process allows for three types of multicast address assignments. These are permanent IPv6 multicast addresses, dynamic IPv6 multicast addresses, and permanent IPv6 multicast group IDs. The following guidelines assume that the prefix of the multicast address has been initialized according to [ADDRARCH] or [UNIMCAST].
グループIDの選択プロセスは、マルチキャストアドレスの割り当ての3種類が可能になります。これらは、永久的なIPv6マルチキャストアドレス、動的IPv6マルチキャストアドレス、永久IPv6マルチキャストグループIDです。次のガイドラインは、マルチキャストアドレスのプレフィックスは[UNIMCAST] [ADDRARCH]にまたはに従って初期化されていることを前提としています。
Permanent multicast addresses, like those defined in [RFC 2375], are allocated by IANA. These addresses will be assigned with group ID's, in the range of 0x00000001 to 0x3FFFFFFF, on an Expert Review basis.
[RFC 2375]で定義されたもののような永久的なマルチキャストアドレスは、IANAによって割り当てられています。これらのアドレスは、専門家のレビューに基づき、0x3FFFFFFFへ0x00000001の範囲で、グループIDので割り当てられます。
Multicast addresses assigned by IANA MUST have the T bit set to 0 and the P bit set to 0.
IANAによって割り当てられたマルチキャストアドレスは、Tが0に設定ビットとPを0に設定ビットを持たなければなりません。
Permanent group IDs allow for a global identifier of a particular service (e.g. Network Time Protocol (NTP) being assigned the group ID 0x40404040). The use of permanent group IDs differs from permanent multicast addresses in that a permanent group ID offers a global identifier for a service being offered by numerous servers.
永久的なグループIDは、特定のサービス（グループID 0x40404040を割り当てられ、例えばネットワークタイムプロトコル（NTP））のグローバル識別子を可能にします。永久グループIDの使用は永久的なグループIDは、多数のサーバによって提供されるサービスのグローバル識別子を提供することで永久的なマルチキャストアドレスとは異なります。
As an example, consider the NTP example group ID of 0x40404040. An NTP client would be able to access multiple servers and multiple scopes. That is, the NTP client will know that the group ID 0x40404040 identifies an NTP multicast stream regardless of the upper 96 bits of the multicast address.
例として、0x40404040のNTP例グループIDを検討してください。 NTPクライアントは、複数のサーバと複数のスコープにアクセスすることができるだろう。すなわち、NTPクライアントがグループID 0x40404040にかかわらず、マルチキャストアドレスの上位96ビットのNTPマルチキャストストリームを識別することを知っているだろう、です。
Permanent group IDs are allocated on an Expert Review basis, in the range 0x40000000 to 0x7FFFFFFF. These permanent group IDs are meant to be used in IPv6 multicast addresses, defined in [UNIMCAST].
常設グループIDは0x7FFFFFFFでの範囲0x40000000からで、専門家レビューごとに割り当てられています。これらの永久的なグループIDは[UNIMCAST]で定義されたIPv6マルチキャストアドレスに使用されることを意味します。
Dynamic IPv6 multicast addresses can be allocated by an allocation server or by an end-host. Regardless of the allocation mechanism, all dynamically allocated IPv6 multicast addresses MUST have the T bit set to 1. This will distinguish the dynamically allocated addresses from the permanently assigned multicast addresses, defined in [RFC 2375], at the link-layer on any media that maps the lower portion of the IPv6 multicast address into a link-layer address. It should be noted that the high-order bit of the Group ID will be the same value as the T flag.
動的IPv6マルチキャストアドレスが割り当てサーバによって、またはエンドホストによって割り当てられることができます。かかわらず、割り当て機構の、すべての動的に割り当てられたIPv6マルチキャストアドレスは、Tが、任意のメディア上のリンクレイヤで、これは[RFC 2375]で定義された永続的割り当てられたマルチキャストアドレスから動的に割り当てられたアドレスを区別します1に設定ビットを持たなければなりませんつまり、リンク層アドレスにIPv6マルチキャストアドレスの下位部分をマッピングします。グループIDの上位ビットは、Tフラグと同じ値になることに留意すべきです。
As an example, the permanent IPv6 multicast address FF02::9 maps to an Ethernet group address of 33-33-00-00-00-09. A dynamically allocated IPv6 multicast address of FF32::8000:9 would map to the Ethernet group address 33-33-80-00-00-09.
一例として、永久的なIPv6マルチキャストアドレスFF02 :: 33-33-00-00-00-09のイーサネットグループアドレスへ9つのマップ。 FF32 :: 8000の動的に割り当てられたIPv6マルチキャストアドレス：9は、イーサネットグループアドレス33-33-80-00-00-09にマップします。
The allocation of IPv6 multicast addresses, by a server, is defined in [RFC 2730]. Address management is the responsibility of the allocation protocol and outside the scope of this document. Allocation servers MUST use the group ID range 0x80000000 to 0xFFFFFFFF.
IPv6マルチキャストアドレスの割り当ては、サーバによって、[RFC 2730]で定義されています。アドレス管理は、割り当てプロトコルのと、この文書の範囲外の責任です。割り当てサーバは、0xFFFFFFFFのにグループIDの範囲は0x80000000を使用しなければなりません。
Host-based allocation allows hosts to self-select IPv6 multicast addresses. One example of host-based allocation is the Zeroconf Multicast Address Allocation Protocol [ZMAAPDOC]. Issues with collision detection, claim notification, etc. are outside the scope of this document and the responsibility of the protocol being used, such as [ZMAAPDOC].
ホストベースの割り当ては、自己選択のIPv6マルチキャストアドレスにホストすることができます。ホストベースの割り当ての一例は、のZeroconfマルチキャストアドレス割り当てプロトコル[ZMAAPDOC]です。等衝突検出、請求通知、の問題は、[ZMAAPDOC]として、使用されている。この文書およびプロトコルの責任の範囲外です。
The group ID portion of the address is created using either a pseudo-random 32-bit number or a 32-bit number created using the guidelines in [RFC 1750]. The generated group ID MUST fall in the range 0x80000000 to 0xFFFFFFFF. This can be accomplished by setting the high-order bit of the generated number to 1.
アドレスのグループID部分は、擬似ランダム32ビット数、または[RFC 1750]のガイドラインを使用して作成した32ビットの数値のいずれかを使用して作成されます。生成されたグループIDは0xFFFFFFFFの範囲のは0x80000000に入らなければなりません。これは、1に生成された数の上位ビットを設定することによって達成することができます。
This document requests the creation of a new registry maintained by IANA. This new registry will maintain permanent group ID values. The premise of this new registry is to allow for permanent group IDs to be used across multiple domains utilizing the multicast address architecture defined in [UNIMCAST]. The permanent group IDs will fall in the range 0x40000000 to 0x7FFFFFFF.
この文書は、IANAによって維持新しいレジストリの作成を依頼します。この新しいレジストリは、永久的なグループID値を維持します。この新しいレジストリの前提は、永久的なグループIDに[UNIMCAST]で定義されたマルチキャストアドレスのアーキテクチャを利用し、複数のドメインにわたって使用されることを可能にすることです。永久的なグループIDは0x7FFFFFFFでの範囲0x40000000からに分類されます。
In addition, this document also defines rules for the allocation of permanent IPv6 multicast addresses by IANA. These rules specify different ranges for multicast addresses that are IPv6-only and for IPv6 multicast addresses that have corresponding IPv4 multicast addresses.
また、この文書はまた、IANAによって永久IPv6マルチキャストアドレスの割り当てのための規則を定義します。これらのルールは、IPv6のみと対応するIPv4マルチキャストアドレスを持つIPv6マルチキャストアドレスのためのものであるマルチキャストアドレスの異なる範囲を指定します。
Following the policies outlined in [RFC 2434]:
[RFC 2434]で概説された方針を次のとおりです。
- Permanent IPv6 multicast addresses with corresponding IPv4 multicast addresses, like those defined in [RFC 2375], are allocated with group ID's in the range of 1 to 0x3FFFFFFF on an Expert Review basis, see Section 4.1.
- 対応するIPv4マルチキャストアドレス永久IPv6マルチキャストアドレスは、[RFC 2375]で定義されたもののように、セクション4.1を参照して、専門家のレビューに基づいて、グループIDの0x3FFFFFFF 1の範囲内で割り当てられています。
- Permanent IPv6-only multicast addresses are allocated with group ID's in the range 0x100 to 0x3FFFFFFF on an Expert Review basis. - Permanent group ID's are allocated on an Expert Review basis in the range 0x40000000 to 0x7FFFFFFF, see Section 4.2. - The range 0x80000000 to 0xFFFFFFFF is reserved for use by dynamic multicast address allocation mechanisms, see Section 4.3.
- 恒久IPv6のみのマルチキャストアドレスは、専門家レビューごとに0x3FFFFFFFの範囲は0x100でグループIDので割り当てられています。 - 常設グループのは0x7FFFFFFFでの範囲0x40000000からで専門家レビューごとに割り当てられたIDは、4.2節を参照してください。 - 0xFFFFFFFFの範囲は0x80000000はセクション4.3を参照して、動的マルチキャストアドレス割り当てメカニズムによって使用するために予約されます。
All approved requests for a permanent IPv6 multicast address will result in the assignment of a unique group ID which shall be reserved in all valid IPv6 multicast scopes.
永久的なIPv6マルチキャストアドレスのすべて承認された要求は、すべての有効なIPv6マルチキャストスコープ内に確保されなければならない一意のグループIDの割り当てになります。
The allocation mechanisms described in this document do not alter the security properties of either the Any Source or Source Specific multicast service models of IPv4 and IPv6.
この文書で説明配分メカニズムは、IPv4とIPv6のいずれかの任意のソースまたは送信元固有マルチキャストサービスモデルのセキュリティプロパティを変更しません。
The potential to allocate large blocks of addresses can lead to Denial-of-Service attacks. A more in-depth discussion of the security issues surrounding dynamic allocation of multicast addresses can be found in [RFC 2908].
アドレスの大きなブロックを割り当てる可能性は、サービス拒否攻撃につながることができます。マルチキャストアドレスの動的割り当てを取り巻くセキュリティ問題のより詳細な議論は、[RFC 2908]に見出すことができます。
The author would like to thank Dave Thaler, Steve Deering, Allison Mankin, Thomas Narten, and Erik Nordmark for their thorough review of this document.
作者はこのドキュメントの彼らの徹底的な見直しのためにデーブターラー、スティーブデアリング、アリソンマンキン、トーマスNarten氏、およびエリックNordmarkとに感謝したいと思います。
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC 2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[UNIMCAST] Haberman, B. and D. Thaler, "Unicast Prefix-based IPv6 Multicast Addresses", RFC 3306, June 2002.
[UNIMCAST]ハーバーマン、B.とD.ターラー、 "ユニキャストプレフィックスベースのIPv6マルチキャストアドレス"、RFC 3306、2002年6月。
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[ADDRARCH] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1999.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1999年3月。
[RFC 2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[RFC 2730]ハンナ、S.、パテル、B.及びM.シャー、 "マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）"、RFC 2730、1999年12月。
[RFC 2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC 2464]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットのトランスミッション"、RFC 2464、1998年12月。
[RFC 2467] Crawford, M., "Transmission of IPv6 over FDDI Networks", RFC 2467, December 1998.
[RFC 2467]クロフォード、M.、 "FDDIネットワークの上のIPv6の送信"、RFC 2467、1998年12月。
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC 1750]イーストレイク、D.、クロッカー、S.とJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[RFC 2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[RFC 2375] HindenとR.とS.デアリング、 "IPv6のマルチキャストアドレスの割り当て"、RFC 2375、1998年7月。
[RFC 2908] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.
[RFC 2908]ターラー、D.、ハンドリー、M.とD. Estrin、 "インターネットマルチキャストアドレス配分アーキテクチャ"、RFC 2908、2000年9月。
[ZMAAPDOC] Catrina, et al, "Zeroconf Multicast Address Allocation Protocol (ZMAAP)", Work In Progress.
【ZMAAPDOC]カトリーナら、「のZeroconfマルチキャストアドレス割り当てプロトコル（ZMAAP）」、進行中の作業。
Author's Address
著者のアドレス
Brian Haberman Consultant Phone: 1-919-949-4828 EMail: bkhabs@nc.rr.com
ブライアンハーバーマンコンサルタント電話：1-919-949-4828 Eメール：bkhabs@nc.rr.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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 assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。