Network Working Group D. Farinacci
Request for Comments: 4610 Y. Cai
Category: Standards Track Cisco Systems
August 2006
Anycast-RP Using Protocol Independent Multicast (PIM)
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only. Other multicast protocols (such as Multicast Source Discovery Protocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP.
この仕様は、エニーキャスト-RP（ランデブーポイント）のみでProtocol Independent Multicast（PIM）を実行するドメイン内で使用することができます。 （この問題を解決するために、伝統的に使用されているは、Multicast Source Discovery Protocol（MSDP）、など）他のマルチキャストプロトコルは、エニーキャスト-RPをサポートする必要はありません。
Anycast-RP as described in [I1] is a mechanism that ISP-based backbones have used to get fast convergence when a PIM Rendezvous Point (RP) router fails. To allow receivers and sources to Rendezvous to the closest RP, the packets from a source need to get to all RPs to find joined receivers.
エニーキャスト-RP [I1]に記載されているようにISPベースのバックボーンはPIMランデブーポイント（RP）ルータが失敗した場合に高速収束を取得するために使用した機構です。レシーバおよびソースが最も近いRPにランデブーすることを可能にするには、ソースからのパケットが参加しましたレシーバを見つけるために、すべてのRPに取得する必要があります。
This notion of receivers finding sources is the fundamental problem of source discovery that MSDP was intended to solve. However, if one would like to retain the Anycast-RP benefits from [I1] with less protocol machinery, removing MSDP from the solution space is an option.
情報源を見つける受信機のこの概念は、MSDPを解決するために意図されたソース発見の根本的な問題です。しかし、人は少ないのプロトコル機械で[I1]からエニーキャストRP-の利点を保持したい場合は、解空間からMSDPを除去することはオプションです。
This memo extends the Register mechanism in PIM so Anycast-RP functionality can be retained without using MSDP.
エニーキャストRP-機能はMSDPを使用せずに保持することができますので、このメモは、PIMに登録するメカニズムを拡張します。
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 [N2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[N2]に記載されているように解釈されます。
o A unicast IP address is chosen to use as the RP address. This address is statically configured, or distributed using a dynamic protocol, to all PIM routers throughout the domain.
OユニキャストIPアドレスをRPアドレスとして使用するために選択されます。このアドレスは静的に構成、またはドメイン全体のすべてのPIMルータに、ダイナミックプロトコルを使用して分配されます。
o A set of routers in the domain is chosen to act as RPs for this RP address. These routers are called the Anycast-RP set.
Oドメイン内のルータのセットが、このRPアドレスのRPとして動作するように選択されます。これらのルータはエニーキャスト-RPセットと呼ばれています。
o Each router in the Anycast-RP set is configured with a loopback interface using the RP address.
Oエニーキャスト-RPセット内の各ルータは、RPアドレスを使用して、ループバックインタフェースで構成されています。
o Each router in the Anycast-RP set also needs a separate IP address, to be used for communication between the RPs.
Oエニーキャスト-RPセット内の各ルータはまた、RP間の通信に使用されるように、別個のIPアドレスを必要とします。
o The RP address, or a prefix that covers the RP address, is injected into the unicast routing system inside of the domain.
RPアドレス、またはRPアドレスをカバーするプレフィックスO、ドメインの内部ユニキャストルーティングシステムに注入されます。
o Each router in the Anycast-RP set is configured with the addresses of all other routers in the Anycast-RP set. This must be consistently configured in all RPs in the set.
O Anycast-RPセットに属する各ルータはエニーキャスト-RPセット内の他のすべてのルータのアドレスが設定されています。これは、一貫してセット内のすべてのRPに設定する必要があります。
The following diagram illustrates a domain using 3 RPs where receivers are joining to the closest RP according to where unicast routing metrics take them and 2 sources sending packets to their respective RPs.
次の図は、受信機がユニキャストルーティングメトリックは、それらを取ると2つのソースは、それぞれのRPにパケットを送信する場合に応じて、最も近いRPに接合されている3つのRPを使用してドメインを示します。
The rules described in this section do not override the rules in [N1]. They are intended to blend with the rules in [N1]. If there is any question on the interpretation, precedent is given to [N1].
このセクションで説明するルールは[N1]のルールを上書きしません。これらは[N1]の規則とブレンドすることを意図しています。解釈上の任意の質問がある場合は、先例は[N1]に与えられています。
S1-----RP1 RP2 RP3------S3
/ \ |
/ \ |
R1 R1' R2
Assume the above scenario is completely connected where R1, R1', and R2 are receivers for a group, and S1 and S3 send to that group. Assume RP1, RP2, and RP3 are all assigned the same IP address, which is used as the Anycast-RP address (let's say the IP address is RPA).
R1、R1' およびR2は、グループのための受信機であり、S1及びS3がそのグループに送信する場合、上記のシナリオが完全に接続されていると仮定する。 RP1、RP2、およびRP3は、すべてのAnycast-RPアドレス（のは、IPアドレスはRPAであるとしましょう）として使用されているのと同じIPアドレスが割り当てられていると仮定します。
Note, the address used for the RP address in the domain (the Anycast-RP address) needs to be different than the addresses used by the Anycast-RP routers to communicate with each other.
メモ、ドメイン内のRPアドレス（エニーキャスト-RPアドレス）のために使用されるアドレスは、互いに通信するエニーキャスト-RPルータによって使用されるアドレスとは異なることが必要です。
The following procedure is used when S1 starts sourcing traffic:
S1は、ソーシングトラフィックを開始したときに、次の手順が使用されます。
o S1 sends a multicast packet.
O S1は、マルチキャストパケットを送信します。
o The designated router (DR) directly attached to S1 will form a PIM Register message to send to the Anycast-RP address (RPA). The unicast routing system will deliver the PIM Register message to the nearest RP, in this case RP1.
oを直接S1に取り付けられた指定ルータ（DR）は、エニーキャスト-RPアドレス（RPA）に送信するPIM Registerメッセージを形成します。ユニキャストルーティングシステムは、この場合はRP1に、最も近いRPにPIM Registerメッセージを配信します。
o RP1 will receive the PIM Register message, decapsulate it, and send the packet down the shared-tree to get the packet to receivers R1 and R1'.
OのRP1は、PIM Registerメッセージを受け取り、それをデカプセル化し、受信機R1およびR1' にパケットを取得するには、共有ツリーの下のパケットを送信します。
o RP1 is configured with RP2 and RP3's IP address. Since the Register message did not come from one of the RPs in the anycast-RP set, RP1 assumes the packet came from a DR. If the Register is not addressed to the Anycast-RP address, an error has occurred and it should be rate-limited logged.
OのRP1はRP2とRP3のIPアドレスが設定されています。 Registerメッセージをエニーキャスト-RPセット内のRPのいずれかから来ていないので、RP1は、パケットがDRから来前提としています。登録は、エニーキャストRP-アドレス宛でない場合は、エラーが発生し、それがレート制限ログインする必要があります。
o RP1 will then send a copy of the Register message from S1's DR to both RP2 and RP3. RP1 will use its own IP address as the source address for the PIM Register message.
OのRP1は、RP2とRP3の両方にS1のDRからのRegisterメッセージのコピーを送信します。 RP1は、PIM Registerメッセージの送信元アドレスとして自身のIPアドレスを使用します。
o RP1 MAY join back to the source-tree by triggering a (S1,G) Join message toward S1. However, RP1 MUST create (S1,G) state.
入出力RP1は（S1、G）S1に向けてメッセージを参加をトリガすることによってバックソースツリーに参加することができます。しかし、RP1は、（S1、G）ステートを作成する必要があります。
o RP1 sends a Register-Stop back to the DR. If, for some reason, the Register messages to RP2 and RP3 are lost, then when the Register suppression timer expires in the DR, it will resend Registers to allow another chance for all RPs in the Anycast-RP set to obtain the (S,G) state.
O RP1はバックDRへの登録が-STOP送信します。 、何らかの理由で、RP2とRP3への登録メッセージが失われた場合の登録抑制タイマーがDRで期限が切れると、それから、それは（Sを得るために、Anycast-RPセット内のすべてのRPのために別の機会を許可するレジスタを再送信します、 G）状態。
o RP2 receives the Register message from RP1, decapsulates it, and also sends the packet down the shared-tree to get the packet to receiver R2.
OのRP2は、それをデカプセル化し、RP1から登録メッセージを受信し、また受信機R2にパケットを取得するために、共有ツリーダウンパケットを送信します。
o RP2 sends a Register-Stop back to RP1. RP2 MAY wait to send the Register-Stop if it decides to join the source-tree. RP2 should wait until it has received data from the source on the source-tree before sending the Register-Stop. If RP2 decides to wait, the Register-Stop will be sent when the next Register is received. If RP2 decides not to wait, the Register-Stop is sent now.
O RP2はRP1に戻って登録を-STOP送信します。それは、ソースツリーに参加することを決定した場合RP2は登録ストップを送信するために待つことができます。それは登録ストップを送信する前に、ソースツリー上のソースからのデータを受信するまでRP2は待たなければなりません。 RP2が待機することを決定した場合、次の登録が受信されると、登録ストップが送信されます。 RP2が待機しないことを決定した場合、登録・停止は、現在送信されます。
o RP2 MAY join back to the source-tree by triggering a (S1,G) Join message toward S1. However, RP2 MUST create (S1,G) state.
入出力RP2は、（S1、G）S1に向けてメッセージを参加をトリガすることによってバックソースツリーに参加することができます。しかし、RP2は、（S1、G）ステートを作成する必要があります。
o RP3 receives the Register message from RP1, decapsulates it, but since there are no receivers joined for the group, it can discard the packet.
O RP3は、RP1から登録メッセージを受信し、それをデカプセル化し、ない受信機がグループのためにそこに接合されていないので、そのパケットを廃棄することができます。
o RP3 sends a Register-Stop back to RP1.
O RP3はRP1に戻って登録を-STOP送信します。
o RP3 creates (S1,G) state so when a receiver joins after S1 starts sending, RP3 can join quickly to the source-tree for S1.
O RP3は、（S1、G）ステートを作成S1が送信を開始した後に受信機が参加するときに、RP3は、S1のソースツリーに迅速に参加することができます。
o RP1 processes the Register-Stop from each of RP2 and RP3. There is no specific action taken when processing Register-Stop messages.
O RP1はRP2とRP3のそれぞれから登録・停止を処理します。登録・停止のメッセージを処理する際に撮影した具体的なアクションはありません。
The procedure for S3 sending follows the same as above but it is RP3 that sends a copy of the Register originated by S3's DR to RP1 and RP2. Therefore, this example shows how sources anywhere in the domain, associated with different RPs, can reach all receivers, also associated with different RPs, in the same domain.
S3は、送信するための手順は、上記と同様に従いますが、それは登録のコピーがRP1とRP2にS3のDRによって発信送信RP3です。したがって、この例では、どのソースがどこドメインで示し、異なるのRPに関連付けられ、また、同じドメイン内の別のRPに関連付けられたすべての受信機に到達することができます。
o An RP will send a copy of a Register only if the Register is received from an IP address not in the Anycast-RP list (i.e., the Register came from a DR and not another RP). An implementation MUST safeguard against inconsistently configured Anycast-RP sets in each RP by copying the Time to Live (TTL) from a Register message to the Register messages it copies and sends to other RPs.
登録がないエニーキャストRP-リスト内のIPアドレスから受信された場合にのみ、O RPレジスタのコピーを送信します（すなわち、レジスタDRから来ていない別のRP）。実装は、それをコピーRegisterメッセージにRegisterメッセージから生存時間（TTL）をコピーすることによって、各RPにおける矛盾構成されたエニーキャスト-RPセットに対して保護し、他のRPに送信しなければなりません。
o Each DR that PIM registers for a source will send the message to the Anycast-RP address (which results in the packet getting to the closest physical RP). Therefore, there are no changes to the DR logic.
各DR Oソース用のPIMレジスタは（最も近い物理RPになってパケットをもたらす）エニーキャスト-RPアドレスにメッセージを送信すること。したがって、DRロジックへの変更はありません。
o Packets flow to all receivers no matter what RP they have joined to.
Oパケットは、彼らが参加しているものをRPに関係なくすべての受信機に流れます。
o The source gets Registered to a single RP by the DR. It's the responsibility of the RP that receives the PIM Register messages from the DR (the closest RP to the DR based on routing metrics) to get the packet to all other RPs in the Anycast-RP set.
Oソースは、DRによって単一RPに登録されます。これは、エニーキャスト-RPセット内の他のすべてのRPにパケットを取得するために、DR（ルーティングメトリックに基づいてDRに最も近いRP）からPIM Registerメッセージを受信RPの責任です。
o Logic is changed only in the RPs. The logic change is for sending copies of Register messages. Register-Stop processing is unchanged. However, an implementation MAY suppress sending Register-Stop messages in response to a Register received from an RP.
OロジックだけのRPに変更されます。論理変化は、Registerメッセージのコピーを送信するためです。登録・停止処理が変更されません。しかし、実装は、RPから受信登録に応じて、登録・停止メッセージの送信を抑制することができます。
o The rate-limiting of Register and Register-Stop messages are done end-to-end. That is from DR -> RP1 -> {RP2 and RP3}. There is no need for specific rate-limiting logic between the RPs.
Oレート制限レジスタのとRegister停止メッセージは、エンドツーエンドを行っています。 > {RP2及びRP3} - > RP1 - つまりDRからのものです。 RP間の特定の速度制限ロジックは必要ありません。
o When topology changes occur, the existing source-tree adjusts as it does today according to [N1]. The existing shared-trees, as well, adjust as they do today according to [N1].
トポロジの変更が発生した場合、それは[N1]によると、今日そうであるよう、O、既存のソースツリーを調整します。彼らは[N1]によると、今日がそうであるように、既存の共有ツリーは、同様に、調整します。
o Physical RP changes are as fast as unicast route convergence, retaining the benefit of [I1].
O物理RPの変化は[I1]の利点を保持し、ユニキャスト経路収束ほど高速です。
o An RP that doesn't support this specification can be mixed with RPs that do support this specification. However, the non-supporter RP should not have sources registering to it, but may have receivers joined to it.
Oこの仕様をサポートしていませんRPは、この仕様をサポートしてのRPと混合することができます。しかし、非サポーターRPは、それへの登録情報源を持っていないはずですが、受信機がそれに参加していることがあります。
o If Null Registers are sent (Registers with an IP header and no IP payload), they MUST be replicated to all of the RPs in the Anycast-RP set so that source state remains alive for active sources.
ヌルレジスタは（IPヘッダなしIPペイロードとレジスタ）送信された場合、ソースの状態がアクティブソースの生きているままであるようにO、彼らは、エニーキャスト-RPセット内のRPの全てに複製されなければなりません。
o The number of RPs in the Anycast-RP set should remain small so the amount of non-native replication is kept to a minimum.
非ネイティブのレプリケーションの量が最小限に抑えられるように、Oエニーキャスト-RPセット内のRPの数が少ないままにしてください。
o Since the RP, who receives a Register from the DR, will send copies of the Register to the other RPs at the same time it sends a Register-Stop to the DR, there could be packet loss and lost state in the other RPs until the time the DR sends Register messages again.
O DRからの登録を受けたRPは、それがDRへの登録は、ストップ送信し、同時に他のRPへの登録のコピーをお送りしますので、まで他のRPにパケットロスや失われた状態があるかもしれません時間DRは再びRegisterメッセージを送信します。
The objective of this Anycast-PIM proposal is to remove the dependence on using MSDP. This can be achieved by removing MSDP peering between the Anycast-RPs. However, to advertise internal sources to routers outside of a PIM routing domain and to learn external sources from other routing domains, MSDP may still be required.
このエニーキャスト-PIM提案の目的は、MSDPを使用しての依存を削除することです。これは、エニーキャスト-RP間MSDPピアリングを除去することによって達成することができます。しかし、PIMルーティングドメインの外のルータに内部ソースをアドバタイズすると、他のルーティングドメインからの外部ソースを学ぶために、MSDPはまだ必要な場合があります。
In this capacity, when there are internal sources that need to be advertised externally, an Anycast-RP that receives a Register message, either from a DR or an Anycast-RP, should process it as described in this specification as well as how to process a Register message as described in [N1]. That means a Source-Active (SA) for the same internal source could be originated by multiple Anycast-RPs doing the MSDP peering. There is nothing inherently wrong with this other than that the source is being advertised into the MSDP infrastructure from multiple places from the source domain. However, if this is not desirable, configuration of one or more (rather than all) Anycast-RP MSDP routers would allow only those routers to originate SAs for the internal source. And in some situations, there is a good possibility not all Anycast-RPs in the set will have MSDP peering sessions so this issue can be mitigated to a certain extent.
処理方法、ならびに本明細書に記載されているように、この容量では、ときに外部アドバタイズする必要が内部ソースがあり、DRまたはエニーキャスト-RPのいずれかから、登録メッセージを受信するエニーキャスト-RPは、それを処理しなければなりません[N1]に記載されているようにRegisterメッセージ。それは意味のsource-active複数のエニーキャスト-RPがMSDPピアリングを行うことによって発信することができ、同じ内部ソース用（SA）。ソースはソースドメインからの複数の場所からMSDPインフラストラクチャに公示されていることよりも、この他のと本質的には何も問題はありません。これが望ましくない場合は、（むしろ全てより）は、1つ以上の構成エニーキャスト-RP MSDPルータは、それらのルータは、内部ソースのSAを発信することを可能にします。そして、いくつかの状況では、この問題をある程度緩和することができるので、セットでないすべてのエニーキャスト-RPがMSDPピアリングセッションを持っています良い可能性があります。
From an Anycast-RP perspective, a source should be considered internal to a domain when it is discovered by an Anycast-RP through a received Register message, regardless of whether the Register message was sent by a DR, another Anycast-RP member, or the router itself.
エニーキャスト-RPの観点から、ソースは、それが関係なく、登録メッセージがDR、別のエニーキャスト-RP部材、またはによって送信されたかどうか、受信した登録メッセージによりエニーキャスト-RPによって発見されたドメインに内部考慮されるべきですルータ自体。
For learning sources external to a domain, the MSDP SA messages could arrive at multiple MSDP-peering Anycast-RPs. The rules for processing an SA, according to [I1], should be followed. That is, if G is joined in the domain, an (S,G) join is sent towards the source. And if data accompanies the SA, each Anycast-PIM RP doing MSDP peering will forward the data down each of its respective shared-trees.
ドメインへの外部ソースを学習するために、MSDP SAメッセージは、複数のMSDPピアリングのAnycast-RPの到着でした。 SAを処理するための規則は、[I1]によれば、従うべきです。つまりGがドメインに参加している場合、（S、G）が参加元に向けて送信されます。データはSAを伴う場合と、MSDPピアリングを行う各エニーキャスト-PIM RPは、それぞれの共有ツリーの各ダウンデータを転送します。
The above assumes each Anycast-RP has external MSDP peering connections. If this is not the case, the Anycast-PIM routers with the MSDP peering connections would follow the same procedure as if a Data-Register or Null-Register was received from either a DR or another Anycast-RP. That is, they would send Registers to the other members of the Anycast-RP set.
上記各エニーキャスト-RPは外部MSDPピアリング接続を持っている前提としています。そうでない場合は、データレジスタまたはNull-登録がDRまたは別のAnycast-RPのいずれかから受信された場合、MSDPピアリング接続でエニーキャスト-PIMルータは、同じ手順に従います。つまり、彼らは、エニーキャスト-RPセットの他のメンバーにレジスタを送信します。
If there is a mix of Anycast-RPs that do and do not have external MSDP peering connections, then the ones that do must be configured with the set that do not. So Register messages are sent only to the members of the Anycast-RP set that do not have external MSDP peering connections.
行うと、外部MSDPピアリング接続を持っていないエニーキャスト-RPSのミックスがある場合、行うものではないセットを設定する必要があります。だから、Registerメッセージは、外部MSDPピアリング接続を持っていないエニーキャスト-RPセットのメンバーに送信されます。
The amount of Register traffic generated by this MSDP-peering RP would be equal to the number of active sources external to the domain. The Source-Active state would have to be conveyed to all other RPs in the Anycast-RP set since the MSDP-peering RP would not know about the group membership associated with the other RPs. To avoid this periodic control traffic, it is recommended that all Anycast-RPs be configured with external MSDP peering sessions so no RP in the Anycast-RP set will have to originate Register messages on behalf of external sources.
このMSDPピアリング-RPによって生成された登録トラフィックの量は、ドメインへの外部アクティブなソースの数に等しくなります。ソースアクティブ状態がMSDPピアリング-RPは、他のRPに関連付けられたグループメンバーシップについて知ることはできませんので、エニーキャスト-RPセット内の他のすべてのRPに伝えなければなりません。この周期的な制御トラフィックを回避するために、すべてのAnycast-RPがそうエニーキャスト-RPセットにRPが外部ソースに代わって登録メッセージを発信しなければならないだろう、外部MSDPピアリングセッションを使用して設定することをお勧めします。
Within a routing domain, it is recommended that an Anycast-RP set defined in this specification should not be mixed with MSDP peering among the members. In some cases, the source discovery will work but it may not be obvious to the implementations which sources are local to the domain and which are not. This may affect external MSDP advertisement of internal sources.
ルーティングドメイン内で、本明細書で定義されているエニーキャスト-RPセットはMSDPがメンバー間のピアリングと混合されるべきではないことが推奨されます。いくつかのケースでは、ソースの発見は動作しますが、それはソースがドメインに対してローカルであるとされていない実装に明らかではないかもしれません。これは、内部ソースの外部MSDP広告に影響を与える可能性があります。
Having said that, this document makes no attempt to connect MSDP peering domains together by using Anycast-PIM inside a transit domain.
この文書はトランジットドメイン内のAnycast-PIMを使用して一緒にMSDPピアリングドメインに接続を試みません、と述べました。
This section describes the security consideration for Register and Register-Stop messages between Anycast-RPs. For PIM messages between DR and RP, please see [N1].
このセクションでは、登録のためのセキュリティの考慮事項について説明し、エニーキャスト-RP間のメッセージ・ストップ・レジスタ。 DRとRPの間でPIMメッセージの場合、[N1]を参照してください。
An attacker may forge a Register message using one of the addresses in the Anycast-RP list in order to achieve one or more of the following effects:
攻撃者は、以下の効果の1つ以上を達成するために、エニーキャストRP-リスト内のアドレスのいずれかを使用して登録メッセージを偽造可能性があります。
1. Overwhelm the target RP in a denial-of-service (DoS) attack 2. Inject unauthorized data to receivers served by the RP 3. Inject unauthorized data and create bogus SA entries in other PIM domains if the target RP has external MSDP peerings
1. RP 3.注入する不正なデータが提供する受信器にサービス拒否（DoS）攻撃に2を注入不正なデータをターゲットRPを圧倒し、ターゲットRPは外部MSDPピアリングを持っている場合は、他のPIMドメインに偽のSAエントリを作成します
An attacker may also forge a Register-Stop message using one of the addresses in the Anycast-RP list. However, besides denial-of-service, the effect of such an attack is limited because an RP usually ignores Register-Stop messages.
攻撃者はまた、エニーキャストRP-リスト内のアドレスのいずれかを使用して登録-Stopメッセージを偽造します。 RPは、通常の登録・停止メッセージを無視するためしかし、サービス拒否以外にも、このような攻撃の効果は限られています。
The DoS attack using forged Register or Register-Stop messages cannot be prevented. But the RP can still be protected. For example, the RP can rate-limit incoming messages. It can also choose to refuse to process any Register-Stop messages. The actual protection mechanism is implementation specific.
偽造登録または登録ストップをメッセージを使用してDoS攻撃を防ぐことはできません。しかし、RPは、まだ保護することができます。例えば、RPは、レートを制限することができ、着信メッセージを。また、任意の登録・停止のメッセージを処理することを拒否するかを選択することができます。実際の保護メカニズムは、実装固有のものです。
The distribution of unauthorized data and bogus Register messages can be prevented using the method described in section 6.3.2 of [N1]. When RP1 sends a copy of a register to RP2, RP1 acts as [N1] describes the DR and RP2 acts as [N1] describes the RP.
不正なデータと偽の登録メッセージの分布は[N1]のセクション6.3.2に記載した方法を用いて防止することができます。 RP1はRP2にレジスタのコピーを送信すると、[N1] RPを説明して、[N1] DRとRP2行為を説明して、RP1が動作します。
As described in [N1], an RP can be configured using a unique SA and Security Parameter Index (SPI) for traffic (Registers or Register-Stops) to each member of Anycast-RPs in the list, but this results in a key management problem; therefore, it may be preferable in PIM domains where all Rendezvous Points are under a single administrative control to use the same authentication algorithm parameters (including the key) for all Registered packets in a domain.
[N1]で説明したように、RPは、リスト内のエニーキャスト-RPSの各メンバーへのトラフィックのためのユニークなSAおよびセキュリティパラメータインデックス（SPI）（レジスタまたは登録-停止）を使用して構成され、これは、鍵管理につながることができます問題;従って、それはすべてのランデブーポイントがドメインに登録されたすべてのパケットの（キーを含む）同じ認証アルゴリズムパラメータを使用する単一の管理制御下にあるPIMドメインに好ましいかもしれません。
The authors prototyped this document in the cisco IOS and Procket implementations, respectively.
著者は、それぞれのCisco IOSおよびProcketの実装でこの文書を試作しました。
The authors would like to thank John Zwiebel for doing interoperability testing of the two prototype implementations.
著者は、2つのプロトタイプの実装の相互運用性テストを行うためのジョンZwiebelに感謝したいと思います。
The authors would like to thank Thomas Morin from France Telecom for having an extensive discussion on Multicast the Registers to an SSM-based full mesh among the Anycast-RP set. This idea may come in a subsequent document.
著者は、エニーキャスト-RPセットの中SSMベースのフルメッシュにマルチキャストレジスタの広範な議論を持つため、フランステレコムからトーマス・モランに感謝したいと思います。このアイデアは、後続の文書に来るかもしれません。
And finally, the authors would like to thank the following for their comments on earlier drafts:
そして最後に、著者は、以前のドラフトでの彼らのコメントのために以下のことを感謝したいと思います：
Greg Shepherd (Procket Networks (now Cisco Systems)) Lenny Giuliano (Juniper Networks) Prashant Jhingran (Huawei Technologies) Pekka Savola (CSC/FUNET) Bill Fenner (AT&T) James Lingard (Data Connection) Amit Shukla (Juniper Networks) Tom Pusateri (Juniper Networks)
グレッグ・シェパード（Procket Networksの（今シスコシステムズ））レニージュリアーノ（ジュニパーネットワークス）のPrashant Jhingran（華為技術）ペッカSavola（CSC / FUNET）ビルフェナー（AT＆T）ジェームズ・リンガード（データ接続）アミット・シュクラ（ジュニパーネットワークス）トム・Pusateri（ジュニパーネットワークス）
[N1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[N1]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
[N2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N2]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[I1] 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.
、RFC 3446 [I1]キム、D.、マイヤー、D.、キルマー、H.、およびD.ファリナッチ、 "プロトコル独立マルチキャスト（PIM）とMulticast Source Discovery Protocol（MSDP）を使用して、エニーキャストRendevousポイント（RP）メカニズム" 、2003年1月。
Appendix A: Possible Configuration Language
付録A：可能な構成言語
A possible set of commands to be used could be:
使用するコマンドの可能なセットは次のようになります。
ip pim anycast-rp <anycast-rp-addr> <rp-addr>
IP PIMエニーキャストRP-<エニーキャスト-RP-addrに> <RP-addrに>
Where:
どこ：
<anycast-rp-addr> describes the Anycast-RP set for the RP that is assigned to the group range. This IP address is the address that first-hop and last-hop PIM routers use to register and join to.
<エニーキャスト-RP-addrが>グループ範囲に割り当てられているRPのためのAnycast-RPのセットを記述する。このIPアドレスは、最初のホップと最後のホップPIMルータは登録しに参加するために使用するアドレスです。
<rp-addr> describes the IP address where Register messages copies are sent to. This IP address is any address assigned to the RP router not including the <anycast-rp-addr>.
<RP-addrには> Registerメッセージのコピーがに送信されたIPアドレスを記述します。このIPアドレスは、<エニーキャスト-RP-addrに>含まないRPルータに割り当てられたアドレスです。
Example:
例：
From the illustration above, the configuration commands would be:
上の図から、設定コマンドは次のようになります。
ip pim anycast-rp RPA RP1 ip pim anycast-rp RPA RP2 ip pim anycast-rp RPA RP3
IP PIMエニーキャストRP-RPA RP1のIP PIMエニーキャストRP-RPA RP2のIP PIMエニーキャストRP-のRPAのRP3
Comment:
コメント：
It may be useful to include the local router IP address in the command set so the above lines can be cut-and-pasted or scripted into all the RPs in the Anycast-RP set.
設定コマンドでローカルルータのIPアドレスを含めることが有用であるかもしれないので、上記ラインがカット・アンド・ペーストし又はエニーキャスト-RPセット内のすべてのRPにスクリプト化することができます。
But the implementation would have to be aware of its own address and not inadvertently send a Register to itself.
しかし、実装は、自分のアドレスを意識する必要があり、うっかり自分自身への登録を送信しません。
Authors' Addresses
著者のアドレス
Dino Farinacci Cisco Systems
ディノファリナッチシスコシステムズ
EMail: dino@cisco.com
メールアドレス：dino@cisco.com
Yiqun Cai Cisco Systems
Y IグループCAIシスコシステムズ
EMail: ycai@cisco.com
メールアドレス：ycai@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。