Network Working Group N. Bhaskar
Request for Comments: 5059 Arastra
Obsoletes: 2362 A. Gall
Updates: 4601 SWITCH
Category: Standards Track J. Lingard
Arastra
S. Venaas
UNINETT
January 2008
Bootstrap Router (BSR) Mechanism
for 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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure.
この文書では、特定のマルチキャストグループに送信元を検出するための受信機のための手段として、ランデブーポイントの概念を使用してPIM（プロトコル独立マルチキャスト）家族の中でマルチキャストルーティングプロトコルのクラスのためのブートストラップルータ（BSR）メカニズムを指定します。 BSRは、マルチキャストルータが機能するために必要なグループに-RPマッピングのセットを学ぶことができる1つの方法です。メカニズムは、主に自己設定、ダイナミック、およびルータの故障に対してロバストです。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Protocol Overview ..........................................5
1.3. Administrative Scoping and BSR .............................6
2. BSR State and Timers ............................................8
3. Bootstrap Router Election and RP-Set Distribution ...............9
3.1. Bootstrap Router Election ..................................9
3.1.1. Per-Scope-Zone Candidate-BSR State Machine .........10
3.1.2. Per-Scope-Zone State Machine for
Non-Candidate-BSR Routers ..........................11
3.1.3. Bootstrap Message Processing Checks ................13
3.1.4. State Machine Transition Events ....................14
3.1.5. State Machine Actions ..............................15
3.2. Sending Candidate-RP-Advertisement Messages ...............17
3.3. Creating the RP-Set at the BSR ............................18
3.4. Forwarding Bootstrap Messages .............................21
3.5. Bootstrap Messages to New and Rebooting Routers ...........22
3.5.1. No-Forward Bootstrap Messages ......................23
3.5.2. Unicasting Bootstrap Messages ......................23
3.6. Receiving and Using the RP-Set ............................23
4. Message Formats ................................................24
4.1. Bootstrap Message Format ..................................26
4.1.1. Semantic Fragmentation of BSMs .....................30
4.2. Candidate-RP-Advertisement Message Format .................31
5. Timers and Timer Values ........................................33
6. Security Considerations ........................................36
6.1. Possible Threats ..........................................36
6.2. Limiting Third-Party DoS Attacks ..........................36
6.3. Bootstrap Message Security ................................37
6.3.1. Unicast Bootstrap Messages .........................37
6.3.2. Multi-Access Subnets ...............................38
6.4. Candidate-RP-Advertisement Message Security ...............38
6.4.1. Non-Cryptographic Security of C-RP-Adv Messages ....38
6.4.2. Cryptographic Security of C-RP-Adv Messages ........39
6.5. Denial of Service using IPsec .............................39
7. Contributors ...................................................40
8. Acknowledgments ................................................40
9. Normative References ...........................................40
10. Informative References ........................................41
This document assumes some familiarity with the concepts of Protocol Independent Multicast - Sparse Mode (PIM-SM) [1] and Bidirectional Protocol Independent Multicast (BIDIR-PIM) [2], as well as with Administratively Scoped IP Multicast [3] and the IPv6 Scoped Address Architecture [4].
この文書では、プロトコル独立マルチキャストの概念をある程度の知識を前提としてい - スパースモード（PIM-SM）を[1]と[2]、ならびに行政スコープIPマルチキャスト[3]との双方向プロトコル独立マルチキャスト（BIDIR-PIM） IPv6のスコープは、アーキテクチャをアドレス[4]。
For correct operation, every multicast router within a PIM domain must be able to map a particular multicast group address to the same Rendezvous Point (RP). The PIM specifications do not mandate the use of a single mechanism to provide routers with the information to perform this group-to-RP mapping.
正しい動作のためには、PIMドメイン内のすべてのマルチキャストルータは、同じランデブーポイント（RP）に、特定のマルチキャストグループアドレスをマッピングすることができなければなりません。 PIMの仕様は、このグループに-RPマッピングを実行するための情報を、ルータを提供するために、単一のメカニズムの使用を強制しません。
This document describes the PIM Bootstrap Router (BSR) mechanism. BSR is one way that a multicast router can learn the information required to perform the group-to-RP mapping. The mechanism is dynamic, largely self-configuring, and robust to router failure.
この文書では、PIMブートストラップルータ（BSR）メカニズムを説明しています。 BSRは、マルチキャストルータがグループ-RPマッピングを実行するために必要な情報を学ぶことができる1つの方法です。メカニズムは、主に自己設定、ダイナミック、およびルータの故障に対してロバストです。
BSR was first defined in RFC 2362 [7] as part of the original PIM-SM specification, which has been obsoleted by RFC 4601 [1]. This document provides an updated specification of the BSR mechanism from RFC 2362, and also extends it to cope with administratively scoped region boundaries and different flavors of routing protocols.
BSRは、最初の[7] RFC 4601によって廃止された元のPIM-SM仕様の一部として、RFC 2362で定義された[1]。この文書は、RFC 2362からBSR機構の更新された仕様を提供し、また、管理スコープ領域の境界とルーティングプロトコルの異なる味に対応するように延びています。
Throughout the document, any reference to the PIM protocol family is restricted to the subset of RP-based protocols, namely PIM-SM and BIDIR-PIM, unless stated otherwise.
特に明記しない限り、明細書を通して、PIMプロトコルファミリへの参照は、RPベースのプロトコル、すなわち、PIM-SMおよびBIDIR-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 RFC 2119 [6].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[6]。
A PIM domain is a contiguous set of routers that all implement PIM and are configured to operate within a common boundary defined by PIM Multicast Border Routers (PMBRs). PMBRs connect each PIM domain to the rest of the Internet.
PIMドメインは、すべてのPIMを実装し、PIMマルチキャスト境界ルータ（PMBRs）によって定義された共通の境界内で動作するように構成されているルータの連続集合です。 PMBRsは、インターネットの残りの部分に各PIMドメインに接続します。
Every PIM multicast group needs to be associated with the IP address of a Rendezvous Point (RP). This address is used as the root of a group-specific distribution tree whose branches extend to all nodes in the domain that want to receive traffic sent to the group. Senders inject packets into the tree in such a manner that they reach all connected receivers. How this is done and how the packets are forwarded along the distribution tree depends on the particular routing protocol.
すべてのPIMマルチキャストグループは、ランデブーポイント（RP）のIPアドレスに関連付けする必要があります。このアドレスは、支店のグループに送信されたトラフィックを受信したいドメイン内のすべてのノードに及ぶグループ固有の配布ツリーのルートとして使用されています。送信者は、彼らが接続されているすべての受信機に届くようにツリーへパケットを注入します。どのようにこれが行われるとどのように分布ツリーは、特定のルーティングプロトコルに依存沿ってパケットが転送されます。
For all senders to reach all receivers, it is crucial that all routers in the domain use the same mappings of group addresses to RP addresses.
すべての送信者は、すべての受信機に到達するためには、ドメイン内のすべてのルータがRPアドレスにグループアドレスの同じマッピングを使用することが重要です。
An exception to the above is where a PIM domain has been broken up into multiple administrative scope regions. These are regions where a border has been configured so that a set of multicast groups will not be forwarded across that border. In this case, all PIM routers within the same scope region must map a particular scoped group to the same RP within that region.
PIMドメインが複数の管理範囲の領域に分割されている場合、上記の例外があります。これらは、マルチキャストグループのセットは、その国境を越えて転送されないように境界が設定されている領域です。この場合には、同じ範囲領域内のすべてのPIMルータは、その領域内の同じRPに特定のスコープグループをマップする必要があります。
In order to determine the RP for a multicast group, a PIM router maintains a collection of group-to-RP mappings, called the RP-Set. A group-to-RP mapping contains the following elements.
マルチキャストグループのRPを決定するために、PIMルータがグループに-RPマッピングのコレクションを維持し、RP-セットと呼ばれます。グループ-RPマッピングは、次の要素が含まれています。
o Multicast group range, expressed as an address and prefix length
マルチキャストグループの範囲、O、アドレスとプレフィックス長として表さ
o RP priority
OのRPの優先順位
o RP address
OのRPアドレス
o Hash mask length
Oハッシュマスク長
o SM / BIDIR flag
O SM / BIDIRフラグ
In general, the group ranges of these group-to-RP mappings may overlap in arbitrary ways; hence, a particular multicast group may be covered by multiple group-to-RP mappings. When this is the case, the router chooses only one of the RPs by applying a deterministic algorithm so that all routers in the domain make the same choice. It is important to note that this algorithm is part of the specification of the individual routing protocols (and may differ among them), not of the BSR specification. For example, PIM-SM [1] defines one such algorithm. It makes use of a hash function for the case where a group range has multiple RPs with the same priority. The hash mask length is used by this function.
一般に、これらのグループとRPのマッピングのグループの範囲は、任意の方法で重複していてもよいです。したがって、特定のマルチキャストグループは、複数のグループとRPのマッピングによって覆われていてもよいです。このような場合、ルータは、ドメイン内のすべてのルータが同じ選択をするように、決定論的アルゴリズムを適用してのRPを1つだけ選択します。このアルゴリズムは、個々のルーティングプロトコルの仕様（およびそれらの間で異なる場合があります）のではなく、BSR仕様の一部であることに注意することが重要です。例えば、PIM-SMは、[1]一つのこのようなアルゴリズムを定義します。これは、グループ範囲が同じ優先度を持つ複数のRPを有する場合のハッシュ関数を利用します。ハッシュマスク長は、この関数によって使用されます。
There are a number of ways in which such group-to-RP mappings can be established. The simplest solution is for all the routers in the domain to be statically configured with the same information. However, static configuration generally doesn't scale well, and, except when used in conjunction with Anycast-RP (see [8] and [9]), does not dynamically adapt to route around router or link failures.
このようなグループ-RPマッピングを確立することができるいくつかの方法があります。ドメイン内のすべてのルータが静的に同じ情報を設定するための最も簡単な解決策です。しかし、静的な設定は、一般的にエニーキャスト-RPと組み合わせて使用する場合を除いて、うまくスケールせず、動的ルータまたはリンク障害の周囲経路に適合しない（[8]、[9]を参照）。
The BSR mechanism provides a way in which viable group-to-RP mappings can be created and rapidly distributed to all the PIM routers in a domain. It is adaptive, in that if an RP becomes unreachable, this will be detected and the RP-Sets will be modified so that the unreachable RP is no longer used.
BSRメカニズムは、実行可能なグループに-RPマッピングが作成され、急速に、ドメイン内のすべてのPIMルータに配布することができる方法を提供します。これは、RPが到達不能になった場合、これが検出され、到達不能RPがもはや使用されているように、RP-設定が変更されないことで、適応性があります。
In this section we give an informal and non-definitive overview of the BSR mechanism. The definitive specification begins in section 2.
このセクションでは、BSRメカニズムの非公式および非決定的な概観を与えます。決定的な仕様は、セクション2で開始されます。
The general idea behind the BSR mechanism is that some of the PIM routers within a PIM domain are configured to be potential RPs for the domain. These are known as Candidate-RPs (C-RPs). A subset of the C-RPs will eventually be used as the actual RPs for the domain. In addition, some of the PIM routers in the domain are configured to be candidate bootstrap routers, or Candidate-BSRs (C-BSRs). One of these C-BSRs will be elected to be the bootstrap router (BSR) for the domain, and all the PIM routers in the domain will learn the result of this election through Bootstrap messages. The C-RPs will then report their candidacy to the elected BSR, which chooses a subset of these C-RPs and distributes corresponding group-to-RP mappings to all the routers in the domain through Bootstrap messages.
BSRメカニズムの背後にある一般的な考え方は、PIMドメイン内のPIMルータの一部はドメインの可能性のRPになるように構成されていることです。これらは、候補のRP（C-RPS）として知られています。 C-RPSのサブセットは、最終的にはドメインの実際のRPとして使用されます。また、ドメイン内のPIMルータの一部は、候補ブートストラップルータ、または候補のBSR（C-BSRの）可能に構成されています。これらのC-BSRのの一つは、ドメインのブートストラップルータ（BSR）であると選出され、ドメイン内のすべてのPIMルータがブートストラップメッセージを介してこの選挙の結果を学びます。 C-RPは、これらのC-RPSのサブセットを選択し、ブートストラップメッセージを介して、ドメイン内のすべてのルータに対応するグループ-RPマッピングを配布選出されたBSRに彼らの立候補を報告します。
In more detail, the BSR mechanism works as follows. There are four basic phases (although in practice, all phases may be occurring simultaneously):
以下のように、より詳細には、BSRメカニズムが機能します。 4つの基本フェーズ（実際には、すべての相が同時に発生してもよいが）があります。
1. BSR Election. Each Candidate-BSR originates Bootstrap messages (BSMs). Every BSM contains a BSR Priority field. Routers within the domain flood the BSMs throughout the domain. A C-BSR that hears about a higher-priority C-BSR than itself suppresses its sending of further BSMs for some period of time. The single remaining C-BSR becomes the elected BSR, and its BSMs inform all the other routers in the domain that it is the elected BSR.
1. BSR選挙。各候補-BSRはブートストラップメッセージ（のBSM）を発信します。すべてのBSMは、BSR Priorityフィールドが含まれています。ドメイン内のルータは、ドメイン全体のBSMをあふれさせます。 C-BSR自体よりも高い優先度C-BSRについて聞くそのはしばらくの間さらにのBSMの送信を抑制することができます。単一残りのC-BSRは選出されたBSRになり、そののBSMは、それが選出されたBSRであるドメイン内の他のすべてのルータに通知します。
2. C-RP Advertisement. Each Candidate-RP within a domain sends periodic Candidate-RP-Advertisement (C-RP-Adv) messages to the elected BSR. A C-RP-Adv message includes the priority of the advertising C-RP, as well as a list of group ranges for which the candidacy is advertised. In this way, the BSR learns about possible RPs that are currently up and reachable.
2. C-RP広告。ドメイン内の各候補-RPは、選出されたBSRに定期的な候補-RP-広告（C-RP-ADV）メッセージを送信します。 C-RP-ADVメッセージは、広告C-RPの優先順位、ならびに候補がアドバタイズされたグループのリスト範囲を含みます。このように、BSRは、現在起動して到達可能である可能性のRPについて学習します。
3. RP-Set Formation. The BSR selects a subset of the C-RPs that it has received C-RP-Adv messages from to form the RP-Set. In general, it should do this in such a way that the RP-Set is neither so large that all the routers in the domain cannot be informed about it, nor so small that the load is overly concentrated on some RPs. It should also attempt to produce an RP-Set that does not change frequently.
3. RP-SET形成。 BSRは、RP-セットを形成するためのC-RP-ADVメッセージを受信したことC-RPSのサブセットを選択します。一般的に、それはRP-セットどちらも、ドメイン内のすべてのルータがそれを知らさことができないほど大きく、また負荷がいくつかのRPに過度に集中しているほど小さいないようにこれを行う必要があります。また、頻繁に変更されませんRP-セットを生成しようとしなければなりません。
4. RP-Set Flooding. In future Bootstrap messages, the BSR includes the RP-Set information. Bootstrap messages are flooded through the domain, which ensures that the RP-Set rapidly reaches all the routers in the domain. BSMs are originated periodically to ensure consistency after failure restoration.
4. RP-SETフラッディング。将来のブートストラップメッセージでは、BSRはRP-の設定情報が含まれています。ブートストラップメッセージはRP-設定し、急速には、ドメイン内のすべてのルータに到達することを確実にドメインを通じてフラッディングされます。 BSMは、障害復旧後の一貫性を確保するために定期的に発信しています。
When a PIM router receives a Bootstrap message, it adds the
group-to-RP mappings contained therein to its pool of mappings
obtained from other sources (e.g., static configuration). It
calculates the final mappings of group addresses to RP addresses
from this pool according to rules specific to the particular
routing protocol and uses that information to construct multicast
distribution trees.
If a PIM domain becomes partitioned, each area separated from the old BSR will elect its own BSR, which will distribute an RP-Set containing RPs that are reachable within that partition. When the partition heals, another election will occur automatically and only one of the BSRs will continue to send out Bootstrap messages. As is expected at the time of a partition or healing, some disruption in packet delivery may occur. The duration of the disruption period will be on the order of the region's round-trip time and the BS_Timeout value.
PIMドメインがパーティション分割された場合は、古いBSRから分離された各領域は、そのパーティション内で到達可能なRPを含むRP-セットを配布する独自のBSRを、選出されます。ときにパーティションが治癒する、別の選挙が自動的に行われますと、一つだけのBSRのブートストラップメッセージを送信し続けます。パーティションまたは治癒の際に予想されるように、パケット配信の一部の破壊が発生する可能性があります。中断期間の長さは、地域のラウンドトリップ時間の順とBS_Timeout値になります。
The mechanism described in the previous section does not work when the PIM domain is divided into administratively scoped regions. To handle this situation, we use the protocol modifications described in this section.
PIMドメインが管理スコープの領域に分割されている場合、前のセクションで説明した機構は働きません。このような状況に対処するために、我々は、このセクションで説明されたプロトコルの変更を使用しています。
In the remainder of this document, we will use the term scope zone, or simply zone, when we are talking about a connected region of topology of a given scope. For a more precise definition of scope zones, see [4], which emphasizes that the scope zones are administratively configured.
我々は、与えられた範囲のトポロジの接続領域について話している場合は、この文書の残りでは、我々は、用語の範囲ゾーン、または単にゾーンが使用されます。スコープゾーンのより正確な定義については、スコープゾーンが管理上設定されていることを強調した、[4]を参照。
Administrative scoping permits a PIM domain to be divided into multiple admin-scope zones. Each admin-scope zone is a convex connected set of PIM routers and is associated with a set of group addresses. The boundary of the admin-scope zone is formed by Zone Border Routers (ZBRs). ZBRs are configured not to forward traffic for any of the scoped group addresses into or out of the scoped zone. It is important to note that a given scope boundary always creates at least two scoped zones: one on either side of the boundary.
管理スコープは、複数の管理スコープのゾーンに分割されるPIMドメインを許可します。各管理スコープゾーンはPIMルータの凸接続されたセットであり、グループアドレスのセットに関連付けられています。管理スコープゾーンの境界はゾーン境界ルータ（ZBRs）によって形成されています。 ZBRsは、スコープのゾーンのうちに、またはスコープのグループアドレスのいずれかのトラフィックを転送しないように構成されています。境界の両側に1：与えられた範囲の境界が常に少なくとも二つのスコープのゾーンを作成することに注意することが重要です。
In IPv4, administratively scoped zones are associated with a set of addresses given by an address and a prefix length. In IPv6, administratively scoped zones are associated with a set of addresses given by a single scope ID value. The set of addresses corresponding to a given scope ID value is defined in [5]. For example, a scope ID of 5 maps to the 16 IPv6 address ranges ff[0-f]5::/16.
IPv4では、管理スコープゾーンは、アドレスとプレフィックス長により与えられるアドレスのセットに関連付けられています。 IPv6では、管理スコープゾーンは、単一のスコープIDの値によって指定されたアドレスのセットと関連付けられています。与えられたスコープID値に対応するアドレスのセットが[5]で定義されています。例えば、16個のIPv6アドレス範囲のFF [0-F] 5 :: / 16から5つのマップのスコープID。
There are certain topological restrictions on admin-scope zones. The scope zone border must be complete and convex. By this we mean that there must be no path from the inside to the outside of the scoped zone that does not pass through a configured scope border router, and that the multicast capable path between any arbitrary pair of multicast routers in the scope zone must remain in the zone.
管理スコープゾーンに一定の位相幾何学的制約があります。スコープゾーンの境界線は、完全かつ凸でなければなりません。これによって我々は、構成されたスコープボーダルータを通過しないスコープのゾーンの内側から外側に何らの経路があってはならないこと、および範囲ゾーン内のマルチキャストルータの任意の対の間のマルチキャスト可能なパスを維持しなければならないことを意味しますゾーン内。
Administrative scoping complicates BSR because we do not want a PIM router within the scoped zone to use an RP outside the scoped zone. Thus we need to modify the basic mechanism to ensure that this doesn't happen.
我々はスコープの範囲外のRPを使用するスコープのゾーン内のPIMルータをしたくないので、管理スコープは、BSRを複雑にします。したがって、私たちはこれが起こらないことを確実にするための基本的な仕組みを変更する必要があります。
This is done by running a separate copy of the basic BSR mechanism, as described in the previous section, within each admin-scope zone of a PIM domain. Thus a separate BSR election takes place for each admin-scope zone, a C-RP typically registers to the BSR of every admin-scope zone it is in, and every PIM router receives Bootstrap messages for every scope zone it is in. The Bootstrap messages sent by the BSR for a particular scope zone contain information about the RPs that should be used for the set of addresses associated with that scope zone.
PIMドメインの各管理スコープゾーン内で、前のセクションで説明したように、これは、基本的なBSR機構の別のコピーを実行することによって行われます。したがって、別のBSR選挙は、C-RPは、一般的に、それはであり、かつすべてのPIMルータが、それはしているすべてのスコープゾーンのブートストラップメッセージを受け取るすべての管理スコープゾーンのBSRに登録し、各管理スコープゾーンの行われます。ブートストラップ特定のスコープゾーンのBSRによって送信されたメッセージは、その有効範囲領域に関連付けられたアドレスのセットに使用されるべきでのRPに関する情報を含みます。
Bootstrap messages are marked to indicate which scope zone they belong to. Such admin-scoped Bootstrap messages are flooded in the normal way, but will not be forwarded by a ZBR across the boundary for that scope zone.
ブートストラップメッセージは、それらが属する範囲ゾーンを示す印が付けられています。このような管理スコープのブートストラップメッセージは、通常の方法でフラッディングされますが、そのスコープゾーンの境界を越えZBRによって転送されません。
For the BSR mechanism to function correctly with admin scoping, there must be at least one C-BSR within each admin-scope zone, and there must be at least one C-RP that is configured to be a C-RP for the set of group addresses associated with the scoped zone.
BSR機構が管理スコープで正しく機能するために、各管理スコープゾーン内の少なくとも1つのC-BSRが存在しなければならない、との組のためにC-RPに構成されている少なくとも1つのC-RPが存在しなければなりませんスコープゾーンに関連付けられたグループアドレス。
Even when administrative scoping is used, a copy of the BSR mechanism is still used across the entire PIM domain in order to distribute RP information for groups that are not administratively scoped. We call this copy of the mechanism non-scoped BSR. The copies of the mechanism run for each admin-scope zone are called scoped BSR.
管理スコープを使用している場合でも、BSRメカニズムのコピーがまだ管理用スコープされていないグループのためのRP情報を配信するために全体のPIMドメイン全体で使用されています。私たちは、メカニズム非スコープBSRのこのコピーを呼び出します。各管理スコープゾーンのメカニズムの実行のコピーがスコープBSRと呼ばれています。
Only the C-BSRs and the ZBRs need to be configured to know about the existence of the scope zones. Other routers, including the C-RPs, learn of their existence from Bootstrap messages.
C-BSRのとZBRsだけはスコープゾーンの存在を認識するように設定する必要があります。 C-RPを含む他のルータは、ブートストラップメッセージから自分の存在を知ります。
All PIM routers within a PIM bootstrap domain where admin-scope ranges are in use must be capable of receiving Bootstrap messages and storing the winning BSR and RP-Set for all admin-scope zones that apply. Thus, PIM routers that only implement RFC 2362 or non-scoped BSR (which only allows one BSR per domain) cannot be used within the admin-scope zones of a PIM domain.
管理スコープの範囲が使用されているPIMブートストラップドメイン内のすべてのPIMルータがブートストラップメッセージを受信し、適用するすべての管理スコープゾーンの受賞BSRとRP-セットを格納することが可能でなければなりません。したがって、唯一のRFC 2362または（専用ドメインごとにBSRを可能にする）非スコープBSRを実装PIMルータは、PIMドメインの管理スコープゾーン内で使用することができません。
A PIM router implementing BSR holds the following state.
BSRを実装するPIMルータは、次の状態を保持しています。
RP-Set
RP-SET
Per Configured or Learned Scope Zone (Z):
ごとに設定または学習範囲のゾーン（Z）：
At all routers:
すべてのルータで：
Current Bootstrap Router's IP Address
現在のブートストラップルータのIPアドレス
Current Bootstrap Router's BSR Priority
現在のブートストラップルータのBSRプライオリティ
Last BSM received from current BSR
最終BSMは、現在のBSRから受け取りました
Bootstrap Timer (BST(Z))
ブートストラップタイマー（BST（Z））
Per group-to-RP mapping (M):
グループごと-RPマッピング（M）：
Group-to-RP mapping Expiry Timer (GET(M,Z))
グループ-RPマッピングの有効期限タイマー（GET（M、Z））
At a Candidate-BSR for Z:
Zの候補-BSRで：
My state: One of "Candidate-BSR", "Pending-BSR",
"Elected-BSR"
At a router that is not a Candidate-BSR for Z:
Zの候補-BSRでないルータで：
My state: One of "Accept Any", "Accept Preferred"
私の状態：「どれを受け入れる」の一つ、「優先を受け入れます」
Scope-Zone Expiry Timer (SZT(Z))
スコープゾーンタイマー満了（PCS（Z））
At the current Bootstrap Router for Z only:
Zの現在のブートストラップルータにおいてのみ：
Per group-to-C-RP mapping (M):
グループごとツーC-RPマッピング（M）：
Group-to-C-RP mapping Expiry Timer (CGET(M,Z))
基対C-RPマッピング有効期限タイマ（CGET（M、Z））
At a C-RP only:
C-RPでのみ：
C-RP Advertisement Timer (CRPT)
C-RP広告タイマ（CRPT）
For simplicity, Bootstrap messages are used in both the BSR election and the RP-Set distribution mechanisms.
簡単にするために、ブートストラップメッセージはBSR選挙とRP-SET配布メカニズムの両方で使用されています。
Each Bootstrap message indicates the scope to which it belongs. If the Admin Scope Zone bit is set in the first group range in the Bootstrap message, the message is called a scoped BSM. If the Admin Scope Zone bit is not set in the first group range in the Bootstrap message, the message is called a non-scoped BSM.
各ブートストラップメッセージは、それが属するスコープを示します。管理スコープゾーンビットはブートストラップメッセージ内の最初のグループの範囲内に設定されている場合は、メッセージがスコープBSMと呼ばれています。管理スコープゾーンビットはブートストラップメッセージ内の最初のグループの範囲内に設定されていない場合、メッセージは非スコープBSMと呼ばれています。
In a scoped IPv4 BSM, the scope of the message is given by the first group range in the message, which can be any sub-range of 224/4. In a scoped IPv6 BSM, the scope of the message is given by the scope ID of the first group range in the message, which must have a mask length of at least 16. For example, a group range of ff05::/16 with the Admin Scope Zone bit set indicates that the Bootstrap message is for the scope with scope ID 5. If the mask length of the first group range in a scoped IPv6 BSM is less than 16, the message MUST be dropped and a warning SHOULD be logged.
スコープのIPv4 BSMにおいて、メッセージの範囲は224/4の任意の部分範囲とすることができるメッセージの最初のグループの範囲で与えられます。スコープのIPv6 BSMにおいて、メッセージの範囲は、例えば、少なくとも16のマスクの長さを有していなければならないメッセージの最初のグループの範囲のスコープID、によって与えられ、FF05 :: / 16のグループ範囲を有します管理スコープゾーンビットセットは、ブートストラップメッセージがスコープのIPv6 BSM内の最初のグループ範囲のマスク長が16未満であれば、メッセージが廃棄されなければならないと警告が記録されるべきであるスコープID 5とスコープのためのものであることを示しています。
The state machine for Bootstrap messages depends on whether or not a router has been configured to be a Candidate-BSR for a particular scope zone. The per-scope-zone state machine for a C-BSR is given below, followed by the state machine for a router that is not configured to be a C-BSR.
ブートストラップメッセージのステートマシンは、ルータが特定のスコープゾーンの候補BSRになるように構成されているかどうかに依存します。 C-BSRごとのスコープゾーンステートマシンは、C-BSRとなるように構成されていないルータの状態機械、続いて以下に与えられます。
A key part of the election mechanism is that we associate a weight with each BSR. The weight of a BSR is defined to be the concatenation in fixed-precision unsigned arithmetic of the BSR Priority field from the Bootstrap message and the IP address of the BSR from the Bootstrap message (with the BSR Priority taking the most-significant bits and the IP address taking the least-significant bits).
選挙メカニズムの重要な部分は、私たちが各BSRに重みを関連付けることです。 BSRの重量は、BSRの優先順位は、最上位ビットをとるとブートストラップメッセージからBSRの優先度フィールドの固定精度の符号なし算術演算における連結及びブートストラップメッセージからBSRのIPアドレス（あると定義され、最下位ビットを取ってIPアドレス）。
+-------------------------------------------------------------------+
| When in C-BSR state |
+----------+-----------------+-------------------+------------------+
| Event | Receive | Bootstrap | Receive Non- |
| | Preferred BSM | Timer Expires | preferred BSM |
| | | | from Elected |
| | | | BSR |
+----------+-----------------+-------------------+------------------+
| | -> C-BSR state | -> P-BSR state | -> P-BSR state |
| | Forward BSM; | Set Bootstrap | Forward BSM; |
| Action | Store RP-Set; | Timer to | Set Bootstrap |
| | Set Bootstrap | BS_Rand_Override | Timer to |
| | Timer to | | BS_Rand_Override |
| | BS_Timeout | | |
+----------+-----------------+-------------------+------------------+
+-------------------------------------------------------------------+
| When in P-BSR state |
+-----------+------------------+------------------+-----------------+
| Event | Receive | Bootstrap | Receive Non- |
| | Preferred BSM | Timer Expires | preferred BSM |
+-----------+------------------+------------------+-----------------+
| | -> C-BSR state | -> E-BSR state | -> P-BSR state |
| | Forward BSM; | Originate BSM; | Forward BSM |
| Action | Store RP-Set; | Set Bootstrap | |
| | Set Bootstrap | Timer to | |
| | Timer to | BS_Period | |
| | BS_Timeout | | |
+-----------+------------------+------------------+-----------------+
+-------------------------------------------------------------------+
| When in E-BSR state |
+-----------+------------------+------------------+-----------------+
| Event | Receive | Bootstrap | Receive Non- |
| | Preferred BSM | Timer Expires | preferred BSM |
+-----------+------------------+------------------+-----------------+
| | -> C-BSR state | -> E-BSR state | -> E-BSR state |
| | Forward BSM; | Originate BSM; | Originate BSM; |
| Action | Store RP-Set; | Set Bootstrap | Set Bootstrap |
| | Set Bootstrap | Timer to | Timer to |
| | Timer to | BS_Period | BS_Period |
| | BS_Timeout | | |
+-----------+------------------+------------------+-----------------+
A Candidate-BSR may be in one of three states for a particular scope zone:
候補BSRは、特定のスコープゾーンの3つの状態であってもよいです。
Candidate-BSR (C-BSR) The router is a candidate to be the BSR for the scope zone, but currently another router is the preferred BSR.
候補BSR（C-BSR）ルータスコープゾーンのBSRされる候補であるが、現在、別のルータが好ましいBSRあります。
Pending-BSR (P-BSR) The router is a candidate to be the BSR for the scope zone. Currently, no other router is the preferred BSR, but this router is not yet the elected BSR. This is a temporary state that prevents rapid thrashing of the choice of BSR during BSR election.
（P-BSR） - BSRペンディングルータスコープゾーンのBSRされる候補です。現在、他のルータが優先BSRありませんが、このルータはまだ選出されたBSRではありません。これは、BSR選挙時のBSRの選択の迅速なスラッシングを防ぐ一時的な状態です。
Elected-BSR (E-BSR) The router is the elected BSR for the scope zone and it must perform all the BSR functions.
選出された-BSR（E-BSR）ルータはスコープゾーンのため選出されたBSRであり、それはすべてのBSR機能を実行する必要があります。
In addition to the three states, there is one timer:
三つの状態に加えて、1つのタイマーがあります：
o The Bootstrap Timer (BST) - used to time out old bootstrap router information, and used in the election process to terminate P-BSR state.
ブートストラップタイマー（BST）O - タイムアウト古いブートストラップルータ情報に使用され、P-BSRの状態を終了するために、選挙プロセスで使用されます。
The initial state for this configured scope zone is "Pending-BSR"; the Bootstrap Timer is initialized to BS_Rand_Override. This is the case both if the router is a Candidate-BSR at startup, and if it is reconfigured to become one later.
この構成スコープゾーンの初期状態は「保留-BSR」です。ブートストラップタイマーはBS_Rand_Overrideに初期化されます。これは、両方のルータは起動時に候補BSRであり、後に一つになるように再設定されている場合場合場合です。
The following state machine is used for scope zones that are discovered by the router from bootstrap messages. A simplified state machine is used for scope zones that are explicitly configured on the router and for the global zone. The differences are listed at the end of this section.
以下のステートマシンは、ブートストラップメッセージからルータによって発見されているスコープゾーンに使用されます。簡略化され、状態マシンは、明示的にルータに、グローバルゾーンに設定されているスコープゾーンのために使用されます。違いは、このセクションの最後に記載されています。
+-------------------------------------------------------------------+
| When in NoInfo state |
+--------------+----------------------------------------------------+
| Event | Receive BSM |
+--------------+----------------------------------------------------+
| | -> AP state |
| Action | Forward BSM; Store RP-Set; |
| | Set Bootstrap Timer to BS_Timeout |
+--------------+----------------------------------------------------+
+-------------------------------------------------------------------+
| When in Accept Any state |
+-------------+---------------------------+-------------------------+
| Event | Receive BSM | Scope-Zone Expiry |
| | | Timer Expires |
+-------------+---------------------------+-------------------------+
| | -> AP state | -> NoInfo state |
| | Forward BSM; Store | Remove scope zone |
| Action | RP-Set; Set | state |
| | Bootstrap Timer to | |
| | BS_Timeout | |
+-------------+---------------------------+-------------------------+
+-------------------------------------------------------------------+
| When in Accept Preferred state |
+---------+---------------------+------------------+----------------+
| Event | Receive Preferred | Bootstrap | Receive Non- |
| | BSM | Timer Expires | preferred BSM |
+---------+---------------------+------------------+----------------+
| | -> AP state | -> AA state | -> AP state |
| | Forward BSM; Store | Refresh RP- | |
| Action | RP-Set; Set | Set; Remove | |
| | Bootstrap Timer to | BSR state; Set | |
| | BS_Timeout | SZT to | |
| | | SZ_Timeout | |
+---------+---------------------+------------------+----------------+
A router that is not a Candidate-BSR may be in one of three states:
候補BSRでないルータは、3つの状態のいずれであってもよいです。
NoInfo The router has no information about this scope zone. When in this state, no state information is held and no timers (that refer to this scope zone) run. Conceptually, the state machine is only instantiated when the router receives a scoped BSM for a scope about which it has no prior knowledge. However, because the router immediately transitions to the AA state unconditionally, the NoInfo state can be considered to be virtual in a certain sense. For this reason, it is omitted from the description in section 2.
ルータNoInfoこのスコープゾーンに関する情報がありません。この状態で場合、何ら状態情報が保持されていないと（このスコープゾーンを参照）は、タイマーラン。ルータはそれが何の予備知識を持っていないかについてのスコープのスコープBSMを受信したときに概念的には、ステートマシンのみがインスタンス化されます。ルータはただちに無条件でAAの状態に遷移するのでしかし、NoInfo状態は、ある意味で仮想であると考えることができます。このため、セクション2に記述から省略されています。
Accept Any (AA) The router does not know of an active BSR, and will accept the first Bootstrap message it sees as giving the new BSR's identity and the RP-Set.
ルータがアクティブBSRを知りませんし、それは新しいBSRのアイデンティティとRP-SETを与えるとして見て最初のブートストラップメッセージを受け入れる任意の（AA）を受け入れます。
Accept Preferred (AP) The router knows the identity of the current BSR, and is using the RP-Set provided by that BSR. Only Bootstrap messages from that BSR or from a C-BSR with higher weight than the current BSR will be accepted.
ルータは、現在のBSRのアイデンティティを知っており、そのBSRが提供するRP-セットを使用している優先（AP）を受け入れます。現在のBSRよりも高い重みを持つことBSRからまたはC-BSRからのみブートストラップメッセージが受け付けられます。
In addition to the three states, there are two timers:
三つの状態に加えて、2つのタイマがあります。
o The Bootstrap Timer (BST) - used to time out old bootstrap router information.
古いブートストラップルータ情報をタイムアウトするために使用 - ブートストラップ・タイマー（BST）は、O。
o The Scope-Zone Expiry Timer (SZT) - used to time out the scope zone itself if Bootstrap messages specifying this scope zone stop arriving.
スコープゾーン期限タイマー（SZT）O - このスコープゾーンを指定するブートストラップメッセージが到着し停止した場合スコープゾーン自体アウト時に使用。
The initial state for scope zones about which the router has no knowledge is "NoInfo".
ルータが認識していないかについてスコープゾーンの初期状態は「NoInfo」です。
The state machine used for scopes that have been configured explicitly on the router and for the global scope (which always exists) differs from the state machine above as follows.
ルータ上で明示的に設定されているスコープおよび（常に存在する）グローバルスコープに使用されるステートマシンは、次のように上記状態マシンは異なります。
o The "NoInfo" state doesn't exist.
O「NoInfo」の状態は存在しません。
o No SZT is maintained. Hence, the event "Scope-Zone Expiry Timer Expires" does not exist and no actions with regard to this timer are executed.
OませSZTが維持されていません。したがって、イベントは「スコープゾーンの有効期限タイマーが切れる」が存在しないと、このタイマーにつきましては一切のアクションは実行されません。
The initial state for this state machine is "Accept Any".
この状態マシンの初期状態は「どれを受け入れる」です。
When a Bootstrap message is received, the following initial checks must be performed:
ブートストラップメッセージを受信した場合、以下の初期チェックを実行する必要があります。
if ((DirectlyConnected(BSM.src_ip_address) == FALSE) OR (we have no Hello state for BSM.src_ip_address)) { drop the Bootstrap message silently }
（（直接接続（BSM.src_ip_address）== FALSE）OR（我々はBSM.src_ip_address）にはHELOコマンドの状態を持たない）場合、{サイレントブートストラップメッセージをドロップ}
if (BSM.dst_ip_address == ALL-PIM-ROUTERS) { if (BSM.no_forward_bit == 0) { if (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address)) { drop the Bootstrap message silently } } else if ((any previous BSM for this scope has been accepted) OR (more than BS_Period has elapsed since startup)) {
IF（BSM.dst_ip_address == ALL-PIM-ルータ）{場合（BSM.no_forward_bit == 0）{場合（BSM.src_ip_address！= RPF_neighbor（BSM.BSR_ip_address））{他IF（（}}サイレントブートストラップメッセージをドロップこのスコープの以前のBSMが受け付けられた）OR BS_Period以上（より経過起動））{
#only accept no-forward BSM if quick refresh on startup drop the Bootstrap message silently } } else if ((Unicast BSM support enabled) AND (BSM.dst_ip_address is one of my addresses)) { if ((any previous BSM for this scope has been accepted) OR (more than BS_Period has elapsed since startup)) { #the packet was unicast, but this wasn't #a quick refresh on startup drop the Bootstrap message silently } } else { drop the Bootstrap message silently }
起動時に迅速なリフレッシュは静かにブートストラップメッセージをドロップする場合は、このスコープのための（（以前のBSM場合#only {場合（（ユニキャストBSMサポートが有効）AND（BSM.dst_ip_addressが私のアドレスの一つである））、他}}ノーフォワードBSMを受け入れます}受け入れ）OR（BS_Period以上が起動してから経過した））{＃このパケットは、ユニキャストだったが、これは静かにブートストラップメッセージをドロップし、起動時に#A迅速なリフレッシュませんでした}静かにブートストラップメッセージをドロップ{他}されました
if (the interface the message arrived on is an admin scope border for the BSM.first_group_address) { drop the Bootstrap message silently }
（メッセージが到着したインターフェイスがBSM.first_group_addressための管理スコープ境界である）場合、{サイレントブートストラップメッセージをドロップ}
Basically, the packet must have come from a directly connected neighbor for which we have active Hello state. It must have been sent to the ALL-PIM-ROUTERS group, and unless it is a No-Forward BSM, it must have been sent by the correct upstream router towards the BSR that originated the Bootstrap message; or, if it is a No-Forward BSM, we must have recently restarted and have no BSR state for that admin scope. Also, if unicast BSM support is enabled, a unicast BSM is accepted if it is addressed to us, we have recently restarted, and we have no BSR state for that admin scope. In addition, it must not have arrived on an interface that is a configured admin-scope border for the first group address contained in the Bootstrap message.
基本的には、パケットは、我々はアクティブハロー状態を持っている直接接続されている隣人から来ている必要があります。これは、ALL-PIM-ROUTERSグループに送信されている必要があり、それが無フォワードBSMでない限り、それはブートストラップメッセージを発信したBSRに向けた正しい上流のルータによって送信されている必要があります。それは無フォワードBSMである場合や、我々は最近、再起動し、その管理範囲にはBSRの状態を持っていないしている必要があります。ユニキャストのBSMのサポートが有効になっている場合も、ユニキャストBSMは、それが私たちに宛てられた場合に受け入れられている、我々は最近、再起動している、と私たちは、その管理者のスコープにはBSRの状態を持っていません。また、ブートストラップメッセージに含まれる最初のグループアドレスのために設定、管理スコープの境界線であるインターフェイスに到着していてはいけません。
If the Bootstrap message passes the initial checks above without being discarded, then it may cause a state transition event in one of the above state machines. For both candidate and non-candidate BSRs, the following transition events are defined:
ブートストラップメッセージは破棄されずに前記初期チェックに合格した場合、それは上記状態マシンのいずれかの状態遷移イベントを引き起こし得ます。候補と非候補BSRの両方のために、次の遷移イベントが定義されています。
Receive Preferred BSM A Bootstrap message is received from a BSR that has weight higher than or equal to that of the current BSR. If a router is in P-BSR state, then it uses its own weight as that of the current BSR.
受信好ましいBSM Aブートストラップメッセージがより高いか、現在のBSRのと等しい量を有するBSRから受信されます。ルータはP-BSR状態にある場合、それは現在のBSRのような自重を使用しています。
A Bootstrap message is also preferred if it is from the
current BSR with a lower weight than the previous BSM it sent,
provided that if the router is a Candidate-BSR the current BSR still has a weight higher than or equal to that of the router
itself. In this case, the "Current Bootstrap Router's BSR
Priority" state must be updated. (For lower weight, see Non-
preferred BSM from Elected BSR case.)
Receive Non-preferred BSM A Bootstrap message is received from a BSR other than the current BSR that has lower weight than that of the current BSR. If a router is in P-BSR state, then it uses its own weight as that of the current BSR.
受信非優先BSM Aブートストラップメッセージは、現在のBSRのより低い量を有する現在のBSRを除くBSRから受信されます。ルータはP-BSR状態にある場合、それは現在のBSRのような自重を使用しています。
Receive Non-preferred BSM from Elected BSR A Bootstrap message is received from the elected BSR, but the BSR Priority field in the received message has changed, so that now the currently elected BSR has lower weight than that of the router itself.
選出されたBSR Aブートストラップメッセージから非優先BSMを受信が選出されたBSRから受信されたが、今現在、選出されたBSRは、ルータ自体のより低い量を有するように、受信したメッセージでBSR Priorityフィールドは、変更されました。
Receive BSM A Bootstrap message is received, regardless of BSR weight.
受信BSM Aブートストラップメッセージは関係なく、BSR重量の、受信されます。
In addition to state machine transitions caused by the receipt of Bootstrap messages, a state machine transition takes place each time the Bootstrap Timer or Scope-Zone Expiry Timer expires.
ブートストラップメッセージの受信によって引き起こされる状態マシンの移行に加えて、ステートマシンの移行は、ブートストラップ・タイマーまたは範囲ゾーン期限タイマーの期限が切れるたびに行われます。
The state machines specify actions that include setting the Bootstrap Timer and the Scope-Zone Expiry Timer to various values. These values are defined in section 5.
ステートマシンは、種々の値にブートストラップタイマーと範囲ゾーンの有効期限タイマーの設定、アクションを指定します。これらの値は、セクション5で定義されています。
In addition to setting and cancelling the timers, the following actions may be triggered by state changes in the state machines:
タイマーを設定し、キャンセルに加えて、次のアクションは、ステートマシンの状態変化によってトリガされてもよいです。
Forward BSM A multicast Bootstrap message with No-Forward bit cleared that passes the Bootstrap Message Processing Checks is forwarded out of all interfaces with PIM neighbors (including the interface it is received on), except where this would cause the BSM to cross an admin-scope boundary for the scope zone indicated in the message. For details, see section 3.4.
無フォワード前方BSM Aマルチキャストブートストラップメッセージは、これはBSMがADMIN-を横断する原因となる場合を除き、（それが上で受信されたインターフェイスを含む）PIMネイバーとのすべてのインターフェイスから転送されたブートストラップメッセージ処理チェックを通過するクリアビットスコープゾーンの範囲の境界がメッセージに示さ。詳細については、3.4節を参照してください。
Originate BSM A new Bootstrap message is constructed by the BSR, giving the BSR's address and BSR priority, and containing the BSR's chosen RP-Set. The message is forwarded out of all interfaces on which PIM neighbors exist, except where this would cause the BSM to cross an admin-scope boundary for the scope zone indicated in the message.
発信BSM A新しいブートストラップメッセージはBSRのアドレスとBSRの優先順位を与え、およびBSRの選択RP-セットを含む、BSRによって構成されています。メッセージは、このBSMは、メッセージに示されているスコープゾーンの管理スコープの境界を横断する原因となる場合を除き、PIMネイバーが存在するすべてのインターフェイスから転送されます。
Store RP-Set The router uses the group-to-RP mappings contained in a BSM to update its local RP-Set.
ストアRP-設定するルータは、ローカルRP-セットを更新するBSMに含まれるグループ・ツー・RPマッピングを使用しています。
This action is skipped for an empty BSM. A BSM is empty if it
contains no group ranges, or if it only contains a single
group range where that group range has the Admin Scope Zone
bit set (a scoped BSM) and an RP count of zero.
If a mapping does not yet exist, it is created and the associated Group-to-RP mapping Expiry Timer (GET) is initialized with the holdtime from the BSM.
マッピングがまだ存在しない場合は、それが作成され、関連するグループ-RPマッピングの有効期限タイマーは（GET）BSMからのホールドタイムで初期化されます。
If a mapping already exists, its GET is set to the holdtime from the BSM. If the holdtime is zero, the mapping is removed immediately. Note that for an existing mapping, the RP priority must be updated if changed.
マッピングがすでに存在する場合、そのGETは、BSMからのホールドタイムに設定されています。ホールドタイムがゼロの場合、マッピングはすぐに削除されます。変更された場合は、既存のマッピングのために、RPの優先順位を更新しなければならないことに注意してください。
Mappings for a group range are also to be immediately removed if they are not present in the received group range. This means that if there are any existing group-to-RP mappings for a range where the respective RPs are not in the received range, then those mappings must be removed.
グループ範囲のマッピングは、それらが受信されたグループの範囲に存在しない場合は、直ちに除去されることもあります。これは、各RPは受信範囲内にない範囲の既存のグループとRPのマッピングが存在する場合、それらのマッピングが除去されなければならないことを意味します。
All RP mappings associated with the scope zone of the BSM are updated with the new hash mask length from the received BSM. This includes RP mappings for all group ranges learned for this zone, not just the ranges in this particular BSM.
BSMのスコープゾーンに関連付けられているすべてのRPマッピングは受信BSMから新しいハッシュマスク長で更新されます。これは、このゾーン、この特定のBSM内だけではなく範囲について学んだすべてのグループ範囲のRPマッピングを含んでいます。
In addition, the entire BSM is stored for use in the action Refresh RP-Set and to prime a new PIM neighbor as described below.
後述のように加えて、全体BSMは、アクション更新RP-セットにし、プライム新しいPIMネイバーに使用するために格納されています。
Refresh RP-Set When the Bootstrap Timer expires, the router uses the copy of the last BSM that it has received to refresh its RP-Set according to the action Store RP-Set as if it had just received it. This will increase the chance that the group-to-RP mappings will not expire during the election of the new BSR.
リフレッシュRP-セットのブートストラップタイマーの期限が切れると、ルータは、それがちょうどそれを受信したかのように行動ストアRP-の設定に応じてそのRP-セットをリフレッシュするために受信した最後のBSMのコピーを使用しています。これは、グループ・ツー・RPマッピングが新しいBSRの選挙時に期限切れになりませんチャンスを増加します。
Remove BSR state When the Bootstrap Timer expires, all state associated with the current BSR is removed (address, priority, BST, and saved last BSM; see section 2). Note that this does not include any group-to-RP mappings.
ブートストラップタイマが満了するとBSRの状態を外し、現在のBSRに関連するすべての状態は、（アドレス、優先順位、BSTを、そして最後BSM保存し、セクション2を参照）が除去されます。これは、任意のグループツーRPのマッピングが含まれていないことに注意してください。
Remove scope zone state When the Scope-Zone Expiry Timer expires, all state associated with the scope zone is removed (see section 2).
スコープゾーン期限タイマーが満了すると（セクション2を参照）スコープゾーンに関連付けられたすべての状態が除去され、スコープゾーン状態を取り除きます。
Every C-RP periodically unicasts a C-RP-Adv message to the BSR for each scope zone for which it has state, to inform the BSR of the C-RP's willingness to function as an RP. These messages are sent with an interval of C_RP_Adv_Period, except when a new BSR is elected; see below.
すべてのC-RPは、定期的にRPとして機能するC-RPの意欲のBSRを知らせるために、それは状態を持っている各スコープゾーンのBSRとC-RP-ADVメッセージをユニキャストします。これらのメッセージは、新しいBSRが選出されている場合を除きC_RP_Adv_Periodの間隔で送信されます。下記参照。
When a new BSR is elected, the C-RP MUST send one to three C-RP-Adv messages and wait a small randomized period C_RP_Adv_Backoff before sending each message. We recommend sending three messages because it is important that the BSR quickly learns which RPs are active, and some packet loss may occur when a new BSR is elected due to changes in the network. One way of implementing this is to set the CRPT to C_RP_Adv_Backoff when the new BSR is elected, as well as setting a counter to 2. Whenever the CRPT expires, we first send a C-RP-Adv message as usual. Next, if the counter is non-zero, it is decremented and the CRPT is again set to C_RP_Adv_Backoff instead of C_RP_Adv_Period.
新しいBSRが選出された場合、C-RPは、3 C-RP-Advメッセージに1を送信し、それぞれのメッセージを送信する前に、小さな無作為化期間C_RP_Adv_Backoffを待たなければなりません。 BSRはすぐにRPがアクティブである学習し、新しいBSRがネットワーク内の変更のために選出されたときに、いくつかのパケット損失が発生する可能性があることが重要であるので、我々は3つのメッセージを送ることをお勧めします。これを実現する1つの方法は、新しいBSRが選出されたときにC_RP_Adv_BackoffにCRPTを設定し、同様に2にカウンタを設定するなどCRPTの有効期限が切れるたびに、私たちが最初にいつものようにC-RP-ADVメッセージを送信することです。カウンタがゼロでない場合次に、それがデクリメントされ、CRPT再びC_RP_Adv_Backoff代わりのC_RP_Adv_Periodに設定されています。
The Priority field in these messages is used by the BSR to select which C-RPs to include in the RP-Set. Note that lower values of this field indicate higher priorities, so that a value of zero is the highest possible priority. C-RPs should, by default, send C-RP-Adv messages with the Priority field set to 192.
これらのメッセージにPriorityフィールドは、C-RPはRP-セットに含めるかを選択するためにBSRによって使用されます。ゼロの値は、可能な限り最高の優先順位であるように、このフィールドの低い値は、より高い優先順位を示すことに留意されたいです。 C-RPは、デフォルトでは、192に設定された優先分野とC-RP-Advメッセージを送信する必要があります。
When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv message to the BSR for each scope zone for which it is currently serving as an RP; the Holdtime in this C-RP-Adv message should be zero. The BSR will then immediately time out the C-RP and generate a new Bootstrap message with the shut down RP holdtime set to 0.
C-RPがシャットダウンされているとき、それはすぐに、それが現在RPとして機能しているため、各スコープゾーンのBSRとC-RP-ADVメッセージを送信すべきです。このC-RP-ADVメッセージ内のホールドタイムがゼロでなければなりません。 BSRは、直ちにC-RPをタイムアウトして0に設定シャットダウンRPホールドタイムを持つ新しいブートストラップメッセージを生成します。
A C-RP-Adv message carries a list of group address and group mask field pairs. This enables the C-RP to specify the group ranges for which it is willing to be the RP. If the C-RP becomes an RP, it may enforce this scope acceptance when receiving Register or Join/Prune messages.
C-RP-ADVメッセージは、グループアドレスとグループマスクフィールドペアのリストを運びます。 RPことが喜んでいるグループの範囲を指定するためにC-RPを可能にします。 C-RPがRPになった場合、それは登録を受けたときに、このスコープの受け入れを強制するか、/プルーンのメッセージを参加することができます。
A C-RP is configured with a list of group ranges for which it should advertise itself as the C-RP. A C-RP uses the following algorithm to determine which ranges to send to a given BSR.
C-RPは、グループのリストで構成され、それはC-RPとしてそれ自身を宣伝する必要がありれる範囲です。 C-RPは、与えられたBSRに送信する範囲を決定するために、次のアルゴリズムを使用します。
For each group range R in the list, the C-RP advertises that range to the scoped BSR for the smallest scope that "contains" R. For IPv6, the containing scope is determined by matching the scope identifier of the group range with the scope of the BSR. For IPv4, it is the longest-prefix match for R, amongst the known admin-scope ranges. If no scope is found to contain the group range, the C-RP includes it in the C-RP-Adv sent to the non-scoped BSR. If a non-scoped BSR is not known, the range is not included in any C-RP-Adv.
リスト内の各グループの範囲Rは、C-RPは、IPv6のR.「を含む」ことを最小スコープのスコープBSRにその範囲をアドバタイズし、含有範囲は、範囲とグループ範囲のスコープ識別子を照合することによって決定されますBSRの。 IPv4の場合、それは既知の管理スコープの範囲の中で、Rのために最長プレフィックス・マッチです。スコープがグループの範囲を含むことが見出されていない場合は、C-RPは、C-RP-ADVでそれを含む非スコープBSRに送られます。非スコープBSRが知られていない場合、範囲は、任意のC-RP-ADVに含まれていません。
In addition, for each IPv4 group range R in the list, for each scoped BSR whose scope range is strictly contained within R, the C-RP SHOULD by default advertise that BSR's scope range to that BSR. And for each IPv6 group range R in the list with prefix length < 16, the C-RP SHOULD by default advertise each sub-range of prefix length 16 to the scoped BSR with the corresponding scope ID. An implementation MAY supply a configuration option to prevent the behavior described in this paragraph, but such an option SHOULD be disabled by default.
また、リスト内のそれぞれのIPv4グループ範囲Rのために、それぞれについては、その範囲の範囲厳密デフォルトでR、C-RP SHOULD内に含まれていることをBSRをBSRの範囲の範囲ことをアドバタイズBSRスコープ。そしてプレフィックス長<16でリスト内の各グループのIPv6範囲Rのために、C-RPは、デフォルトで、対応するスコープIDを持つスコープBSRにプレフィックス長16の各サブ範囲をアドバタイズすべきです。実装は、この段落で説明した動作を防止するための設定オプションを供給することができるが、そのようなオプションはデフォルトで無効にする必要があります。
For IPv6, the mask length of all group ranges included in the C-RP-Adv message sent to a scoped BSR MUST be >= 16.
IPv6の場合、すべてのグループのマスク長は、> = 16でなければなりませんスコープBSRに送信されたC-RP-ADVメッセージに含まれる範囲です。
If the above algorithm determines that there are no group ranges to advertise to the BSR for a particular scope zone, a C-RP-Adv message MUST NOT be sent to that BSR. A C-RP MUST NOT send a C-RP-Adv message with no group ranges in it.
上記のアルゴリズムは何グループが存在しないと判断した場合、特定のスコープゾーンのBSRにアドバタイズする範囲で、C-RP-ADVメッセージは、BSRに送信してはいけません。何のグループがそれに及ぶないとC-RPは、C-RP-ADVメッセージを送ってはいけません。
If the same router is the BSR for more than one scope zone, the C-RP-Adv messages for these scope zones MAY be combined into a single message.
同じルータが複数のスコープゾーンのBSRである場合、これらのスコープゾーンのC-RP-ADVメッセージは単一のメッセージに結合されてもよいです。
If the C-RP is a ZBR for an admin-scope zone, then the Admin Scope Zone bit MUST be set in the C-RP-Adv messages it sends for that scope zone; otherwise this bit MUST NOT be set. This information is currently only used for logging purposes by the BSR, but might allow for future extensions of the protocol.
C-RPは、管理スコープゾーンのZBRである場合には、管理スコープゾーンのビットは、それがそのスコープゾーンの送信C-RP-Advメッセージに設定しなければなりません。そうでない場合は、このビットを設定してはいけません。この情報は、現在、BSRによってログ記録の目的のために使用されますが、プロトコルの将来の拡張を可能にすることがあります。
Upon receiving a C-RP-Adv message, the router needs to decide whether or not to accept each of the group ranges included in the message. For each group range in the message, the router checks to see if it is the elected BSR for any scope zone that contains the group range, or if it is elected as the non-scoped BSR. If so, the group range is accepted; if not, the group range is ignored.
C-RP-ADVメッセージを受信すると、ルータは、グループの各メッセージに含まれる範囲を受け入れるかどうかを決定する必要があります。それはグループの範囲が含まれているか、またはそれは、非スコープBSRとして選定された場合、任意のスコープゾーンの選出されたBSRがある場合、メッセージの各グループの範囲に対して、ルータかどうかを確認します。そうである場合、グループ範囲が受け入れられます。ない場合は、グループ範囲は無視されます。
For security reasons, we recommend that implementations have a way of restricting which IP addresses the BSR accepts C-RP-Adv messages from, e.g., access lists. For use of scoped BSR, it may also be useful to specify which group ranges should be accepted.
セキュリティ上の理由から、我々は、実装は、IPは、BSRは、アクセスリスト、例えば、からC-RP-Advメッセージを受け入れるアドレス制限の方法を持っていることをお勧めします。スコープBSRの使用のために、また、受け入れられるべきグループの範囲を指定するために有用であり得ます。
If the group range is accepted, a group-to-C-RP mapping is created for this group range and the RP Address from the C-RP-Adv message.
グループ範囲が受け入れられた場合、グループ・ツー・C-RPマッピングは、このグループの範囲とC-RP-ADVメッセージからRPアドレスのために作成されます。
If the mapping is not already part of the C-RP-Set, it is added to the C-RP-Set and the associated Group-to-C-RP mapping Expiry Timer (CGET) is initialized to the holdtime from the C-RP-Adv message. Its priority is set to the Priority from the C-RP-Adv message.
マッピングは既にC-RP-セットの一部ではない場合は、C-RP-セットに追加され、関連するグループとC-RPマッピング有効期限タイマ（CGET）C-からホールドタイムに初期化されます。 RP-ADVメッセージ。その優先順位は、C-RP-ADVメッセージから優先順位に設定されています。
If the mapping is already part of the C-RP-Set, it is updated with the Priority from the C-RP-Adv message, and its associated CGET is reset to the holdtime from the C-RP-Adv message. If the holdtime is zero, the mapping is immediately removed from the C-RP-Set.
マッピングは既にC-RP-セットの一部である場合、それはC-RP-ADVメッセージから優先順位で更新、およびそれに関連するCGETは、C-RP-ADVメッセージからホールド時間にリセットされます。ホールドタイムがゼロの場合、マッピングはすぐにC-RP-セットから削除されます。
The hash mask length is a global property of the BSR and is therefore the same for all mappings managed by the BSR.
ハッシュマスク長は、BSRのグローバルプロパティであるため、BSRによって管理されるすべてのマッピングのために同じです。
For compatibility with the previous version of the BSR specification, a C-RP-Adv message with no group ranges SHOULD be treated as though it contained the single group range ff00::/8 or 224/4. Therefore, according to the rule above, this group range will be accepted if and only if the router is elected as the non-scoped BSR.
それは、単一のグループ範囲FF00 :: / 8又は224/4を含有しているかのようにBSR仕様の以前のバージョンとの互換性のために、グループの範囲を有するC-RP-ADVメッセージは、治療すべきです。したがって、上記の規則に従って、このグループの範囲があれば受け入れられると、ルータは、非スコープBSRとして選定されている場合にのみ。
When a CGET expires, the corresponding group-to-C-RP mapping is removed from the C-RP-Set.
CGETが期限切れになると、対応するグループ・ツー・C-RPマッピングは、C-RP-セットから除去されます。
The BSR constructs the RP-Set from the C-RP-Set. It may apply a local policy to limit the number of Candidate-RPs included in the RP-Set. The BSR may override the range indicated in a C-RP-Adv message unless the 'Priority' field from the C-RP-Adv message is less than 128.
BSRはRP-SET C-RP-セットからを構築します。これは、候補-RPSの数はRP-セットに含ま制限するローカルポリシーを適用することができます。 C-RP-ADVメッセージから「優先度」フィールドは128未満でない限り、BSRはC-RP-ADVメッセージに示された範囲をオーバーライドすることができます。
If the BSR learns of both BIDIR and PIM-SM Candidate-RPs for the same group range, the BSR MUST only include RPs for one of the protocols in the BSMs. The default behavior SHOULD be to prefer BIDIR.
BSRは、同じグループの範囲に対してBIDIRおよびPIM-SM候補-RPSの両方で学習した場合、BSRのみのBSMにおけるプロトコルのいずれかのRPを含まなければなりません。デフォルトの動作はBIDIRを好むとすべきです。
For inclusion in a BSM, the RP-Set is subdivided into sets of {group-range, RP-Count, RP-addresses}. For each RP-address, the "RP-Holdtime" field is set to the Holdtime from the C-RP-Set, subject to the constraint that it MUST be larger than BS_Period and SHOULD be larger than 2.5 times BS_Period to allow for some Bootstrap messages getting lost. If some holdtimes from the C-RP-Sets do not satisfy this constraint, the BSR MUST replace those holdtimes with a value satisfying the constraint. An exception to this is the holdtime of zero, which is used to immediately withdraw mappings.
BSMに含めるために、RP-セット{グループレンジ、RP-カウント、RP-アドレス}の集合に細分されます。各RPアドレスは、「RP-ホールドタイム」フィールドは、それがBS_Periodより大きくなければならないし、いくつかのブートストラップを可能にするために、2.5倍BS_Periodより大きくなければならないという制約を受ける、C-RP-セットからホールドタイムに設定されていますメッセージが迷子に。 C-RP-セットからいくつかのholdtimesはこの制約を満たしていない場合は、BSRは、制約を満たす値とそれらのholdtimesを交換しなければなりません。この例外は、直ちにマッピングを撤回するために使用されるゼロのホールド時間、です。
The format of the Bootstrap message allows 'semantic fragmentation', if the length of the original Bootstrap message exceeds the packet maximum boundaries. However, to reduce the semantic fragmentation required, we recommend against configuring a large number of routers as C-RPs.
元のブートストラップメッセージの長さは、パケットの最大境界を超えた場合にブートストラップメッセージのフォーマットは、「セマンティックフラグメンテーション」を可能にします。しかし、必要なセマンティック断片化を減らすために、我々は、C-RPとしてルータの多数の設定に対してお勧めします。
In general, BSMs are originated at regular intervals according to the BS_Period timer. We do recommend that a BSM is also originated whenever the RP-set to be announced in the BSMs changes. This will usually happen when receiving C-RP advertisements from a new C-RP, or when a C-RP is shut down (C-RP advertisement with a holdtime of zero). There MUST however be a minimum of BS_Min_Interval between each time a BSM is sent. In particular, when a new BSR is elected, it will first send one BSM (which is likely to be empty since it has not yet received any C-RP advertisements), and then wait at least BS_Min_Interval before sending a new one. During that time, it is likely to have received C-RP advertisements from all usable C-RPs (since we say that a C-RP should send one or more advertisements with small random delays of C_RP_Adv_Backoff when a new BSR is elected). For this case in particular, where routers may not have a usable RP-set, we recommend originating a BSM as soon as BS_Min_Interval has passed. We suggest though that a BSR can do this in general. One way of implementing this, is to decrease the Bootstrap Timer to BS_Min_Interval whenever the RP-set changes, while not changing the timer if it is less than or equal to BS_Min_Interval.
一般的には、個のBSMはBS_Periodタイマーに応じて、一定の間隔で発生しています。私たちは、RP-セットはのBSMの変化に発表されるたびBSMも発信されることをお勧めします。これは通常、新しいC-RPからC-RPアドバタイズメントを受信したときにどうなるか、C-RPは、（ゼロのホールドタイムとC-RPアドバタイズメント）をシャットダウンしたとき。しかし、BSMが送信されるたび間BS_Min_Intervalの最小値があるに違いありません。新しいBSRが選出されたとき、特に、それは最初に（それはまだC-RPアドバタイズメントを受信していないので、空である可能性が高い）1つのBSMが送信されますし、新しいものを送信する前に、少なくともBS_Min_Intervalを待ちます。その時に、（私たちは新しいBSRが選出されたときにC-RPはC_RP_Adv_Backoffの小さなランダムな遅延で、1つまたは複数の広告を送信しなければならないと言うので）すべての使用可能なC-RPSからC-RPアドバタイズメントを受けている可能性があります。ルータが使用可能なRP-セットを持っていない可能性があり、特にこの場合は、のために、私たちはできるだけ早くBS_Min_Intervalが経過したとしてBSMを発信することをお勧めします。私たちは、BSRは、一般的にこれを行うことができますけれども示唆しています。これを実現する1つの方法は、RP-設定の変更は、タイマーを変更していない間、それは以下BS_Min_Intervalに等しい場合はいつでもBS_Min_Intervalにブートストラップタイマーを減少させることです。
A BSR originates separate scoped BSMs for each scope zone for which it is the elected BSR, as well as originating non-scoped BSMs if it is the elected non-scoped BSR.
BSRは、選出されたBSRされている各スコープゾーンの別々のスコープのBSMを発信し、並びにそれが選出され、非スコープBSRである場合、非スコープのBSMを発信します。
Each group-to-C-RP mapping is included in precisely one of these BSMs -- namely, the scoped BSM for the narrowest scope containing the group range of the mapping, if any, or the non-scoped BSM otherwise.
そうでない場合、すなわち、マッピングのグループ範囲を含む最も狭いスコープのスコープBSM、もしあれば、または非スコープBSM - 各グループとC-RPマッピングは、これらのBSMの正確に1つに含まれています。
A scoped BSM MUST have at least one group range, and the first group range in a scoped BSM MUST have the Admin Scope Zone bit set. This group range identifies the scope of the BSM. In a scoped IPv4 BSM, the first group range is the range corresponding to the scope of the BSM. In a scoped IPv6 BSM, the first group range may be any group range subject to the general condition that all the group ranges in such a BSM MUST have a mask length of at least 16 and MUST have the same scope ID as the scope of the BSM.
スコープBSMは、少なくとも一つのグループの範囲でなければならず、そしてスコープBSM内の最初のグループの範囲は、ゾーンビットが設定管理範囲を持たなければなりません。このグループの範囲は、BSMの範囲を特定します。スコープのIPv4 BSMにおいて、最初のグループの範囲は、BSMの範囲に対応する範囲です。スコープのIPv6 BSMにおいて、最初のグループの範囲は、少なくとも16のマスク長さを持たなければならないとの範囲と同じスコープIDを持つ必要があるすべてのグループは、BSMの範囲である一般的な状態への任意のグループ範囲の被写体であってもよいですBSM。
Apart from identifying the scope, the first group range in a scoped BSM is treated like any other range with respect to RP mappings. That is, all mappings in the RP-set for this group range, if any, must be included in this first group range in the BSM. After this group range, other group ranges in this scope (for which there are RP mappings) appear in any order.
別にスコープを識別するから、スコープBSM内の最初のグループの範囲は、RPマッピングに対する他の範囲と同様に扱われます。つまり、このグループ範囲のRP-セット内のすべてのマッピングが、もしあれば、BSMでこの最初のグループの範囲に含まれている必要があり、です。このグループの範囲の後に、他のグループは、任意の順序で表示される（RPマッピングが存在しているため）このスコープの範囲です。
The Admin Scope Zone bit of all group ranges other than the first SHOULD be set to 0 on origination, and MUST be ignored on receipt.
すべてのグループの管理スコープゾーンのビットは、最初の発信に0に設定する必要があり、領収書で無視しなければなりません以外の範囲です。
When an elected BSR is being shut down, it should immediately originate a Bootstrap message listing its current RP-Set, but with the BSR Priority field set to the lowest priority value possible. This will cause the election of a new BSR to happen more quickly.
選出されたBSRがシャットダウンされている場合、それはすぐにその現在のRP-セットリストブートストラップメッセージを発信するが、可能な限り低い優先度の値に設定BSR Priorityフィールドを持つ必要があります。これは、新しいBSRの選挙がより迅速に起こるようになります。
Generally, bootstrap messages originate at the BSR, and are hop-by-hop forwarded by intermediate routers if they pass the Bootstrap Message Processing Checks. There are two exceptions to this. One is that a bootstrap message is not forwarded if its No-Forward bit is set; see section 3.5.1. The other is that unicast BSMs (see section 3.5.2) are usually not forwarded. Implementers MAY, however, at their own discretion choose to re-send a No-Forward or unicast BSM in a multicast BSM, which MUST have the No-Forward bit cleared. It is essential that the No-Forward bit is cleared, since no Reverse Path Forwarding (RPF) check is performed by the receiver when it is set.
一般的には、ブートストラップメッセージがBSRで発生し、ホップバイホップの中間ルータによって転送彼らはブートストラップメッセージ処理チェックに合格した場合です。これには2つの例外があります。一つは、その無転送ビットが設定されている場合、ブートストラップメッセージが転送されないことです。セクション3.5.1を参照してください。他のユニキャストのBSMは（セクション3.5.2を参照）は、通常転送されないということです。実装者は、しかし、自分の裁量で無フォワードビットがクリアされていなければならない、マルチキャストBSMに無フォワードまたはユニキャストBSM再送信しないことを選択するかもしれません。それが設定されているときに何のReverse Path Forwarding（RPF）チェックが受信機によって実行されませんので、無フォワードビットは、クリアされていることが不可欠です。
By hop-by-hop forwarding, we mean that the Bootstrap message itself is forwarded, not the entire IP packet. Each hop constructs an IP packet for each of the interfaces the BSM is to be forwarded out of; each packet contains the entire BSM that was received.
ホップバイホップ転送することによって、我々は、ブートストラップメッセージ自体は、全体ではなく、IPパケットを転送していることを意味します。各ホップは、BSMは、外に転送されるべきインターフェースのそれぞれについてIPパケットを構築します。各パケットが受信された全体のBSMが含まれています。
When a Bootstrap message is forwarded, it is forwarded out of every multicast-capable interface that has PIM neighbors (including the one over which the message was received). The exception to this is if the interface is an admin-scope boundary for the admin-scope zone indicated in the first group range in the Bootstrap message packet.
ブートストラップメッセージが転送されるとき、それは、（メッセージを受信した上を含む）PIMネイバーを持つすべてのマルチキャスト可能なインタフェースから転送されます。インタフェースは、ブートストラップ・メッセージ・パケットの最初のグループの範囲に示されている管理スコープゾーンの管理スコープ境界である場合は例外です。
As an optimization, a router MAY choose not to forward a BSM out of the interface the message was received on if that interface is a point-to-point interface. On interfaces with multiple PIM neighbors, a router SHOULD forward an accepted BSM out of the interface that BSM was received on, but if the number of PIM neighbors on that interface is large, it MAY delay forwarding a BSM out of that interface by a small randomized interval to prevent message implosion. A configuration option MAY be provided to disable forwarding out of the interface a message was received on, but we recommend that the default behavior is to forward out of that interface.
最適化として、ルータはそのインターフェイスがポイントツーポイントインターフェイスの場合、メッセージが受信されたインターフェイスからBSMを転送しないことを選択することができます。複数のPIMネイバーとのインターフェイスで、ルータは、BSMが受信されたインターフェイスから受け入れBSMを転送する必要がありますが、そのインターフェイス上のPIMネイバーの数が多い場合、それは小さなによってそのインターフェイスのうちBSMの転送を遅延させることができますメッセージ爆縮を防止するための無作為化間隔。設定オプションは、メッセージが受信されたインターフェイスから転送を無効にするために提供されるかもしれないが、我々は、デフォルトの動作は、そのインターフェイスから転送するためにであることをお勧めします。
Rationale: A BSM needs to be forwarded out of the interface the message was received on (in addition to the other interfaces) because the routers on a LAN may not have consistent routing information. If three routers on a LAN are A, B, and C, and at router B RPF(BSR)==A and at router C RPF(BSR)==B, then router A originally forwards the BSM onto the LAN, but router C will only accept it when router B re-forwards the message onto the LAN. If the underlying routing protocol configuration guarantees that the routers have consistent routing information, then forwarding out of the incoming interface may safely be disabled.
理論的根拠：BSMは、LAN上のルータが一致するルーティング情報を有していなくてもよいため、メッセージが（他のインタフェースに加えて）受信されたインターフェイスから転送する必要があります。 LAN上の3つのルータは、B、およびCである場合、及びA ==ルータB RPF（BSR）において、ルータC RPF（BSR）== Bにおいて、ルータA元々LANにBSMを転送するが、ルータルータBのLAN上にメッセージを再転送するときCは、それを受け入れます。基礎となるルーティングプロトコルの設定を保証場合ルータが一致するルーティング情報を持っていること、着信インターフェイスから転送すると、安全に無効にすることができます。
A ZBR constrains all BSMs that are of equal or smaller scope than the configured boundary. That is, the BSMs are not accepted from, originated, or forwarded on the interfaces on which the boundary is configured. For IPv6, the check is a comparison between the scope of the first range in the scoped BSM and the scope of the configured boundary. For IPv4, the first range in the scoped BSM is checked to see if it is contained in or is the same as the range of the configured boundary.
ZBRは構成境界より等しいか小さい範囲であるすべてのBSMを制約します。つまり、のBSMは、から受け付けた発信、または境界が設定されているインターフェイス上で転送されません。 IPv6の場合、チェックはスコープBSM及び構成境界の範囲内の第1の範囲の範囲との間の比較です。 IPv4の場合、スコープBSMにおける第1の範囲はそれに含まれているか、構成された境界の範囲と同じであるかどうかを確認するためにチェックされます。
When a Hello message is received from a new neighbor, or a Hello message with a new GenID is received from an existing neighbor, one router on the LAN sends a stored copy of the Bootstrap message for each admin-scope zone to the new or rebooting router. This allows new or rebooting routers to learn the RP-Set quickly.
Helloメッセージは、新しい隣人、または新規られたGenIDとHelloメッセージから受信した場合、既存のネイバーから受信され、LAN上のルータは、新規または再起動するには、各管理スコープゾーンのブートストラップメッセージの保存されたコピーを送信しますルータ。これは、新規または再起動するルータがRP-SET迅速に学ぶことができます。
This message SHOULD be sent as a No-Forward Bootstrap message; see section 3.5.1. For backwards compatibility, this message MAY instead or in addition be sent as a unicast Bootstrap message; see section 3.5.2. These messages MUST only be accepted at startup; see section 3.1.3.
このメッセージは、フォワードブートストラップメッセージとして送ってください。セクション3.5.1を参照してください。下位互換性のため、このメッセージは、代わりに又は加えて、ユニキャストブートストラップメッセージとして送信されるかもしれません。セクション3.5.2を参照してください。これらのメッセージは、起動時にのみ受け入れなければなりません。セクション3.1.3を参照してください。
The router that does this is the Designated Router (DR) on the LAN, or, if the new or rebooting router is the DR, the router that would be the DR if the new or rebooting router were excluded from the DR election process.
新規または再起動するルータがDR、新規または再起動するルータがDR選出プロセスから除外された場合にはDRになりルータであればこれを行うルータは、LAN上の指定ルータ（DR）である、または。
Before sending a Bootstrap message in this manner, the router must wait until it has sent a triggered Hello message on this interface; otherwise, the new neighbor will discard the Bootstrap message.
それは、このインターフェイス上のトリガのHelloメッセージを送信したまでは、このようにブートストラップメッセージを送信する前に、ルータが待機する必要があります。そうでない場合は、新しい隣人はブートストラップメッセージを破棄します。
A No-Forward Bootstrap message, is a bootstrap message that has the No-Forward bit set. All implementations SHOULD support sending of No-Forward Bootstrap messages, and SHOULD also accept them. The RPF check MUST NOT be performed in the BSM processing check for a No-Forward BSM; see section 3.1.3. The messages have the same source and destination addresses as the usual multicast Bootstrap messages.
いいえフォワードブートストラップメッセージは、無転送ビットがセットされているブートストラップメッセージです。すべての実装はありませんフォワードブートストラップメッセージの送信をサポートしなければならず、また、それらを受け入れるべきです。 RPFチェックは、無フォワードBSM用BSM処理チェックで実行してはいけません。セクション3.1.3を参照してください。メッセージは、通常のマルチキャストブートストラップメッセージと同じ送信元アドレスと宛先アドレスを持っています。
For backwards compatibility, implementations MAY support unicast Bootstrap messages. Whether to send unicast Bootstrap messages instead of or in addition to No-Forward Bootstrap messages, and also whether to accept such messages, SHOULD be configurable. This message is unicast to the neighbor.
後方互換性のために、実装は、ユニキャストブートストラップメッセージをサポートするかもしれません。代わりに、または無フォワードブートストラップメッセージに加えて、ユニキャストブートストラップメッセージを送信し、またこのようなメッセージを受け入れるかどうかにするかどうかは、構成可能であるべきです。このメッセージは、隣人へのユニキャストです。
The RP-Set maintained by BSR is used by RP-based multicast routing protocols like PIM-SM and BIDIR-PIM. These protocols may obtain RP-Sets from other sources as well. How the final group-to-RP mappings are obtained from these RP-Sets is not part of the BSR specification. In general, the routing protocols need to re-calculate the mappings when any of their RP-Sets change. How such a change is signalled to the routing protocol is also not part of the present specification.
BSRによって維持RP-セットは、PIM-SMおよびBIDIR-PIM様RPベースのマルチキャストルーティングプロトコルによって使用されます。これらのプロトコルは、他のソースからのRP-Setを得ることができます。どのように最後のグループツーRPのマッピングは、これらのRP-セットから得られるBSR仕様の一部ではありません。一般的には、ルーティングプロトコルがそのRP-セットのいずれかが変更されたときにマッピングを再計算する必要があります。そのような変更は、ルーティングプロトコルに通知する方法もまた、本明細書の一部ではありません。
Some group-to-RP mappings in the RP-Set indicate group ranges for which PIM-SM should be used; others indicate group ranges for use with BIDIR-PIM. Routers that support only one of these protocols MUST NOT ignore ranges indicated as being for the other protocol. They MUST NOT treat them as being for the protocol they support.
RP-セットのいくつかのグループに-RPのマッピングは、グループがPIM-SMを使用する必要のある範囲を示しています。他の人は、グループがBIDIR-PIMで使用するための範囲を示しています。唯一これらのプロトコルをサポートするルータは、他のプロトコルのためのものとして示されている範囲を無視してはいけません。彼らはサポートプロトコルのためのものとして扱うてはなりません。
If a mapping is not already part of the RP-Set, it is added to the RP-Set and the associated Group-to-RP mapping Expiry Timer (GET) is initialized to the holdtime from the Bootstrap message. Its priority is set to the Priority from the Bootstrap message.
マッピングがすでにRP-セットの一部でない場合は、RP-設定および関連グループ-RPマッピングの有効期限タイマーに追加されます（GET）ブートストラップメッセージからホールドタイムに初期化されます。その優先順位は、ブートストラップメッセージから優先順位に設定されています。
If a mapping is already part of the RP-Set, it is updated with the Priority from the Bootstrap message and its associated GET is reset to the holdtime from the Bootstrap message. If the holdtime is zero, the mapping is removed from the RP-Set immediately.
マッピングがすでにRP-セットの一部である場合、それはブートストラップメッセージとそれに関連するGETから優先で更新されたブートストラップメッセージからホールド時間にリセットされます。ホールドタイムがゼロの場合、マッピングはRP-設定し、直ちにから削除されます。
BSR messages are PIM messages, as defined in [1]. The values of the PIM Message Type field for BSR messages are:
[1]で定義されるようにBSRメッセージは、PIMメッセージです。 BSRメッセージのPIMメッセージタイプフィールドの値は次のとおりです。
4 Bootstrap
4ブートストラップ
8 Candidate-RP-Advertisement
8候補RP-広告
As with all other PIM control messages, BSR messages have IP protocol number 103.
他のすべてのPIMコントロールメッセージと同じように、BSRメッセージは、IPプロトコル番号103を持っています。
Candidate-RP-Advertisement messages are unicast to a BSR. Usually, Bootstrap messages are multicast with TTL 1 to the ALL-PIM-ROUTERS group, but in some circumstances (described in section 3.5.2) Bootstrap messages may be unicast to a specific PIM neighbor.
候補RP-広告メッセージはBSRへのユニキャストです。通常ブートストラップメッセージは、特定のPIMネイバーにユニキャストすることができる、ブートストラップメッセージがALL-PIM-ルータ群にTTL 1でマルチキャストされるが、いくつかの状況では（セクション3.5.2を参照します）。
The IP source address used for Candidate-RP-Advertisement messages is a domain-wide reachable address. The IP source address used for Bootstrap messages (regardless of whether they are being originated or forwarded) is the link-local address of the interface on which the message is being sent (i.e., the same source address that the router uses for the Hello messages that it sends out that interface).
候補RP-広告メッセージに使用されるIP送信元アドレスは、ドメイン全体の到達可能なアドレスです。ブートストラップメッセージ（かかわらず、彼らが起源または転送されているかどうかの）ために使用されるIP送信元アドレスは、メッセージ、すなわち（ルータは、Helloメッセージのために使用するのと同じ送信元アドレスを送信元となるインターフェイスのリンクローカルアドレスであります）それはそのインターフェイスを送信しています。
The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS group is ff02::d.
IPv4のALL-PIM-ROUTERSグループが224.0.0.13です。 IPv6のALL-PIM-ROUTERSグループは、FF02 :: dとします。
In this section, we use the following terms defined in the PIM-SM specification [1]:
このセクションでは、我々は、PIM-SM仕様[1]で定義された次の用語を使用します。
o Encoded-Unicast format
Oエンコード・ユニキャスト・フォーマット
o Encoded-Group format
Oエンコード・グループ・フォーマット
We repeat these here to aid readability.
私たちは、読みやすさを支援するために、ここでこれらを繰り返します。
Encoded-Unicast address
エンコードされたユニキャストアドレス
An Encoded-Unicast address takes the following format:
エンコードされたユニキャストアドレスは次の形式を取ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family The PIM address family of the 'Unicast Address' field of this address.
ADDR家族このアドレスの「ユニキャストアドレス」欄のPIMアドレスファミリ。
Values of 0-127 are as assigned by the IANA for Internet Address
Families in [11]. Values 128-250 are reserved to be assigned by
the IANA for PIM-specific Address Families. Values 251 though
255 are designated for private use. As there is no assignment
authority for this space, collisions should be expected.
Encoding Type The type of encoding used within a specific Address Family. The value '0' is reserved for this field, and represents the native encoding of the Address Family.
エンコーディングは、特定のアドレスファミリ内で使用されるエンコーディングの種類を入力します。値が「0」このフィールドのために確保し、アドレスファミリのネイティブエンコーディングを表しています。
Unicast Address The unicast address as represented by the given Address Family and Encoding Type.
与えられたアドレスファミリとエンコードタイプで表されるようにユニキャストユニキャストアドレスです。
Encoded-Group address
エンコード・グループのアドレス
Encoded-Group addresses take the following format:
エンコード・グループのアドレスは次の形式を取ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type |B| Reserved |Z| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family Described above.
ADDRファミリーは、前述しました。
Encoding Type Described above.
エンコードの種類は、前述しました。
[B]IDIR bit When set, all BIDIR-capable PIM routers will operate the protocol described in [2] for the specified group range.
[B] IDIRのとき設定されたビット、全てBIDIR対応PIMルータは、指定されたグループの範囲について、[2]に記載のプロトコルを動作します。
Reserved Transmitted as zero. Ignored upon receipt.
予約ゼロとして送信します。受信時に無視されます。
Admin Scope [Z]one When set, this bit indicates that this group range is an administratively scoped range.
管理範囲[Z]一組、このビットは、このグループの範囲が管理スコープの範囲であることを示しています。
Mask Len The Mask length field is 8 bits. The value is the number of contiguous one bits that are left justified and used as a mask; when combined with the group address, it describes a range of groups. It is less than or equal to the address length in bits for the given Address Family and Encoding Type. If the message is sent for a single group, then the Mask length must equal the address length in bits for the given Address Family and Encoding Type (e.g., 32 for IPv4 native encoding and 128 for IPv6 native encoding).
マスク長フィールドは8ビットであるレンマスク。値は左寄せとマスクとして使用される隣接1つのビットの数です。グループアドレスと組み合わされたとき、それがグループの範囲が記載されています。これは、指定されたアドレスファミリとエンコードタイプのためのビットのアドレスの長さ以下です。メッセージが単一のグループのために送られている場合、マスクの長さは、指定されたアドレスファミリとエンコードタイプ（例えば、IPv4のネイティブ符号化のための32とIPv6ネイティブ符号化のための128）のためのビットのアドレスの長さに等しくなければなりません。
Group multicast Address Contains the group address.
グループのマルチキャストアドレスは、グループアドレスが含まれています。
A Bootstrap message may be divided up into 'semantic fragments' if the resulting IP datagram would exceed the maximum packet size boundaries. Basically, a single Bootstrap message can be sent as multiple semantic fragments (each in a separate IP datagram), so long as the fragment tags of all the semantic fragments comprising the message are the same. The format of a single non-fragmented message is the same as the one used for semantic fragments.
結果としてIPデータグラムは、最大パケットサイズの境界を超える場合はブートストラップメッセージは、「セマンティック」断片に分割することができます。基本的に、単一のブートストラップメッセージがあればメッセージを含むすべてのセマンティックフラグメントのフラグメントタグが同じであるように、複数のセマンティックフラグメント（別々のIPデータグラム内の各）として送信することができます。単一の非断片化されたメッセージのフォーマットは、意味論的フラグメントを使用したものと同じです。
The format of a single 'fragment' is given below:
単一「断片」のフォーマットは以下のとおりであります：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type |N| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Tag | Hash Mask Len | BSR Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSR Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Count 1 | Frag RP Cnt 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1 Holdtime | RP1 Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2 Holdtime | RP2 Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm Holdtime | RPm Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 2 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address n (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Count n | Frag RP Cnt n | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1 Holdtime | RP1 Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2 Holdtime | RP2 Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm Holdtime | RPm Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Reserved, Checksum Described in [1].
PIMバージョンは、予約済み、チェックサムは、[1]で説明しました。
Type PIM Message Type. Value is 4 for a Bootstrap message.
PIMメッセージタイプを入力します。値は、ブートストラップメッセージの4です。
[N]o-Forward bit When set, this bit means that the Bootstrap message fragment is not to be forwarded.
[N]のセットは、このビットがブートストラップメッセージフラグメントが転送されるべきではないことを意味Oフォワードビット。
Fragment Tag A randomly generated number, acts to distinguish the fragments belonging to different Bootstrap messages; fragments belonging to same Bootstrap message carry the same 'Fragment Tag'.
フラグメントタグランダムに生成された番号は、別のブートストラップメッセージに属するフラグメントを区別するように作用します。同じブートストラップメッセージに属するフラグメントは、同じ「フラグメントタグ」を運びます。
Hash Mask Len The length (in bits) of the mask to use in the hash function. For IPv4, we recommend a value of 30. For IPv6, we recommend a value of 126.
マスクのハッシュマスクレン長さ（ビット単位）はハッシュ関数で使用します。 IPv4の場合、我々はIPv6の30の値をお勧めします、我々は126の値をお勧めします。
BSR Priority Contains the BSR priority value of the included BSR. This field is considered as a high-order byte when comparing BSR addresses. BSRs should by default set this field to 64. Note that for historical reasons, the highest BSR priority is 255 (the higher the better), whereas the highest RP Priority (see below) is 0 (the lower the better).
BSRプライオリティは含まBSRのBSRプライオリティ値が含まれています。 BSRアドレスを比較した場合、このフィールドは上位バイトとして考えられています。 BSRのは、デフォルトでは（下記参照）歴史的な理由のために、最高のBSRの優先順位が最も高いRPの優先順位のに対し、（高い良い）255であることを64注意にこのフィールドを設定する必要があります0（低良い）です。
BSR Address The address of the bootstrap router for the domain. The format for this address is given in the Encoded-Unicast address in [1].
BSRは、ドメインのブートストラップルーターのアドレス。このアドレスのフォーマットは、[1]に符号化・ユニキャストアドレスで与えられます。
Group Address 1..n The group ranges (address and mask) with which the Candidate-RPs are associated. Format described in [1]. In a fragment containing admin-scope ranges, the first group range in the fragment MUST satisfy the following conditions:
候補RPが関連付けられているグループ範囲（アドレスとマスク）1..nのグループアドレス。形式[1]に記載しました。管理スコープの範囲を含む断片は、断片の最初のグループの範囲は、以下の条件を満たさなければなりません。
o it MUST have the Admin Scope Zone bit set;
o for IPv4, it MUST be the group range for the entire admin-
scope range (this is required even if there are no RPs in the
RP-Set for the entire admin-scope range -- in this case, the
sub-ranges for the RP-Set are specified later in the fragment
along with their RPs);
o for IPv6, the Mask Len MUST be at least 16 and have the scope
ID of the admin-scope range.
RP Count 1..n The number of Candidate-RP addresses included in the whole Bootstrap message for the corresponding group range. A router does not replace its old RP-Set for a given group range until/unless it receives 'RP-Count' addresses for that range; the addresses could be carried over several fragments. If only part of the RP-Set for a given group range was received, the router discards it without updating that specific group range's RP-Set.
候補RPアドレスの数1..nのRP数は、対応するグループ範囲の全体ブートストラップメッセージに含まれます。それはその範囲のための「RP-カウント」のアドレスを受信しない限り、/まで、ルータはその古い与えられたグループ範囲のためのRP-SET代わるものではありません。アドレスは、いくつかの断片上で実行することができました。 RP-SET指定したグループ範囲のための一部のみを受信した場合、ルータは、その特定のグループ範囲のRP-設定を更新せず、それを破棄します。
Frag RP Cnt 1..m The number of Candidate-RP addresses included in this fragment of the Bootstrap message, for the corresponding group range. The 'Frag RP Cnt' field facilitates parsing of the RP-Set for a given group range, when carried over more than one fragment.
FRAG RP CNTは、対応するグループの範囲に対して、ブートストラップメッセージのこのフラグメントに含まれる候補RPアドレスの数を1..m。複数の断片を介して搬送する際「FRAG RP Cntを」フィールドは、指定されたグループの範囲に対してRP-セットの解析を容易にします。
RP address 1..m The address of the Candidate-RPs, for the corresponding group range. The format for these addresses is given in the Encoded-Unicast address in [1].
RPアドレス1..m対応するグループ範囲の候補のRPのアドレス。これらのアドレスのフォーマットは、[1]に符号化・ユニキャストアドレスで与えられます。
RP1..m Holdtime The Holdtime (in seconds) for the corresponding RP. This field is copied from the 'Holdtime' field of the associated RP stored at the BSR.
対応するRPのためRP1..mホールドタイムザ・ホールドタイム（秒単位）。このフィールドは、BSRに格納されている関連したRPの「ホールドタイム」フィールドからコピーされます。
RP1..m Priority The 'Priority' of the corresponding RP and Encoded-Group Address. This field is copied from the 'Priority' field stored at the BSR when receiving a C-RP-Adv message. The highest priority is '0' (i.e., unlike BSR priority, the lower the value of the 'Priority' field, the better). Note that the priority is per RP and per Group Address.
RP1..mプライオリティ対応RPおよびエンコード・グループアドレスの「優先順位」。このフィールドは、C-RP-ADVメッセージを受信した場合BSRに格納されている「優先度」フィールドからコピーされます。最高の優先順位は「0」（すなわち、BSRの優先度とは異なり、より良い、「優先度」フィールドの値が小さいです）。優先順位は、RPごとにグループアドレスごとであることに注意してください。
Within a Bootstrap message, the BSR Address, all the Group Addresses, and all the RP Addresses MUST be of the same address family. In addition, the address family of the fields in the message MUST be the same as the IP source and destination addresses of the packet. This permits maximum implementation flexibility for dual-stack IPv4/IPv6 routers.
ブートストラップメッセージ内では、BSRアドレス、すべてのグループアドレス、およびすべてのRPアドレスが同じアドレスファミリである必要があります。また、メッセージ内のフィールドのアドレスファミリは、パケットのIP送信元アドレスと宛先アドレスと同じでなければなりません。これは、デュアルスタックIPv4 / IPv6ルータの最大の実装の柔軟性を可能にします。
Bootstrap messages may be split over several PIM Bootstrap Message Fragments (BSMFs); this is known as semantic fragmentation. Each of these must follow the above format. All fragments of a given Bootstrap message MUST have identical values for the Type, No-Forward bit, Fragment Tag, Hash Mask Len, BSR Priority, and BSR Address fields. That is, only the group-to-RP mappings may differ between fragments.
ブートストラップメッセージは、いくつかのPIMブートストラップメッセージフラグメント（BSMFs）に分割することができます。これは、意味断片化として知られています。これらのそれぞれは、上記のフォーマットに従わなければなりません。与えられたブートストラップメッセージのすべての断片は、タイプ、無フォワードビット、フラグメントタグ、ハッシュマスクレン、BSRプライオリティ、およびBSRアドレスフィールドに同じ値を持たなければなりません。それは、唯一のグループツーRPのマッピングは、フラグメント間で異なることがあります。
This is useful if the BSM would otherwise exceed the MTU of the link the message will be forwarded over. If one relies purely on IP fragmentation, one would lose the entire message if a single fragment is lost. By use of semantic fragmentation, a single lost IP fragment will only cause the loss of the semantic fragment that the IP fragment was part of. As described below, a router only needs to receive all the RPs for a specific group range to update that range. This means that loss of a semantic fragment, due to an IP fragment getting lost, only affects the group ranges for which the lost semantic fragment contains information.
BSMは、そうでない場合は、メッセージがオーバー転送されるリンクのMTUを超えてしまう場合に便利です。 1は、IPフラグメンテーションに純粋に依存している場合は、単一の断片が失われた場合、1は、メッセージ全体を失うことになります。セマンティックフラグメンテーションを使用することにより、単一の失われたIPフラグメントはIPフラグメントは、の一部であったセマンティックフラグメントの損失が発生します。以下に説明するように、ルータは、その範囲を更新するために、特定のグループの範囲のすべてのRPを受信する必要があります。これは、IPフラグメントによるセマンティックフラグメントの損失は、迷子ことを意味し、グループのみに影響失ったセマンティックフラグメントは情報が含まれている範囲です。
If the BSR can split up the BSM so that each group range (and all of its RP information) can fit entirely inside one BSMF, then it should do so. If a BSMF is lost, the state from the previous BSM for the group ranges from the missing BSMF will be retained. Each fragment that does arrive will update the RP information for the group ranges contained in that fragment, and the new group-to-RP mappings for those can be used immediately. The information from the missing fragment will be obtained when the next BSM is transmitted.
各グループの範囲（およびそのRP情報のすべてが）1 BSMFの内側に完全に収まることができるようにBSRがBSMを分割することができた場合、それはそうする必要があります。 BSMFが失われた場合、グループの以前のBSMからの状態が欠落しているBSMFが保持されますの範囲です。到着しない各断片は、その断片に含まれるグループの範囲についてRP情報を更新し、それらのための新しいグループとRPのマッピングは、直ちに使用することができます。次BSMが送信されるときに欠落フラグメントからの情報が得られるであろう。
If the list of RPs for a single group range is long, one may split the information across multiple BSMFs to avoid IP fragmentation. In this case, all the BSMFs comprising the information for that group range must be received before the group-to-RP mapping in use can be modified. This is the purpose of the RP Count field -- a router receiving BSMFs from the same BSM (i.e., that have the same fragment tag) must wait until BSMFs providing RP Count RPs for that group range have been received before the new group-to-RP mapping can be used for that group range. If a single BSMF from such a large group range is lost, then that entire group range will have to wait until the next BSM is originated. Hence, in this case, the benefit of using semantic fragmentation is dubious.
単一グループ範囲のためのRPのリストが長い場合、1はIP断片化を避けるために、複数のBSMFs間で情報を分割することができます。使用中のグループとRPのマッピングを変更することができる前に、この場合には、そのグループの範囲の情報を含むすべてのBSMFsが受信されなければなりません。これは、RP Countフィールドの目的です - ルータは（すなわち、同じフラグメントタグを持っている）、そのグループの範囲のためのRPカウントRPを提供BSMFsが新しいグループに前に受信されるまで待たなければなりません同じBSMからBSMFsを受け取ります-RPマッピングは、そのグループの範囲に使用することができます。このような大規模なグループ範囲から単一BSMFが失われた場合、そのグループ全体の範囲は、次のBSMが発信されるまで待機する必要があります。従って、この場合には、意味論的断片を使用する利点は、疑わしいあります。
Next we need to consider how a BSR would remove group ranges. A router receiving a set of BSMFs cannot tell if a group range is missing. If it has seen a group range before, it must assume that that group range still exists, and that the BSMF describing that group range has been lost. The router should retain this information for BS_Timeout. Thus, for a BSR to remove a group range, it should include that group range, but with an RP Count of zero, and it should resend this information in each BSM for BS_Timeout.
次はBSRは、グループ範囲を削除する方法を検討する必要があります。グループ範囲が欠落している場合BSMFsのセットを受信したルータは言うことができません。それは前のグループの範囲を見ている場合は、そのグループの範囲がまだ存在すると仮定し、BSMFは、グループ範囲が失われたことを記述している必要があります。ルータはBS_Timeoutために、この情報を保持する必要があります。したがって、グループ範囲を除去するBSRのためには、グループの範囲でなく、ゼロのRP数に含める必要があり、それはBS_Timeout各BSMにこの情報を再送信すべきです。
Candidate-RP-Advertisement messages are periodically unicast from the C-RPs to the BSR.
候補RP-広告メッセージを定期的にBSRにC-RPSからユニキャストされています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Count | Priority | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address n (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Reserved, Checksum Described in [1].
PIMバージョンは、予約済み、チェックサムは、[1]で説明しました。
Type PIM Message Type. Value is 8 for a Candidate-RP-Advertisement message.
PIMメッセージタイプを入力します。値は、候補RP-広告メッセージの8です。
Prefix Count The number of Encoded-Group Addresses included in the message; indicating the group range for which the C-RP is advertising. C-RPs MUST NOT send C-RP-Adv messages with a Prefix Count of '0'.
プレフィックスは、メッセージに含まれる符号化・グループアドレスの数を数えます。 C-RPが広告されたグループの範囲を示します。 C-RPは「0」のプレフィックスカウントとC-RP-Advメッセージを送ってはいけません。
Priority The 'Priority' of the included RP, for the corresponding Encoded- Group Address (if any). The highest priority is '0' (i.e., the lower the value of the 'Priority' field, the higher the priority). This field is stored at the BSR upon receipt along with the RP address and corresponding Encoded-Group Address.
対応Encoded-グループアドレス（もしあれば）のための優先順位が含まRPの「優先順位」、。最高の優先度は「0」（すなわち、「優先度」フィールドの低い値は、より高い優先度）です。このフィールドは、RPアドレスと対応する符号化・グループアドレスと共に受信時にBSRに格納されています。
Holdtime The amount of time (in seconds) the advertisement is valid. This field allows advertisements to be aged out. This field should be set to 2.5 times C_RP_Adv_Period.
広告が有効である時間（秒単位）をホールドタイム。このフィールドは、広告が期限切れにすることができます。このフィールドは、2.5倍のC_RP_Adv_Periodに設定する必要があります。
RP Address The address of the interface to advertise as a Candidate-RP. The format for this address is given in the Encoded-Unicast address in [1].
RPインターフェイスのアドレスが候補RPとしてアドバタイズするアドレス。このアドレスのフォーマットは、[1]に符号化・ユニキャストアドレスで与えられます。
Group Address-1..n The group ranges for which the C-RP is advertising. Format described in Encoded-Group-Address in [1].
グループアドレス-1..nのグループは、C-RPは、広告されている範囲です。でエンコード・グループアドレスに記述フォーマット[1]。
Within a Candidate-RP-Advertisement message, the RP Address and all the Group Addresses MUST be of the same address family. In addition, the address family of the fields in the message MUST be the same as the IP source and destination addresses of the packet. This permits maximum implementation flexibility for dual-stack IPv4/IPv6 routers.
候補RP-広告メッセージの中で、RPアドレスと、すべてのグループのアドレスは、同じアドレスファミリーのものでなければなりません。また、メッセージ内のフィールドのアドレスファミリは、パケットのIP送信元アドレスと宛先アドレスと同じでなければなりません。これは、デュアルスタックIPv4 / IPv6ルータの最大の実装の柔軟性を可能にします。
Timer Name: Bootstrap Timer (BST(Z))
タイマー名：ブートストラップ時間（BST（Z））
+------------------+-------------------------+----------------------+
| Value Name | Value | Explanation |
+------------------+-------------------------+----------------------+
| BS_Period | Default: 60 seconds | Periodic interval |
| | | with which BSMs |
| | | are normally |
| | | originated |
+------------------+-------------------------+----------------------+
| BS_Timeout | Default: 130 seconds | Interval after |
| | | which a BSR is |
| | | timed out if no |
| | | BSM is received |
| | | from that BSR |
+------------------+-------------------------+----------------------+
| BS_Min_Interval | Default: 10 seconds | Minimum interval |
| | | with which BSMs |
| | | may be originated |
+------------------+-------------------------+----------------------+
| BS_Rand_Override | see below | Randomized |
| | | interval used to |
| | | reduce control |
| | | message overhead |
| | | during BSR |
| | | election |
+------------------+-------------------------+----------------------+
Note that BS_Timeout MUST be larger than BS_Period, even if their values are changed from the defaults. We recommend that BS_Timeout is set to 2 times BS_Period plus 10 seconds.
それらの値がデフォルトから変更されていてもBS_Timeoutは、BS_Periodより大きくなければならないことに留意されたいです。私たちは、BS_Timeoutが2回BS_Periodプラス10秒に設定されていることをお勧めします。
BS_Rand_Override is calculated using the following pseudocode, in which all values are in units of seconds. The values of BS_Rand_Override generated by this pseudocode are between 5 and 23 seconds, with smaller values generated if the C-BSR has a high bootstrap weight, and larger values generated if the C-BSR has a low bootstrap weight.
BS_Rand_Overrideすべての値は秒単位でされた以下の疑似コードを使用して計算されます。この擬似コードによって生成されるBS_Rand_Overrideの値はC-BSRが高いブートストラップ量を有する場合に生成小さな値、及びC-BSRが低いブートストラップ量を有する場合に生成大きな値で、5〜23秒の間です。
BS_Rand_Override = 5 + priorityDelay + addrDelay
BS_Rand_Override = 5 + priorityDelay + addrDelay
where priorityDelay is given by:
priorityDelayはで与えられます：
priorityDelay = 2 * log_2(1 + bestPriority - myPriority)
priorityDelay = 2 * log_2（1 + bestPriority - myPriority）
and addrDelay is given by the following for IPv4:
そしてaddrDelayは、IPv4のために、以下の式で与えられます。
if (bestPriority == myPriority) { addrDelay = log_2(1 + bestAddr - myAddr) / 16 } else { addrDelay = 2 - (myAddr / 2^31) }
（bestPriority == myPriority）であれば{addrDelay = log_2（1 + bestAddr - MYADDR）/ 16}他{addrDelay = 2 - （MYADDR / 2 ^ 31）}
and addrDelay is given by the following for IPv6:
そしてaddrDelayは、IPv6のために、以下の式で与えられます。
if (bestPriority == myPriority) { addrDelay = log_2(1 + bestAddr - myAddr) / 64 } else { addrDelay = 2 - (myAddr / 2^127) }
IF（bestPriority == myPriority）{addrDelay = log_2（1 + bestAddr - MYADDR）/ 64}他{addrDelay = 2 - （MYADDR / 2 ^ 127）}
and bestPriority is given by:
そしてbestPriorityは次式で与えられます。
bestPriority = max(storedPriority, myPriority)
bestPriority = MAX（storedPriority、myPriority）
and bestAddr is given by:
そしてbestAddrは次式で与えられます。
bestAddr = max(storedAddr, myAddr)
bestAddr = MAX（storedAddr、MYADDR）
and where myAddr is the Candidate-BSR's address, storedAddr is the stored BSR's address, myPriority is the Candidate-BSR's configured priority, and storedPriority is the stored BSR's priority.
MYADDRは、候補BSRのアドレスである場合と、storedAddrは、格納されたBSRのアドレスであり、myPriorityは、候補BSRの構成の優先順位であり、そしてstoredPriorityは、格納されたBSRの優先順位です。
Timer Name: Scope Zone Expiry Timer (SZT(Z))
タイマー名：範囲ゾーン有効期限タイマー（SZT（Z））
+---------------+---------------------------+-----------------------+
| Value Name | Value | Explanation |
+---------------+---------------------------+-----------------------+
| SZ_Timeout | Default: 1300 seconds | Interval after |
| | | which a scope zone |
| | | is timed out if no |
| | | BSM is received |
| | | for that scope |
| | | zone |
+---------------+---------------------------+-----------------------+
Note that SZ_Timeout MUST be larger than BS_Timeout, even if their values are changed from the defaults. We recommend that SZ_Timeout is set to 10 times BS_Timeout.
それらの値がデフォルトから変更されていてもSZ_Timeoutは、BS_Timeoutより大きくなければならないことに留意されたいです。私たちは、SZ_Timeoutが10倍BS_Timeoutに設定されていることをお勧めします。
Timer Name: Group-to-C-RP mapping Expiry Timer (CGET(M,Z))
タイマ名：グループとC-RPマッピング有効期限タイマー（CGET（M、Z））
+------------------------+-------------------+----------------------+
| Value Name | Value | Explanation |
+------------------------+-------------------+----------------------+
| C-RP Mapping Timeout | from message | Holdtime from C- |
| | | RP-Adv message |
+------------------------+-------------------+----------------------+
Timer Name: Group-to-RP mapping Expiry Timer (GET(M,Z))
タイマー名：グループ-RPマッピングの有効期限タイマー（GET（M、Z））
+-----------------------+-------------------+-----------------------+
| Value Name | Value | Explanation |
+-----------------------+-------------------+-----------------------+
| RP Mapping Timeout | from message | Holdtime from BSM |
+-----------------------+-------------------+-----------------------+
Timer Name: C-RP Advertisement Timer (CRPT)
タイマー名：C-RPの広告時間（CRPT）
+-------------------+------------------------+----------------------+
| Value Name | Value | Explanation |
+-------------------+------------------------+----------------------+
| C_RP_Adv_Period | Default: 60 seconds | Periodic interval |
| | | with which C-RP- |
| | | Adv messages are |
| | | sent to a BSR |
+-------------------+------------------------+----------------------+
| C_RP_Adv_Backoff | Default: 0-3 seconds | Whenever a |
| | | triggered C_RP_Adv |
| | | is sent, a new |
| | | randomized value |
| | | between 0 and 3 |
| | | is used |
+-------------------+------------------------+----------------------+
Threats affecting the PIM BSR mechanism are primarily of two forms: denial-of-service (DoS) attacks and traffic-diversion attacks. An attacker that subverts the BSR mechanism can prevent multicast traffic from reaching the intended recipients, can divert multicast traffic to a place where they can monitor it, and can potentially flood third parties with traffic.
PIM BSRメカニズムに影響を与える脅威は、主に次の2つの形式である：サービス拒否（DoS）攻撃とトラフィック迂回攻撃。 BSRメカニズムを覆す攻撃者は、彼らがそれを監視できる場所にマルチキャストトラフィックをそらすことができ、潜在的にトラフィックを持つ第三者をあふれさせることができ、目的の受信者に到達するマルチキャストトラフィックを防ぐことができます。
Traffic can be prevented from reaching the intended recipients by one of two mechanisms:
トラフィックは、二つのメカニズムのいずれかによって受信者に到達することを防止することができます。
o Subverting a BSM, and specifying RPs that won't actually forward traffic.
BSMを覆す、およびRPを指定するOそのトラフィック実際に転送しません。
o Registering with the BSR as a C-RP, and then not forwarding traffic.
次いで、C-RPとしてBSRの登録、およびOトラフィックを転送しません。
Traffic can be diverted to a place where it can be monitored by both of the above mechanisms; in this case, the RPs would forward the traffic, but are located so as to aid monitoring or man-in-the-middle attacks on the multicast traffic.
トラフィックは、それが上記のメカニズムの両方によって監視することができる場所に転用することができます。この場合には、RPは、トラフィックを転送するだろうが、マルチキャストトラフィックをモニタリングやman-in-the-middle攻撃を支援するように配置されています。
A third party can be flooded by either of the above two mechanisms by specifying the third party as the RP, and register traffic will then be forwarded to the third party.
第三者は、RPとして第三者を指定することにより、上記の二つのメカニズムのいずれかによって浸水、およびトラフィックを登録することができ、その後、第三者に転送されます。
The third-party DoS attack above can be greatly reduced if PIM routers acting as DR do not continue to forward Register traffic to the RP in the presence of ICMP Protocol Unreachable or ICMP Host Unreachable responses. If a PIM router sending Register packets to an RP receives one of these responses to a data packet it has sent, it should rate- limit the transmission of future Register packets to that RP for a short period of time.
DRとして動作するPIMルータはICMPプロトコル到達不能またはICMPホスト到達不能応答の存在下でのRPにトラフィックを転送登録を継続していない場合は、上記のサードパーティ製のDoS攻撃を大幅に低減することができます。 RPに登録するパケットを送信するPIMルータは、それが送信したデータパケットにこれらのいずれかの応答を受信した場合、それは時間の短い期間のためにそのRPへの将来Registerパケットの送信を制限するレート - 必要があります。
As this does not affect interoperability, the precise details are left to the implementer to decide. However, we note that a router implementing such rate limiting must only do so if the ICMP packet correctly echoes part of a Register packet that was sent to the RP. If this check were not made, then simply sending ICMP Unreachable packets to the DR with the source address of the RP spoofed would be sufficient to cause a denial-of-service attack on the multicast traffic originating from that DR.
これは相互運用性には影響を与えませんので、正確な詳細を決定するために実装者に委ねられています。しかし、我々は、ルータはICMPパケットが正しくRPに送信されたRegisterパケットの一部をエコーする場合にのみ、そうしなければならない制限ような速度を実装することに注意してください。このチェックが行われていなかった場合は、単純に偽装されたRPの送信元アドレスとDRにICMP到達不能パケットを送信すると、そのDRから発信マルチキャストトラフィックにDoS攻撃を引き起こすのに十分であろう。
If a legitimate PIM router in a domain is compromised, there is little any security mechanism can do to prevent that router from subverting PIM traffic in that domain.
ドメインの正当なPIMルータが侵害された場合は、すべてのセキュリティ・メカニズムは、そのドメイン内のPIMトラフィックを破壊するから、そのルータを防ぐためにできることはほとんどありません。
Implementations SHOULD provide a per-interface configuration option where one can specify that no Bootstrap messages are to be sent out of or accepted on the interface. This should generally be configured on all PMBRs in order not to receive messages from neighboring domains. This avoids receiving legitimate messages with conflicting BSR information from other domains, and also prevents BSR attacks from neighboring domains. This option is also useful on leaf interfaces where there are only hosts present. However, the Security Considerations section of [1] states that there should be a mechanism for not accepting PIM Hello messages on leaf interfaces and that messages should only be accepted from valid PIM neighbors. There may however be additional issues with unicast Bootstrap messages; see below. In addition to dropping all multicast Bootstrap messages on PMBRs, we also recommend configuring PMBRs (both towards other domains and on leaf interfaces) to drop all unicast PIM messages (Bootstrap message, Candidate-RP Advertisement, PIM register, and PIM register stop).
実装は1つが何のブートストラップメッセージが外に送られるか、またはインターフェイス上で受け入れられていないことを指定することができますインターフェースごとの設定オプションを提供する必要があります。これは、一般に、隣接するドメインからメッセージを受信しないようにするためにすべてのPMBRsに設定されるべきです。これは、他のドメインからの競合BSR情報を正当なメッセージを受信回避し、また、隣接するドメインからBSR攻撃を防止します。また、このオプションは存在する唯一のホストがある葉のインターフェイス上で有用です。しかし、のSecurity Considerations部は、[1]葉のインターフェイス上とメッセージが唯一の有効なPIMネイバーから受け入れられるべきであるとPIM Helloメッセージを受け付けないためのメカニズムが存在すべきであると述べています。しかし、ユニキャストブートストラップメッセージとその他の問題があるかもしれません。下記参照。 PMBRs上のすべてのマルチキャストブートストラップメッセージをドロップすることに加えて、我々はまた、すべてのユニキャストPIMメッセージ（ブートストラップメッセージ、候補-RP広告、PIMレジスタ、およびPIMレジスタ停止）をドロップする（他のドメインに向けて、葉のインターフェイス上の両方）PMBRsの設定をお勧めします。
There are some possible security issues with unicast Bootstrap messages. The Bootstrap Message Processing Checks prevent a router from accepting a Bootstrap message from outside of the PIM Domain, as the source address on Bootstrap messages must be an immediate PIM neighbor. There is however a small window of time after a reboot where a PIM router will accept a bad Bootstrap message that is unicast from an immediate neighbor, and it might be possible to unicast a Bootstrap message to a router during this interval from outside the domain, using the spoofed source address of a neighbor. The best way to protect against this is to use the above-mentioned mechanism of configuring border and leaf interfaces to drop all bootstrap messages, including unicast messages. This can also be prevented if PMBRs perform source-address filtering to prevent packets entering the PIM domain with IP source addresses that are infrastructure addresses in the PIM domain.
ユニキャストブートストラップメッセージを持ついくつかの可能なセキュリティ上の問題があります。ブートストラップメッセージ処理チェックは、ブートストラップメッセージの送信元アドレスは、即時PIMネイバーでなければならないとして、PIMドメインの外部からブートストラップメッセージを受け入れることからルータを防ぎます。そこPIMルータがすぐ隣からのユニキャストである悪いブートストラップメッセージを受け入れる、再起動後の時間の小さなウィンドウがしかしあり、そしてドメイン外からこのインターバルの間にルータにブートストラップメッセージをユニキャストすることは可能かもしれないが、隣人の偽装された送信元アドレスを使用して。これに対して保護するための最善の方法は、ユニキャストメッセージを含むすべてのブートストラップメッセージを、ドロップする境界線と葉のインターフェイスを設定する上記のメカニズムを使用することです。 PMBRsは、PIMドメイン内のインフラアドレスであるIP送信元アドレスを持つPIMドメインに入るパケットを防ぐために、ソース・アドレス・フィルタリングを行う場合にも防止することができます。
The use of unicast Bootstrap messages is for backwards compatibility only. Due to the possible security implications, implementations supporting unicast Bootstrap messages SHOULD provide a configuration option for whether they are to be used.
ユニキャストブートストラップメッセージの使用は、後方互換性のためです。起因する潜在的なセキュリティ上の影響に、ユニキャストブートストラップメッセージをサポートする実装は、彼らが使用するかどうかのコンフィギュレーションオプションを提供する必要があります。
As mentioned above, implementations SHOULD provide a per-interface configuration option so that leaf interfaces and interfaces facing other domains can be configured to drop all Bootstrap messages. In this section, we will consider multi-access subnets where there are both multiple PIM routers in a PIM domain and PIM routers outside the PIM domain or non-trusted hosts. On such subnets, one should (if possible) configure the PMBRs to drop Bootstrap messages. This is possible provided that the routers in the PIM domain receive Bootstrap messages on other internal subnets. That is, for each of the routers on the multi-access subnet that are in our domain, the RPF interface for each of the Candidate-BSR addresses must be an internal interface (an interface not on a multi-access subnet). There are however network topologies where this is not possible. For such topologies, we recommend that IPsec Authentication Header (AH) is used to protect communication between the PIM routers in the domain, and that such routers are configured to drop and log communication attempts from any nodes that do not pass the authentication check. When all the PIM routers are under the same administrative control, this authentication may use a configured shared secret. In order to prevent replay attacks, one will need to have one security association (SA) per sender and use the sender address for SA lookup. The securing of interactions between PIM neighbors is discussed in more detail in the Security Considerations section of [1], and so we do not discuss the details further here. The same security mechanisms that can be used to secure PIM Join, Prune, and Assert messages should also be used to secure Bootstrap messages. How exactly to secure PIM link-local messages is still being worked on by the PIM working group; see [10].
上述したように、他のドメインに対向するリーフインターフェイスとインターフェイスは、すべてのブートストラップメッセージをドロップするように構成することができるように、実装は、インターフェースごとの設定オプションを提供すべきです。このセクションでは、PIMドメインまたは信頼できないホスト外の複数のPIM PIMドメイン内のルータとのPIMルータの両方が存在するマルチアクセスサブネットを検討します。このようサブネット上で、一つは（可能な場合）ブートストラップメッセージをドロップするPMBRsを設定する必要があります。これは、PIMドメイン内のルータは、他の内部のサブネット上のブートストラップメッセージを受信することを提供することも可能です。それが私たちのドメイン内にあるマルチアクセスサブネット上の各ルータのために、である、候補BSRアドレスのそれぞれについて、RPFインターフェイスは内部インターフェイス（マルチアクセスサブネット上のインターフェイスではない）でなければなりません。これが不可能であるしかし、ネットワークトポロジがあります。このようなトポロジのために、我々は、IPsec認証ヘッダ（AH）は、ドメイン内のPIMルータ間の通信を保護するために使用されることをお勧めし、そのようなルータは、認証チェックに合格しない任意のノードから通信試行を削除してログするように構成されています。すべてのPIMルータが同じ管理制御下にある場合は、この認証が設定した共有秘密鍵を使用することができます。リプレイ攻撃を防ぐために、1は、送信者ごとにセキュリティアソシエーション（SA）を持っており、SA検索の送信者アドレスを使用する必要があります。 PIMネイバー間の相互作用の固定は、[1]のSecurity Considerations部で詳しく説明されており、私たちは、ここでは詳細は説明しません。 、PIM参加確保プルーン、およびメッセージをアサートするために使用することができ、同じセキュリティ・メカニズムは、ブートストラップメッセージを保護するために使用されるべきです。どのように正確にはまだPIMワーキンググループが作業しているPIMリンクローカルメッセージを確保します。 [10]を参照してください。
Even if it is not possible to subvert Bootstrap messages, an attacker might be able to perform most of the same attacks by simply sending C-RP-Adv messages to the BSR specifying the attacker's choice of RPs. Thus, it is necessary to control the sending of C-RP-Adv messages in essentially the same ways that we control Bootstrap messages. However, C-RP-Adv messages are unicast and normally travel multiple hops, so controlling them is more difficult.
それはブートストラップメッセージを覆すことはできない場合でも、攻撃者は単にのRPの攻撃者の選択を指定するBSRにC-RP-Advメッセージを送信することにより、同じ攻撃のほとんどを実行することができるかもしれません。したがって、我々がブートストラップメッセージを制御する本質的に同じ方法でC-RP-Advメッセージの送信を制御する必要があります。ので、それらを制御することがより困難であり、ただし、C-RP-Advメッセージは、ユニキャストであり、通常は複数のホップを旅行します。
We recommend that PMBRs are configured to drop C-RP-Adv messages. One might configure the PMBRs to drop all unicast PIM messages (Bootstrap message, Candidate-RP Advertisement, PIM register, and PIM register stop). PMBRs may also perform source-address filtering to prevent packets entering the PIM domain with IP source addresses that are infrastructure addresses in the PIM domain. We also recommend that implementations have a way of restricting which IP addresses the BSR accepts C-RP-Adv messages from. The BSR can then be configured to only accept C-RP-Adv messages from infrastructure addresses or the subset used for Candidate-RPs.
私たちは、PMBRsがC-RP-Advメッセージをドロップするように設定されていることをお勧めします。一つは、すべてのユニキャストPIMメッセージ（ブートストラップメッセージ、候補RP-広告、PIMレジスタ、およびPIMレジスタ停止）をドロップするPMBRsを構成することができます。 PMBRsも、PIMドメイン内のインフラアドレスであるIP送信元アドレスを持つPIMドメインに入るパケットを防ぐために、ソース・アドレス・フィルタリングを行うことができます。我々はまた、BSRからC-RP-Advメッセージを受け入れ、実装はIPアドレスが制限の方法を持っていることをお勧めします。 BSRは、その後だけ候補RPのために使用されるインフラストラクチャ・アドレスまたはサブセットからC-RP-ADVメッセージを受け入れるように構成することができます。
If the unicast and multicast topologies are known to be congruent, the following checks should be made. On interfaces that are configured to be leaf subnets, all C-RP-Adv messages should be dropped. On multi- access subnets with multiple PIM routers and hosts that are not trusted, the router can at least check that the source Media Access Control (MAC) address is that of a valid PIM neighbor.
ユニキャストおよびマルチキャストトポロジが合同であることが知られている場合、以下のチェックがなされるべきです。葉のサブネットになるように構成されたインターフェイス上で、すべてのC-RP-ADVメッセージは廃棄されるべきです。信頼されていない複数のPIMルータとホストとのマルチアクセスサブネットに、ルータは、少なくともソースメディアアクセス制御（MAC）アドレスが有効PIMネイバーのものであることを確認することができます。
For true security, we recommend that all C-RPs are configured to use IPsec authentication. The authentication process for a C-RP-Adv message between a C-RP and the BSR is identical to the authentication process for PIM Register messages between a DR and the relevant RP, except that there will normally be fewer C-RPs in a domain than there are DRs, so key management is a little simpler. We do not describe the details of this process further here, but refer to the Security Considerations section of [1]. Note that the use of cryptographic security for C-RP-Adv messages does not remove the need for the non-cryptographic mechanisms, as explained above.
真のセキュリティを確保するために、我々は、すべてのC-RPはIPsec認証を使用するように設定されていることをお勧めします。 C-RPとBSRの間のC-RP-ADVメッセージは、通常、ドメイン内の少数C-RPSが存在するであろうことを除いて、DRと関連RPとの間のPIM登録メッセージの認証プロセスと同じであるため、認証プロセスDRがあるよりも、その鍵の管理は少し単純です。私たちは、ここでさらに、このプロセスの詳細を説明しますが、[1]のSecurity Considerations部を指すものではありません。上述したようにC-RP-Advメッセージの暗号化セキュリティの使用は、非暗号化メカニズムの必要性を削除しないことに注意してください。
An additional concern is that of denial-of-service attacks caused by sending high volumes of Bootstrap messages or C-RP-Adv messages with invalid IPsec authentication information. It is possible that these messages could overwhelm the CPU resources of the recipient.
追加の懸念は、ブートストラップメッセージまたは無効なIPsecの認証情報とC-RP-Advメッセージの高いボリュームを送信することにより生じたサービス拒否攻撃のことです。これらのメッセージは、受信者のCPUリソースを圧倒する可能性があります。
The non-cryptographic security mechanisms above restrict from where unicast Bootstrap messages and C-RP-Adv messages are accepted. In addition, we recommend that rate-limiting mechanisms can be configured, to be applied on receipt of unicast PIM packets. The rate-limiter MUST independently rate-limit different types of PIM packets -- for example, a flood of C-RP-Adv messages MUST NOT cause a rate limiter to drop low- rate Bootstrap messages. Such a rate-limiter might itself be used to cause a denial-of-service attack by causing valid packets to be dropped, but in practice this is more likely to constrain bad PIM messages. The rate-limiter will prevent attacks on PIM from affecting other activity on the receiving router, such as unicast routing.
上記非暗号化セキュリティメカニズムは、ユニキャストブートストラップメッセージとC-RP-ADVメッセージが受け入れられる場所から制限します。加えて、我々は、レート制限メカニズムはユニキャストPIMパケットの受信時に適用されるように、構成することができることをお勧めします。レートリミッタは、独立してレートを制限しなければならないPIMパケットの種類を - 例えば、C-RP-Advメッセージの洪水は、レートリミッタは、低レートのBootstrapメッセージを低下させてはなりません。このようなレートリミッタ自体は有効なパケットがドロップさせることにより、サービス拒否攻撃を引き起こすために使用されるかもしれないが、実際にはこれは悪いPIMメッセージを制約する可能性が高いです。レートリミッタは、ユニキャストルーティングのように、受信ルータ上の他の活動に影響を与えるからPIMへの攻撃を防ぐことができます。
Bill Fenner, Mark Handley, Roger Kermode, and David Thaler have contributed greatly to this document. They were authors of this document up to version 03, and much of the current text comes from version 03.
ビルフェナー、マーク・ハンドリー、ロジャーKermode、とDavidターラーは、本文書に大きく貢献してきました。彼らは、バージョン03までの、この文書の著者だった、と現在のテキストの多くは、バージョン03から来ています。
PIM-SM was designed over many years by a large group of people, including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas, and Hugh Holbrook. This BSR specification draws heavily on text from RFC 2362.
PIM-SMはデボラ・エストリン、ディノファリナッチ、アーメド・ヘルミー、スティーブデアリング、バン・ジェイコブソン、C.劉、Puneetシャルマ、黎明魏、トムPusateri、トニー・Ballardie、スコットからのアイデアを含む人々の大規模なグループで長年にわたり設計されましたブリム、ジョンクロウクロフト、ポール・フランシス、ジョエル・ハルパーン、ホルストHodel、ポリー黄、スティーブンOstrowski、Lixiaチャン、Girish Chandranmenon、Pavlin Radoslavov、ジョンZwiebel、イジドールKouvelas、そしてヒュー・ホルブルック。このBSR仕様はRFC 2362からテキストに大きく描画します。
Many members of the PIM Working Group have contributed comments and corrections for this document, including Christopher Thomas Brown, Ardas Cilingiroglu, Murthy Esakonu, Venugopal Hemige, Prashant Jhingran, Rishabh Parekh, and Katta Sambasivarao.
PIMワーキンググループの多くのメンバーは、クリストファー・トーマス・ブラウン、Ardas Cilingiroglu、マーシーEsakonu、Venugopal Hemige、のPrashant Jhingran、Rishabh Parekhの、そして刈田Sambasivaraoを含め、この文書に関するコメントや修正を貢献してきました。
[1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[1]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月を。
[2] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[2]ハンドレー、M.、Kouvelas、I.、スピークマン、T.、およびL. Vicisano、 "双方向プロトコル独立マルチキャスト（BIDIR-PIM）"、RFC 5015、2007年10月。
[3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[3]マイヤー、D.、 "管理用スコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。
[4] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[4]デアリング、S.、ハーバーマン、B.、神明、T.、Nordmarkと、E.、およびB. Zill、 "IPv6のスコープアドレスアーキテクチャ"、RFC 4007、2005年3月。
[5] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[5] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[7] Estrin, D., et al., "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[7] Estrin、D.、ら、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様"、RFC 2362、1998年6月。
[8] 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.
[8]キム、D.、マイヤー、D.、キルマー、H.、およびD.ファリナッチ、 "プロトコル独立マルチキャスト（PIM）とMulticast Source Discovery Protocol（MSDP）を使用して、エニーキャストRendevousポイント（RP）機構"、RFC 3446 、2003年1月。
[9] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006.
[9]ファリナッチ、D.およびY.カイ、 "Protocol Independent Multicast（PIM）を使用してエニーキャスト-RP"、RFC 4610、2006年8月。
[10] Atwood, W. and S. Islam, "Security Issues in PIM-SM Link-local Messages", Work in Progress, July 2007.
[10]アトウッド、W.および "PIM-SMリンクローカルメッセージでセキュリティの問題" S.イスラム教、進歩、2007年7月の作業。
[11] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[11] IANA、 "アドレスファミリ番号"、<http://www.iana.org/assignments/address-family-numbers>。
Authors' Addresses
著者のアドレス
Nidhi Bhaskar Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303 USA EMail: nidhi@arastra.com
基金タイムズArsatrこれを。 Pkok 10905パロアルト、94303 Eメールボックス：निधि@ारास्त्र.कॉम
Alexander Gall SWITCH P.O. Box CH-8021 Zurich Switzerland EMail: alexander.gall@switch.ch
アレクサンダーガルスイッチの私書箱ボックスCH-8021チューリッヒスイスメール：alexander.gall@switch.ch
James Lingard Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303 USA EMail: jchl@arastra.com
ジェームズ・リンガードArastra、株式会社私書箱ボックス10905パロアルト、CA 94303 USA電子メール：jchl@arastra.com
Stig Venaas UNINETT NO-7465 Trondheim Norway EMail: venaas@uninett.no
スティグVenaas UNINETT NO-7465トロンハイムノルウェーEメール：venaas@uninett.no
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。