[要約] RFC 3306は、IPv6マルチキャストアドレスのユニキャストプレフィックスベースの使用方法を定義しています。このRFCの目的は、IPv6ネットワークでのマルチキャスト通信の効率と柔軟性を向上させることです。
Network Working Group B. Haberman
Request for Comments: 3306 Consultant
Category: Standards Track D. Thaler
Microsoft
August 2002
Unicast-Prefix-based IPv6 Multicast Addresses
Unicast-Prefixベースの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 (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol.
この仕様は、IPバージョン6プロトコルのマルチキャストアドレス指定アーキテクチャの拡張機能を定義します。このドキュメントに示されている拡張機能により、マルチキャストアドレスのユニキャスト対応ベースの割り当てが可能になります。ユニキャストプレフィックスと同時にマルチキャストアドレスを委任することにより、ネットワークオペレーターは、ドメイン間割り当てプロトコルを実行する必要なく、マルチキャストアドレスを識別できます。
Table of Contents
目次
1. Introduction....................................................2
2. Motivation......................................................2
3. Terminology.....................................................2
4. Multicast Address Format........................................2
5. Address Lifetime................................................4
6. Source-Specific Multicast Addresses.............................4
7. Examples........................................................4
8. Security Considerations.........................................5
9. References......................................................5
Author's Address...................................................6
Full Copyright Statement...........................................7
This document specifies an extension to the multicast portion of the IPv6 addressing architecture [ADDRARCH]. The current architecture does not contain any built-in support for dynamic address allocation. This proposal introduces encoded information in the multicast address to allow for dynamic allocation of IPv6 multicast addresses and IPv6 source-specific multicast addresses.
このドキュメントは、IPv6アドレス指定アーキテクチャ[Addrarch]のマルチキャスト部分への拡張機能を指定します。現在のアーキテクチャには、動的アドレス割り当てのための組み込みサポートは含まれていません。この提案では、IPv6マルチキャストアドレスとIPv6ソース固有のマルチキャストアドレスの動的割り当てを可能にするために、マルチキャストアドレスにエンコードされた情報を導入します。
The current IPv4 multicast address allocation architecture [RFC 2908] is based on a multi-layered, multi-protocol system. The goal of this proposal is to reduce the number of protocols that need to be deployed in order to get dynamic multicast address allocation.
現在のIPv4マルチキャストアドレスアロケーションアーキテクチャ[RFC 2908]は、マルチレイヤーのマルチプロトコルシステムに基づいています。この提案の目標は、動的なマルチキャストアドレスの割り当てを取得するために展開する必要があるプロトコルの数を減らすことです。
The use of unicast prefix-based multicast address allocation will, at a minimum, remove the need to run the Multicast Address Allocation Protocol (AAP) [AAP WORK] and the Multicast Address-Set Claim (MASC) Protocol [RFC 2909].
ユニキャストプレフィックスベースのマルチキャストアドレス割り当ての使用は、少なくとも、マルチキャストアドレス割り当てプロトコル（AAP）[AAPワーク]とマルチキャストアドレスセットクレーム（MASC）プロトコル[RFC 2909]を実行する必要性を削除します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC 2119]で説明されているように解釈される。
Section 2.7 of [ADDRARCH] defines the following operational format of IPv6 multicast addresses:
[Addrarch]のセクション2.7は、IPv6マルチキャストアドレスの次の運用形式を定義しています。
| 8 | 4 | 4 | 112 |
+--------+----+----+---------------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------------+
This document introduces a new format that incorporates unicast prefix information in the multicast address. The following illustrates the new format:
このドキュメントでは、マルチキャストアドレスにユニキャストプレフィックス情報を組み込んだ新しい形式を紹介します。以下は、新しい形式を示しています。
| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+--------+----------------+----------+
|11111111|flgs|scop|reserved| plen | network prefix | group ID |
+--------+----+----+--------+--------+----------------+----------+
+-+-+-+-+
flgs is a set of 4 flags: |0|0|P|T|
+-+-+-+-+
o P = 0 indicates a multicast address that is not assigned based on the network prefix. This indicates a multicast address as defined in [ADDRARCH].
o p = 0は、ネットワークプレフィックスに基づいて割り当てられないマルチキャストアドレスを示します。これは、[addrarch]で定義されているマルチキャストアドレスを示します。
o P = 1 indicates a multicast address that is assigned based on the network prefix.
o p = 1は、ネットワークのプレフィックスに基づいて割り当てられるマルチキャストアドレスを示します。
o If P = 1, T MUST be set to 1, otherwise the setting of the T bit is defined in Section 2.7 of [ADDRARCH].
o p = 1の場合、tを1に設定する必要があります。そうしないと、tビットの設定は[addrarch]のセクション2.7で定義されます。
The reserved field MUST be zero.
予約済みフィールドはゼロでなければなりません。
plen indicates the actual number of bits in the network prefix field that identify the subnet when P = 1.
PLENは、p = 1のときにサブネットを識別するネットワークプレフィックスフィールド内の実際のビット数を示します。
network prefix identifies the network prefix of the unicast subnet owning the multicast address. If P = 1, this field contains the unicast network prefix assigned to the domain owning, or allocating, the multicast address. All non-significant bits of the network prefix field SHOULD be zero.
ネットワークプレフィックスは、マルチキャストアドレスを所有するユニキャストサブネットのネットワークプレフィックスを識別します。p = 1の場合、このフィールドには、マルチキャストアドレスを所有または割り当てるドメインに割り当てられたユニキャストネットワークプレフィックスが含まれています。ネットワークプレフィックスフィールドの重要でないビットはすべてゼロにする必要があります。
It should be noted that the Interface Identifier requirements in Section 2.5.1 of [ADDRARCH] effectively restrict the length of the unicast prefix to 64 bits, hence the network prefix portion of the multicast address will be at most 64 bits.
[addrarch]のセクション2.5.1のインターフェイス識別子要件は、ユニキャストプレフィックスの長さを64ビットに効果的に制限するため、マルチキャストアドレスのネットワークプレフィックス部分は最大64ビットになることに注意してください。
Group ID is set based on the guidelines outlined in [IPV6 GID].
グループIDは、[IPv6GID]で概説されているガイドラインに基づいて設定されています。
The scope of the unicast-prefix based multicast address MUST NOT exceed the scope of the unicast prefix embedded in the multicast address.
Unicast-Prefixベースのマルチキャストアドレスの範囲は、マルチキャストアドレスに埋め込まれたユニキャストプレフィックスの範囲を超えてはなりません。
The lifetime of a unicast prefix-based multicast address SHOULD NOT exceed the Valid Lifetime field in the Prefix Information option, corresponding to the unicast prefix being used, contained in the Neighbor Discovery Router Advertisement message [RFC 2461]. The lifetime of the multicast address is needed to support the Abstract API for Multicast Address Allocation [RFC 2771].
Unicastプレフィックスベースのマルチキャストアドレスの寿命は、近隣ディスカバリールーター広告メッセージ[RFC 2461]に含まれる、使用されているユニキャストプレフィックスに対応するプレフィックス情報オプションの有効な寿命フィールドを超えてはなりません。マルチキャストアドレスの抽象的なAPIをサポートするには、マルチキャストアドレスの寿命が必要です[RFC 2771]。
It should be noted that the unicast prefix's Valid Lifetime in the Router Advertisement message does not indicate that the prefix will become invalid at the end of the lifetime. Rather, that value is typically a constant until a renumbering event is scheduled after which, the prefix does become invalid.
ルーター広告メッセージのユニキャストプレフィックスの有効な寿命は、寿命の終わりに接頭辞が無効になることを示していないことに注意する必要があります。むしろ、その値は通常、変更イベントがスケジュールされるまで一定であり、その後、プレフィックスは無効になります。
The use of unicast prefix-based multicast addresses after the unicast prefix has become invalid may lead to operational problems. For example, routers that perform policy checks comparing the multicast prefix against the unicast prefix assigned to an AS may discard the packet.
ユニキャストプレフィックスが無効になった後のユニキャストプレフィックスベースのマルチキャストアドレスの使用は、運用上の問題につながる可能性があります。たとえば、ASに割り当てられたユニキャストプレフィックスとマルチキャストプレフィックスを比較するポリシーチェックを実行するルーターは、パケットを破棄する場合があります。
The unicast prefix-based IPv6 multicast address format supports Source-specific multicast addresses, as defined by [SSM ARCH]. To accomplish this, a node MUST:
ユニキャストプレフィックスベースのIPv6マルチキャストアドレス形式は、[SSM Arch]で定義されているように、ソース固有のマルチキャストアドレスをサポートしています。これを達成するには、ノードが次のことをしなければなりません。
o Set P = 1. o Set plen = 0. o Set network prefix = 0.
o p = 1を設定します。os set plen = 0を設定します。oネットワークプレフィックス= 0を設定します。
These settings create an SSM range of FF3x::/32 (where 'x' is any valid scope value). The source address field in the IPv6 header identifies the owner of the multicast address.
これらの設定は、FF3X ::/32のSSM範囲を作成します（ここで、「X」は有効なスコープ値です）。IPv6ヘッダーのソースアドレスフィールドは、マルチキャストアドレスの所有者を識別します。
The following are a few examples of the structure of unicast prefix-based multicast addresses.
以下は、ユニキャストプレフィックスベースのマルチキャストアドレスの構造のいくつかの例です。
- Global prefixes - A network with a unicast prefix of 3FFE:FFFF:1::/48 would also have a unicast prefix-based multicast prefix of FF3x:0030:3FFE:FFFF:0001::/96 (where 'x' is any valid scope).
- グローバルプレフィックス-3FFEのユニキャストプレフィックスを備えたネットワーク：FFFF：1 ::/48には、FF3X：0030：3FFE：FFFF：0001 ::/96のユニキャストプレフィックスベースのマルチキャストプレフィックスもあります（ 'x'は任意のものです有効な範囲）。
- SSM - All IPv6 SSM multicast addresses will have the format FF3x::/96.
- SSM -すべてのIPv6SSMマルチキャストアドレスには、FF3X ::/96の形式があります。
It is possible that the embedded unicast prefix can aid in identifying the allocation domain of a given multicast address, though an allocation domain choosing to avoid being traced has no obstacles currently to creating addresses using a prefix not assigned to it, or using a smaller scope embedded prefix.
埋め込まれたユニキャストプレフィックスは、特定のマルチキャストアドレスの割り当てドメインを識別するのに役立つ可能性がありますが、トレースされないように選択する割り当てドメインには現在、それに割り当てられていないプレフィックスを使用したり、より小さなスコープを使用したりするアドレスを作成するための障害はありません。埋め込まれたプレフィックス。
Using source-specific multicast addresses can sometimes aid in the prevention of denial-of-service attacks by arbitrary sources, although no guarantee is provided. A more in-depth discussion of the security considerations for SSM can be found in [SSM ARCH].
ソース固有のマルチキャストアドレスを使用すると、任意のソースによるサービス拒否攻撃の防止に役立つ場合がありますが、保証は提供されません。SSMのセキュリティ上の考慮事項についてのより詳細な議論は、[SSM Arch]に記載されています。
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC 2026] Bradner、S。、「インターネット標準プロセス - 改訂3」、BCP 9、RFC 2026、1996年10月。
[RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC 2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[Addrarch] Hinden、R。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。
[RFC 2908] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.
[RFC 2908] Thaler、D.、Handley、M。and D. Estrin、「The Internet Multicast Address Arlocation Architecture」、RFC 2908、2000年9月。
[AAP WORK] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol (AAP)", Work In Progress.
[AAPワーク] Handley、M。およびS. Hanna、「マルチキャストアドレス割り当てプロトコル（AAP）」、Work in Progress。
[RFC 2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., Kumar, S. and D. Thaler, "The Multicast Address-Set Claim (MASC) Protocol", RFC 2909, September 2000.
[RFC 2909] Radoslavov、P.、Estrin、D.、Govindan、R.、Handley、M.、Kumar、S.およびD. Thaler、「マルチキャストアドレスセットクレーム（MASC）プロトコル」、RFC 2909、9月2000。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1999.
[RFC 2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1999年3月。
[IPV6 GID] Haberman, B., "Dynamic Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, June 2002.
[IPv6 GID] Haberman、B。、「IPv6マルチキャストアドレスの動的割り当てガイドライン」、RFC 3307、2002年6月。
[RFC 2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC 2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC 2771] Finlayson, R., "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000.
[RFC 2771] Finlayson、R。、「マルチキャストアドレス割り当ての抽象API」、RFC 2771、2000年2月。
[SSM ARCH] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", Work In Progress.
[SSM Arch] Holbrook、H。およびB. Cain、「IPのソース固有のマルチキャスト」、作業中の作業。
Author's Address
著者の連絡先
Brian Haberman Consultant Phone: 1-919-949-4828 EMail: bkhabs@nc.rr.com
ブライアンハーバーマンコンサルタント電話：1-919-949-4828メール：bkhabs@nc.rr.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 48105-6399 Phone: 1-425-703-8835 EMail: dthaler@microsoft.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond、WA 48105-6399電話：1-425-703-8835メール：dthaler@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。