[要約] RFC 5059は、プロトコル非依存マルチキャスト（PIM）のためのブートストラップルータ（BSR）メカニズムについての規格です。その目的は、マルチキャストグループの情報を効率的に配布し、ネットワークのスケーラビリティと柔軟性を向上させることです。
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)
プロトコル独立マルチキャスト（PIM）のブートストラップルーター（BSR）メカニズム
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は、マルチキャストルーターが機能するために必要なグループ間マッピングのセットを学習できる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]および双方向のプロトコル独立マルチキャスト（Bidir-PIM）[2]の概念にある程度精通しているだけでなく、管理的にスコープされたIPマルチキャスト[3]および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仕様は、このグループ間マッピングを実行するための情報をルーターに提供するための単一のメカニズムの使用を義務付けていません。
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は、マルチキャストルーターがグループ間マッピングを実行するために必要な情報を学習できる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は、RFC 2362 [7]で、RFC 4601 [1]によって廃止された元のPIM-SM仕様の一部として最初に定義されました。このドキュメントは、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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セットと呼ばれるグループ間マッピングのコレクションを維持します。グループ間マッピングには、次の要素が含まれています。
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の1つのみを選択して、ドメイン内のすべてのルーターが同じ選択をするようにします。このアルゴリズムは、BSR仕様ではなく、個々のルーティングプロトコルの仕様の一部である（およびそれらの間で異なる場合がある）ことに注意することが重要です。たとえば、PIM-SM [1]はそのようなアルゴリズムの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.
このようなグループ間マッピングを確立できる方法はいくつかあります。最も単純なソリューションは、ドメイン内のすべてのルーターが同じ情報で静的に構成されることです。ただし、静的構成は一般に十分にスケーリングされません。Anycast-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メカニズムは、実行可能なグループ間マッピングを作成し、ドメイン内のすべての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ルーターの一部がドメインの潜在的なRPSに設定されていることです。これらは候補RPS（C-RPS）と呼ばれます。C-RPSのサブセットは、最終的にドメインの実際のRPSとして使用されます。さらに、ドメイン内の一部のPIMルーターは、候補のブートストラップルーター、または候補BSR（C-BSR）として構成されています。これらのC-BSRの1つは、ドメインのブートストラップルーター（BSR）に選出され、ドメイン内のすべてのPIMルーターがブートストラップメッセージを通じてこの選挙の結果を学習します。次に、C-RPSは、これらのC-RPのサブセットを選択し、Bootstrapメッセージを介してドメイン内のすべてのルーターに対応するグループ間マッピングを分布させる選出された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優先度フィールドが含まれています。ドメイン内のルーターは、ドメイン全体のBSMSにflood濫します。それ自体よりも優先順位の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-Advertisement（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セット形成。BSRは、C-RP-ADVメッセージを受信してRPセットを形成する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セット洪水。将来のブートストラップメッセージでは、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.
PIMルーターがブートストラップメッセージを受信すると、他のソースから取得したマッピングのプールに含まれるグループ間マッピングを追加します（例：静的構成）。特定のルーティングプロトコルに固有のルールに従って、このプールからRPアドレスへのグループアドレスの最終マッピングを計算し、その情報を使用してマルチキャスト配布ツリーを構築します。
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から分離された各領域は独自のBSRを選択し、そのパーティション内で到達可能なRPセットを含むRPセットを配布します。パーティションが癒されると、別の選挙が自動的に発生し、BSRの1つだけがBootstrapメッセージを送信し続けます。パーティションまたはヒーリングの時点で予想されるように、パケット配信の混乱が発生する可能性があります。破壊期間の期間は、地域の往復時間と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）によって形成されます。ZBRは、スコープゾーンに出入りするスコープグループアドレスのいずれのトラフィックを転送しないように構成されています。特定のスコープ境界が常に少なくとも2つのスコープゾーンを作成することに注意することが重要です。1つは境界の両側に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アドレスの範囲に5つのマップのスコープID FF [0-F] 5 ::/16。
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.
管理ゾーン内のPIMルーターがスコープゾーンの外側のRPを使用したくないため、管理スコーピングは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は通常、すべての管理者スコープゾーンのBSRに登録され、すべてのPIMルーターはそれがあるすべてのスコープゾーンのブートストラップメッセージを受信します。特定のスコープゾーンにBSRが送信したメッセージには、そのスコープゾーンに関連付けられたアドレスのセットに使用する必要があるRPSに関する情報が含まれています。
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が必要であり、少なくとも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.
管理スコーピングが使用されている場合でも、管理上スコープされていないグループのRP情報を配布するために、BSRメカニズムのコピーが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.
Sc-BSRとZBRのみを構成する必要があります。スコープゾーンの存在を知る必要があります。C-RPSを含む他のルーターは、ブートストラップメッセージからその存在を学びます。
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のみを実装するPIMルーター（ドメインごとに1つのBSRのみを許可します）は、PIMドメインの管理者スコープゾーン内では使用できません。
A PIM router implementing BSR holds the following state.
BSRを実装するPIMルーターが次の状態を保持します。
RP-Set
RPセット
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
現在のBSRから受信した最後のBSM
Bootstrap Timer (BST(Z))
ブートストラップタイマー（BST（Z））
Per group-to-RP mapping (M):
Group-to-RPマッピングごと（M）：
Group-to-RP mapping Expiry Timer (GET(M,Z))
Group-to-RPマッピングExpiry Timer（get（m、z））
At a Candidate-BSR for Z:
Zの候補BSRで：
My state: One of "Candidate-BSR", "Pending-BSR", "Elected-BSR"
私の状態：「候補者-BSR」、「保留中のBSR」、「Elected-BSR」の1つ
At a router that is not a Candidate-BSR for Z:
Zの候補BSRではないルーターで：
My state: One of "Accept Any", "Accept Preferred"
私の状態：「受け入れる」、「希望を受け入れる」の1つ
Scope-Zone Expiry Timer (SZT(Z))
Scope-Zone Expiry Timer（SZT（Z））
At the current Bootstrap Router for Z only:
Zのみの現在のブートストラップルーターでのみ：
Per group-to-C-RP mapping (M):
Group-to-C-RPマッピング（M）ごとに：
Group-to-C-RP mapping Expiry Timer (CGET(M,Z))
Group-to-C-RPマッピングExpiry Timer（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セット分布メカニズムの両方でブートストラップメッセージが使用されます。
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.
各ブートストラップメッセージは、それが属する範囲を示します。Admin Scope ZoneビットがBootstrapメッセージの最初のグループ範囲に設定されている場合、メッセージはスコープ付きBSMと呼ばれます。Admin Scope ZoneビットがBootstrapメッセージの最初のグループ範囲に設定されていない場合、メッセージは非スコープ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では、メッセージの範囲は、メッセージの最初のグループ範囲によって与えられます。スコープ付きIPv6 BSMでは、メッセージの範囲は、メッセージ内の最初のグループ範囲の範囲IDで与えられます。これには、少なくとも16のマスク長が必要です。たとえば、FF05 ::/16のグループ範囲は管理スコープゾーンビットセットは、ブートストラップメッセージがスコープID 5のスコープ用であることを示します。ScopedIPv6BSMの最初のグループ範囲のマスクの長さが16未満である場合、メッセージをドロップし、警告を記録する必要があります。
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の重みは、BOOTSTRAPメッセージからのBSR優先フィールドの固定前符号なしの算術とBSRのIPアドレス（BOOTSTRAPメッセージからのBSRのIPアドレス）の連結と定義されています（BSRの優先順位が最も重要なビットとビットを取得します。最も重要でないビットを取得する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:
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.
保留中のBSR（P-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.
Elected-BSR（E-BSR）ルーターは、スコープゾーンの選出されたBSRであり、すべてのBSR関数を実行する必要があります。
In addition to the three states, there is one timer:
3つの状態に加えて、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.
o ブートストラップタイマー（BST） - 古いブートストラップルーター情報のタイムアウトに使用され、選挙プロセスで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である場合と、後で1つになるように再構成されている場合の場合です。
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.
（AA）を受け入れるルーターは、アクティブなBSRを知らず、新しいBSRのアイデンティティとRPセットを提供すると見なす最初のブートストラップメッセージを受け入れます。
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.
Acputed Preferred（AP）ルーターは現在のBSRのアイデンティティを知っており、そのBSRが提供するRPセットを使用しています。そのBSRまたは現在のBSRよりも高い重量のC-BSRからのブートストラップメッセージのみが受け入れられます。
In addition to the three states, there are two timers:
3つの州に加えて、2つのタイマーがあります。
o The Bootstrap Timer (BST) - used to time out old bootstrap router information.
o ブートストラップタイマー（BST） - 古いブートストラップルーター情報のタイムアウトに使用されます。
o The Scope-Zone Expiry Timer (SZT) - used to time out the scope zone itself if Bootstrap messages specifying this scope zone stop arriving.
o Scope -Zone Expiry Timer（SZT） - このスコープゾーンが到着する停止を指定するブートストラップメッセージの場合、スコープゾーン自体のタイムアウトに使用されます。
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 「ノインフォー」状態は存在しません。
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
}
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)) {
#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
}
if (the interface the message arrived on is an admin scope
border for the BSM.first_group_address) {
drop the Bootstrap message silently
}
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.
基本的に、パケットは、アクティブなHello Stateを持っている直接接続された隣人から来たに違いありません。それはAll-PIM-Routersグループに送信されたに違いありません。それが不適当なBSMでない限り、BOOTSTRAPメッセージを発信したBSRに向かって正しいアップストリームルーターによって送信されたに違いありません。または、それが不適切なBSMである場合、最近再起動し、その管理範囲のBSR状態がないに違いありません。また、Unicast BSMサポートが有効になっている場合、Unicast 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は、現在の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.)
ルーターが候補BSRである場合、現在のBSRがルーターの重量よりも高い重量を持っている場合、ブートストラップメッセージは、以前のBSMよりも低い現在のBSRからの場合にも好まれます。自体。この場合、「現在のブートストラップルーターのBSR優先度」状態を更新する必要があります。（重量が少ない場合は、選出されたBSRケースの非優先BSMを参照してください。）
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を受信して、ブートストラップメッセージは、現在の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から非優先BSMを受信したBSRからのブートストラップメッセージは、選出されたBSRから受信されますが、受信したメッセージのBSR優先フィールドが変更されたため、現在選出されているBSRはルーター自体の重量よりも低くなっています。
Receive BSM A Bootstrap message is received, regardless of BSR weight.
BSRの重量に関係なく、BSMの受信ブートストラップメッセージが受信されます。
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は、ブートストラップのメッセージ処理チェックを通過することを許可していないマルチキャストブートストラップメッセージを、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の起源新しいブートストラップメッセージはBSRによって作成され、BSRのアドレスとBSRの優先度を与え、BSRが選択したRPセットを含みます。メッセージは、PIMの隣接が存在するすべてのインターフェイスから転送されます。ただし、これにより、BSMがメッセージに示されているスコープゾーンの管理者スコープ境界を越えます。
Store RP-Set The router uses the group-to-RP mappings contained in a BSM to update its local RP-Set.
RP-SETストアルーターは、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.
このアクションは、空のBSMのためにスキップされます。BSMは、グループ範囲が含まれていない場合、またはそのグループ範囲にAdmin Scope Zoneビットセット（スコープBSM）とRPカウントがゼロの単一のグループ範囲のみが含まれている場合に空です。
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.
マッピングがまだ存在しない場合、それが作成され、関連するグループ間マッピング有効期限タイマー（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が受信範囲にない範囲の既存のグループ間マッピングがある場合、それらのマッピングを削除する必要があることを意味します。
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-SETを更新Bootstrapタイマーの有効期限が切れると、ルーターは、アクションストアRPセットに従ってRPセットを更新するために受け取った最後のBSMのコピーを使用します。これにより、新しい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状態を削除Bootstrapタイマーの有効期限が切れると、現在のBSRに関連するすべての状態が削除されます（アドレス、優先度、BST、および最後のBSMの保存、セクション2を参照）。これには、グループ間マッピングは含まれていないことに注意してください。
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は、C-RP-ADVメッセージを状態の各スコープゾーンのBSRに定期的にユニカストし、BSRにRPとして機能する意欲をBSRに通知します。これらのメッセージは、新しい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は1〜3つのC-RP-ADVメッセージを送信し、各メッセージを送信する前に小さなランダム化期間C_RP_ADV_BACKOFFを待つ必要があります。BSRがどのRPがアクティブであるかを迅速に学習し、ネットワークの変更により新しいBSRが選出されたときにパケット損失が発生する可能性があるため、3つのメッセージを送信することをお勧めします。これを実装する1つの方法は、新しいBSRが選出されたときにCRPTをC_RP_ADV_BACKOFFに設定し、2にカウンターを設定することです。CRPTが期限切れになるたびに、最初にC-RP-ADVメッセージを通常どおり送信します。次に、カウンターが非ゼロの場合、それは減少し、CRPTはC_RP_ADV_PERIODの代わりにC_RP_ADV_BACKOFFに再び設定されます。
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.
これらのメッセージの優先フィールドは、BSRによって使用され、RPセットに含めるC-RPSを選択します。このフィールドの値が低いことは優先度が高いことを示しているため、ゼロの値が最高の優先度であることに注意してください。C-RPSは、デフォルトでは、優先フィールドを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をタイムアウトし、シャットダウンRP Holdtimeセットを0に設定して新しいブートストラップメッセージを生成します。
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メッセージには、グループアドレスとグループマスクフィールドペアのリストが含まれています。これにより、C-RPは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は、Rを「含む」最小スコープのスコープBSRに範囲を宣伝します。IPv6の場合、グループ範囲のスコープ識別子をスコープと一致させることによって含まれます。BSRの。IPv4の場合、既知の管理者スコープ範囲の中で、Rで最も長いPrefixマッチです。グループの範囲が含まれていることがわかった場合、C-RPには非スコープBSRに送信されたC-RP-ADVにそれを含めます。非スコープ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内に厳密に含まれているスコープBSRごとに、C-RPはデフォルトでBSRのスコープ範囲をそのBSRに宣伝する必要があります。プレフィックス長<16のリスト内の各IPv6グループ範囲rについて、C-RPはデフォルトでは、対応するスコープIDを使用して、プレフィックス長16の各サブレンジをスコープBSRに宣伝する必要があります。実装は、この段落で説明されている動作を防ぐための構成オプションを提供する場合がありますが、そのようなオプションはデフォルトで無効にする必要があります。
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の場合、スコープされたBSRに送信されたC-RP-ADVメッセージに含まれるすべてのグループ範囲のマスク長は> = 16でなければなりません。
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.
セキュリティ上の理由から、実装には、BSRがどのIPアドレスがアクセスするか、たとえばアクセスリストからC-RP-ADVメッセージを受け入れる方法があることをお勧めします。Scoped 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-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-SETの一部でない場合、C-RP-SETに追加され、関連するGroup-to-C-RP Mapping Expiry Timer（CGET）がC-からHoldTimeに初期化されます。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-SETの一部である場合、C-RP-ADVメッセージの優先順位で更新され、その関連するCGETはC-RP-ADVメッセージからHoldTimeにリセットされます。ホールドタイムがゼロの場合、マッピングはすぐに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.
BSR仕様の以前のバージョンと互換性があるため、グループ範囲のないC-RP-ADVメッセージは、単一のグループ範囲FF00 ::/8または224/4が含まれているかのように扱う必要があります。したがって、上記の規則によれば、ルーターが非スコープ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は、C-RPセットからRPセットを構築します。ローカルポリシーを適用して、RPセットに含まれる候補RPの数を制限する場合があります。BSRは、C-RP-ADVメッセージの「優先度」フィールドが128未満でない限り、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候補-RPの両方を知っている場合、BSRにはBSMSのプロトコルの1つにRPSのみを含める必要があります。デフォルトの動作は、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-setは{group-range、rp-count、rp-addresses}のセットに細分化されます。各RPアドレスについて、「RP-Holdtime」フィールドは、BS_PerioDよりも大きく、BS_PERIODが2.5倍である必要があるという制約を条件として、C-RP-SetからHoldTimeに設定されます。メッセージが迷子になります。C-RPセットからの一部の保留がこの制約を満たしていない場合、BSRはそれらの保留タイムを制約を満たす値に置き換える必要があります。これの例外は、ゼロの保留タイムです。これは、すぐにマッピングを引き出すために使用されます。
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-RPSとして構成することをお勧めします。
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タイマーに従って定期的に発信されます。BSMSの変更で発表されるRPセットがいつでもBSMを発信することをお勧めします。これは通常、新しいC-RPからC-RP広告を受信したとき、またはC-RPがシャットダウンされたときに発生します（ゼロの保留タイムのC-RP広告）。ただし、BSMが送信されるたびにBS_MIN_INTERVALが最小限に抑える必要があります。特に、新しいBSRが選出されると、最初に1つのBSM（まだC-RP広告を受け取っていないため空になる可能性が高い）を送信し、新しいものを送信する前に少なくともBS_MIN_INTERVALを待ちます。その間、すべての使用可能なC-RPからC-RP広告を受け取った可能性があります（C-RPは、新しいBSRが選出されたときにC_RP_ADV_BACKOFFの小さなランダム遅延を持つ1つ以上の広告を送信する必要があると言うため）。特に、ルーターが使用可能なRPセットを持たない場合があるこの場合、BS_MIN_INTERVALが合格するとすぐにBSMを発信することをお勧めします。ただし、BSRは一般にこれを行うことができることをお勧めします。これを実装する1つの方法は、RPセットが変更されるたびにブートストラップタイマーを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.
各グループからC-RPマッピングは、これらのBSMの正確な1つに含まれています。つまり、マッピングのグループ範囲がある場合、または非スコープBSMを含む最も狭いスコープのスコープBSMです。
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には少なくとも1つのグループ範囲が必要であり、スコープ付きBSMの最初のグループ範囲には、管理スコープゾーンビットが設定されている必要があります。このグループ範囲は、BSMの範囲を識別します。スコープ付きIPv4 BSMでは、最初のグループ範囲はBSMの範囲に対応する範囲です。スコープ付きIPv6 BSMでは、最初のグループ範囲は、そのようなBSMのすべてのグループの範囲が少なくとも16のマスク長を持ち、同じスコープIDを持つ必要があるという一般的な条件を条件として、任意のグループ範囲である場合があります。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優先度フィールドは可能な限り最低の優先度値に設定されています。これにより、新しい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つの例外があります。1つは、ブートストラップメッセージが設定されていない場合、ブートストラップメッセージが転送されないことです。セクション3.5.1を参照してください。もう1つは、ユニキャストBSM（セクション3.5.2を参照）が通常転送されないことです。ただし、実装者は、独自の裁量により、マルチキャストBSMでNo-forwardまたはUnicast BSMを再送信することを選択できます。リバースパス転送（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.
ホップバイホップの転送により、Bootstrapメッセージ自体が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 Neighbors（メッセージが受信されたものを含む）を含むすべてのマルチキャスト対応インターフェイスから転送されます。これの例外は、インターフェイスがブートストラップメッセージパケットの最初のグループ範囲に示されている管理者スコープゾーンの管理者スコープ境界である場合です。
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.
理論的根拠：LAN上のルーターには一貫したルーティング情報がない可能性があるため、メッセージが（他のインターフェイスに加えて）メッセージが受信されたインターフェイスからBSMを転送する必要があります。LANの3つのルーターがA、B、C、およびルーターB RPF（BSR）== AおよびルーターC RPF（BSR）== Bである場合、ルーターAは元々BSMをLANに転送しますが、RouterCは、ルーターBがLANにメッセージを再構成した場合にのみ受け入れます。基礎となるルーティングプロトコル構成が、ルーターに一貫したルーティング情報があることを保証する場合、着信インターフェイスから転送することが安全に無効になる可能性があります。
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の最初の範囲の範囲と構成された境界の範囲の比較です。IPv4の場合、スコープされたBSMの最初の範囲がチェックされて、構成された境界の範囲と同じかどうかが含まれているかどうかを確認します。
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.
新しい隣人からハローメッセージが受信された場合、または既存の隣人から新しい遺伝子を含むハローメッセージが受信されると、LAN上の1つのルーターは、各管理者スコープゾーンのブートストラップメッセージの保存コピーを新しいまたは再起動に送信しますルーター。これにより、新規または再起動するルーターがRPセットをすばやく学習できます。
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.
これを行うルーターは、LAN上の指定ルーター（DR）、または新しいまたは再起動するルーターがDRである場合、新しいまたは再起動するルーターがDR選挙プロセスから除外された場合の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.
この方法でブートストラップメッセージを送信する前に、ルーターはこのインターフェイスにトリガーされたハローメッセージが送信されるまで待つ必要があります。それ以外の場合、新しい隣人はブートストラップメッセージを破棄します。
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チェックは、No-forward 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.
後方互換性のために、実装はユニキャストブートストラップメッセージをサポートする場合があります。No-Forward Bootstrapメッセージの代わりに、またはそれに加えてUnicast Bootstrapメッセージを送信するかどうか、およびそのようなメッセージを受け入れるかどうかは、構成可能である必要があります。このメッセージは隣人にとってユニキャストです。
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セットを取得する場合があります。これらの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セットの一部のグループ間マッピングは、PIM-SMを使用する必要があるグループ範囲を示しています。その他は、Bidir-PIMで使用するグループ範囲を示しています。これらのプロトコルの1つのみをサポートするルーターは、他のプロトコル用であると示されている範囲を無視してはなりません。彼らは彼らが彼らがサポートするプロトコルのためであると扱ってはなりません。
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-SETに追加され、関連するグループ間マッピングExpiry Timer（GET）がBootstrapメッセージからHoldTimeに初期化されます。その優先順位は、ブートストラップメッセージから優先順位に設定されています。
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-Advertisement
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-advertisementメッセージは、BSRへのユニキャストです。通常、ブートストラップメッセージはマルチキャストであり、TTL 1をAll-PIM-Routersグループに合わせていますが、状況によっては（セクション3.5.2で説明されている）ブートストラップメッセージは、特定のPIMネイバーにとってユニカストである可能性があります。
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-advertisementメッセージに使用されるIPソースアドレスは、ドメイン全体の到達可能なアドレスです。ブートストラップメッセージに使用されるIPソースアドレス（それらが発信されているか転送されているかに関係なく）は、メッセージが送信されているインターフェイスのリンクローカルアドレスです（つまり、ルーターがハローメッセージに使用するのと同じソースアドレスですそのインターフェイスを送信すること）。
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 エンコード-Unicast形式
o Encoded-Group format
o エンコードされたグループ形式
We repeat these here to aid readability.
ここでこれらを繰り返して、読みやすさを支援します。
Encoded-Unicast address
エンコードされたUnicastアドレス
An Encoded-Unicast address takes the following format:
エンコードされたUnicastアドレスは、次の形式を取ります。
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.
0-127の値は、[11]のインターネットアドレスファミリーにIANAによって割り当てられたとおりです。値128-250は、PIM固有の住所ファミリのためにIANAによって割り当てられるように予約されています。値251ただし、255は私的使用のために指定されています。このスペースには割り当て権限がないため、衝突が予想されるはずです。
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 BIT SETの場合、すべての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.
Admin Scope [z] SETの場合、このビットは、このグループの範囲が管理上スコープ範囲であることを示しています。
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-forward bitを設定すると、このビットは、ブートストラップメッセージフラグメントを転送しないことを意味します。
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の場合、30の値をお勧めします。IPv6には、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アドレスを比較する際に高次バイトと見なされます。BSRSはデフォルトでこのフィールドを64に設定する必要があります。歴史的な理由で、BSRの優先度が最も高いのは255（より高い方が高い）であるのに対し、最高のRP優先度（以下を参照）は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]のエンコードされたUnicastアドレスに記載されています。
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:
グループアドレス1..n候補RPが関連付けられているグループの範囲（アドレスとマスク）。[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.
o Admin Scope Zoneビットを設定する必要があります。o IPv4の場合、それは管理者スコープ範囲全体のグループ範囲でなければなりません（これは、管理者スコープ範囲全体にRPセットにRPSがない場合でも必要です。RPセットは、rps）とともにフラグメントの後半で指定されています。o IPv6の場合、マスクレンは少なくとも16で、管理者スコープ範囲のスコープIDを持っている必要があります。
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-Count」アドレスを受け取るまで/ない限り、特定のグループ範囲の古いRPセットを置き換えません。アドレスは、いくつかのフラグメントの上に運ばれる可能性があります。特定のグループ範囲のRPセットの一部のみを受信した場合、ルーターはその特定のグループ範囲の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 1..m対応するグループ範囲に対して、ブートストラップメッセージのこのフラグメントに含まれる候補RPアドレスの数。「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対応するグループ範囲の候補RPSのアドレス。これらのアドレスの形式は、[1]のエンコードされたUnicastアドレスに記載されています。
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.
RP1..Mホールドタイム対応するRPの保留タイム（秒単位）。このフィールドは、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アドレスフィールドの同一の値が必要です。つまり、グループ間マッピングのみがフラグメント間で異なる場合があります。
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を超えている場合に役立ちます。メッセージが転送されます。IPの断片化に純粋に依存している場合、単一のフラグメントが失われた場合、メッセージ全体が失われます。セマンティックフラグメンテーションを使用することにより、単一の失われた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.
BSRがBSMを分割して、各グループの範囲（およびすべてのRP情報）が1つのBSMF内に完全に収まるようにすることができる場合、そうする必要があります。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.
単一のグループ範囲のRPSのリストが長い場合、IPの断片化を避けるために、複数のBSMFに情報を分割する場合があります。この場合、使用中のグループ間マッピングを変更する前に、そのグループ範囲の情報を含むすべてのBSMFを受信する必要があります。これがRPカウントフィールドの目的です - 同じBSMからBSMFを受信するルーター（つまり、同じフラグメントタグを持っている）は、そのグループ範囲のRPカウントRPSを提供するBSMFが新しいグループから受信されるまで待つ必要があります。-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がグループ範囲をどのように削除するかを検討する必要があります。一連のBSMFを受信するルーターは、グループ範囲が欠落しているかどうかを判断できません。以前にグループの範囲が見られた場合、そのグループの範囲がまだ存在し、そのグループ範囲を説明するBSMFが失われたと仮定する必要があります。ルーターは、bs_timeoutのこの情報を保持する必要があります。したがって、BSRがグループ範囲を削除するには、そのグループの範囲を含める必要がありますが、RPカウントはゼロであり、BS_Timeoutの各BSMでこの情報を再送信する必要があります。
Candidate-RP-Advertisement messages are periodically unicast from the C-RPs to the BSR.
候補-RP-advertisementメッセージは、定期的にC-RPSからBSRへのユニキャストです。
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-RPSは、「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.
対応するエンコードされたグループアドレス（ある場合）の場合、付属の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.
HOLDTIME時間（秒単位で）広告が有効です。このフィールドを使用すると、広告を老化させることができます。このフィールドは、C_RP_ADV_PERIODの2.5倍に設定する必要があります。
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]のエンコードされたUnicastアドレスに記載されています。
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-advertisementメッセージ内で、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は、BS_Periodと10秒の2倍に設定することをお勧めします。
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の値は5〜23秒で、C-BSRのブートストラップ重量が高い場合は値が少なく、C-BSRのブートストラップ重量が低い場合はより大きな値が生成されます。
BS_Rand_Override = 5 + priorityDelay + addrDelay
where priorityDelay is given by:
PriorityDelayが与えられる場所：
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)
}
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)
}
and bestPriority is given by:
そして、Best Priorityは次のように与えられます。
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の住所である場合、保存されたadaddrは保存されたBSRのアドレスであり、mypriorityは候補者BSRの設定された優先度であり、保存されている範囲が保存されている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は、BS_TIMEOUTの10倍に設定することをお勧めします。
Timer Name: Group-to-C-RP mapping Expiry Timer (CGET(M,Z))
タイマー名：Group-to-C-RPマッピングExpiry Timer（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))
タイマー名：グループ間マッピング有効期限タイマー（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メカニズムに影響を与える脅威は、主にサービス拒否（DOS）攻撃と交通隣接攻撃の2つの形式です。BSRメカニズムを覆す攻撃者は、マルチキャストトラフィックが意図した受信者に届かないようにし、マルチキャストトラフィックを監視できる場所に迂回させ、潜在的にトラフィックで第三者を襲う可能性があります。
Traffic can be prevented from reaching the intended recipients by one of two mechanisms:
トラフィックは、2つのメカニズムのいずれかによって、意図した受信者に届かないようにすることができます。
o Subverting a BSM, and specifying RPs that won't actually forward traffic.
o BSMを破壊し、実際にトラフィックを転送しないRPSを指定します。
o Registering with the BSR as a C-RP, and then not forwarding traffic.
o BSRにC-RPとして登録し、トラフィックを転送しません。
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.
トラフィックは、上記の両方のメカニズムによって監視できる場所に迂回できます。この場合、RPSはトラフィックを転送しますが、マルチキャストトラフィックに対する監視または中間の攻撃を支援するように配置されています。
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.
サードパーティは、上記の2つのメカニズムのいずれかによって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に短期間制限する必要があります。
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に送信されたレジスタパケットの一部を正しくエコーした場合にのみそうする必要があることに注意してください。このチェックが作成されていない場合、RPスプーフィングのソースアドレスを使用してDRにICMPの到達不可能なパケットを送信するだけで、そのDRに由来するマルチキャストトラフィックに対するサービス拒否攻撃を引き起こすのに十分です。
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).
実装は、インターフェイスごとの構成オプションを提供する必要があります。この場合、インターフェイスでBootstrapメッセージを送信または受け入れないことを指定できます。これは通常、隣接するドメインからメッセージを受信しないように、すべてのPMBRで構成する必要があります。これにより、他のドメインからBSR情報が矛盾する正当なメッセージが受信されないようになり、近隣のドメインからのBSR攻撃を防ぎます。このオプションは、ホストのみが存在する葉のインターフェイスでも役立ちます。ただし、[1]のセキュリティに関する考慮事項セクションでは、リーフインターフェイスでPIM Helloメッセージを受け入れないメカニズムが必要であり、有効なPIMネイバーからのみメッセージを受け入れる必要があると述べています。ただし、Unicast Bootstrapメッセージには追加の問題がある場合があります。下記参照。PMBRですべてのマルチキャストブートストラップメッセージを削除することに加えて、すべてのユニキャストPIMメッセージ（Bootstrapメッセージ、候補RP広告、PIMレジスタ、PIMレジスタストップ）をドロップするために、PMBR（他のドメインとリーフインターフェイスの両方）を構成することもお勧めします。
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ルーターが即時隣人からユニキャストされる悪いブートストラップメッセージを受け入れるという小さな時間があり、ドメインの外側からのこのインターバル中にブートストラップメッセージをルーターにユニキャストすることが可能かもしれません。隣人のスプーフィングされたソースアドレスを使用します。これを保護する最良の方法は、Unicastメッセージを含むすべてのブートストラップメッセージをドロップするために、境界線と葉のインターフェイスを構成する上記のメカニズムを使用することです。これは、PMBRSがSource-Addressフィルタリングを実行して、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.
Unicast Bootstrapメッセージの使用は、後方互換性のみを目的としています。セキュリティへの影響の可能性があるため、ユニキャストブートストラップメッセージをサポートする実装は、使用するかどうかの構成オプションを提供する必要があります。
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ルーターまたは非信頼性ホストの両方があるマルチアクセスサブネットを検討します。このようなサブネットでは、PMBRを構成するように（可能であれば）ブートストラップメッセージをドロップする必要があります。これは、PIMドメイン内のルーターが他の内部サブネットでブートストラップメッセージを受信することを条件としています。つまり、ドメインにあるマルチアクセスサブネット上の各ルーターの場合、各候補-BSRアドレスのRPFインターフェイスは、内部インターフェイス（マルチアクセスサブネットではないインターフェイス）でなければなりません。ただし、これが不可能なネットワークトポロジがあります。このようなトポロジについては、IPSEC認証ヘッダー（AH）を使用して、ドメイン内のPIMルーター間の通信を保護し、そのようなルーターは、認証チェックに合格しないノードから通信試行をドロップしてログするように構成されることをお勧めします。すべてのPIMルーターが同じ管理制御下にある場合、この認証は構成された共有秘密を使用する場合があります。リプレイ攻撃を防ぐために、送信者ごとに1つのセキュリティアソシエーション（SA）があり、SAルックアップに送信者アドレスを使用する必要があります。PIMネイバー間の相互作用の確保については、[1]のセキュリティに関する考慮事項セクションで詳細に説明しているため、詳細についてはこれ以上説明しません。PIM結合、プルーン、およびアサートメッセージを保護するために使用できるのと同じセキュリティメカニズムも、ブートストラップメッセージを保護するために使用する必要があります。PIM Link-Localメッセージをどのように正確に保護するかは、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.
ブートストラップメッセージを破壊することが不可能であっても、攻撃者は、攻撃者がRPSの選択を指定してC-RP-ADVメッセージをBSRに送信するだけで、同じ攻撃のほとんどを実行できる可能性があります。したがって、ブートストラップメッセージを制御するのと同じ方法で、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.
PMBRは、C-RP-ADVメッセージをドロップするように構成することをお勧めします。すべてのユニキャストPIMメッセージ（Bootstrapメッセージ、候補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メッセージの認証プロセスは、DRと関連するRPの間のPIMレジスタメッセージの認証プロセスと同一ですが、通常、ドメインでC-RPが少ないことを除きます。DRSよりも、キー管理は少し簡単です。このプロセスの詳細についてはこれ以上説明していませんが、[1]のセキュリティ上の考慮事項セクションを参照してください。上記のように、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.
Unicast BootstrapメッセージとC-RP-ADVメッセージが受け入れられる場所から、上記の非暗号化セキュリティメカニズムが制限されます。さらに、ユニキャストPIMパケットの受領時に適用するために、レート制限メカニズムを設定できることをお勧めします。レートリミッターは、個別に異なるタイプのPIMパケットを格付けする必要があります。たとえば、C-RP-ADVメッセージのフラッドは、レートリミッターが低レートのブートストラップメッセージをドロップさせてはなりません。このようなレートリミター自体は、有効なパケットを削除することによりサービス拒否攻撃を引き起こすために使用される可能性がありますが、実際には、これは悪い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.
ビル・フェナー、マーク・ハンドリー、ロジャー・カーモード、デビッド・ターラーは、この文書に大きく貢献しています。それらはこの文書の著者であり、バージョン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・リュー、プニート・シャルマ、ライムー・ウェイ、トム・プサテリ、トニー・バラルディ、スコットのアイデアを含む、長年にわたって長年にわたって設計されました。ブリム、ジョン・クロッククロフト、ポール・フランシス、ジョエル・ハルパーン、ホースト・ホーデル、ポリー・ファン、スティーブン・オストロフスキ、リキシア・チャン、ギリッシュ・チャンドランメノン、パブリン・ラドスラボフ、ジョン・ズウィーベル、イシドール・コウベラス、ヒュー・ホルブルック。この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ワーキンググループの多くのメンバーは、クリストファー・トーマス・ブラウン、アルダス・チーリンガル、マーシー・エサコヌ、ベニュゴパル・ヘミゲ、プラシャント・ジンガン、リシャブ・パレフ、カッタ・サンバシヴァラオなど、この文書のコメントと修正を提供しています。
[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] Fenner、B.、Handley、M.、Holbrook、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] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「双方向プロトコル独立マルチキャスト（Bidir-PIM）」、RFC 5015、2007年10月。
[3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[3] Meyer、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] Deering、S.、Haberman、B.、Jinmei、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. Deering、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Estrin, D., et al., "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[7] Estrin、D.、et al。、「Protocol Independent Multicast-Sparse Mode（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）およびマルチキャストソースディスカバリープロトコル（MSDP）を使用したAnycast Rendevous Point（RP）メカニズム」、RFC 3446、2003年1月。
[9] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006.
[9] Farinacci、D。およびY. Cai、「プロトコル独立マルチキャスト（PIM）を使用したAnycast-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] Atwood、W。およびS. Islam、「PIM-SM Link-Localメッセージのセキュリティ問題」、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
Nidhi Bhaskar Arastra、Inc。P.O.Box 10905 Palo Alto、CA 94303 USAメール：nidhi@arastra.com
Alexander Gall SWITCH P.O. Box CH-8021 Zurich Switzerland EMail: alexander.gall@switch.ch
アレクサンダーガルスイッチP.O.Box CH-8021 Zurich Switzerlandメール：Alexander.gall@switch.ch
James Lingard Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303 USA EMail: jchl@arastra.com
James Lingard Arastra、Inc。P.O.Box 10905 Palo Alto、CA 94303 USAメール：jchl@arastra.com
Stig Venaas UNINETT NO-7465 Trondheim Norway EMail: venaas@uninett.no
Stig Venaas Uninett No-7465 Trondheim Norway Email：venaas@uninett.no
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。