[要約] RFC 3956は、IPv6マルチキャストアドレスにランデブーポイント（RP）アドレスを埋め込む方法を定義しています。このRFCの目的は、IPv6ネットワークでのマルチキャストグループの管理を簡素化し、スケーラビリティを向上させることです。
Network Working Group P. Savola
Request for Comments: 3956 CSC/FUNET
Updates: 3306 B. Haberman
Category: Standards Track JHU APL
November 2004
Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
IPv6 マルチキャスト アドレスへのランデブー ポイント (RP) アドレスの埋め込み
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 (2004).
著作権 (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.
このメモは、ランデブー ポイント (RP) のアドレスが IPv6 マルチキャスト グループ アドレスにエンコードされるアドレス割り当てポリシーを定義します。Protocol Independent Multicast - Sparse Mode（PIM-SM）の場合、これはグループから RP へのマッピング メカニズムの仕様と見なすことができます。これにより、スケーラブルなドメイン間マルチキャストの展開が容易になり、ドメイン内マルチキャスト構成も簡素化されます。このメモは、RFC 3306 で示されているアドレス指定形式を更新します。
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
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
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] で知られているように、グローバルなドメイン間 IPv6 マルチキャストには展開上の問題が存在します。PIM-SM [PIM-SM] RP には、（アクティブな）マルチキャスト ソースに関する情報を他のマルチキャスト ドメインにマルチキャスト ソースとして通信する方法がありません。Discovery Protocol (MSDP) [MSDP] は、IPv6 に対して意図的に指定されていません。したがって、ドメイン間 Any Source Multicast (ASM) モデル全体が使用できなくなります。Source-Specific 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 が短期的に唯一のドメイン間マルチキャスト ルーティング メカニズムとして使用できる可能性は低いと思われます。
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 ドメイン間任意ソース マルチキャストの単純なソリューションを提供するだけでなく、スコープ付きマルチキャスト アドレスを使用する IPv6 ドメイン内 ASM の単純なソリューションとしても使用できます。
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].
また、以前はブートストラップ ルーター プロトコル (BSR) [BSR] を使用していた展開シナリオで、自動 RP 検出メカニズムとしても使用できます。
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 [RFC3306] IPv6 マルチキャスト グループ アドレスのサブ範囲の仕様。Flags フィールドの未使用の 1 ビットを「1」に設定することで定義されます。
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.
サブ範囲内のアドレスは、embedded-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.
このメモは、RFC 3306 で示されているアドレス指定形式を更新します。
Some design tradeoffs are discussed in Appendix A.
いくつかの設計上のトレードオフについては、付録 A で説明します。
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 アドレスは、グループ ID 自体を伝送するためのスペースが残っている 128 ビット グループ アドレスに埋め込むことはできません。したがって、エンコーディングの適切な形式は、組み込み RP 範囲内の RP のインターフェイス 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 で簡単に説明します。
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.
Embedded-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].
この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。[RFC2119] に記載されているように解釈されます。
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 任意のソース マルチキャスト BSR ブートストラップ ルーター DR 指定ルーター IGP インテリア ゲートウェイ プロトコル MLD マルチキャスト リスナー検出 MSDP マルチキャスト ソース検出プロトコル PIM プロトコル独立型マルチキャスト PIM-SM プロトコル独立型マルチキャスト - スパース モード RIID RP インターフェイス ID (このメモで指定されている) RP ランデブー ポイントRPF リバース パス フォワーディング SPT 最短パス ツリー SSM 送信元固有のマルチキャスト
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 |
+--------+----+----+--------+----+----------------+----------+
Where flgs are "0011". (The first two bits are as yet undefined, sent as zero and ignored on receipt.)
ここで、flgs は「0011」です。(最初の 2 ビットはまだ未定義で、ゼロとして送信され、受信時に無視されます。)
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|
+-+-+-+-+
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 にアドレスが埋め込まれたマルチキャスト アドレスを示します。[RFC3306] で規定されているように、P は 1 に設定されなければならず、その結果として T も 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 仕様がなければ、実装は FFF0::/12 範囲を Embedded-RP として扱うべきではありません (SHOULD NOT)。
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」の値はゼロとして送信されなければならず、受信時に無視されなければなりません。
The address of the RP can only be embedded in unicast-prefix-based ASM addresses.
RP のアドレスは、ユニキャスト プレフィックス ベースの ASM アドレスにのみ埋め込むことができます。
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 「flgs」が 0111 に設定されたマルチキャスト アドレス、つまりプレフィックス FF70::/12 である必要があります。
o "plen" MUST NOT be 0 (i.e., not SSM), and o "plen" MUST NOT be greater than 64.
o "plen" は 0 (つまり、SSM ではない) であってはならず、また、"plen" は 64 を超えてはなりません。
The address of the RP can be obtained from a multicast address satisfying the above criteria by taking the following two steps:
RP のアドレスは、次の 2 つの手順を実行することで、上記の基準を満たすマルチキャスト アドレスから取得できます。
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|
+------------+---------------------+----+
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] ステートメント「ネットワーク プレフィックス フィールドのすべての非重要ビットはゼロでなければならない (SHOULD)」が無視される場合、いくつかの運用シナリオ (以下の例 3 を参照) があることに注意する必要があります。これは、マルチキャスト グループ アドレスの割り当てがユニキャスト プレフィックスと一致するようにするためです。マルチキャスト アドレスは、ネットワーク プレフィックスに関連付けられた RP を引き続き使用します。
"plen" higher than 64 MUST NOT be used, as that would overlap with the high-order bits of multicast group-id.
64 より大きい「plen」は、マルチキャスト グループ ID の上位ビットと重複するため、使用してはなりません (MUST NOT)。
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 アドレスを取得するためにエンコードを処理するとき、マルチキャスト ルータは、計算された RP アドレスに対して、他の手段 (BSR [BSR] や IPv4 の MSDP など) で受信したものと少なくとも同じアドレス有効性チェックを実行しなければなりません (MUST)。少なくとも 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 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).
「RIID」用に予約されている 4 ビットは、スコープ、ネットワーク プレフィックス、およびグループ ID の組み合わせの RP の上限を設定することに注意してください。これらのいずれも変更せずに、2^4-1 = 15 の異なる RP を持つことができます。(RIID=0 は予約されているため、セクション 6.3 を参照)。ただし、これらはそれぞれ独自の IPv6 グループ アドレスです (つまり、マルチキャスト アドレスごとに RP は 1 つだけ存在できます)。
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 つの例を、エンコーディングによって提供される可能性をよりわかりやすく説明するためにここで説明します。
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::/32 のネットワーク管理者は、既存のサブネット (例: 2001:DB8:BEEF:FEED::/64) に RP を配置して、ネットワークとすべての顧客に対して RP をセットアップしたいと考えています。
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:BEEF:FEED::/96」のようになり、その RP アドレスは「2001:DB8:BEEF:FEED::y」になります。顧客と自分自身に割り当てるマルチキャスト グループ ID がまだ 32 ビットあります (0 は使用できないため、「y」は 1 から F までの任意の値になります)。
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:
例 1 と同様に、2001:DB8::/32 のネットワーク管理者は RP をセットアップしたいと考えていますが、より柔軟にするために、RP を特別にルーティングされたサブネット上に配置し、グループ割り当て用により大きなアドレス スペースを確保したいと考えています。つまり、管理者はユニキャスト プレフィックスの最も具体性の低い部分 (plen=32) を選択し、グループ アドレスはマルチキャスト プレフィックスから取得されます。
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、グループ ID または割り当てには 64 ビットがあります。この場合、RP のアドレスは次のようになります。
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 つまたは 2 つの RP のみをセットアップする場合 (たとえば、サブネットごとに 1 つの RP ではない場合)、このアプローチは例 1 で説明したアプローチよりも好ましい可能性があります。
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.)
例 2 と同様に、ネットワーク管理者は一部の顧客に「FF7x:y20:2001:DB8:DEAD::/80」などのマルチキャスト プレフィックスを割り当てることもできます。この場合、RP アドレスは依然として「2001:DB8::y」になります。(これは例 2 のより具体的なサブケースであり、管理者が個々のグループ ID だけでなくマルチキャスト プレフィックスを割り当てることに注意してください。)
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」フィールド、0x20 = 32 は、RP アドレスを取得するときに考慮される「ネットワーク プレフィックス」フィールドの長さを指します。この場合、ネットワーク プレフィックス フィールド「2001:DB8」の最初の 32 ビットのみが保存されます。「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 アドレス設定が可能になります。
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".
例 1、2、および 3 のネットワークでは、ネットワーク管理者は顧客が使用するアドレスを設定しますが、組織は独自の PIM-SM ドメインを持ちたいと考えています。組織は「FF7x:y30:2001:DB8:BEEF::/80」などのマルチキャスト アドレスを選択でき、RP アドレスは「2001:DB8:BEEF::y」になります。
This section describes the major operational considerations for those deploying this mechanism.
このセクションでは、このメカニズムを導入する場合の運用上の主な考慮事項について説明します。
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].
「エニーキャスト RP」と呼ばれる技術は、主に冗長性を目的として、RP のセット間でアドレスとマルチキャスト状態情報を共有するために PIM-SM ドメイン内で使用されます。通常、MSDP はこれにも使用されています [ANYCASTRP]。この情報を共有するために PIM を使用するなど、他のアプローチもあります [ANYPIMRP]。
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 フェールオーバーの最も実現可能な候補は、エニーキャスト RP または状態共有なしでインテリア ゲートウェイ プロトコル (IGP) の RP アドレスを「エニーキャスト」(つまり、共有ユニキャスト モデル [ANYCAST]) する PIM を使用することです (ただし、冗長性の要件によって異なります)。、これで十分でない場合もあります）。ただし、冗長メカニズムはこのメモの範囲外です。
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 とドメイン間の状態を共有する必要がないため、マルチキャスト ソースに接続する各指定ルーターは、MSDP セッションのセットアップと維持に関するスケーラビリティの問題を気にせずに RP として機能できます。
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.
これは、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.
同様に、RP の責任を複数の RP に分散することも望ましい場合があります。異なる RP が異なるグループにサービスを提供する限り、これは簡単です。各グループは異なる RP (または 1 つの RP の負荷が問題にならないほど多くの異なる RP) にマッピングできます。ただし、あるグループが直面する負荷分散の課題は、エニーキャスト RP の課題と似ています。
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].
RIID = 0 を使用すると、サブネット ルーター エニーキャスト アドレス [ADDRARCH] とのあいまいさが生じるため、使用しないでください。
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 の例 2 で説明した、ルータに割り当てられた追加のループバック アドレスなど) を使用したい場合、そのアドレスは、ホスト ルートを介してルーティング システムに注入できます。
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 では、各グループ アドレスが使用する RP を指定するため、PIM ドメイン全体で BSR または他の RP 設定メカニズムを使用する必要はありません。
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 を誰がどのように使用できるかという制御と管理が若干変更されており、明確に議論する価値があります。
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.
ただし、このような制御では、部外者によるそのようなグループの使用はまだブロックされていません。部外者は、(ソース、グループ) または (S,G) 参加によるソース アクティブ アドバタイズメントがなくても、ソースおよび/またはソースを推測/学習することでグループに参加できるからです。グループアドレス。適切に保護するには、境界ルータで PIM マルチキャスト スコープ ボーダーなどを設定する必要があります。したがって、embedded-RP には、SA フィルタリングを備えた MSDP とほぼ同等の「保護」レベルがデフォルトで備わっています。
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 に送信したりする可能性があることです。(これらは過去にもある程度可能でしたが、それは DR での意図的な試みまたは意図的な RP 設定によってのみ可能でした。) この場合の主な脅威は、部外者が RP を不正に使用して自分のグループをホストする可能性があることです。(s)。これは、RP で許可されるグループまたはグループ範囲をフィルタリングすることである程度軽減できます。より具体的な制御については、このメモの範囲外です。/64 ユニキャスト プレフィックスを持つ人は誰でも、他人から不正に取得することなく独自の RP を作成できるため、これはそもそも深刻な脅威ではないようです。
This section specifies the group-to-RP mapping mechanism for Embedded RP.
このセクションでは、Embedded RP のグループから 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 アドレスを導出および使用する必要があります。この情報は、少なくともリバース パス転送 (RPF) ルックアップの実行時、結合/プルーン メッセージの処理時、または登録の実行時に使用されます。-カプセル化。
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 マッピングは可能な限り最長の一致であり、他のメカニズムよりも高い優先順位であると見なされなければなりません (MUST)。
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 マッピングは、別の RP にマッピングされる新しい IPv6 グループ アドレスごとに再実行する必要があることに注意してください。効率性を高めるために、埋め込み 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 へのマッピング メカニズムは、RP、送信者に隣接する DR、および受信者から RP へのパス上の任意のルーターによってサポートされている必要があります。最短パス ツリー (SPT) 形成およびレジスターストップのパスは、(S,G) 結合で実現されるため、サポートは必要ありません。
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 や Web ページなど) でグループ アドレスを見つけます。
2. The receiver issues an Multicast Listener Discovery (MLD) Report, joining the group.
2. 受信者はマルチキャスト リスナー検出 (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 は、「ローカル」 PIM ドメイン内にあるか「リモート」 PIM ドメイン内にあるかに関係なく、マルチキャスト アドレスでエンコードされた RP に対して PIM-SM 参加プロセスを開始します。
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 は、PIM-SM Register メッセージにユニキャストでカプセル化されたパケットを、マルチキャスト アドレスでエンコードされた RP アドレスに送信します (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 のアドレスを取得する代わりに、このアルゴリズムは、エンコードされたマルチキャスト アドレスから透過的にアドレスを取得します。
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 ドメインを接続するためのドメイン間 MSDP モデルは、構成と展開においてほとんどが階層的ですが、情報配信に関してはフラットです。組み込み RP ドメイン間モデルは、受信者または送信者がどこにいても、グループが単一の RP にマッピングされて、すべてのグループが独自のインターネット全体の PIM ドメインを形成しているかのように動作します。したがって、ドメイン間マルチキャストはフラットな 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 マルチキャストでは、インターネット全体の状態として、MSDP (どこにでも伝播される) と (受信側または送信側のブランチ上で) マルチキャスト ルーティングの状態という、おおまかに 2 種類あります。前者は削除されますが、バックボーン ルータは、(S, G) に加えて、受信機 (および PIM プルーンの場合は過去の受信機) と RP の間で (*, G) および (S, G, rpt) 状態になる可能性があります。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 のアドレスがマルチキャスト アドレスに関連付けられると、展開されたフェイルオーバーまたは冗長メカニズム (BSR、MSDP を使用した Anycast-RP など) をそのままでは使用できないため、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 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].
PIM-SM 仕様には、「設定または学習された RP アドレスは、ドメイン全体で到達可能なアドレスでなければならない」と記載されています。「到達可能」が正確に何を意味するかは、埋め込み RP がない場合でも明らかではありません。このステートメントは、特に外部 RP の場合、RP が存在することさえ保証できないため、証明できません。RP と DR を手動で設定する代わりに (まれですが、存在しない RP を設定することは可能でした)、この仕様ではマルチキャストを使用するホストとユーザーが間接的に RP 自体を指定するため、RP 到達可能性の期待値が低くなります。これは比較的重大な問題ですが、現在のマルチキャスト展開と大きな違いはありません。たとえば、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.
リモート RP に参加/送信できることは、個別に考慮されるセキュリティ上の懸念を引き起こしますが、利点もあります。すべてのグループには、グループに送信できるユーザーを (ある程度) 制御できる「責任ある 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] で説明されています。
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.
ジェローム・デュランは、このメモの初期バージョンについてコメントしました。Marshall Eubanks はショートプレン値に関する問題を指摘しました。Tom Pusateri 氏は、初期の SPT 参加アプローチの問題点を指摘しました。Rami Lehtonen は、SA 州の範囲に関する問題を指摘し、広範な解説を提供しました。Nidhi Bhaskar はこの文書を徹底的にレビューしました。Toerless Eckert、Hugh Holbrook、Dave Meyer が非常に広範なフィードバックを提供してくれました。特に、Pavlin Radoslavov、Dino Farinacci、Nidhi Bhaskar、Jerome Durand は、WG の最終通話中およびその後に良いコメントを提供してくれました。Mark Allman、Bill Fenner、Thomas Narten、Alex Zinin は、IESG の評価中に実質的なコメントを提供しました。MboneD ワーキンググループ全体にも、継続的なサポートとコメントをいただきました。
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.
RP のアドレスはマルチキャスト アドレス内でエンコードされるため、単一障害点として認識されやすくなります。これはマルチキャスト ルーティングのセキュリティに大きな影響を与えませんが、RP が他の種類の攻撃にさらされる可能性があります。オペレータは、これらのルータの保護に特別な注意を払うことが推奨されます。フェールオーバーに関する考慮事項についてはセクション 6.1 を、ある程度の運命共有特性をもたらす RP の配置についてはセクション 6.2 を参照してください。
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/Prune/Register メッセージを受け入れる必要があるため、潜在的なサービス拒否攻撃シナリオが発生する可能性があります。ただし、RP は、RP のアドレスをエンコードしていないすべてのマルチキャスト アドレスに対するそのようなメッセージをすべて破棄できるため、これは軽減できます。送信者ベースの攻撃と受信者ベースの攻撃の両方については、[PIMSEC] で詳しく説明されています。
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/Prune メッセージは依然としてネットワーク内に状態を残し、Register メッセージはスプーフィングされる可能性があることに注意してください [PIMSEC]。) 明らかに、これらの制御は RP でのみ可能であり、中間ルータや DR では可能ではありません。
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 として機能しないことが推奨されます。これは、RP になるために (BSR を介して、または手動で) アドバタイズメントを必要としないためです。そうしないと、ルーターが RP になる可能性があります (そして、そのように悪用される可能性があります)。さらに、提供されるマルチキャスト グループまたはグループ範囲は、不用意に使用されないように保護するために、RP で明示的に設定する必要があってもよい(MAY)。誰にグループの使用を許可するかについての、より具体的な制御 (例: 「内部者必須作成」または「外部者招待」モデル) は、このメモの範囲外であることに注意してください。
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) join を実行する可能性があるため、脅威はある程度似ていますが、ローカル 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.
実装は、埋め込み RP アドレスに対して、他の手段で受信した場合と少なくとも同じアドレス有効性チェックを実行しなければなりません (MUST)。少なくとも 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].
ドメイン間マルチキャスト ルーティング モデル (MSDP を使用した従来の ASM、組み込み RP、SSM) とそのセキュリティ プロパティのより広範な説明と比較は、[PIMSEC] で個別に行われています。
[ADDRARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[ADDRARCH] Hinden、R.、S. Deering、「インターネット プロトコル バージョン 6 (IPv6) アドレッシング アーキテクチャ」、RFC 3513、2003 年 4 月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306] Haberman, B. および D. Thaler、「ユニキャスト プレフィックスベースの IPv6 マルチキャスト アドレス」、RFC 3306、2002 年 8 月。
[ANYCAST] Hagino, J. and K. Ettikan, "An analysis of IPv6 anycast", Work in Progress, June 2003.
[ANYCAST] ハギノ、J.、K. エティカン、「IPv6 エニーキャストの分析」、進行中の作業、2003 年 6 月。
[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] Kim, D.、Meyer, D.、Kilmer, H.、および D. Farinacci、「Protocol Independent Multicast (PIM) および Multicast Source Discovery Protocol (MSDP) を使用した Anycast Rendevous Point (RP) メカニズム」、RFC 3446、2003年1月。
[ANYPIMRP] Farinacci, D. and Y. Cai, "Anycast-RP using PIM", Work in Progress, June 2004.
[ANYPIMRP] Farinacci, D. および Y. Cai、「PIM を使用した Anycast-RP」、進行中の作業、2004 年 6 月。
[BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress, July 2004.
[BSR] Fenner, B. 他、「PIM スパース モードのブートストラップ ルーター (BSR) メカニズム」、進行中の作業、2004 年 7 月。
[MSDP] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[MSDP] Fenner、B.、D. Meyer、「マルチキャスト ソース ディスカバリ プロトコル (MSDP)」、RFC 3618、2003 年 10 月。
[PIMSEC] Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast Routing Security Issues and Enhancements", Work in Progress, October 2004.
[PIMSEC] Savola, P.、Lehtonen, R.、および D. Meyer、「PIM-SM マルチキャスト ルーティングのセキュリティの問題と機能強化」、進行中の作業、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] Fenner, B. 他、「プロトコル独立マルチキャスト - スパース モード (PIM-SM): プロトコル仕様 (改訂版)」、進行中の作業、2004 年 7 月。
[SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", Work in Progress, September 2004.
[SSM] Holbrook, H. 他、「Source-Specific Multicast for IP」、進行中の作業、2004 年 9 月。
[V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", Work in Progress, September 2004.
[V6MISSUES] Savola, P.、「IPv6 マルチキャスト展開の問題」、進行中の作業、2004 年 9 月。
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 にどのように適用されるかを指定する必要があります。たとえば、現在指定されている FF70::/12 が PIM-SM 専用であるのとは対照的に、PIM の別のモードまたは別のプロトコルがその範囲を使用する可能性があります。
Instead of using flags bits ("FF70::/12"), one could have used the leftmost reserved bits instead ("FF3x:8000::/17").
フラグ ビット (「FF70::/12」) を使用する代わりに、左端の予約ビット (「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.
値 64 < "plen" < 96 は、マルチキャスト グループ ID の上位ビットと重複します。この制限により、「plen」は 64 ビットを超えてはなりません。これは RFC 3306 に準拠しています。
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 アドレス指定は、PIM-SM の RPT しきい値など、他の情報 (RP アドレス以外) を伝えるためにも使用できます。これらは、実現可能かどうかにかかわらず、何らかの方法で 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].
RP が存在しないか、到達不能である場合、またはリソース枯渇のサービス拒否攻撃で到達できないほど多くの状態が生成されている場合には、何らかの形式のレート制限またはその他のメカニズムを導入して、脅威を軽減しながら脅威を軽減することができます。正当な使用を妨害すること。ただし、これらの脅威は一般的なものであるため、範囲外とみなされ、[PIMSEC] で個別に議論されます。
Authors' Addresses
著者の住所
Pekka Savola CSC/FUNET Espoo, Finland
Pekka Savola CSC/FUNET エスポー、フィンランド
EMail: psavola@funet.fi
Brian Haberman Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
ブライアン・ハーバーマン ジョンズ・ホプキンス大学応用物理学研究室 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2004).
著作権 (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.
この文書は、BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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 は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、そのような権利を特定するために独自の努力を行ったことを示すものでもありません。IETF 文書の権利に関する IETF の手順に関する情報は、BCP 78 および BCP 79 に記載されています。
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.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/ipr) から入手してください。
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 (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。