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
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マルチキャストグループアドレスに符号化されたアドレス割り当てポリシーを定義します。プロトコル独立マルチキャストのため - スパースモード（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はマルチキャストソースとして、他のマルチキャストドメインに（アクティブ）マルチキャスト送信元に関する情報を通信する方法がありません発見プロトコル（MSDP）[MSDP]は、意図的にIPv6用に指定されていません。したがって、全体のドメイン間の任意のソースマルチキャスト（ASM）モデルが使用不能にされます。ソース固有マルチキャスト（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マルチキャストグループアドレスのサブレンジの仕様が「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
このようなグループアドレスがこのグループに使用するRPアドレスをコードすることにより、マッピングの仕様O、及び
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.
このメモは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.
同様に、エニーキャスト-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.
組み込み-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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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
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上のアドレスを埋め込むマルチキャストアドレスを示しています。その後、Pを1に設定しなければなりません、その結果、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仕様がなければ、実装は、組み込み-RPとしてFFF0 :: / 12の範囲を扱うべきではありません。
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それは、プレフィックスFF70 :: / 12のように、つまり、0111に設定し、「FLGS」とマルチキャストアドレスをでなければなりません、
o "plen" MUST NOT be 0 (i.e., not SSM), and o "plen" MUST NOT be greater than 64.
O "PLEN" 0（すなわち、しないSSM）、および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:
RPのアドレスは、次の2つのステップを取ることによって、上記の基準を満たすマルチキャストアドレスから得ることができます。
1. Copy the first "plen" bits of the "network prefix" to a zeroed 128-bit address structure, and
1.コピーゼロ128ビットのアドレス構造を「ネットワークプレフィックス」の最初の「PLEN」ビット、および
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.
一つは、いくつかの動作シナリオ（下記の実施例3を参照のこと）[RFC3306]文が無視され、「ネットワークプレフィックスフィールドのすべての非上位ビットがゼロであるべき」ときがあることに注意してください。これは、マルチキャストグループアドレスの割り当ては、ユニキャストプレフィクスと一致するようにすることです。マルチキャストアドレスは、まだネットワークプレフィックスに関連したRPを使用します。
"plen" higher than 64 MUST NOT be used, as that would overlap with the high-order bits of multicast group-id.
そのマルチキャストグループ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アドレスを取得するための符号化を処理する場合、マルチキャストルータは（BSR [BSR]またはIPv4の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
これらのいずれかを変えることなく、一方が異なる2 ^ 4-1 = 15を持つことができる - 一つ「はRIID」のために予約4ビットがスコープ、ネットワークプレフィックス、及びグループIDの組合せのためのRPの上限を設定することに注意してください
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).
RP（RIID = 0は予約されているように、セクション6.3を参照）。しかしながら、これらの各々は、それ自身のIPv6のグループアドレス（すなわち、マルチキャストアドレスごとに1つだけRPが存在することができる）です。
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：：BEEF：FEED :: / 64 DB8 :: / 32は、例えば、2001年、既存のサブネット上に置くことによって、ネットワークおよびすべての顧客のための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).
その場合には、グループアドレスは "：Y40：2001：DB8：BEEF：FF7x FEED :: / 96" のようなものになるでしょう、そして彼らのRPアドレスは次のようになり、 "2001：DB8：BEEF：FEED :: Y"。 （0は使用してはならないように「Y」は、1からFまで何でもあり得る）顧客と自己に割り当てるマルチキャストグループIDの32ビットが残っています。
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を設定したいが、それはより柔軟な、特にルーティングされたサブネット上に置きたいとグループの割り当てのために、より大きなアドレス空間を維持したいと考えてい作ること。すなわち、管理者はPLEN = 32と、ユニキャストプレフィックスの少なくとも特定の部分を選択し、グループアドレスがマルチキャストプレフィックスからなり、次のとおりです。
FF7x:y20:2001:DB8::/64
FF7x：Y20：2001：TB8 :: / 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
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のように、ネットワーク管理者はまた、「DEAD :: / 80 2001：：：Y20：DB8 FF7x」などのマルチキャストプレフィックスを割り当てることができます。この場合、RPアドレスはまだ「：DB8 :: Y 2001」になります。 （これは単に、管理者がマルチキャストプレフィックスだけでなく、個々のグループIDを割り当てて、実施例2のより具体的なサブケースであることに注意してください。）
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アドレスを導出する第二のルール注：マルチキャストアドレスに「PLEN」フィールドを0x20に= 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アドレスの設定を可能にします。
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ドメインを持って望んでいます。組織は、このような "：Y30：2001：DB8：FF7x 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】もこのために使用されています。そのような情報[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フェイルオーバーのための最も実現可能な候補は、冗長性の要件にもよるが（状態共有なしエニーキャストRPまたは「エニーキャスティング」（すなわち、共有ユニキャストモデル[ANYCAST]）インテリアゲートウェイプロトコル（IGP）でRPアドレスの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.
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.
同じ線に沿って、その月はまた、複数のRPをRP責任を分散することが望ましいこと。限り、異なるRPは異なるグループに仕えるように、これは簡単です：各グループは異なるRP（または1つのRPの負荷が問題ではないことを十分に多くの異なったRPS）にマップすることができます。しかし、負荷分散は、1つのグループ面がエニーキャスト-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.
管理者が対処するトポロジに準拠しますが（セクション5.1で実施例2で説明したように、例えば、ルータに割り当てられた追加のループバックアドレス）ネットワークプロバイダのユニキャストプレフィックスからまだいませんRPアドレスを使用したい場合は、そのアドレスホストルートを介してルーティングシステムに注入することができます。
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マルチキャストスコープの境界線を設定する必要があります。したがって、埋め込み-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はRPに参加送ることです。 （これらはだけ故意の試みまたはDRSに意図RPの構成を介して、程度、ならびに過去に可能であった。）この場合の主な脅威は部外者が不正に彼/彼女自身のグループをホストするためにRPを使用することができるということです（複数可）。これは、基または基の範囲がRPで許可されているフィルタリングによって程度に緩和することができます。より具体的なコントロールは、このメモの範囲を超えています。 / 64ユニキャストプレフィックスを持つ誰もが不正に他の誰かからそれを得ることなく、自分自身のRPを作成することができますように、これは最初の場所で深刻な脅威であると思わないことに注意してください。
This section specifies the group-to-RP mapping mechanism for Embedded RP.
このセクションでは、組み込みRPのグループツーRPマッピングメカニズムを指定します。
The only PIM-SM modification required is implementing this mechanism as one group-to-RP mapping method.
必要な唯一のPIM-SMの修飾は、一グループと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.
実装は、この情報はリバースパス転送（RPF）ルックアップを実行するときに参加/プルーンのメッセージを処理するときに、少なくとも使用、または登録を行っているアドレス形式を認識する必要があると派生し、第4節では、ルールを使用してRPアドレスを使用します-encapsulation。
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のアドレスのためのループとの不整合を回避するために、埋め込み-RPマッピングは、任意の他の機構よりも可能な限り長い一致より高い優先度とみなされなければなりません。
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への受信機からの経路上のルータでサポートされなければなりません。これらは、（S、G）で達成されるよう最短パスツリー（SPT）を形成するためのパスと登録・停止は参加し、支援を必要としません。
This section gives a high-level, non-normative overview of how Embedded RP operates, as specified in the previous section.
このセクションでは、前のセクションで指定された組み込み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.受信機がグループに参加する、マルチキャストリスナー発見（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ドメイン内にあるかどうかの、マルチキャストアドレスに符号化された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.送信者は（グループ割り当ての管理者に接触するか、マルチキャストアドレス割り当てプロトコルを使用して、例えば）不特定のメソッドを使用してグループアドレスを見つけ出します。
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は（DRがRPである特別な場合には、そのような送信概念のみである）マルチキャストアドレスに符号化されたRPアドレスにパケットをユニキャストカプセル化PIM-SMのレジスタ・メッセージを送信します。
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マッピングメカニズムとして機能します。代わりに、ローカル構成または構成プロトコルからRPのアドレスを取得する（例えば、BSR）は、アルゴリズムは、符号化されたマルチキャストアドレスからの透過を導出します。
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.
MSDP（どこにでも伝播）、及び（受信または送信者ブランチ上の）マルチキャストルーティング状態：IPv4のASMのマルチキャストと、大きく二つインターネット、ワイド状態の種類があります。前者は排除されるが、バックボーンルータは、（*、G）とに加えて、受信機（及び過去の受信機、PIMプルーンの場合）とRPとの間の（S、G、RPT）状態で終わるかもしれない（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のアドレスがマルチキャストアドレスに関連付けられているように展開フェイルオーバまたは冗長性メカニズムが（例えば、BSRは、エニーキャスト-RP MSDPを有する）は、そのまま使用することができないように、RP障害管理は、より困難になります。しかし、PIMを使用したエニーキャスト-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なしで、明確ではありません。 1でもRPが存在することを保証することはできませんので、この文では、特に外国のRPで、証明することはできません。代わりに、手動でのRPとDRSを構成する（稀が、存在しない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.
ジェロームデュランは、このメモの初期バージョンについてコメントしました。マーシャルユーバンクスは短いPLEN値に関する問題を指摘しました。トムPusateriは、以前のSPT-参加アプローチの問題点を指摘しました。ラミLehtonenのは、SA-状態の範囲の問題を指摘し、大規模な論評を提供します。 Nidhi Bhaskarは、ドキュメントに徹底的な見直しを行いました。 Toerlessエッカート、ヒュー・ホルブルック、とDaveマイヤーは非常に広範なフィードバックを提供しました。特に、Pavlin Radoslavov、ディノファリナッチ、Nidhi Bhaskar、そしてジェロームデュランは、最後の呼び出し中およびWG後に良好なコメントを提供しました。印オールマン、ビルフェナー、トーマスNarten氏、およびアレックスジニンは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を露出させることができます。事業者は、これらのルータの確保に特別な注意を払うことをお勧めします。運命共有プロパティの度につながるのRPを配置するためのフェイルオーバーとセクション6.2に関する考慮事項については、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はPIM-SMは、任意のDRから/プルーン/ 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.
また、実装はまた、マルチキャストプレフィックスを使用することを許可された手動設定を可能にすべきです。これは、指定されたグループへのRPの使用を制限するために使用することができます。いくつかのケースでは、ユニキャストアドレスがグループに送信したり、参加を許可されている（RPで）制限することができることが望ましいです。 （ただし、/プルーンのメッセージを参加ノートは、まだネットワークの状態を残して、および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.
明示的に（例えば、BSRを介して、または手動で）任意の広告を必要としないRPになってきて、そうするように構成されていない限り、この仕様をサポートするルータがRPとして機能しないことをお勧めします。それ以外の場合は、任意のルータは、潜在的にRPになる可能性があり（そのように悪用されます）。さらに、マルチキャストグループまたはグループが-提供される範囲は、不本意に使用されているからそれらを保護するために、明示的のRPで設定する必要があるかもしれません。グループを使用することが許可された人へのように、その複数の特定のコントロール（例えば、「インサイダー-作成しなければなりません」または「招待・アウトサイダー」のモデル）注意このメモの範囲を超えています。
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].
より広範な説明およびドメイン間マルチキャストルーティングモデルの比較（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.デアリング、 "インターネットプロトコルバージョン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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]ハーバーマン、B.とD.ターラー、 "ユニキャストプレフィックスベースのIPv6マルチキャストアドレス"、RFC 3306、2002年8月。
[ANYCAST] Hagino, J. and K. Ettikan, "An analysis of IPv6 anycast", Work in Progress, June 2003.
[ANYCAST]萩野、J.及びK. Ettikan "の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]キム、D.、マイヤー、D.、キルマー、H.、およびD.ファリナッチ、 "プロトコル独立マルチキャスト（PIM）とMulticast Source Discovery Protocol（MSDP）を使用して、エニーキャストRendevousポイント（RP）機構"、RFC 3446 、2003年1月。
[ANYPIMRP] Farinacci, D. and Y. Cai, "Anycast-RP using PIM", Work in Progress, June 2004.
[ANYPIMRP]ファリナッチ、D.およびY.カイ、 "PIMを使用したエニーキャスト-RP"、進歩、2004年6月での作業。
[BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress, July 2004.
[BSR]フェナー、B.、ら、 "PIMスパースモードのためのブートストラップルータ（BSR）メカニズム"、進歩、2004年7月ワーク。
[MSDP] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[MSDP]フェナー、B.とD.マイヤー、 "は、Multicast Source Discovery Protocol（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.マイヤー、 "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]フェナー、B.ら、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、進歩、2004年7月ワーク。
[SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", Work in Progress, September 2004.
[SSM]ホルブルック、H.ら、「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を指定します。最上位ビットを使用する場合/場合、一つは組込み-RPに適用する方法FFF0 :: / 12を指定する必要があります。例えば、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"）を用いての、一つは（ "：8000 :: / 17 FF3x"）の代わりに、左端の予約ビットを使用している可能性があります。
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
ペッカ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ジョンズホプキンスロードローレル、MD 20723から6099米
Phone: +1 443 778 1319 EMail: brian@innovationslab.net
電話：+1 443 778 1319 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。