この文書はRFC3306の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group B. Haberman
Request for Comments: 3306 Consultant
Category: Standards Track D. Thaler
Microsoft
August 2002
Unicast-Prefix-based 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 (2002). All Rights Reserved.
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.
この仕様書はＩＰバージョン６プロトコルアーキテクチャのマルチキャスト
アドレスの拡張を定義します。この文書で提出された拡張はマルチキャスト
アドレスのユニキャストプレフィックスベースの割当を考慮します。ユニキャ
ストプレフィックスと同時にマルチキャストアドレスを委任することによっ
て、ネットワークオペレーターはドメイン間の割当プロトコルを駆動する必
要なしでそれらのマルチキャストアドレスを識別可能でしょう。
Table of Contents
目次
1. Introduction
1. はじめに
2. Motivation
2. 動機
3. Terminology
3. 用語
4. Multicast Address Format
4. マルチキャストアドレスフォーマット
5. Address Lifetime
5. アドレス寿命
6. Source-Specific Multicast Addresses
6. ソース特定のマルチキャストアドレス
7. Examples
7. 例
8. Security Considerations
8. セキュリティの考察
9. References
9. 参考文献
Author's Address
著者のアドレス
Full Copyright Statement
著作権表示全文
1. Introduction
1. はじめに
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.
この文書はＩＰｖ６アドレスアーキテクチャ[ADDRARCH]のマルチキャスト部
への拡張を指定します。現在のアーキテクチャはダイナミックなアドレス割
り当てに対する組み込みのサポートを含んでいません。この提案はＩＰｖ６
マルチキャストアドレスとＩＰｖ６ソース特定のマルチキャストアドレスの
ダイナミックな割り当てを考慮するためにマルチキャストアドレスのコード
化情報を紹介します。
2. Motivation
2. 動機
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.
現在のＩＰｖ４マルチキャストアドレス割当アーキテクチャ[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 WORK]と
マルチキャストアドレス設定要求プロトコル[RFC 2909]の動作の必要を除き
ます。
3. Terminology
3. 用語
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"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
[RFC 2119]に記述されるように解釈されるはずです。
4. Multicast Address Format
4. マルチキャストアドレスフォーマット
Section 2.7 of [ADDRARCH] defines the following operational format of
IPv6 multicast addresses:
[ADDRARCH]の２.７章が次のＩＰｖ６マルチキャストアドレスの運用フォー
マットを定義します：
| 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|
flgsは４つのフラグの集合です +-+-+-+-+
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なら、Ｔが１に設定されます(MUST)、さもなければＴビッ
トの設定は[ADDRARCH]の２.７章で定義されます。
The reserved field MUST be zero.
予約フィールドはゼロに違いありません(MUST)。
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.
network prefixがマルチキャストアドレスを所有しているユニキャストサブ
ネットのネットワークプレフィックスを識別します。もしP = 1ならこのフィー
ルドはマルチキャストアドレスを所有するか割り当てられたドメインが割り
当てたユニキャストネットワークプレフィックスを含んでいます。すべての
ネットワークプレフィックスフィールドの意味のないビットはゼロであるべ
きです(SHOULD)。
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]の２.５.１章でインタフェース識別子条件が実質的にユニキャス
トプレフィックスの長さを６４ビットに制限してることが指摘されるべきで
す、それ故マルチキャストアドレスのネットワークプレフィックス部はせい
ぜい６４ビットでしょう。
Group ID is set based on the guidelines outlined in [IPV6 GID].
Group IDは[IPV6 GID]で解説されたガイドラインに基づいて設定されます。
The scope of the unicast-prefix based multicast address MUST NOT
exceed the scope of the unicast prefix embedded in the multicast
address.
ユニキャストプレフィックスに基づくマルチキャストアドレスの範囲はマル
チキャストアドレスに埋めこまれたユニキャストプレフィックスの範囲を超
えてはなりません(MUST NOT)。
5. Address Lifetime
5. アドレス寿命
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].
プレフィックスに基づくマルチキャストアドレスの寿命は、対応するユニキャ
ストプレフィックスを使う際の近隣探索ルータ広告メッセージ[RFC 2461]の
プレフィックス情報オプションの正当な寿命フィールドを越えるべきであり
ません(SHOULD NOT)。マルチキャストアドレスの寿命はマルチキャストアド
レス割当［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.
ユニキャストプレフィックスが無効になった後のユニキャストプレフィック
スに基づくマルチキャストアドレスの使用は運用上の問題を導くかもしれま
せん。例えば、ＡＳに割り当てられたユニキャストプレフィックスを基準に
してマルチキャストプレフィックスを判断してポリシー検査を行うルータが
パケットを捨ててもよいです。
6. Source-Specific Multicast Addresses
6. ソース特定のマルチキャストアドレス
The unicast prefix-based IPv6 multicast address format supports
Source-specific multicast addresses, as defined by [SSM ARCH]. To
accomplish this, a node MUST:
ユニキャストプレフィックスに基づくＩＰｖ６マルチキャストアドレスフォー
マットが、[SSM ARCH]によって定義されるように、ソース特定のマルチキャス
トアドレスをサポートします。これを達成するために、ノードが以下の通りに
しなければなりません(MUST)：
o Set P = 1.
o Set plen = 0.
o Set network prefix = 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（「x」は有効な範囲値） のＳＳＭ範囲を作ります。
ＩＰｖ６ヘッダーのソースアドレスフィールドはマルチキャストアドレスの
所有者を識別します。
7. Examples
7. 例
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.
− ＳＳＭ − すべてのＩＰｖ６ＳＳＭマルチキャストアドレスの
フォーマットはFF3x::/96でしょう。
8. Security Considerations
8. セキュリティの考察
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 ARCH]にあります。
9. References
9. 参考文献
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC 2908] Thaler, D., Handley, M. and D. Estrin, "The Internet
Multicast Address Allocation Architecture", RFC 2908,
September 2000.
[AAP WORK] Handley, M. and S. Hanna, "Multicast Address Allocation
Protocol (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 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1999.
[IPV6 GID] Haberman, B., "Dynamic Allocation Guidelines for IPv6
Multicast Addresses", RFC 3307, June 2002.
[RFC 2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC 2771] Finlayson, R., "An Abstract API for Multicast Address
Allocation", RFC 2771, February 2000.
[SSM ARCH] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", Work In Progress.
Author's Address
著者のアドレス
Brian Haberman
Consultant
Phone: 1-919-949-4828
EMail: bkhabs@nc.rr.com
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 48105-6399
Phone: 1-425-703-8835
EMail: dthaler@microsoft.com
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2002). 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 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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。