RFC3306 日本語訳
3306 Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, D.Thaler. August 2002. (Format: TXT=12713 bytes) (Updated by RFC3956, RFC4489) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Haberman
Request for Comments: 3306 Consultant
Category: Standards Track D. Thaler
Microsoft
August 2002
コメントを求めるワーキンググループB.ハーバーマンの要求をネットワークでつないでください: 3306年のコンサルタントカテゴリ: 標準化過程D.ターレルマイクロソフト2002年8月
Unicast-Prefix-based IPv6 Multicast Addresses
ユニキャスト接頭語ベースのIPv6マルチキャストアドレス
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(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....................................................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
1. 序論…2 2. 動機…2 3. 用語…2 4. マルチキャストアドレス形式…2 5. 生涯を扱ってください…4 6. ソース特有のマルチキャストアドレス…4 7. 例…4 8. セキュリティ問題…5 9. 参照…5作者のアドレス…6 完全な著作権宣言文…7
Haberman & Thaler Standards Track [Page 1] RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002
IPv6マルチキャスト2002年8月のユニキャスト接頭語ベースのハーバーマンとターレル標準化過程[1ページ]RFC3306
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]であると扱うIPv6のマルチキャスト一部まで指定します。 現在のアーキテクチャはダイナミックなアドレス配分のためのどんな標準装備も含んでいません。 この提案は、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マルチキャストアドレス配分アーキテクチャ[RFC2908]は多層性の、そして、マルチプロトコルのシステムに基づいています。 この提案の目標はダイナミックなマルチキャストアドレス配分を得るために配布される必要があるプロトコルの数を減少させることです。
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].
最小限で、ユニキャストの接頭語ベースのマルチキャストアドレス配分の使用はMulticast Address Allocationプロトコル(AAP)[AAP WORK]とMulticast Address-セットクレーム(MASC)プロトコル[RFC2909]を実行する必要性を取り除くでしょう。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
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 |
+--------+----+----+---------------------------------------------+
| 8 | 4 | 4 | 112 | +--------+----+----+---------------------------------------------+ |11111111|flgs|scop| グループID| +--------+----+----+---------------------------------------------+
Haberman & Thaler Standards Track [Page 2] RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002
IPv6マルチキャスト2002年8月のユニキャスト接頭語ベースのハーバーマンとターレル標準化過程[2ページ]RFC3306
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 |
+--------+----+----+--------+--------+----------------+----------+
| 8 | 4 | 4 | 8 | 8 | 64 | 32 | +--------+----+----+--------+--------+----------------+----------+ |11111111|flgs|scop|予約されます。| plen| ネットワーク接頭語| グループID| +--------+----+----+--------+--------+----------------+----------+
+-+-+-+-+
flgs is a set of 4 flags: |0|0|P|T|
+-+-+-+-+
+++++flgsは4個の旗のセットです: |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であるなら、この分野はマルチキャストアドレスを所有しているか、または割り当てるドメインに割り当てられたユニキャストネットワーク接頭語を含んでいます。 非重要なビットのすべてのネットワークが分野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.
事実上、.1セクション2.5[ADDRARCH]のInterface Identifier要件がユニキャスト接頭語の長さを64ビットに制限することに注意されるべきであり、したがって、マルチキャストアドレスのネットワーク接頭語部分は高々64ビットになるでしょう。
Group ID is set based on the guidelines outlined in [IPV6 GID].
グループ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.
ベースのユニキャスト接頭語マルチキャストアドレスの範囲はマルチキャストアドレスに埋め込まれたユニキャスト接頭語の範囲を超えてはいけません。
Haberman & Thaler Standards Track [Page 3] RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002
IPv6マルチキャスト2002年8月のユニキャスト接頭語ベースのハーバーマンとターレル標準化過程[3ページ]RFC3306
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].
SHOULD NOTがValid Lifetime分野を超えている使用されるユニキャスト接頭語に対応するPrefix情報オプションがNeighborディスカバリーRouter Advertisementメッセージ[RFC2461]に含んだユニキャストの接頭語ベースのマルチキャストアドレスの生涯。 マルチキャストアドレスの寿命が、Multicast Address Allocation[RFC2771]のために抽象的な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.
Router Advertisementメッセージのユニキャスト接頭語のValid Lifetimeが、接頭語が生涯の終わりに無効になるのを示さないことに注意されるべきです。 番号を付け替えるイベントが後に予定されるまでむしろ、通常、その値が定数である、どれ、接頭語は無効になるか。
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:
[SSM ARCH]によって定義されるようにユニキャストの接頭語ベースのIPv6マルチキャストアドレス形式はSource特有のマルチキャストアドレスをサポートします。 これを達成するために、ノードはそうしなければなりません:
o Set P = 1.
o Set plen = 0.
o Set network prefix = 0.
o 1つのo Set plen=0o Setネットワーク接頭語=P=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のSSM範囲を作成します:、:/32('x'があらゆる有効な範囲値であるところ)。 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).
- グローバルな接頭語--Aは3FFE:FFFF:1のユニキャスト接頭語で以下をネットワークでつなぎます:また、/48には、0001年のFF3x:0030:3FFE:FFFF:ユニキャストの接頭語ベースのマルチキャスト接頭語があるでしょう:、:/96('x'があらゆる有効な範囲であるところ)。
- SSM - All IPv6 SSM multicast addresses will have the format
FF3x::/96.
- SSM--すべてのIPv6 SSMマルチキャストアドレスには、形式FF3xがあるでしょう:、:/96.
Haberman & Thaler Standards Track [Page 4] RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002
IPv6マルチキャスト2002年8月のユニキャスト接頭語ベースのハーバーマンとターレル標準化過程[4ページ]RFC3306
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]でSSMのためのセキュリティ問題の、より徹底的な議論を見つけることができます。
9. References
9. 参照
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]のデアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[ADDRARCH] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[RFC 2908] Thaler, D., Handley, M. and D. Estrin, "The Internet
Multicast Address Allocation Architecture", RFC 2908,
September 2000.
[RFC2908] ターレルとD.とハンドレーとM.とD.Estrin、「インターネットマルチキャストアドレス配分アーキテクチャ」、RFC2908、2000年9月。
[AAP WORK] Handley, M. and S. Hanna, "Multicast Address Allocation
Protocol (AAP)", Work In Progress.
[AAP仕事] 「マルチキャストアドレス配分プロトコル(AAP)」というハンドレー、M.、およびS.ハンナは進行中で働いています。
[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.
[RFC2909] ラドスラーボフとP.とEstrinとD.とGovindanとR.とハンドレーとM.とクマーとS.とD.ターレル、「マルチキャストアドレスセットクレーム(MASC)プロトコル」、RFC2909、2000年9月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1999.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1999年3月。
[IPV6 GID] Haberman, B., "Dynamic Allocation Guidelines for IPv6
Multicast Addresses", RFC 3307, June 2002.
[IPV6ヒツジ暈倒病] ハーバーマン、B.、「IPv6マルチキャストアドレスのための動的割当てガイドライン」、RFC3307、2002年6月。
[RFC 2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2461] NartenとT.とNordmarkとE.とW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[RFC 2771] Finlayson, R., "An Abstract API for Multicast Address
Allocation", RFC 2771, February 2000.
[RFC2771] フィンリースン、R.、「マルチキャストアドレス配分のための抽象的なAPI」、RFC2771、2000年2月。
Haberman & Thaler Standards Track [Page 5] RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002
IPv6マルチキャスト2002年8月のユニキャスト接頭語ベースのハーバーマンとターレル標準化過程[5ページ]RFC3306
[SSM ARCH] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", Work In Progress.
[SSMはアーチ形に曲げます] 「IPのためのソース特有のマルチキャスト」というホルブルック、H.、およびB.カインは進行中で働いています。
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
レッドモンド、ワシントン48105-6399が以下に電話をするデーヴターレルマイクロソフト社1マイクロソフト方法 1-425-703-8835 メールしてください: dthaler@microsoft.com
Haberman & Thaler Standards Track [Page 6] RFC 3306 Unicast-Prefix-based IPv6 Multicast August 2002
IPv6マルチキャスト2002年8月のユニキャスト接頭語ベースのハーバーマンとターレル標準化過程[6ページ]RFC3306
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Haberman & Thaler Standards Track [Page 7]
ハーバーマンとターレル標準化過程[7ページ]
一覧
スポンサーリンク
