この文書はRFC3306の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                        B. Haberman
Request for Comments: 3306                                    Consultant
Category: Standards Track                                      D. Thaler
                                                               Microsoft
                                                             August 2002


             Unicast-Prefix-based 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 (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.
   この仕様書はIPバージョン6プロトコルアーキテクチャのマルチキャスト
   アドレスの拡張を定義します。この文書で提出された拡張はマルチキャスト
   アドレスのユニキャストプレフィックスベースの割当を考慮します。ユニキャ
   ストプレフィックスと同時にマルチキャストアドレスを委任することによっ
   て、ネットワークオペレーターはドメイン間の割当プロトコルを駆動する必
   要なしでそれらのマルチキャストアドレスを識別可能でしょう。

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.
   この文書はIPv6アドレスアーキテクチャ[ADDRARCH]のマルチキャスト部
   への拡張を指定します。現在のアーキテクチャはダイナミックなアドレス割
   り当てに対する組み込みのサポートを含んでいません。この提案はIPv6
   マルチキャストアドレスとIPv6ソース特定のマルチキャストアドレスの
   ダイナミックな割り当てを考慮するためにマルチキャストアドレスのコード
   化情報を紹介します。

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.
   現在の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 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]の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|
   flgsは4つのフラグの集合です    +-+-+-+-+

         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に設定されます(MUST)、さもなければTビッ
            トの設定は[ADDRARCH]の2.7章で定義されます。

   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]の2.5.1章でインタフェース識別子条件が実質的にユニキャス
   トプレフィックスの長さを64ビットに制限してることが指摘されるべきで
   す、それ故マルチキャストアドレスのネットワークプレフィックス部はせい
   ぜい64ビットでしょう。

   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]の抽象APIをサポートするために必要です。

   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に割り当てられたユニキャストプレフィックスを基準に
   してマルチキャストプレフィックスを判断してポリシー検査を行うルータが
   パケットを捨ててもよいです。

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:
   ユニキャストプレフィックスに基づくIPv6マルチキャストアドレスフォー
   マットが、[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」は有効な範囲値) のSSM範囲を作ります。
   IPv6ヘッダーのソースアドレスフィールドはマルチキャストアドレスの
   所有者を識別します。

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.
         − SSM − すべてのIPv6SSMマルチキャストアドレスの
            フォーマットは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に対するセキュリティ
   の考察のいっそう深い論議が[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.
   著作権(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エディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So