RFC3956 日本語訳
3956 Embedding the Rendezvous Point (RP) Address in an IPv6 MulticastAddress. P. Savola, B. Haberman. November 2004. (Format: TXT=40136 bytes) (Updates RFC3306) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Savola
Request for Comments: 3956 CSC/FUNET
Updates: 3306 B. Haberman
Category: Standards Track JHU APL
November 2004
Savolaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 3956のCSC/FUNETアップデート: 3306年のB.ハーバーマンカテゴリ: 標準化過程JHU APL2004年11月
Embedding the Rendezvous Point (RP) Address
in an IPv6 Multicast Address
ランデブーポイント(RP)アドレスを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 (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306.
このメモはRendezvous Point(RP)のアドレスがIPv6マルチキャストグループアドレスでコード化されるアドレス配分方針を定義します。 プロトコル無党派Multicast--まばらなMode(PIM-SM)、これをグループからRPへのマッピングメカニズムの仕様と考えることができます。 これは、スケーラブルな相互ドメインマルチキャストの簡単な展開を許して、また、イントラドメインマルチキャスト構成を簡素化します。 このメモはRFC3306に提示されたアドレス指定形式をアップデートします。
Table of Contents
目次
1. Introduction ............................................... 2
1.1. Background ............................................ 2
1.2. Solution ............................................. 2
1.3. Assumptions and Scope ................................. 3
1.4. Terminology .......................................... 4
1.5. Abbreviations ........................................ 4
2. Unicast-Prefix-based Address Format ........................ 4
3. Modified Unicast-Prefix-based Address Format ............... 5
4. Embedding the Address of the RP in the Multicast Address ... 5
5. Examples ................................................... 7
5.1. Example 1 ............................................ 7
5.2. Example 2 ............................................ 7
5.3. Example 3 ............................................ 8
5.4. Example 4 ............................................ 8
1. 序論… 2 1.1. バックグラウンド… 2 1.2. ソリューション… 2 1.3. 仮定と範囲… 3 1.4. 用語… 4 1.5. 略語… 4 2. ユニキャスト接頭語ベースのアドレス形式… 4 3. ユニキャスト接頭語ベースのアドレス形式を変更します… 5 4. RPのアドレスをマルチキャストアドレスに埋め込みます… 5 5. 例… 7 5.1. 例1… 7 5.2. 例2… 7 5.3. 例3… 8 5.4. 例4… 8
Savola & Haberman Standards Track [Page 1] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[1ページ]RFC3956
6. Operational Considerations ................................. 8
6.1. RP Redundancy ......................................... 8
6.2. RP Deployment ........................................ 9
6.3. Guidelines for Assigning IPv6 Addresses to RPs ........ 9
6.4. Use as a Substitute for BSR ........................... 9
6.5. Controlling the Use of RPs ............................ 9
7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 10
7.1. PIM-SM Group-to-RP Mapping ............................ 10
7.2. Overview of the Model ................................. 11
8. Scalability Analysis ....................................... 12
9. Acknowledgements ........................................... 13
10. Security Considerations ..................................... 13
11. References .................................................. 15
11.1. Normative References .................................. 15
11.2. Informative References ................................ 15
A. Discussion about Design Tradeoffs ........................... 16
Authors' Addresses .............................................. 17
Full Copyright Statement ......................................... 18
6. 操作上の問題… 8 6.1. RP冗長… 8 6.2. RP展開… 9 6.3. RPsへのアドレスをIPv6に割り当てるためのガイドライン… 9 6.4. BSRの代用品として、使用します。 9 6.5. RPsの使用を制御します… 9 7. 埋め込まれたRPグループからRPへのマッピングメカニズム… 10 7.1. PIM-SmグループからRPへのマッピング… 10 7.2. モデルの概観… 11 8. スケーラビリティ分析… 12 9. 承認… 13 10. セキュリティ問題… 13 11. 参照… 15 11.1. 標準の参照… 15 11.2. 有益な参照… 15 デザイン見返りについてのA.議論… 16人の作者のアドレス… 17 完全な著作権宣言文… 18
1. Introduction
1. 序論
1.1. Background
1.1. バックグラウンド
As has been noticed [V6MISSUES], there exists a deployment problem with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no way of communicating the information about (active) multicast sources to other multicast domains, as Multicast Source Discovery Protocol (MSDP) [MSDP] has deliberately not been specified for IPv6. Therefore the whole interdomain Any Source Multicast (ASM) model is rendered unusable; Source-Specific Multicast (SSM) [SSM] avoids these problems but is not a complete solution for several reasons, as noted below.
気付かれたように[V6MISSUES]、グローバルなinterdomain IPv6マルチキャストに関する展開問題は存在しています: PIM-SM[PIM-SM]RPsには、(アクティブ)のマルチキャストソースの情報を他のマルチキャストドメインに伝える方法が全くありません、Multicast Sourceディスカバリープロトコル(MSDP)[MSDP]が故意にIPv6に指定されていないとき。 したがって、全体のinterdomain Any Source Multicast(ASM)モデルは使用不可能に表されます。 ソース特有のMulticast(SSM)[SSM]は以下に述べられるようにこれらの問題を避けますが、いくつかの理由の完全解ではありません。
Further, it has been noted that there are some problems with the support and deployment of mechanisms SSM would require [V6MISSUES]: it seems unlikely that SSM could be usable as the only interdomain multicast routing mechanism in the short term.
さらに、SSMが必要とするメカニズム[V6MISSUES]のサポートと展開に関するいくつかの問題があることに注意されました: SSMが唯一のinterdomainマルチキャストルーティングメカニズムとして短期で使用可能であるかもしれないことはありそうもなく見えます。
1.2. Solution
1.2. ソリューション
This memo describes a multicast address allocation policy in which the address of the RP is encoded in the IPv6 multicast group address, and specifies a PIM-SM group-to-RP mapping to use the encoding, leveraging, and extending unicast-prefix-based addressing [RFC3306].
このメモは、RPのアドレスがIPv6マルチキャストグループアドレスでコード化されるマルチキャストアドレス配分方針を説明して、コード化を使用するためにPIM-SMグループからRPへのマッピングを指定します、ユニキャスト接頭語ベースのアドレシング[RFC3306]に投機して、広げていて。
This mechanism not only provides a simple solution for IPv6 interdomain Any Source Multicast but can be used as a simple solution for IPv6 intra-domain ASM with scoped multicast addresses as well.
このメカニズムをIPv6 interdomain Any Source Multicastの簡単な解決法を提供するだけではありませんが、IPv6イントラドメインASMの簡単な解決策としてまた、見られたマルチキャストアドレスで使用できます。
Savola & Haberman Standards Track [Page 2] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[2ページ]RFC3956
It can also be used as an automatic RP discovery mechanism in those deployment scenarios that would have previously used the Bootstrap Router protocol (BSR) [BSR].
また、自動RP発見メカニズムとして以前にBootstrap Routerプロトコル(BSR)[BSR]を使用したそれらの展開シナリオでそれを使用できます。
The solution consists of three elements:
解決策は3つの要素から成ります:
o A specification of a subrange of [RFC3306] IPv6 multicast group
addresses defined by setting one previously unused bit of the
Flags field to "1",
o Flags分野の以前に未使用の1ビットを「1インチ」に設定することによって定義された[RFC3306]IPv6マルチキャストグループアドレスのサブレンジの仕様
o a specification of the mapping by which such a group address
encodes the RP address that is to be used with this group, and
o そしてグループがどのそのようなものを記述するかによってマッピングの仕様がこのグループと共に使用されることになっているRPアドレスをコード化する。
o a description of operational procedures to operate ASM with PIM-SM
on these IPv6 multicast groups.
o これらのIPv6マルチキャストグループのPIM-SMと共にASMを操作する操作手順の記述。
Addresses in the subrange will be called embedded-RP addresses.
サブレンジのアドレスは埋め込まれたRPアドレスと呼ばれるでしょう。
This scheme obviates the need for MSDP, and the routers are not required to include any multicast configuration, except when they act as an RP.
この計画はMSDPの必要性を取り除きます、そして、ルータはどんなマルチキャスト構成も含むのに必要ではありません、それらがRPとして機能する時を除いて。
This memo updates the addressing format presented in RFC 3306.
このメモはRFC3306に提示されたアドレス指定形式をアップデートします。
Some design tradeoffs are discussed in Appendix A.
Appendix Aでいくつかのデザイン見返りについて議論します。
1.3. Assumptions and Scope
1.3. 仮定と範囲
A 128-bit RP address can't be embedded into a 128-bit group address with space left to carry the group identity itself. An appropriate form of encoding is thus defined by requiring that the Interface-IDs of RPs in the embedded-RP range can be assigned to be a specific value.
グループのアイデンティティ自体を運ぶのを残っているスペースで128ビットのRPアドレスを128ビットのグループアドレスに埋め込むことができません。 特定の値になるように埋め込まれたRP範囲のRPsのInterface-IDを割り当てることができるのを必要とすることによって、適切なフォームのコード化はこのようにして定義されます。
If these assumptions can't be followed, operational procedures and configuration must be slightly changed, or this mechanism can't be used.
これらの仮定に続くことができないなら、操作手順と構成をわずかに変えることができなくなければなりませんか、このメカニズムを使用できません。
The assignment of multicast addresses is outside the scope of this document; it is up to the RP and applications to ensure that group addresses are unique by using some unspecified method. However, the mechanisms are probably similar to those used with [RFC3306].
このドキュメントの範囲の外にマルチキャストアドレスの課題があります。 確実にするRPとアプリケーションまで、グループアドレスは、何らかの不特定の方法を使用することによって、ユニークです。 しかしながら、メカニズムはたぶん[RFC3306]と共に使用されるものと同様です。
Similarly, RP failure management methods, such as Anycast-RP, are out of scope for this document. These do not work without additional specification or deployment. This is covered briefly in Section 6.1.
同様に、このドキュメントのための範囲の外にAnycast-RPなどのRP失敗管理法があります。 これらは追加仕様も展開なしで働いていません。 これはセクション6.1で簡潔に覆われています。
Savola & Haberman Standards Track [Page 3] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[3ページ]RFC3956
1.4. Terminology
1.4. 用語
Embedded-RP behaves as if all the members of the group were intra- domain to the information distribution. However, as it gives a solution for the global IPv6 multicast Internet, spanning multiple administrative domains, we say it is a solution for inter-domain multicast.
埋め込まれたRPはまるでグループのすべてのメンバーが情報流通へのイントラドメインであるかのように振る舞います。 しかしながら、グローバルなIPv6マルチキャストインターネットの解決策を与えるので複数の管理ドメインにかかっていて、私たちは、それが相互ドメインマルチキャストの解決策であると言います。
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.5. Abbreviations
1.5. 略語
ASM Any Source Multicast
BSR Bootstrap Router
DR Designated Router
IGP Interior Gateway Protocol
MLD Multicast Listener Discovery
MSDP Multicast Source Discovery Protocol
PIM Protocol Independent Multicast
PIM-SM Protocol Independent Multicast - Sparse Mode
RIID RP Interface ID (as specified in this memo)
RP Rendezvous Point
RPF Reverse Path Forwarding
SPT Shortest Path Tree
SSM Source-Specific Multicast
ASM Any Source Multicast BSR Bootstrap Router DR Designated Router IGP InteriorゲートウェイプロトコルMLD Multicast ListenerディスカバリーMSDP Multicast SourceディスカバリープロトコルPIMプロトコル無党派Multicast PIM-SMプロトコル無党派Multicast--まばらなMode RIID RP Interface ID(このメモで指定されるように)のRP Rendezvous Point RPF Reverse PathのForwarding SPT Shortest Path Tree SSM Source特有のMulticast
2. Unicast-Prefix-based Address Format
2. ユニキャスト接頭語ベースのアドレス形式
As described in [RFC3306], the multicast address format is as follows:
[RFC3306]で説明されるように、マルチキャストアドレス形式は以下の通りです:
| 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| +--------+----+----+--------+----+----------------+----------+
Where flgs are "0011". (The first two bits are as yet undefined, sent as zero and ignored on receipt.)
flgsが「11インチ」であるところ。 (最初の2ビットは、まだ未定義であり、ゼロとして送られて、領収書の上で無視されます。)
Savola & Haberman Standards Track [Page 4] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[4ページ]RFC3956
3. Modified Unicast-Prefix-based Address Format
3. 変更されたユニキャスト接頭語ベースのアドレス形式
This memo specifies a modification to the unicast-prefix-based
address format by specifying the second high-order bit ("R-bit") as
follows:
このメモは以下の2番目の高位のビット(「Rで噛み付いている」)を指定することによって、ユニキャスト接頭語ベースのアドレス形式への変更を指定します:
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+----+----------------+----------+
|11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID |
+--------+----+----+----+----+----+----------------+----------+
+-+-+-+-+
flgs is a set of four flags: |0|R|P|T|
+-+-+-+-+
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | +--------+----+----+----+----+----+----------------+----------+ |11111111|flgs|scop|rsvd|RIID|plen| ネットワーク接頭語| グループID| +--------+----+----+----+----+----+----------------+----------+++++がflgsする+は4個の旗のセットです: |0|R|P|T| +-+-+-+-+
When the highest-order bit is 0, R = 1 indicates a multicast address that embeds the address on the RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as specified in [RFC3306]. In effect, this implies the prefix FF70::/12. In this case, the last 4 bits of the previously reserved field are interpreted as embedding the RP interface ID, as specified in this memo.
最上位ビットが0であるときに、R=1はアドレスをRPに埋め込むマルチキャストアドレスを示します。 次に、1にPを設定しなければなりません、そして、その結果、Tは[RFC3306]で指定されるように1へのセットであるに違いありません。 事実上、これは接頭語FF70を含意します:、:/12. この場合、以前に予約された分野のベスト4ビットはRPインタフェースIDを埋め込みながら、解釈されます、このメモで指定されるように。
The behavior is unspecified if P or T is not set to 1, as then the
prefix would not be FF70::/12. Likewise, the encoding and the
protocol mode used when the two high-order bits in "flgs" are set to
11 ("FFF0::/12") is intentionally unspecified until such time that
the highest-order bit is defined. Without further IETF
specification, implementations SHOULD NOT treat the FFF0::/12 range
as Embedded-RP.
PかTが1に設定されないなら、振舞いは不特定です、次に、接頭語がFF70でないでしょう、したがって:、:/12. "flgs"の2高位のビットが11に設定されるとき、同様に、コード化とプロトコルモードが使用した、(「FFF0: : /12インチ)、最も高いオーダーに噛み付いたくらいの時間が定義されるまで故意に不特定である、」 さらなるIETF仕様がなければ、実現SHOULD NOTはFFF0を扱います:、:/12はEmbedded-RPとして及びます。
R = 0 indicates a multicast address that does not embed the address of the RP and follows the semantics defined in [ADDRARCH] and [RFC3306]. In this context, the value of "RIID" MUST be sent as zero and MUST be ignored on receipt.
R=0は、RPのアドレスを埋め込まないマルチキャストアドレスを示して、[ADDRARCH]と[RFC3306]で定義された意味論に従います。 このような関係においては、"RIID"の値をゼロとして送らなければならなくて、領収書の上で無視しなければなりません。
4. Embedding the Address of the RP in the Multicast Address
4. RPのアドレスをマルチキャストアドレスに埋め込みます。
The address of the RP can only be embedded in unicast-prefix-based ASM addresses.
ユニキャスト接頭語ベースのASMアドレスにRPのアドレスを埋め込むことができるだけです。
That is, to identify whether it is a multicast address as specified in this memo and to be processed any further, an address must satisfy all of the following:
すなわち、このメモでそれが指定されるとしてマルチキャストアドレスであるかどうか特定して、これ以上処理されるために、アドレスは以下のすべてを満たさなければなりません:
o It MUST be a multicast address with "flgs" set to 0111, that is, to
be of the prefix FF70::/12,
o それが0111に設定された"flgs"があるマルチキャストアドレスであるに違いない、接頭語FF70があるように、それはいます:、:/12,
o "plen" MUST NOT be 0 (i.e., not SSM), and
o そして"plen"が0であるはずがない(すなわち、SSMでない)。
Savola & Haberman Standards Track [Page 5] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[5ページ]RFC3956
o "plen" MUST NOT be greater than 64.
o "plen"は64以上であるはずがありません。
The address of the RP can be obtained from a multicast address satisfying the above criteria by taking the following two steps:
2つの方法を以下に取ることによって上の評価基準を満たすマルチキャストアドレスからRPのアドレスを得ることができます:
1. Copy the first "plen" bits of the "network prefix" to a zeroed
128-bit address structure, and
1. そして「ネットワーク接頭語」の最初の"plen"ビットをゼロに合わせられた128ビットのアドレス構造にコピーしてください。
2. replace the last 4 bits with the contents of "RIID".
2. ベスト4ビットを"RIID"のコンテンツに取り替えてください。
These two steps could be illustrated as follows:
以下の通りこれらの2ステップを例証できました:
| 20 bits | 4 | 8 | 64 | 32 |
+---------+----+----+----------------+----------+
|xtra bits|RIID|plen| network prefix | group ID |
+---------+----+----+----------------+----------+
|| \\ vvvvvvvvvvv
|| ``====> copy plen bits of "network prefix"
|| +------------+--------------------------+
|| | network pre| 0000000000000000000000 |
|| +------------+--------------------------+
\\
``=================> copy RIID to the last 4 bits
+------------+---------------------+----+
| network pre| 0000000000000000000 |RIID|
+------------+---------------------+----+
| 20ビット| 4 | 8 | 64 | 32 | +---------+----+----+----------------+----------+ |xtraビット|RIID|plen| ネットワーク接頭語| グループID| +---------+----+----+----------------+----------+ || \\vvvvvvvvvvv|| ``====「ネットワーク接頭語」の>コピーplenビット|| +------------+--------------------------+ || | ネットワーク、前| 0000000000000000000000 | || +------------+--------------------------+ \\ ``=================ベスト4ビット+への>コピーRIID------------+---------------------+----+ | ネットワーク、前| 0000000000000000000 |RIID| +------------+---------------------+----+
One should note that there are several operational scenarios (see Example 3 below) when the [RFC3306] statement "all non-significant bits of the network prefix field SHOULD be zero" is ignored. This is to allow multicast group address allocations to be consistent with unicast prefixes; the multicast addresses would still use the RP associated with the network prefix.
[RFC3306]声明であるときに、いくつかの操作上のシナリオ(以下のExample3を見る)があることに注意するべきである、「ネットワーク接頭語分野SHOULDでは、すべての非重要なビット、ゼロになってください、」 無視されます。 これはマルチキャストグループアドレス配分がユニキャスト接頭語と一致しているのを許容するためのものです。 マルチキャストアドレスはまだネットワーク接頭語に関連しているRPを使用しているでしょう。
"plen" higher than 64 MUST NOT be used, as that would overlap with the high-order bits of multicast group-id.
それはマルチキャストグループイドの高位のビットに重なるでしょう、したがって、64より高い"plen"は使用されているはずがありません。
When processing an encoding to get the RP address, the multicast routers MUST perform at least the same address validity checks to the calculated RP address as to one received via other means (like BSR [BSR] or MSDP for IPv4). At least fe80::/10, ::/16, and ff00::/8 MUST be excluded. This is particularly important, as the information is obtained from an untrusted source, i.e., any Internet user's input.
RPアドレスを得るためにコード化を処理するとき、マルチキャストルータは他の手段(IPv4のためのBSR[BSR]やMSDPのような)で1に関するアドレスが受けた計算されたRPに少なくとも同じアドレスバリディティチェックを実行しなければなりません。 少なくともfe80:、:/10, ::/16、およびff00:、:/8を除かなければなりません。 すなわち、信頼できないソース、どんなインターネットユーザの入力からも情報を得るとき、これは特に重要です。
One should note that the 4 bits reserved for "RIID" set the upper bound for RPs for the combination of scope, network prefix, and group ID -- without varying any of these, one can have 2^4-1 = 15 different
"RIID"のために予約された4ビットが範囲の組み合わせ、ネットワーク接頭語、およびグループIDのためにRPsに上限を設定することに注意するべきです--これらのいずれも変えないで、1つで2^4-1 = 15は異なるようになる場合があります。
Savola & Haberman Standards Track [Page 6] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[6ページ]RFC3956
RPs (as RIID=0 is reserved, see section 6.3). However, each of these is an IPv6 group address of its own (i.e., there can be only one RP per multicast address).
RPs(RIID=0が予約されているので、セクション6.3を見てください)。 しかしながら、それぞれのこれらはそれ自身のIPv6グループアドレス(すなわち、マルチキャストアドレスあたり1RPしかあることができない)です。
5. Examples
5. 例
Four examples of multicast address allocation and resulting group- to-RP mappings are described here to better illustrate the possibilities provided by the encoding.
マルチキャストアドレス配分とRPへの結果として起こるグループマッピングに関する4つの例が、コード化で提供された可能性をよりよく例証するためにここで説明されます。
5.1. Example 1
5.1. 例1
The network administrator of 2001:DB8::/32 wants to set up an RP for the network and all the customers, by placing it on an existing subnet, e.g., 2001:DB8:BEEF:FEED::/64.
2001年のネットワーク管理者: DB8:、:ネットワークのためのRPと2001:DB8:BEEF: 既存のサブネット、例えば、FEEDにそれを置くのによるすべての顧客に以下を設定する/32必需品:/64.
In that case, the group addresses would be something like
"FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address would
be "2001:DB8:BEEF:FEED::y". There are still 32 bits of multicast
group-ids to assign to customers and self ("y" could be anything from
1 to F, as 0 must not be used).
その場合、グループが記述する、何かが同類であったなら「FF7x:y40:2001:DB8:牛肉: 以下を食べてください」/96インチ、そして、それらのRPアドレスは「2001:DB8:牛肉: 以下を食べてください」ということでしょう。「y。」 まだ、顧客と自己に割り当てるマルチキャストグループイドの32ビットがあります(1〜Fまで「y」は何かであるかもしれません、0を使用してはいけないとき)。
5.2. Example 2
5.2. 例2
As in Example 1, the network administrator of 2001:DB8::/32 wants to set up the RP but, to make it more flexible, wants to place it on a specifically routed subnet and wants to keep larger address space for group allocations. That is, the administrator selects the least specific part of the unicast prefix, with plen=32, and the group addresses will be from the multicast prefix:
2001年のネットワーク管理者: Example1、DB8のような以下のこと、:しかし、それをよりフレキシブルにするようにRPをセットアップする/32必需品、明確に発送されたサブネットにそれを置く必需品、および、より大きいアドレス空間を保つ必需品は配分を分類します。 すなわち、管理者はplen=32でユニキャスト接頭語の最も特定でない部分を選択します、そして、グループアドレスはマルチキャスト接頭語から来ているでしょう:
FF7x:y20:2001:DB8::/64
FF7x: y20:2001:DB8:、:/64
where "x" is the multicast scope, "y" is the interface ID of the RP address, and there are 64 bits for group-ids or assignments. In this case, the address of the RP would be:
「x」がマルチキャスト範囲であるところでは、「y」がRPアドレスのインタフェースIDです、そして、グループイドか課題のための64ビットがあります。 この場合、RPのアドレスは以下の通りでしょう。
2001:DB8::y
2001 : DB8:、:y
The address 2001:DB8::y/128 is assigned to a router as a loopback address and is injected into the routing system; if the network administrator sets up only one or two RPs (and, e.g., not one RP per subnet), this approach may be preferable to the one described in Example 1.
アドレス2001: DB8:、:y/128は、ループバックアドレスとしてルータに割り当てられて、ルーティングシステムに注がれます。 そして、ネットワーク管理者が1か2RPsだけをセットアップする、(例えば、1サブネットあたり1RPでない)、このアプローチはExample1で説明されたものより望ましいかもしれません。
Savola & Haberman Standards Track [Page 7] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[7ページ]RFC3956
5.3. Example 3
5.3. 例3
As in Example 2, the network administrator can also assign multicast prefixes such as "FF7x:y20:2001:DB8:DEAD::/80" to some of customers. In this case the RP address would still be "2001:DB8::y". (Note that this is just a more specific subcase of Example 2, where the administrator assigns a multicast prefix, not just individual group- ids.)
Example2、また管理者がマルチキャスト接頭語を割り当てることができるネットワーク、「FF7x:y20:2001:DB8:死者:、:、」何人かの顧客への/80インチ。 この場合、RPアドレスがまだあるだろう、「2001 : DB8:、:、」「y。」 (これが個々のグループ免疫不全症候群だけではなく、ただ管理者がマルチキャスト接頭語を割り当てるExample2の、より特定の「副-ケース」であることに注意してください。)
Note the second rule of deriving the RP address: the "plen" field in the multicast address, 0x20 = 32, refers to the length of "network prefix" field considered when obtaining the RP address. In this case, only the first 32 bits of the network prefix field, "2001:DB8", are preserved: the value of "plen" takes no stance on actual unicast/multicast prefix lengths allocated or used in the networks, here from 2001:DB8:DEAD::/48.
RPアドレスを引き出す2番目の規則に注意してください: マルチキャスト住所の"plen"分野(0×20=32)はRPアドレスを得るとき考えられた「ネットワーク接頭語」分野の長さについて言及します。 この場合ネットワークの最初の32ビットだけが分野を前に置く、「2001: DB8"、保存されます:、」 "plen"の値はここで2001:DB8:DEADからネットワークに割り当てたか、または使用した実際のユニキャスト/マルチキャスト接頭語の長さの姿勢を全く取りません:、:/48.
In short, this distinction allows more flexible RP address configuration in the scenarios where it is desirable to have the group addresses be consistent with the unicast prefix allocations.
要するに、この区別はグループアドレスがユニキャスト接頭語配分と一致しているのを持っているのが望ましいシナリオでの、よりフレキシブルなRPアドレス構成を許します。
5.4. Example 4
5.4. 例4
In the network of Examples 1, 2, and 3, the network admin sets up addresses for use by customers, but an organization wants to have its own PIM-SM domain. The organization can pick multicast addresses such as "FF7x:y30:2001:DB8:BEEF::/80", and then the RP address would be "2001:DB8:BEEF::y".
Examples1、2、および3のネットワークでは、ネットワークアドミンは顧客による使用のためにアドレスをセットアップしますが、組織はそれ自身のPIM-SMドメインが欲しいです。 組織がマルチキャストアドレスを選ぶことができる、「FF7x:y30:2001:DB8:牛肉:、:、」/80インチ、および次に、RPアドレスがそうであるだろう、「2001:DB8:牛肉:、:、」「y。」
6. Operational Considerations
6. 操作上の問題
This section describes the major operational considerations for those deploying this mechanism.
このセクションはこのメカニズムを配備するもののために主要な操作上の問題について説明します。
6.1. RP Redundancy
6.1. RP冗長
A technique called "Anycast RP" is used within a PIM-SM domain to share an address and multicast state information between a set of RPs mainly for redundancy purposes. Typically, MSDP has been used for this as well [ANYCASTRP]. There are also other approaches, such as using PIM for sharing this information [ANYPIMRP].
"Anycast RP"と呼ばれるテクニックは、主に冗長目的のためにRPsの1セットの間のアドレスとマルチキャスト州の情報を共有するのにPIM-SMドメインの中で使用されます。 また[ANYCASTRP]、通常、MSDPはこれに使用されました。 また、この情報[ANYPIMRP]を共有するのにPIMを使用などなどの他のアプローチがあります。
The most feasible candidate for RP failover is using PIM for Anycast RP or "anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP address in the Interior Gateway Protocol (IGP) without state sharing (although depending on the redundancy requirements, this may or may not be enough). However, the redundancy mechanisms are outside of the scope of this memo.
RPフェイルオーバーの最も可能な候補は、Anycast RPにPIMを使用するか、またはInteriorゲートウェイプロトコル(IGP)の州の共有のないRPアドレスを"anycastingする"です(すなわち、共有されたユニキャストモデル[ANYCAST])(冗長要件によりますが、これは十分であるかもしれません)。 しかしながら、冗長メカニズムがこのメモの範囲の外にあります。
Savola & Haberman Standards Track [Page 8] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[8ページ]RFC3956
6.2. RP Deployment
6.2. RP展開
As there is no need to share inter-domain state with MSDP, each Designated Router connecting multicast sources could act as an RP without scalability concerns about setting up and maintaining MSDP sessions.
相互ドメイン州をMSDPと共有する必要は全くなくて、マルチキャストソースに接する各Designated RouterがRPとしてMSDPセッションをセットアップして、維持することに関するスケーラビリティ心配なしで機能できました。
This might be particularly attractive when one is concerned about RP redundancy. In the case where the DR close to a major source for a group acts as the RP, a certain amount of fate-sharing properties can be obtained without using any RP failover mechanisms: if the DR goes down, the multicast transmission may not work anymore in any case.
1つがRP冗長に関して心配しているとき、これは特に魅力的であるかもしれません。 グループのための主要なソースの近くのDRがRPとして機能する場合では、どんなRPフェイルオーバーメカニズムも使用しないで、ある量の運命を共有する資産は入手できます: DRが落ちるなら、どのような場合でも、マルチキャスト送信はそれ以上働かないかもしれません。
Along the same lines, its may also be desirable to distribute the RP responsibilities to multiple RPs. As long as different RPs serve different groups, this is trivial: each group could map to a different RP (or sufficiently many different RPs that the load on one RP is not a problem). However, load sharing challenges one group faces are similar to those of Anycast-RP.
ずっと、同じくらいが立ち並んでいる、それ、また、複数のRPsにRP責任を分配するのにおいて望ましいかもしれません。 異なったRPsが異なったグループに役立つ限り、これは些細です: 各グループは異なったRP(または、問題ではなく、1RPの上の負荷がそうである十分多くの異なったRPs)に写像されることができました。 しかしながら、1つのグループが直面している負荷分割法難局はAnycast-RPのものと同様です。
6.3. Guidelines for Assigning IPv6 Addresses to RPs
6.3. RPsへのアドレスをIPv6に割り当てるためのガイドライン
With this mechanism, the RP can be given basically any unicast network prefix up to /64. The interface identifier will have to be manually configured to match "RIID".
このメカニズムで、基本的にどんなユニキャストネットワーク接頭語もRPに/64に上がった状態で与えることができます。 インタフェース識別子は、"RIID"を合わせるために手動で構成されなければならないでしょう。
RIID = 0 must not be used, as using it would cause ambiguity with the Subnet-Router Anycast Address [ADDRARCH].
それを使用するとあいまいさがSubnet-ルータAnycast Address[ADDRARCH]と共に引き起こされるようにRIID=0を使用してはいけません。
If an administrator wishes to use an RP address that does not conform to the addressing topology but is still from the network provider's unicast prefix (e.g., an additional loopback address assigned on a router, as described in Example 2 in Section 5.1), that address can be injected into the routing system via a host route.
管理者がアドレシングトポロジーに従いませんが、まだネットワーク内の提供者のユニキャスト接頭語からあるRPアドレス(例えばセクション5.1でExample2で説明されるようにルータで割り当てられた追加ループバックアドレス)を使用したいと思うなら、ホストルートでルーティングシステムにそのアドレスを注ぐことができます。
6.4. Use as a Substitute for BSR
6.4. BSRの代用品としての使用
With embedded-RP, use of BSR or other RP configuration mechanisms throughout the PIM domain is not necessary, as each group address specifies the RP to be used.
埋め込まれたRPがあるので、PIMドメイン中のBSRか他のRP構成メカニズムの使用は必要ではありません、それぞれのグループアドレスが使用されるためにRPを指定するとき。
6.5. Controlling the Use of RPs
6.5. RPsの使用を制御します。
Compared to the MSDP inter-domain ASM model, the control and management of who can use an RP, and how, changes slightly and deserves explicit discussion.
MSDP相互ドメインASMモデルと比べて、コントロールと経営者側は、だれがRP、およびどのようにを使用できるかをわずかに変化して、明白な議論に値します。
Savola & Haberman Standards Track [Page 9] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[9ページ]RFC3956
MSDP advertisement filtering typically includes at least two
capabilities: filtering who is able to create a global session
("source filtering") and filtering which groups should be globally
accessible ("group filtering"). These are done to prevent local
groups from being advertised to the outside or unauthorized senders
from creating global groups.
MSDP広告フィルタリングは少なくとも2つの能力を通常含んでいます: だれが世界的規模のセッション(「ソースフィルタリング」)を作成できるか、そして、それのグループがグローバルに理解できるべきであるフィルタリング(「グループフィルタリング」)をフィルターにかけます。 地域団体がグローバルなグループを創設するので外の、または、権限のない送付者に広告を出すのを防ぐためにこれらをします。
However, such controls do not yet block the outsiders from using such groups, as they could join the groups even without Source Active advertisement with a (Source, Group) or (S,G) Join by guessing/learning the source and/or the group address. For proper protection, one should set up, for example, PIM multicast scoping borders at the border routers. Therefore, embedded-RP has by default a roughly equivalent level of "protection" as MSDP with SA filtering.
しかしながら、そのようなコントロールは、部外者がそのようなグループを使用するのをまだ妨げていません、Source Active広告がなくても(ソース、Group)でグループに加わるかもしれないか、または(S、G)が推測/学習でソース、そして/または、グループアドレスを接合するとき。 適切な保護のために、セットアップされるべきです、例えば、PIMマルチキャストの見ることに境界ルータで接しています。 したがって、埋め込まれたRPには、MSDPとしておよそ同等なレベルの「保護」がデフォルトでSAフィルタリングと共にあります。
A new issue with control is that nodes in a "foreign domain" may register to an RP, or send PIM Join to an RP. (These have been possible in the past as well, to a degree, but only through willful attempts or purposeful RP configuration at DRs.) The main threat in this case is that an outsider may illegitimately use the RP to host his/hers own group(s). This can be mitigated to an extent by filtering which groups or group ranges are allowed at the RP; more specific controls are beyond the scope of this memo. Note that this does not seem to be a serious threat in the first place, as anyone with a /64 unicast prefix can create their own RP without having to illegitimately get it from someone else.
コントロールの新規発行は「外国ドメイン」のノードがRPに登録するか、またはPIM JoinをRPに送るかもしれないということです。 (これらはまた、過去に可能です、DRsでの意図的な試みか故意のRP構成を通してだけ。) この場合主な脅威は部外者がその人を接待するのに不合理にRPを使用するかもしれないということです。自身のグループ。 どのグループをフィルターにかけるかによって、これを程度まで緩和できますか、またはグループ範囲はRPに許容されています。 より特定のコントロールはこのメモの範囲を超えています。 これが第一に重大な脅威であるように思えないことに注意してください、/64ユニキャスト接頭語をもっているだれでも他の誰かからそれを不合理に得る必要はなくてそれら自身のRPを作成できるとき。
7. The Embedded-RP Group-to-RP Mapping Mechanism
7. 埋め込まれたRPグループからRPへのマッピングメカニズム
This section specifies the group-to-RP mapping mechanism for Embedded RP.
このセクションはグループからRPへのマッピングメカニズムをEmbedded RPに指定します。
7.1. PIM-SM Group-to-RP Mapping
7.1. PIM-SmグループからRPへのマッピング
The only PIM-SM modification required is implementing this mechanism as one group-to-RP mapping method.
唯一のPIM-SMが1つのグループからRPへのマッピング法としてこのメカニズムを実行しています変更が、必要であった。
The implementation will have to recognize the address format and derive and use the RP address by using the rules in Section 4. This information is used at least when performing Reverse Path Forwarding (RPF) lookups, when processing Join/Prune messages, or performing Register-encapsulation.
実現は、セクション4の規則を使用することによって、RPアドレスをアドレス形式を認識して、引き出して、使用しなければならないでしょう。 Join/プルーンのメッセージを処理するとき、Reverse Path Forwarding(RPF)ルックアップを実行するか、またはRegister-カプセル化を実行するとき、この情報は少なくとも使用されています。
To avoid loops and inconsistencies, for addresses in the range FF70::/12, the Embedded-RP mapping MUST be considered the longest possible match and higher priority than any other mechanism.
範囲FF70のアドレスのための輪と矛盾を避けるためには以下のこと、:可能な限り長いマッチといかなる他のメカニズムよりも高い優先度であると/12、Embedded-RPマッピングを考えなければなりません。
Savola & Haberman Standards Track [Page 10] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[10ページ]RFC3956
It is worth noting that compared to the other group-to-RP mapping mechanisms, which can be precomputed, the embedded-RP mapping must be redone for every new IPv6 group address that would map to a different RP. For efficiency, the results may be cached in an implementation- specific manner, to avoid computation for every embedded-RP packet.
グループからRPへのマッピング他のメカニズムと比べて、それが異なったRPに写像するあらゆる新しいIPv6グループアドレスのために埋め込まれたRPマッピングを手直ししなければならないことに注意する価値があります。メカニズムを前計算できます。 効率において、結果は、あらゆる埋め込まれたRPパケットのための計算を避けるために実現の特定の方法でキャッシュされるかもしれません。
This group-to-RP mapping mechanism must be supported by the RP, the DR adjacent to the senders, and any router on the path from any receiver to the RP. Paths for Shortest Path Tree (SPT) formation and Register-Stop do not require the support, as those are accomplished with an (S,G) Join.
RP、送付者に隣接したDR、および経路のどんなルータでもどんな受信機からRPまでもグループからRPへのマッピングこのメカニズムをサポートしなければなりません。 Shortest Path Tree(SPT)構成のための経路とRegister-停止が達成されたものとしてのサポートを必要としない、(S、G)は接合します。
7.2. Overview of the Model
7.2. モデルの概観
This section gives a high-level, non-normative overview of how Embedded RP operates, as specified in the previous section.
このセクションはEmbedded RPが前項で指定されるようにどう作動するかに関するハイレベルの、そして、非標準の概観を与えます。
The steps when a receiver wishes to join a group are as follows:
仲間に入るという受信機願望は以下の通りのステップ:
1. A receiver finds out a group address by some means (e.g., SDR or a
web page).
1. 受信機はどうでも(例えば、SDRかウェブページ)グループアドレスを見つけます。
2. The receiver issues an Multicast Listener Discovery (MLD) Report,
joining the group.
2. グループに加わって、受信機はMulticast Listenerディスカバリー(MLD)レポートを発行します。
3. The receiver's DR will initiate the PIM-SM Join process towards
the RP encoded in the multicast address, irrespective of whether
it is in the "local" or "remote" PIM domain.
3. 受信機のDRはマルチキャストアドレスでコード化されたRPに向かってPIM-SM Joinの過程に着手するでしょう、それが「地方」の、または、「リモートな」PIMドメインにあることの如何にかかわらず。
The steps when a sender wishes to send to a group are as follows:
送付者がグループに発信したがっているとき、ステップは以下の通りです:
1. A sender finds out a group address by using an unspecified method
(e.g., by contacting the administrator for group assignment or
using a multicast address assignment protocol).
1. 送付者は、不特定の方法(例えば、グループ課題のために管理者に連絡するか、またはマルチキャストアドレス課題プロトコルを使用するのによる)を使用することによって、グループアドレスを見つけます。
2. The sender sends to the group.
2. 送付者はグループに発信します。
3. The sender's DR will send the packets unicast-encapsulated in
PIM-SM Register-messages to the RP address encoded in the
multicast address (in the special case that DR is the RP, such
sending is only conceptual).
3. 送付者のDRはマルチキャストアドレスでコード化されたRPにユニキャストでPIM-SM Register-メッセージで要約されたアドレスをパケットに送るでしょう(特別な場合では、そのDRがRPである、そのような発信は概念的であるだけです)。
In fact, all the messages go as specified in [PIM-SM]; embedded-RP just acts as a group-to-RP mapping mechanism. Instead of obtaining the address of the RP from local configuration or configuration protocols (e.g., BSR), the algorithm derives it transparently from the encoded multicast address.
事実上、すべてのメッセージが[PIM-SM]で指定されるように進んでいます。 埋め込まれたRPはグループからRPへのマッピングメカニズムとしてただ機能します。 地方の構成か構成プロトコル(例えば、BSR)からRPのアドレスを得ることの代わりに、アルゴリズムがそれにコード化されたマルチキャストアドレスに透明に由来しています。
Savola & Haberman Standards Track [Page 11] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[11ページ]RFC3956
8. Scalability Analysis
8. スケーラビリティ分析
Interdomain MSDP model for connecting PIM-SM domains is mostly hierarchical in configuration and deployment, but flat with regard to information distribution. The embedded-RP inter-domain model behaves as if every group formed its own Internet-wide PIM domain, with the group mapping to a single RP, wherever the receivers or senders are located. Hence, the inter-domain multicast becomes a flat, RP- centered topology. The scaling issues are described below.
接続PIM-SMドメインへのInterdomain MSDPモデルは、構成と展開でほとんど階層的ですが、情報流通に関して平坦です。 まるであらゆるグループがそれ自身のインターネット全体のPIMドメインを形成するかのように埋め込まれたRP相互ドメインモデルは振る舞います、独身のRPへのグループマッピングで、受信機か送付者がどこに位置していても。 したがって、相互ドメインマルチキャストはアパート、RPの中心に置かれたトポロジーになります。 スケーリング問題は以下で説明されます。
Previously, foreign sources sent the unicast-encapsulated data to their "local" RP; now they are sent to the "foreign" RP responsible for the specific group. This is especially important with large multicast groups where there are a lot of heavy senders -- particularly if implementations do not handle unicast-decapsulation well.
以前、外国人のソースはそれらの「地方」のRPにユニキャストで要約されたデータを送りました。 現在、特定のグループに責任がある「外国」のRPにそれらを送ります。 これは実現が特にユニキャスト被膜剥離術をよく扱わないなら多くの重い送付者がいる大きいマルチキャストグループで特に重要です。
With IPv4 ASM multicast, there are roughly two kinds of Internet-wide state: MSDP (propagated everywhere), and multicast routing state (on the receiver or sender branches). The former is eliminated, but the backbone routers might end up with (*, G) and (S, G, rpt) state between receivers (and past receivers, for PIM Prunes) and the RP, in addition to (S, G) states between the receivers and senders, if SPT is used. However, the total amount of state is smaller.
IPv4 ASMマルチキャストと共に、およそ2種類のインターネット全体の状態があります: MSDP(いたる所に伝播される)、およびマルチキャストルーティング状態(受信機か送付者支店の)。 前者は排除されますが、背骨ルータは(*、G)と(S、G、rpt)で受信機の間の状態(そして、PIM Prunesのための過去の受信機)とRPを終わらせるかもしれません、受信機の間の(S、G)州と送付者に加えて、SPTが使用されているなら。 しかしながら、状態の総量は、よりわずかです。
In both inter-domain and intra-domain cases, the embedded-RP model is practically identical to the traditional PIM-SM in intra-domain. On the other hand, PIM-SM has been deployed (in IPv4) in inter-domain using MSDP; compared to that inter-domain model, this specification simplifies the tree construction (i.e., multicast routing) by removing the RP for senders and receivers in foreign domains and eliminating the MSDP information distribution.
相互ドメインとイントラドメインケースの両方では、埋め込まれたRPモデルは実際にイントラドメインの伝統的なPIM-SMと同じです。 他方では、PIM-SMは相互ドメインでMSDPを使用することで配備されました(IPv4で)。 その相互ドメインモデルと比べて、この仕様は、送付者と受信機のために外国ドメインでRPを取り外して、MSDP情報流通を排除することによって、木の工事(すなわち、マルチキャストルーティング)を簡素化します。
As the address of the RP is tied to the multicast address, the RP failure management becomes more difficult, as the deployed failover or redundancy mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be used as-is. However, Anycast-RP using PIM provides equal redundancy; this described briefly in Section 6.1.
RPのアドレスがマルチキャストアドレスに結ばれるとき、RP失敗管理は、より難しくなります、そのままで、配備されたフェイルオーバーか冗長メカニズム(例えば、BSR、MSDPとAnycast-RP)を使用できないとき。 しかしながら、PIMを使用するAnycast-RPが等しい冗長を提供します。 セクション6.1で簡潔に説明されたこれ。
The PIM-SM specification states, "Any RP address configured or learned MUST be a domain-wide reachable address". What "reachable" precisely means is not clear, even without embedded-RP. This statement cannot be proven, especially with the foreign RPs, as one cannot even guarantee that the RP exists. Instead of manually configuring RPs and DRs (configuring a non-existent RP was possible, though rare), with this specification the hosts and users using multicast indirectly specify the RP themselves, lowering the expectancy of the RP reachability. This is a relatively significant
「アドレスが構成したか、または学んだどんなRPもドメイン全体の届いているアドレスであるに違いありません。」と、PIM-SM仕様は述べます。 「届くこと」が正確に意味することは埋め込まれたRPがなくても明確ではありません。 1つが、RPが存在するのを保証さえできないので、特に外国RPsと共にこの声明を立証できません。 手動で、RPsとDRs(実在しないRPが可能であって、もっとも、まれであったのを構成する)を構成することの代わりに、この仕様で、マルチキャストを使用しているホストとユーザは間接的に自分たちでRPを指定します、RPの可到達性の見込みを下ろして。 これ、aは比較的重要です。
Savola & Haberman Standards Track [Page 12] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[12ページ]RFC3956
problem but not much different from the current multicast deployment: e.g., MLDv2 (S,G) joins, whether ASM or SSM, yield the same result [PIMSEC].
多くではなく、現在のマルチキャスト展開と異なった問題: 例えば、MLDv2(S、G)はASMかSSM、同じ利回り結果[PIMSEC]であることにかかわらず接合します。
Being able to join/send to remote RPs raises security concerns that are considered separately, but it has an advantage too: every group has a "responsible RP" that is able to control (to some extent) who is able to send to the group.
リモートRPsに接合するか、または送るできるのは別々に考えられる安全上の配慮を上げますが、それには、利点もあります: あらゆるグループには、(ある程度)だれがグループに発信できるかを制御できる「責任があるRP」があります。
A more extensive description and comparison of the inter-domain multicast routing models (traditional ASM with MSDP, embedded-RP, SSM) and their security properties has been described in [PIMSEC].
相互ドメインマルチキャストルーティングモデル(MSDPと伝統的なASM、埋め込まれたRP、SSM)と彼らのセキュリティの特性の、より大規模な記述と比較は[PIMSEC]で説明されます。
9. Acknowledgements
9. 承認
Jerome Durand commented on an early version of this memo. Marshall Eubanks noted an issue regarding short plen values. Tom Pusateri noted problems with an earlier SPT-join approach. Rami Lehtonen pointed out issues with the scope of SA-state and provided extensive commentary. Nidhi Bhaskar gave the document a thorough review. Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very extensive feedback. In particular, Pavlin Radoslavov, Dino Farinacci, Nidhi Bhaskar, and Jerome Durand provided good comments during and after WG last call. Mark Allman, Bill Fenner, Thomas Narten, and Alex Zinin provided substantive comments during the IESG evaluation. The whole MboneD working group is also acknowledged for continued support and comments.
ジェローム・ジュランドはこのメモの早めのバージョンを批評しました。 マーシャル・ユーバンクスは短いplen値に関する問題に注意しました。 以前のSPT接合しているアプローチに関する問題についてトムPusateriを指摘しました。 Ramiレヒトネンは、SA-状態の範囲の問題を指摘して、大規模な論評を提供しました。 Nidhi Bhaskarは徹底的なレビューをドキュメントに与えました。 Toerlessエッケルト、ヒューHolbrook、およびデーヴ・マイヤーは非常に大規模なフィードバックを提供しました。 特に、WGとWGの後のパブリン・ラドスラーボフ、ディーノ・ファリナッチ、Nidhi Bhaskar、およびジェローム・ジュランドの提供された良いコメントは最後に呼びます。 マーク・オールマン、ビル・フェナー、トーマスNarten、およびアレックス・ジニンはIESG評価の間、実質的なコメントを提供しました。 また、全体のMboneDワーキンググループは継続的なサポートとコメントのために承認されます。
10. Security Considerations
10. セキュリティ問題
The addresses of RPs are encoded in the multicast addresses, thus becoming more visible as single points of failure. Even though this does not significantly affect the multicast routing security, it may expose the RP to other kinds of attacks. The operators are encouraged to pay special attention to securing these routers. See Section 6.1 for considerations regarding failover and Section 6.2 for placement of RPs leading to a degree of fate-sharing properties.
RPsのアドレスはマルチキャストアドレスでコード化されて、その結果、単一のポイントの失敗として、より目に見えるようになります。 これはマルチキャストルーティングセキュリティにかなり影響しませんが、それは他の種類の攻撃にRPを露出するかもしれません。 オペレータがこれらのルータを保証することに関する特別な注意を向けるよう奨励されます。 フェイルオーバーとセクション6.2に関する問題に関して1段階の運命を共有する特性に通じるRPsのプレースメントに関してセクション6.1を見てください。
As any RP will have to accept PIM-SM Join/Prune/Register messages from any DR, this might cause a potential Denial of Service attack scenario. However, this can be mitigated, as the RP can discard all such messages for all multicast addresses that do not encode the address of the RP. Both the sender- and receiver-based attacks are described at greater length in [PIMSEC].
どんなRPもどんなDRからもPIM-SM Join/プルーン/レジスタメッセージを受け入れなければならないとき、これは潜在的サービス妨害攻撃シナリオを引き起こすかもしれません。 しかしながら、これを緩和できます、RPがRPのアドレスをコード化しないすべてのマルチキャストアドレスへのそのようなすべてのメッセージを捨てることができるとき。 送付者と受信機ベースの攻撃の両方が[PIMSEC]で、より大きい長さで説明されます。
Savola & Haberman Standards Track [Page 13] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[13ページ]RFC3956
Additionally, the implementation SHOULD also allow manual configuration of which multicast prefixes are allowed to be used. This can be used to limit the use of the RP to designated groups only. In some cases, being able to restrict (at the RP) which unicast addresses are allowed to send or join to a group is desirable. (However, note that Join/Prune messages would still leave state in the network, and Register messages can be spoofed [PIMSEC].) Obviously, these controls are only possible at the RP, not at the intermediate routers or the DR.
また、さらに、実現SHOULDはマルチキャスト接頭語が使用できる手動の構成を許します。 RPの使用を指定されたグループだけに制限するのにこれを使用できます。 いくつかの場合、グループに送るか、またはユニキャストアドレスがつなぐことができる制限する(RPで)できるのは望ましいです。 (しかしながら、Join/プルーンのメッセージがネットワークでまだ状態を出ていることに注意してください。そうすれば、Registerメッセージはだますことができます[PIMSEC]。) 明らかに、これらのコントロールは中間的ルータかDRで可能であるのではなく、単にRPで可能です。
It is RECOMMENDED that routers supporting this specification do not act as RPs unless explicitly configured to do so, as becoming an RP does not require any advertisement (e.g., through BSR or manually). Otherwise, any router could potentially become an RP (and be abused as such). Further, multicast groups or group ranges to-be-served MAY need to be explicitly configured at the RPs, to protect them from being used unwillingly. Note that the more specific controls (e.g., "insider-must-create" or "invite-outsiders" models) as to who is allowed to use the groups are beyond the scope of this memo.
同じくらいふさわしいRPをするために明らかに構成されない場合RPsが少しの広告(例えば、BSRか手動)も必要としないときこの仕様を支持するルータが行動しないのは、RECOMMENDEDです。 さもなければ、どんなルータも潜在的にRPになることができました(そういうものとして乱用されてください)。 さらに、マルチキャストが分類されるか、または役立たれた5月が分類しなければならない範囲を分類して、RPsで明らかに構成されて、いやいや使用されるのから彼らを保護してください。 だれがグループを使用できるかに関する、より特定のコントロール(例えば、「必須が創造するインサイダー」か「招待部外者」モデル)がこのメモの範囲を超えていることに注意してください。
Excluding internal-only groups from MSDP advertisements does not protect the groups from outsiders but only offers security by obscurity; embedded-RP offers similar level of protection. When real protection is desired, PIM scoping for example, should be set up at the borders. This is described at more length in Section 6.5.
内部で唯一のグループをMSDP広告に入れないようにすると、グループが部外者から保護されませんが、セキュリティは不鮮明によって提供されるだけです。 埋め込まれたRPは同じ水準の保護を提供します。 例えば、PIMが見る場合、本当の保護がいつ望まれているかは境界でセットアップされるべきです。 これはセクション6.5で、より多くの長さで説明されます。
One should observe that the embedded-RP threat model is actually rather similar to SSM; both mechanisms significantly reduce the threats at the sender side. On the receiver side, the threats are somewhat comparable, as an attacker could do an MLDv2 (S,G) join towards a non-existent source, which the local RP could not block based on the MSDP information.
埋め込まれたRP脅威モデルが実際にSSMとかなり同様であることを観測するべきです。 両方のメカニズムは送付者側で脅威をかなり抑えます。 受信機側では、脅威がいくらか匹敵している、攻撃者がMLDv2ができたように(S、G)が実在しないソースに向かって加わります。地方のRPはMSDP情報に基づいてソースを妨げることができませんでした。
The implementation MUST perform at least the same address validity checks to the embedded-RP address as it would to one received via other means; at least fe80::/10, ::/16, and ff00::/8 should be excluded. This is particularly important, as the information is derived from the untrusted source (i.e., any user in the Internet), not from the local configuration.
実現は他の手段で受け取られた1つに実行するように少なくとも同じアドレスバリディティチェックを埋め込まれたRPアドレスに実行しなければなりません。 少なくともfe80:、:/10, ::/16、およびff00:、:/8は除かれるべきです。 これは特に重要です、情報が地方の構成から引き出されるのではなく、信頼できないソース(インターネットのすなわちどんなユーザも)から引き出されるとき。
A more extensive description and comparison of the inter-domain multicast routing models (traditional ASM with MSDP, embedded-RP, SSM) and their security properties has been done separately in [PIMSEC].
別々に[PIMSEC]で相互ドメインマルチキャストルーティングモデル(MSDPと伝統的なASM、埋め込まれたRP、SSM)と彼らのセキュリティの特性の、より大規模な記述と比較をしました。
Savola & Haberman Standards Track [Page 14] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[14ページ]RFC3956
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[ADDRARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[ADDRARCH]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[RFC3306] ハーバーマンとB.とD.ターレル、「ユニキャスト接頭語ベースのIPv6マルチキャストアドレス」、RFC3306、2002年8月。
11.2. Informative References
11.2. 有益な参照
[ANYCAST] Hagino, J. and K. Ettikan, "An analysis of IPv6 anycast",
Work in Progress, June 2003.
[ANYCAST] HaginoとJ.とK.Ettikan、「IPv6 anycastの分析」、Progress、2003年6月のWork。
[ANYCASTRP] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci,
"Anycast Rendevous Point (RP) mechanism using Protocol
Independent Multicast (PIM) and Multicast Source
Discovery Protocol (MSDP)", RFC 3446, January 2003.
[ANYCASTRP] キム、D.、マイヤー、D.、キルマー、H.、およびD.ファリナッチ、「プロトコルの無党派Multicast(PIM)とMulticast Sourceディスカバリープロトコル(MSDP)を使用するAnycast Rendevous Point(RP)メカニズム」、RFC3446(2003年1月)。
[ANYPIMRP] Farinacci, D. and Y. Cai, "Anycast-RP using PIM", Work in
Progress, June 2004.
[ANYPIMRP] 「PIMを使用するAnycast-RP」というファリナッチ、D.、およびY.Caiは進歩、2004年6月に働いています。
[BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for
PIM Sparse Mode", Work in Progress, July 2004.
[BSR] フェナー、B.、他、「PIMのまばらなモードのためにルータ(BSR)メカニズムを独力で進んでください」、Progress、2004年7月のWork。
[MSDP] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003.
[MSDP]フェナーとB.とD.マイヤー、「マルチキャストソース発見プロトコル(MSDP)」、RFC3618 2003年10月。
[PIMSEC] Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast
Routing Security Issues and Enhancements", Work in
Progress, October 2004.
P.、レヒトネン、R.、D.マイヤー、および「PIM-Smマルチキャストルート設定安全保障問題と増進」という[PIMSEC]Savolaは進歩、2004年10月に働いています。
[PIM-SM] Fenner, B. et al, "Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol Specification (Revised)",
Work in Progress, July 2004.
[PIM-SM]フェナー、B.他、「プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm):、」 「プロトコル仕様(改訂される)」、処理中の作業、2004年7月。
[SSM] Holbrook, H. et al, "Source-Specific Multicast for IP",
Work in Progress, September 2004.
[SSM]ホルブルック、H.他、「IPのためのソース特有のマルチキャスト」、Progress、2004年9月のWork。
[V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", Work in
Progress, September 2004.
「IPv6マルチキャスト展開問題」という[V6MISSUES]Savola、P.は進歩、2004年9月に働いています。
Savola & Haberman Standards Track [Page 15] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[15ページ]RFC3956
A. Discussion about Design Tradeoffs
A。 デザイン見返りについての議論
The document only specifies FF70::/12 for now; if/when the upper-most bit is used, one must specify how FFF0::/12 applies to Embedded-RP. For example, a different mode of PIM or another protocol might use that range, in contrast to FF70::/12, as currently specified, being for PIM-SM only.
ドキュメントはFF70を指定するだけです:、:当分間の/12。 最高のビットであるときに、/が使用されているなら、どのようにFFF0を指定しなければならないか:、:/12はEmbedded-RPに適用されます。 例えば、PIMの異なったモードか別のプロトコルがFF70と対照してその範囲を使用するかもしれません:、:現在指定されているとして、/12はPIM-SMだけのためのそうです。
Instead of using flags bits ("FF70::/12"), one could have used the
leftmost reserved bits instead ("FF3x:8000::/17").
使用の代わりにビットに旗を揚げさせる、(「FF70: : /12インチ)、1つが代わりに一番左予約されたビットを使用したかもしれない、(「FF3x: 8000: : /17インチ)、」
It has been argued that instead of allowing the operator to specify RIID, the value could be pre-determined (e.g., "1"). However, this has not been adopted, as this eliminates address assignment flexibility from the operator.
オペレータがRIIDを指定するのを許容することの代わりに値を予定できたと主張された、(例えば、「1インチ)」 しかしながら、オペレータからアドレス課題の柔軟性を根絶するとき、これは採用されません。
Values 64 < "plen" < 96 would overlap with upper bits of the multicast group-id; due to this restriction, "plen" must not exceed 64 bits. This is in line with RFC 3306.
<"plen"<96がマルチキャストグループイドの上側のビットに重ね合わせる値64。 この制限のため、"plen"は64ビットを超えてはいけません。 これはRFC3306に沿ってあります。
The embedded-RP addressing could be used to convey other information (other than RP address) as well, for example, what should be the RPT threshold for PIM-SM. These could be, whether feasible or not, encoded in the RP address somehow, or in the multicast group address. In any case, such modifications are beyond the scope of this memo.
また、例えば他の情報(RPアドレスを除いた)を伝えるのに埋め込まれたRPアドレシングを使用できました、PIM-SMのためのRPT敷居であるべきであること。 どうにか、またはマルチキャストグループアドレスのRPアドレスでコード化されて、可能であるか否かに関係なく、これらはそうであるかもしれません。 どのような場合でも、そのような変更はこのメモの範囲を超えています。
For the cases where the RPs do not exist or are unreachable, or too much state is being generated to reach in a resource exhaustion Denial of Service attack, some forms of rate-limiting or other mechanisms could be deployed to mitigate the threats while trying not to disturb the legitimate usage. However, as the threats are generic, they are considered out of scope and discussed separately in [PIMSEC].
RPsが存在していないか、手が届かない、またはあまりに多くの状態がリソース疲労困憊サービス妨害攻撃で達するように発生しているケースにおいて、正統の用法を擾乱していようとしていない間、脅威を緩和するためにいくつかのフォームのレートを制限しているか、他のメカニズムを配備できました。 しかしながら、脅威が一般的であるので、それらについて、範囲から考えられて、別々に[PIMSEC]で議論します。
Savola & Haberman Standards Track [Page 16] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[16ページ]RFC3956
Authors' Addresses
作者のアドレス
Pekka Savola CSC/FUNET Espoo, Finland
ペッカ・Savola CSC/FUNETエスポー(フィンランド)
EMail: psavola@funet.fi
メール: psavola@funet.fi
Brian Haberman Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
ブライアンハーバーマンジョーンズ・ホプキンス大学応用物理学研究室11100のジョーンズ・ホプキン・Road MD20723-6099ローレル(米国)
Phone: +1 443 778 1319 EMail: brian@innovationslab.net
以下に電話をしてください。 +1 1319年の443 778メール: brian@innovationslab.net
Savola & Haberman Standards Track [Page 17] RFC 3956 The RP Address in IPv6 Multicast Address November 2004
SavolaとRPがマルチキャストアドレス2004年11月にIPv6に記述するハーバーマン標準化過程[17ページ]RFC3956
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Savola & Haberman Standards Track [Page 18]
Savolaとハーバーマン標準化過程[18ページ]
一覧
スポンサーリンク
