idnits 2.17.1 draft-ietf-pim-sm-bsr-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1860. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 136 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (3 August 2007) is 6110 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (ref. '1') (Obsoleted by RFC 7761) == Outdated reference: A later version (-09) exists of draft-ietf-pim-bidir-08 -- Obsolete informational reference (is this intentional?): RFC 2362 (ref. '7') (Obsoleted by RFC 4601, RFC 5059) == Outdated reference: A later version (-10) exists of draft-ietf-pim-sm-linklocal-01 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force PIM WG 2 INTERNET-DRAFT Nidhi Bhaskar/Arastra 3 draft-ietf-pim-sm-bsr-12.txt Alexander Gall/SWITCH 4 James Lingard/Arastra 5 Stig Venaas/UNINETT 6 3 August 2007 7 Expires: February 2008 9 Bootstrap Router (BSR) Mechanism for PIM 11 Status of this Document 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware have 15 been or will be disclosed, and any of which he or she becomes aware will 16 be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This document is a product of the IETF PIM WG. Comments should be 34 addressed to the authors, or the WG's mailing list at pim@ietf.org. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document specifies the Bootstrap Router (BSR) mechanism 43 for the class of multicast routing protocols in the PIM 44 (Protocol Independent Multicast) family that use the concept 45 of a Rendezvous Point as a means for receivers to discover the 46 sources that send to a particular multicast group. BSR is one 47 way that a multicast router can learn the set of group-to-RP 48 mappings required in order to function. The mechanism is 49 dynamic, largely self-configuring, and robust to router 50 failure. 52 Table of Contents 54 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 5 55 1.1. Background . . . . . . . . . . . . . . . . . . . . . 5 56 1.2. Protocol Overview. . . . . . . . . . . . . . . . . . 7 57 1.3. Administrative Scoping and BSR . . . . . . . . . . . 8 58 2. BSR State and Timers. . . . . . . . . . . . . . . . . . 10 59 3. Bootstrap Router Election and RP-Set 60 Distribution. . . . . . . . . . . . . . . . . . . . . . 11 61 3.1. Bootstrap Router Election. . . . . . . . . . . . . . 11 62 3.1.1. Per-Scope-Zone Candidate-BSR State 63 Machine . . . . . . . . . . . . . . . . . . . . . 11 64 3.1.2. Per-Scope-Zone State Machine for Non- 65 Candidate-BSR Routers . . . . . . . . . . . . . . 13 66 3.1.3. Bootstrap Message Processing Checks . . . . . . . 15 67 3.1.4. State Machine Transition Events . . . . . . . . . 16 68 3.1.5. State Machine Actions . . . . . . . . . . . . . . 17 69 3.2. Sending Candidate-RP-Advertisement Messages. . . . . 19 70 3.3. Creating the RP-Set at the BSR . . . . . . . . . . . 21 71 3.4. Forwarding Bootstrap Messages. . . . . . . . . . . . 23 72 3.5. Bootstrap Messages to New and Rebooting 73 Routers. . . . . . . . . . . . . . . . . . . . . . . 24 74 3.5.1. No-Forward Bootstrap Messages . . . . . . . . . . 25 75 3.5.2. Unicasting Bootstrap Messages . . . . . . . . . . 25 76 3.6. Receiving and Using the RP-Set . . . . . . . . . . . 25 77 4. Message Formats . . . . . . . . . . . . . . . . . . . . 25 78 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 28 79 4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 31 80 4.2. Candidate-RP-Advertisement Message Format. . . . . . 33 81 5. Timers and Timer Values . . . . . . . . . . . . . . . . 35 82 6. Security Considerations . . . . . . . . . . . . . . . . 38 83 6.1. Possible Threats . . . . . . . . . . . . . . . . . . 38 84 6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 39 85 6.3. Bootstrap Message Security . . . . . . . . . . . . . 39 86 6.3.1. Unicast Bootstrap Messages. . . . . . . . . . . . 39 87 6.3.2. Multi-access subnets. . . . . . . . . . . . . . . 40 88 6.4. Candidate-RP-Advertisement Message Security. . . . . 41 89 6.4.1. Non-Cryptographic Security of C-RP-Adv 90 Messages. . . . . . . . . . . . . . . . . . . . . 41 91 6.4.2. Cryptographic Security of C-RP-Adv 92 Messages. . . . . . . . . . . . . . . . . . . . . 41 93 6.5. Denial of Service using IPsec. . . . . . . . . . . . 41 94 7. Contributors. . . . . . . . . . . . . . . . . . . . . . 42 95 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 42 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . 42 97 10. Normative References . . . . . . . . . . . . . . . . . 42 98 11. Informative References . . . . . . . . . . . . . . . . 43 100 1. Introduction 102 This document assumes some familiarity with the concepts of Protocol 103 Independent Multicast - Sparse Mode (PIM-SM), as defined in [1], and Bi- 104 directional Protocol Independent Multicast (BIDIR-PIM), as defined in 105 [2], as well as with Administratively Scoped IP Multicast, as described 106 in [3], and the IPv6 Scoped Address Architecture, described in [4]. 108 For correct operation, every multicast router within a PIM domain must 109 be able to map a particular multicast group address to the same 110 Rendezvous Point (RP). The PIM specifications do not mandate the use of 111 a single mechanism to provide routers with the information to perform 112 this group-to-RP mapping. 114 This document describes the PIM Bootstrap Router (BSR) mechanism. BSR 115 is one way that a multicast router can learn the information required to 116 perform the group-to-RP mapping. The mechanism is dynamic, largely 117 self-configuring, and robust to router failure. 119 BSR was first defined in RFC 2362 [7] as part of the original PIM-SM 120 specification, which has been obsoleted by RFC 4601 [1]. This document 121 provides an updated specification of the BSR mechanism from RFC 2362, 122 and also extends it to cope with administratively scoped region 123 boundaries and different flavors of routing protocols. 125 Throughout the document, any reference to the PIM protocol family is 126 restricted to the subset of RP-based protocols, namely PIM-SM and BIDIR- 127 PIM, unless stated otherwise. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [6]. 133 1.1. Background 135 A PIM domain is a contiguous set of routers that all implement PIM and 136 are configured to operate within a common boundary defined by PIM 137 Multicast Border Routers (PMBRs). PMBRs connect each PIM domain to the 138 rest of the internet. 140 Every PIM multicast group needs to be associated with the IP address of 141 a Rendezvous Point (RP). This address is used as the root of a group- 142 specific distribution tree whose branches extend to all nodes in the 143 domain that want to receive traffic sent to the group. Senders inject 144 packets into the tree in such a manner that they reach all connected 145 receivers. How this is done and how the packets are forwarded along the 146 distribution tree depends on the particular routing protocol. 148 For all senders to reach all receivers, it is crucial that all routers 149 in the domain use the same mappings of group addresses to RP addresses. 151 An exception to the above is where a PIM domain has been broken up into 152 multiple administrative scope regions. These are regions where a border 153 has been configured so that a set of multicast groups will not be 154 forwarded across that border. In this case, all PIM routers within the 155 same scope region must map a particular scoped group to the same RP 156 within that region. 158 In order to determine the RP for a multicast group, a PIM router 159 maintains a collection of group-to-RP mappings, called the RP-Set. A 160 group-to-RP mapping contains the following elements. 162 o Multicast group range, expressed as an address and prefix length 164 o RP priority 166 o RP address 168 o Hash mask length 170 o SM / BIDIR flag 172 In general, the group ranges of these group-to-RP mappings may overlap 173 in arbitrary ways; hence a particular multicast group may be covered by 174 multiple group-to-RP mappings. When this is the case, the router 175 chooses only one of the RPs by applying a deterministic algorithm so 176 that all routers in the domain make the same choice. It is important to 177 note that this algorithm is part of the specification of the individual 178 routing protocols (and may differ among them), not of the BSR 179 specification. E.g. PIM-SM [1] defines one such algorithm. It makes 180 use of a hash function for the case where a group range has multiple RPs 181 with the same priority. The hash mask length is used by this function. 183 There are a number of ways in which such group-to-RP mappings can be 184 established. The simplest solution is for all the routers in the domain 185 to be statically configured with the same information. However, static 186 configuration generally doesn't scale well, and, except when used in 187 conjunction with Anycast-RP (see [8] and [9]), does not dynamically 188 adapt to route around router or link failures. 190 The BSR mechanism provides a way in which viable group-to-RP mappings 191 can be created and rapidly distributed to all the PIM routers in a 192 domain. It is adaptive, in that if an RP becomes unreachable, this will 193 be detected and the RP-Sets will be modified so that the unreachable RP 194 is no longer used. 196 1.2. Protocol Overview 198 In this section we give an informal and non-definitive overview of the 199 BSR mechanism. The definitive specification begins in section 2. 201 The general idea behind the BSR mechanism is that some of the PIM 202 routers within a PIM domain are configured to be potential RPs for the 203 domain. These are known as Candidate-RPs (C-RPs). A subset of the C- 204 RPs will eventually be used as the actual RPs for the domain. In 205 addition, some of the PIM routers in the domain are configured to be 206 candidate bootstrap routers, or Candidate-BSRs (C-BSRs). One of these 207 C-BSRs will be elected to be the bootstrap router (BSR) for the domain, 208 and all the PIM routers in the domain will learn the result of this 209 election through Bootstrap messages. The C-RPs will then report their 210 candidacy to the elected BSR, which chooses a subset of these C-RPs and 211 distributes corresponding group-to-RP mappings to all the routers in the 212 domain through Bootstrap messages. 214 In more detail, the BSR mechanism works as follows. There are four 215 basic phases (although in practice all phases may be occurring 216 simultaneously): 218 1. BSR Election. Each Candidate-BSR originates Bootstrap messages 219 (BSMs). Every BSM contains a BSR Priority field. Routers within 220 the domain flood the BSMs throughout the domain. A C-BSR that 221 hears about a higher-priority C-BSR than itself then suppresses its 222 sending of further BSMs for some period of time. The single 223 remaining C-BSR becomes the elected BSR, and its BSMs inform all 224 the other routers in the domain that it is the elected BSR. 226 2. C-RP Advertisement. Each Candidate-RP within a domain sends 227 periodic Candidate-RP-Advertisement (C-RP-Adv) messages to the 228 elected BSR. A C-RP-Adv message includes the priority of the 229 advertising C-RP, as well as a list of group ranges for which the 230 candidacy is advertised. In this way, the BSR learns about 231 possible RPs that are currently up and reachable. 233 3. RP-Set Formation. The BSR selects a subset of the C-RPs that it 234 has received C-RP-Adv messages from to form the RP-Set. In general 235 it should do this in such a way that the RP-Set is neither too 236 large to inform all the routers in the domain about, nor too small 237 so that load is overly concentrated on some RPs. It should also 238 attempt to produce an RP-Set that does not change frequently. 240 4. RP-Set Flooding. In future Bootstrap messages, the BSR includes 241 the RP-Set information. Bootstrap messages are flooded through the 242 domain, which ensures that the RP-Set rapidly reaches all the 243 routers in the domain. BSMs are originated periodically to ensure 244 consistency after failure restoration. 246 When a PIM router receives a Bootstrap message, it adds the group- 247 to-RP mappings contained therein to its pool of mappings obtained 248 from other sources (e.g. static configuration). It calculates the 249 final mappings of group addresses to RP addresses from this pool 250 according to rules specific to the particular routing protocol and 251 uses that information to construct multicast distribution trees. 253 If a PIM domain becomes partitioned, each area separated from the old 254 BSR will elect its own BSR, which will distribute an RP-Set containing 255 RPs that are reachable within that partition. When the partition heals, 256 another election will occur automatically and only one of the BSRs will 257 continue to send out Bootstrap messages. As is expected at the time of 258 a partition or healing, some disruption in packet delivery may occur. 259 This time will be on the order of the region's round-trip time and the 260 BS_Timeout value. 262 1.3. Administrative Scoping and BSR 264 The mechanism described in the previous section does not work when the 265 PIM domain is divided into administratively scoped regions. To handle 266 this situation, we use the protocol modifications described in this 267 section. 269 In the remainder of this document we will use the term scope zone, or 270 simply zone, when we are talking about a connected region of topology of 271 a given scope. For a more precise definition of scope zones, see [4] 272 emphasize that the scope zones are administratively configured. 274 Administrative scoping permits a PIM domain to be divided into multiple 275 admin-scope zones. Each admin-scope zone is a convex connected set of 276 PIM routers, and is associated with a set of group addresses. The 277 boundary of the admin-scope zone is formed by Zone Border Routers 278 (ZBRs). ZBRs are configured not to forward traffic for any of the 279 scoped group addresses into or out of the scoped zone. It is important 280 to note that a given scope boundary always creates at least two scoped 281 zones: one on either side of the boundary. 283 In IPv4, administratively scoped zones are associated with a set of 284 addresses given by an address and a prefix length. In IPv6, 285 administratively scoped zones are associated with a set of addresses 286 given by a single scope ID value. The set of addresses corresponding to 287 a given scope ID value is defined in [5]. For example, a scope ID of 5 288 maps to the 16 IPv6 address ranges ff[0-f]5::/16. 290 There are certain topological restrictions on admin-scope zones. The 291 scope zone border must be complete and convex. By this we mean that 292 there must be no path from inside the scoped zone to outside it that 293 does not pass through a configured scope border router, and that the 294 multicast capable path between any arbitrary pair of multicast routers 295 in the scope zone must remain in the zone. 297 Administrative scoping complicates BSR because we do not want a PIM 298 router within the scoped zone to use an RP outside the scoped zone. 299 Thus we need to modify the basic mechanism to ensure that this doesn't 300 happen. 302 This is done by running a separate copy of the basic BSR mechanism, as 303 described in the previous section, within each admin scope zone of a PIM 304 domain. Thus a separate BSR election takes place for each admin-scope 305 zone, a C-RP typically registers to the BSR of every admin scope zone it 306 is in, and every PIM router receives Bootstrap messages for every scope 307 zone it is in. The Bootstrap messages sent by the BSR for a particular 308 scope zone contain information about the RPs that should be used for the 309 set of addresses associated with that scope zone. 311 Bootstrap messages are marked to indicate which scope zone they belong 312 to. Such admin scoped Bootstrap messages are flooded in the normal way, 313 but will not be forwarded by a ZBR across the boundary for that scope 314 zone. 316 For the BSR mechanism to function correctly with admin scoping, within 317 each admin scope zone there must be at least one C-BSR, and at least one 318 C-RP that is configured to be a C-RP for the set of group addresses 319 associated with the scoped zone. 321 Even when administrative scoping is used, a copy of the BSR mechanism is 322 still used across the entire PIM domain, in order to distribute RP 323 information for groups that are not administratively scoped. We call 324 this copy of the mechanism Non-Scoped BSR. The copies of the mechanism 325 run for each admin-scope zone are called Scoped BSR. 327 Only the C-BSRs and the ZBRs need to be configured to know about the 328 existence of the scope zones. Other routers, including the C-RPs, learn 329 of their existence from Bootstrap messages. 331 All PIM routers within a PIM bootstrap domain where admin scope ranges 332 are in use must be capable of receiving Bootstrap messages and storing 333 the winning BSR and RP-Set for all admin scope zones that apply. Thus 334 PIM routers that only implement RFC 2362 or Non-Scoped BSR (which only 335 allows one BSR per domain) cannot be used within the admin-scope zones 336 of a PIM domain. 338 2. BSR State and Timers 340 A PIM router implementing BSR holds the following state. 342 RP-Set 344 Per Configured or Learned Scope Zone (Z): 346 At all routers: 348 Current Bootstrap Router's IP Address 350 Current Bootstrap Router's BSR Priority 352 Last BSM received from current BSR 354 Bootstrap Timer (BST(Z)) 356 Per group-to-RP mapping (M): 358 Group-to-RP mapping Expiry Timer (GET(M,Z)) 360 At a Candidate-BSR for Z: 362 My state: One of "Candidate-BSR", "Pending-BSR", 363 "Elected-BSR" 365 At a router that is not a Candidate-BSR for Z: 367 My state: One of "Accept Any", "Accept Preferred" 369 Scope-Zone Expiry Timer (SZT(Z)) 371 At the current Bootstrap Router for Z only: 373 Per group-to-C-RP mapping (M): 375 Group-to-C-RP mapping Expiry Timer (CGET(M,Z)) 377 At a C-RP only: 379 C-RP Advertisement Timer (CRPT) 381 3. Bootstrap Router Election and RP-Set Distribution 383 3.1. Bootstrap Router Election 385 For simplicity, Bootstrap messages are used in both the BSR election and 386 the RP-Set distribution mechanisms. 388 Each Bootstrap message indicates the scope that it belongs to. If the 389 Admin Scope Zone bit is set in the first group range in the Bootstrap 390 message, the message is called a scoped BSM. If the Admin Scope Zone 391 bit is not set in the first group range in the Bootstrap message, the 392 message is called a non-scoped BSM. 394 In a scoped IPv4 BSM, the scope of the message is given by the first 395 group range in the message, which can be any sub-range of 224/4. In a 396 scoped IPv6 BSM, the scope of the message is given by the scope ID of 397 the first group range in the message, which must have a mask length of 398 at least 16. For example, a group range of ff05::/16 with the Admin 399 Scope Zone bit set indicates that the Bootstrap message is for the scope 400 with scope ID 5. If the mask length of the first group range in a 401 scoped IPv6 BSM is less than 16, the message MUST be dropped and a 402 warning SHOULD be logged. 404 The state machine for Bootstrap messages depends on whether or not a 405 router has been configured to be a Candidate-BSR for a particular scope 406 zone. The per-scope-zone state machine for a C-BSR is given below, 407 followed by the state machine for a router that is not configured to be 408 a C-BSR. 410 3.1.1. Per-Scope-Zone Candidate-BSR State Machine 412 +-----------------------------------------------------------------------+ 413 | When in C-BSR state | 414 +-----------+------------------+--------------------+-------------------+ 415 | Event | Receive | Bootstrap | Receive Non- | 416 | | Preferred BSM | Timer Expires | preferred BSM | 417 | | | | from Elected | 418 | | | | BSR | 419 +-----------+------------------+--------------------+-------------------+ 420 | | -> C-BSR state | -> P-BSR state | -> P-BSR state | 421 | | Forward BSM; | Set Bootstrap | Forward BSM; | 422 | Action | Store RP-Set; | Timer to | Set Bootstrap | 423 | | Set Bootstrap | BS_Rand_Override | Timer to | 424 | | Timer to | | BS_Rand_Override | 425 | | BS_Timeout | | | 426 +-----------+------------------+--------------------+-------------------+ 427 +-----------------------------------------------------------------------+ 428 | When in P-BSR state | 429 +------------+-------------------+-------------------+------------------+ 430 | Event | Receive | Bootstrap | Receive Non- | 431 | | Preferred BSM | Timer Expires | preferred BSM | 432 +------------+-------------------+-------------------+------------------+ 433 | | -> C-BSR state | -> E-BSR state | -> P-BSR state | 434 | | Forward BSM; | Originate BSM; | Forward BSM | 435 | Action | Store RP-Set; | Set Bootstrap | | 436 | | Set Bootstrap | Timer to | | 437 | | Timer to | BS_Period | | 438 | | BS_Timeout | | | 439 +------------+-------------------+-------------------+------------------+ 441 +-----------------------------------------------------------------------+ 442 | When in E-BSR state | 443 +------------+-------------------+-------------------+------------------+ 444 | Event | Receive | Bootstrap | Receive Non- | 445 | | Preferred BSM | Timer Expires | preferred BSM | 446 +------------+-------------------+-------------------+------------------+ 447 | | -> C-BSR state | -> E-BSR state | -> E-BSR state | 448 | | Forward BSM; | Originate BSM; | Originate BSM; | 449 | Action | Store RP-Set; | Set Bootstrap | Set Bootstrap | 450 | | Set Bootstrap | Timer to | Timer to | 451 | | Timer to | BS_Period | BS_Period | 452 | | BS_Timeout | | | 453 +------------+-------------------+-------------------+------------------+ 455 A Candidate-BSR may be in one of three states for a particular scope 456 zone: 458 Candidate-BSR (C-BSR) 459 The router is a candidate to be the BSR for the scope zone, but 460 currently another router is the preferred BSR. 462 Pending-BSR (P-BSR) 463 The router is a candidate to be the BSR for the scope zone. 464 Currently no other router is the preferred BSR, but this router is 465 not yet the elected BSR. This is a temporary state that prevents 466 rapid thrashing of the choice of BSR during BSR election. 468 Elected-BSR (E-BSR) 469 The router is the elected BSR for the scope zone and it must 470 perform all the BSR functions. 472 In addition to the three states, there is one timer: 474 o The Bootstrap Timer (BST) - used to time out old bootstrap router 475 information, and used in the election process to terminate P-BSR 476 state. 478 The initial state for this configured scope zone is "Pending-BSR"; the 479 Bootstrap Timer is initialized to BS_Rand_Override. This is the case 480 both if the router is a Candidate BSR at startup, and if reconfigured to 481 become one later. 483 3.1.2. Per-Scope-Zone State Machine for Non-Candidate-BSR Routers 485 The following state machine is used for scope zones which are discovered 486 by the router from bootstrap messages. A simplified state machine is 487 used for scope zones which are explicitly configured on the router and 488 for the global zone. The differences are listed at the end of this 489 section. 491 +-----------------------------------------------------------------------+ 492 | When in NoInfo state | 493 +---------------------+-------------------------------------------------+ 494 | Event | Receive BSM | 495 +---------------------+-------------------------------------------------+ 496 | | -> AP state | 497 | Action | Forward BSM; Store RP-Set; | 498 | | Set Bootstrap Timer to BS_Timeout | 499 +---------------------+-------------------------------------------------+ 501 +-----------------------------------------------------------------------+ 502 | When in Accept Any state | 503 +---------------+----------------------------+--------------------------+ 504 | Event | Receive BSM | Scope-Zone Expiry | 505 | | | Timer Expires | 506 +---------------+----------------------------+--------------------------+ 507 | | -> AP state | -> NoInfo state | 508 | | Forward BSM; Store | Remove scope zone | 509 | Action | RP-Set; Set | state | 510 | | Bootstrap Timer to | | 511 | | BS_Timeout | | 512 +---------------+----------------------------+--------------------------+ 513 +-----------------------------------------------------------------------+ 514 | When in Accept Preferred state | 515 +----------+----------------------+-------------------+-----------------+ 516 | Event | Receive Preferred | Bootstrap | Receive Non- | 517 | | BSM | Timer Expires | preferred BSM | 518 +----------+----------------------+-------------------+-----------------+ 519 | | -> AP state | -> AA state | -> AP state | 520 | | Forward BSM; Store | Refresh RP- | | 521 | Action | RP-Set; Set | Set; Remove | | 522 | | Bootstrap Timer to | BSR state; Set | | 523 | | BS_Timeout | SZT to | | 524 | | | SZ_Timeout | | 525 +----------+----------------------+-------------------+-----------------+ 526 A router that is not a Candidate-BSR may be in one of three states: 528 NoInfo 529 The router has no information about this scope zone. When in this 530 state, no state information is held and no timers run that refer to 531 this scope zone. Conceptually, the state machine is only 532 instantiated when the router receives a scoped BSM for a scope 533 about which it has no prior knowledge. However, because the router 534 immediately transitions to the AA state unconditionally, the NoInfo 535 state can be considered to be virtual in a certain sense. For this 536 reason, it is omitted from the description in section 2. 538 Accept Any (AA) 539 The router does not know of an active BSR, and will accept the 540 first Bootstrap message it sees as giving the new BSR's identity 541 and the RP-Set. 543 Accept Preferred (AP) 544 The router knows the identity of the current BSR, and is using the 545 RP-Set provided by that BSR. Only Bootstrap messages from that BSR 546 or from a C-BSR with higher weight than the current BSR will be 547 accepted. 549 In addition to the three states, there are two timers: 551 o The Bootstrap Timer (BST) - used to time out old bootstrap router 552 information. 554 o The Scope-Zone Expiry Timer (SZT) - used to time out the scope zone 555 itself if Bootstrap messages specifying this scope zone stop arriving. 557 The initial state for scope zones about which the router has no 558 knowledge is "NoInfo". 560 The state machine used for scopes which have been configured explicitly 561 on the router and for the global scope, which always exists, differs 562 from the state machine above as follows. 564 o The "NoInfo" state doesn't exist. 566 o No SZT is maintained. Hence, the event "Scope-Zone Expiry Timer 567 Expires" does not exist and no actions with regard to this timer 568 are executed. 570 The initial state for this state machine is "Accept Any". 572 3.1.3. Bootstrap Message Processing Checks 574 When a Bootstrap message is received, the following initial checks must 575 be performed: 577 if ((DirectlyConnected(BSM.src_ip_address) == FALSE) OR 578 (we have no Hello state for BSM.src_ip_address)) { 579 drop the Bootstrap message silently 580 } 582 if (BSM.dst_ip_address == ALL-PIM-ROUTERS) { 583 if (BSM.no_forward_bit == 0) { 584 if (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address)) { 585 drop the Bootstrap message silently 586 } 587 } else if ((any previous BSM for this scope has been accepted) OR 588 (more than BS_Period has elapsed since startup)) { 589 #only accept no-forward BSM if quick refresh on startup 590 drop the Bootstrap message silently 591 } 592 } else if ((Unicast BSM support enabled) AND 593 (BSM.dst_ip_address is one of my addresses)) { 594 if ((any previous BSM for this scope has been accepted) OR 595 (more than BS_Period has elapsed since startup)) { 596 #the packet was unicast, but this wasn't 597 #a quick refresh on startup 598 drop the Bootstrap message silently 599 } 600 } else { 601 drop the Bootstrap message silently 602 } 604 if (the interface the message arrived on is an Admin Scope 605 border for the BSM.first_group_address) { 606 drop the Bootstrap message silently 607 } 609 Basically, the packet must have come from a directly connected neighbor 610 for which we have active Hello state. It must have been sent to the 611 ALL-PIM-ROUTERS group, and unless it is a No-Forward BSM, been sent by 612 the correct upstream router towards the BSR that originated the 613 Bootstrap message; or, if it is a No-Forward BSM, we must have recently 614 restarted and have no BSR state for that admin scope. Also, if unicast 615 BSM support is enabled, a unicast BSM is accepted if it is addressed to 616 us and we have recently restarted and have no BSR state for that admin 617 scope. In addition, it must not have arrived on an interface that is a 618 configured admin scope border for the first group address contained in 619 the Bootstrap message. 621 3.1.4. State Machine Transition Events 623 If the Bootstrap message passes the initial checks above without being 624 discarded, then it may cause a state transition event in one of the 625 above state machines. For both candidate and non-candidate BSRs, the 626 following transition events are defined: 628 Receive Preferred BSM 629 A Bootstrap message is received from a BSR that has higher or 630 equal weight than the current BSR. If a router is in P-BSR 631 state, then it uses its own weight as that of the current BSR. 633 A Bootstrap message is also preferred if it is from the 634 current BSR with a lower weight than the previous BSM it sent, 635 provided that if the router is a Candidate BSR the current BSR 636 still has a weight higher or equal than the router itself. In 637 this case, the "Current Bootstrap Router's BSR Priority" state 638 must be updated. (For lower weight, see Non-preferred BSM 639 from Elected BSR case.) 641 The weight of a BSR is defined to be the concatenation in 642 fixed-precision unsigned arithmetic of the BSR Priority field 643 from the Bootstrap message and the IP address of the BSR from 644 the Bootstrap message (with the BSR Priority taking the most- 645 significant bits and the IP address taking the least 646 significant bits). 648 Receive Non-preferred BSM 649 A Bootstrap message is received from a BSR other than the 650 current BSR that has lower weight than the current BSR. If a 651 router is in P-BSR state, then it uses its own weight as that 652 of the current BSR. 654 Receive Non-preferred BSM from Elected BSR 655 A Bootstrap message is received from the elected BSR, but the 656 BSR Priority field in the received message has changed, so 657 that now the currently elected BSR has lower weight than the 658 router itself. 660 Receive BSM 661 A Bootstrap message is received, regardless of BSR weight. 663 In addition to state machine transitions caused by the receipt of 664 Bootstrap messages, a state machine transition takes place each time the 665 Bootstrap Timer or Scope-Zone Expiry Timer expires. 667 3.1.5. State Machine Actions 669 The state machines specify actions that include setting the Bootstrap 670 Timer and the Scope-Zone Expiry Timer to various values. These values 671 are defined in Section 5. 673 In addition to setting and cancelling the timers, the following actions 674 may be triggered by state changes in the state machines: 676 Forward BSM 677 A multicast Bootstrap message with No-Forward bit cleared that 678 passes the Bootstrap Message Processing Checks is forwarded 679 out of all interfaces with PIM neighbors (including the 680 interface it is received on), except where this would cause 681 the BSM to cross an admin-scope boundary for the scope zone 682 indicated in the message. For details, see section 3.4. 684 Originate BSM 685 A new Bootstrap message is constructed by the BSR, giving the 686 BSR's address and BSR priority, and containing the BSR's 687 chosen RP-Set. The message is forwarded out of all interfaces 688 on which PIM neighbors exist, except where this would cause 689 the BSM to cross an admin-scope boundary for the scope zone 690 indicated in the message. 692 Store RP-Set 693 The router uses the group-to-RP mappings contained in a BSM to 694 update its local RP-Set. 696 This action is skipped for an empty BSM. A BSM is empty if it 697 contains no group ranges, or if it only contains a single 698 group range where that group range has the Admin Scope Zone 699 bit set (a scoped BSM) and an RP count of zero. 701 If a mapping does not yet exist, it is created and the 702 associated Group-to-RP mapping Expiry Timer (GET) is 703 initialized with the holdtime from the BSM. 705 If a mapping already exists, its GET is set to the holdtime 706 from the BSM. If the holdtime is zero, the mapping is removed 707 immediately. Note that for an existing mapping, the RP 708 priority must be updated if changed. 710 Mappings for a group range are also to be immediately removed 711 if they are not present in the received group range. This 712 means that if there are any existing Group-to-RP mappings for 713 a range where the respective RPs are not in the received 714 range, then those mappings must be removed. 716 All RP mappings associated with the scope zone of the BSM are 717 updated with the new hash mask length from the received BSM. 718 This includes RP mappings for all group ranges learned for 719 this zone, not just the ranges in this particular BSM. 721 In addition, the entire BSM is stored for use in the action 722 Refresh RP-Set and to prime a new PIM neighbor as described 723 below. 725 Refresh RP-Set 726 When the Bootstrap Timer expires, the router uses the copy of 727 the last BSM that it has received to refresh its RP-Set 728 according to the action Store RP-Set as if it had just 729 received it. This will increase the chance that the group-to- 730 RP mappings will not expire during the election of the new 731 BSR. 733 Remove BSR state 734 When the Bootstrap Timer expires, all state associated with 735 the current BSR is removed (address, priority, BST and saved 736 last BSM, see section 2). Note that this does not include any 737 group-to-RP mappings. 739 Remove scope zone state 740 When the Scop-Zone Expiry Timer expires, all state associated 741 with the scope zone is removed (see section 2). 743 3.2. Sending Candidate-RP-Advertisement Messages 745 Every C-RP periodically unicasts a C-RP-Adv message to the BSR for each 746 scope zone for which it has state, to inform the BSR of the C-RP's 747 willingness to function as an RP. These messages are sent with an 748 interval of C_RP_Adv_Period, except when a new BSR is elected, see 749 below. 751 When a new BSR is elected, the C-RP MUST send one to three C-RP-Adv 752 messages, waiting a small randomized period C_RP_Adv_Backoff before 753 sending each message. We recommend sending three messages because it is 754 important that the BSR quickly learns which RPs are active, and some 755 packet loss may occur when a new BSR is elected due to changes in the 756 network. One way of implementing this is to set the CRPT to 757 C_RP_Adv_Backoff when the new BSR is elected, as well as setting a 758 counter to 2. Whenever the CRPT expires, we first send a C-RP-Adv 759 message as usual. Next, if the counter is non-zero, it is decremented 760 and the CRPT is again set to C_RP_Adv_Backoff instead of 761 C_RP_Adv_Period. 763 The Priority field in these messages is used by the BSR to select which 764 C-RPs to include in the RP-Set. Note that lower values of this field 765 indicate higher priorities, so that a value of zero is the highest 766 possible priority. C-RPs should by default send C-RP-Adv messages with 767 the Priority field set to 192. 769 When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv 770 message to the BSR for each scope zone for which it is currently serving 771 as an RP; the Holdtime in this C-RP-Adv message should be zero. The BSR 772 will then immediately time out the C-RP and generate a new Bootstrap 773 message with the shut down RP holdtime set to 0. 775 A C-RP-Adv message carries a list of group address and group mask field 776 pairs. This enables the C-RP to specify the group ranges for which it 777 is willing to be the RP. If the C-RP becomes an RP, it may enforce this 778 scope acceptance when receiving Register or Join/Prune messages. 780 A C-RP is configured with a list of group ranges for which it should 781 advertise itself as the C-RP. A C-RP uses the following algorithm to 782 determine which ranges to send to a given BSR. 784 For each group range R in the list, the C-RP advertises that range to 785 the scoped BSR for the smallest scope that "contains" R. For IPv6, the 786 containing scope is determined by matching the scope identifier of the 787 group range with the scope of the BSR. For IPv4, it is the longest- 788 prefix match for R, amongst the known admin-scope ranges. If no scope 789 is found to contain the group range the C-RP includes it in the C-RP-Adv 790 sent to the non-scoped BSR. If a non-scoped BSR is not known, the range 791 is not included in any C-RP-Adv. 793 In addition, for each IPv4 group range R in the list, for each scoped 794 BSR whose scope range is strictly contained within R, the C-RP SHOULD by 795 default advertise that BSR's scope range to that BSR. And for each IPv6 796 group range R in the list with prefix length < 16, the C-RP SHOULD by 797 default advertise each sub-range of prefix length 16 to the scoped BSR 798 with the corresponding scope ID. An implementation MAY supply a 799 configuration option to prevent the behavior described in this 800 paragraph, but such an option SHOULD be disabled by default. 802 For IPv6, the mask length of all group ranges included in the C-RP-Adv 803 message sent to a scoped BSR MUST be >= 16. 805 If the above algorithm determines that there are no group ranges to 806 advertise to the BSR for a particular scope zone, a C-RP-Adv message 807 MUST NOT be sent to that BSR. A C-RP MUST NOT send a C-RP-Adv message 808 with no group ranges in it. 810 If the same router is the BSR for more than one scope zone, the C-RP-Adv 811 messages for these scope zones MAY be combined into a single message. 813 If the C-RP is a ZBR for an admin scope zone, then the Admin Scope Zone 814 bit MUST be set in the C-RP-Adv messages it sends for that scope zone; 815 otherwise this bit MUST NOT be set. This information is currently only 816 used for logging purposes by the BSR, but might allow for future 817 extensions of the protocol. 819 3.3. Creating the RP-Set at the BSR 821 Upon receiving a C-RP-Adv message, the router needs to decide whether or 822 not to accept each of the group ranges included in the message. For 823 each group range in the message, the router checks to see if it is the 824 elected BSR for any scope zone that contains the group range, or if it 825 is elected as the non-scoped BSR. If so, the group range is accepted; 826 if not, the group range is ignored. 828 For security reasons, we recommend that implementations have a way of 829 restricting which IP addresses the BSR accepts C-RP-Adv messages from, 830 e.g., access lists. For use of scoped BSR, it may also be useful to 831 specify which group ranges should be accepted. 833 If the group range is accepted, a group-to-C-RP mapping is created for 834 this group range and the RP Address from the C-RP-Adv message. 836 If the mapping is not already part of the C-RP-Set, it is added to the 837 C-RP-Set and the associated Group-to-C-RP mapping Expiry Timer (CGET) is 838 initialized to the holdtime from the C-RP-Adv message. Its priority is 839 set to the Priority from the C-RP-Adv message. 841 If the mapping is already part of the C-RP-Set, it is updated with the 842 Priority from the C-RP-Adv message and its associated CGET is reset to 843 the holdtime from the C-RP-Adv message. If the holdtime is zero, the 844 mapping is immediately removed from the C-RP-Set. 846 The hash mask length is a global property of the BSR and is therefore 847 the same for all mappings managed by the BSR. 849 For compatibility with the previous version of the BSR specification, a 850 C-RP-Adv message with no group ranges SHOULD be treated as though it 851 contained the single group range ff00::/8 or 224/4. Therefore, 852 according to the rule above, this group range will be accepted if and 853 only if the router is elected as the non-scoped BSR. 855 When a CGET expires, the corresponding group-to-C-RP mapping is removed 856 from the C-RP-Set. 858 The BSR constructs the RP-Set from the C-RP-Set. It may apply a local 859 policy to limit the number of Candidate-RPs included in the RP-Set. The 860 BSR may override the range indicated in a C-RP-Adv message unless the 861 `Priority' field from the C-RP-Adv message is less than 128. 863 If the BSR learns of both BIDIR and PIM-SM Candidate-RPs for the same 864 group range, the BSR MUST only include RPs for one of the protocols in 865 the BSMs. The default behavior SHOULD be to prefer BIDIR. 867 For inclusion in a BSM, the RP-Set is subdivided into sets of {group- 868 range, RP-Count, RP-addresses}. For each RP-address, the "RP-Holdtime" 869 field is set to the Holdtime from the C-RP-Set, subject to the 870 constraint that it MUST be larger than BS_Period and SHOULD be larger 871 than 2.5 times BS_Period to allow for some Bootstrap messages getting 872 lost. If some holdtimes from the C-RP-Sets do not satisfy this 873 constraint, the BSR MUST replace those holdtimes with a value satisfying 874 the constraint. An exception to this is the holdtime of zero which is 875 used to immediately withdraw mappings. 877 The format of the Bootstrap message allows `semantic fragmentation', if 878 the length of the original Bootstrap message exceeds the packet maximum 879 boundaries. However, we recommend against configuring a large number of 880 routers as C-RPs, to reduce the semantic fragmentation required. 882 In general BSMs are originated at regular intervals according to the 883 BS_Period timer. We do recommend that a BSM is also originated whenever 884 the RP-set to be announced in the BSMs changes. This will usually 885 happen when receiving C-RP advertisements from a new C-RP, or when a C- 886 RP is shut down (C-RP advertisement with a holdtime of zero). There 887 MUST however be a minimum of BS_Min_Interval between each time a BSM is 888 sent. In particular, when a new BSR is elected, it will first send one 889 BSM (which is likely to be empty since it has not yet received any C-RP 890 advertisements), and then wait at least BS_Min_Interval before sending a 891 new one. During that time, it is likely to have received C-RP 892 advertisements from all usable C-RPs (since we say that a C-RP should 893 send one or more advertisements with small random delays of 894 C_RP_Adv_Backoff when a new BSR is elected). For this case in 895 particular, where routers may not have a usable RP-set, we recommend 896 originating a BSM as soon as BS_Min_Interval has passed. We suggest 897 though that a BSR can do this in general. One way of implementing this, 898 is to decrease the Bootstrap Timer to BS_Min_Interval whenever the RP- 899 set changes, while not changing the timer if it is less or equal to 900 BS_Min_Interval. 902 A BSR originates separate scoped BSMs for each scope zone for which it 903 is the elected BSR, as well as originating non-scoped BSMs if it is the 904 elected non-scoped BSR. 906 Each group-to-C-RP mapping is included in precisely one of these BSM, 907 namely the scoped BSM for the narrowest scope containing the group range 908 of the mapping, if any, or the non-scoped BSM otherwise. 910 A scoped BSM MUST have at least one group range, and the first group 911 range in a scoped BSM MUST have the "Admin Scope Zone" bit set. This 912 group range identifies the scope of the BSM. In a scoped IPv4 BSM, the 913 first group range is the range corresponding to the scope of the BSM. 914 In a scoped IPv6 BSM, the first group range may be any group range 915 subject to the general condition that all the group ranges in such a BSM 916 MUST have a mask length of at least 16 and MUST have the same scope ID 917 as the scope of the BSM. 919 Apart from identifying the scope, the first group range in a scoped BSM 920 is treated like any other range with respect to RP mappings. I.e., all 921 mappings in the RP-set for this group range, if any, must be included in 922 this first group range in the BSM. After this group range, other group 923 ranges in this scope for which there are RP mappings appear in any 924 order. 926 The "Admin Scope Zone" bit of all group ranges other than the first 927 SHOULD be set to 0 on origination, and MUST be ignored on receipt. 929 When an elected BSR is being shut down, it should immediately originate 930 a Bootstrap message listing its current RP-Set, but with the BSR 931 Priority field set to the lowest priority value possible. This will 932 cause the election of a new BSR to happen more quickly. 934 3.4. Forwarding Bootstrap Messages 936 Generally, bootstrap messages originate at the BSR, and are hop-by-hop 937 forwarded by intermediate routers if they pass the Bootstrap Message 938 Processing Checks. There are two exceptions to this. One is that a 939 bootstrap message is not forwarded if its No-Forward bit is set, see 940 3.5.1. The other is that unicast BSMs, see 3.5.2, are usually not 941 forwarded. Implementers MAY, however, at their own discretion choose to 942 re-send a No-Forward or unicast BSM in a multicast BSM which MUST have 943 the No-Forward bit cleared. It is essential that the No-Forward bit is 944 cleared, since no RPF check is performed by the receiver when set. 946 By hop-by-hop forwarding, we mean that the bootstrap message itself is 947 forwarded, not the entire IP packet. Each hop constructs an IP packet 948 for each of the interfaces the BSM is to be forwarded out of; each 949 packet containing the entire BSM that was received. 951 When a Bootstrap message is forwarded, it is forwarded out of every 952 multicast-capable interface which has PIM neighbors (including the one 953 over which the message was received). The exception to this is if the 954 interface is an administrative scope boundary for the admin scope zone 955 indicated in the first group range in the Bootstrap message packet. 957 As an optimization, a router MAY choose not to forward a BSM out of the 958 interface the message was received on if that interface is a point-to- 959 point interface. On interfaces with multiple PIM neighbors, a router 960 SHOULD forward an accepted BSM onto the interface that BSM was received 961 on, but if the number of PIM neighbors on that interface is large, it 962 MAY delay forwarding a BSM onto that interface by a small randomized 963 interval to prevent message implosion. A configuration option MAY be 964 provided to disable forwarding onto the interface a message was received 965 on, but we recommend that the default behavior is to forward onto that 966 interface. 968 Rationale: A BSM needs to be forwarded onto the interface the message 969 was received on (in addition to the other interfaces) because the 970 routers on a LAN may not have consistent routing information. If three 971 routers on a LAN are A, B, and C, and at router B RPF(BSR)==A and at 972 router C RPF(BSR)==B, then router A originally forwards the BSM onto the 973 LAN, but router C will only accept it when router B re-forwards the 974 message onto the LAN. If the underlying routing protocol configuration 975 guarantees that the routers have consistent routing information, then 976 forwarding onto the incoming interface may safely be disabled. 978 A ZBR constrains all BSMs which are of equal or smaller scope than the 979 configured boundary. That is, the BSMs are not accepted from, 980 originated or forwarded on the interfaces on which the boundary is 981 configured. For IPv6 the check is a comparison between the scope of the 982 first range in the scoped BSM and the scope of the configured boundary. 983 For IPv4, the first range in the scoped BSM is checked to see if it is 984 contained in or is the same as the range of the configured boundary. 986 3.5. Bootstrap Messages to New and Rebooting Routers 988 To allow new or rebooting routers to learn the RP-Set quickly, when a 989 Hello message is received from a new neighbor, or a Hello message with a 990 new GenID is received from an existing neighbor, one router on the LAN 991 sends a stored copy of the Bootstrap message for each admin scope zone 992 to the new or rebooting router. 994 This message SHOULD be sent as a No-Forward Bootstrap message, see 995 3.5.1. For backwards compatibility, this message MAY instead or in 996 addition be sent as a Unicast Bootstrap message, see 3.5.2. These 997 messages MUST only be accepted at startup, see 3.1.3. 999 The router that does this is the Designated Router (DR) on the LAN, or, 1000 if the new or rebooting router is the DR, the router that would be the 1001 DR if the new or rebooting router were excluded from the DR election 1002 process. 1004 Before sending a Bootstrap message in this manner, the router must wait 1005 until it has sent a triggered Hello message on this interface; 1006 otherwise, the new neighbor will discard the Bootstrap message. 1008 3.5.1. No-Forward Bootstrap Messages 1010 A No-Forward Bootstrap message, is a bootstrap message that has the No- 1011 Forward bit set. All implementations SHOULD support sending of No- 1012 Forward Bootstrap messages, and SHOULD also accept them. The RPF check 1013 MUST NOT be performed in the BSM processing check for a No-Forward BSM, 1014 see 3.1.3. The messages have the same source and destination addresses 1015 as the usual multicast Bootstrap messages. 1017 3.5.2. Unicasting Bootstrap Messages 1019 For backwards compatibility implementations MAY support Unicast 1020 Bootstrap messages. Whether to send Unicast Bootstrap Messages instead 1021 of or in addition to No-Forward Bootstrap Messages, and also whether to 1022 accept such messages, SHOULD be configurable. This message is unicast 1023 to the neighbor. 1025 3.6. Receiving and Using the RP-Set 1027 The RP-Set maintained by BSR is used by RP-based multicast routing 1028 protocols like PIM-SM and BIDIR-PIM. These protocols may obtain RP-Sets 1029 from other sources as well. How the final group-to-RP mappings are 1030 obtained from these RP-Sets is not part of the BSR specification. In 1031 general, the routing protocols need to re-calculate the mappings when 1032 any of their RP-Sets change. How such a change is signalled to the 1033 routing protocol is also not part of the present specification. 1035 Some group-to-RP mappings in the RP-Set indicate group ranges for which 1036 PIM-SM should be used; others indicate group ranges for use with BIDIR- 1037 PIM. Routers that only support one of these protocols MUST NOT ignore 1038 ranges indicated as being for the other protocol. They MUST NOT treat 1039 them as being for the protocol they support. 1041 If a mapping is not already part of the RP-Set, it is added to the RP- 1042 Set and the associated Group-to-RP mapping Expiry Timer (GET) is 1043 initialized to the holdtime from the Bootstrap message. Its priority is 1044 set to the Priority from the Bootstrap message. 1046 If a mapping is already part of the RP-Set, it is updated with the 1047 Priority from the Bootstrap message and its associated GET is reset to 1048 the holdtime from the Bootstrap message. If the holdtime is zero, the 1049 mapping is removed from the RP-Set immediately. 1051 4. Message Formats 1053 BSR messages are PIM messages, as defined in [1]. The values of the PIM 1054 Message Type field for BSR messages are: 1056 4 Bootstrap 1058 8 Candidate-RP-Advertisement 1060 As with all other PIM control messages, BSR messages have IP protocol 1061 number 103. 1063 Candidate-RP-Advertisement messages are unicast to a BSR. Usually, 1064 Bootstrap messages are multicast with TTL 1 to the ALL-PIM-ROUTERS 1065 group, but in some circumstances (described in section 3.5.2) Bootstrap 1066 messages are unicast to a specific PIM neighbor. 1068 The IP source address used for Candidate-RP-Advertisement messages is a 1069 domain-wide reachable address. The IP source address used for Bootstrap 1070 messages (regardless of whether they are being originated or forwarded) 1071 is the link-local address of the interface on which the message is being 1072 sent (that is, the same source address that the router uses for the 1073 Hello messages it sends out that interface). 1075 The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS 1076 group is ff02::d. 1078 In this section we use the following terms defined in the PIM-SM 1079 specification [1]: 1081 o Encoded-Unicast format 1083 o Encoded-Group format 1085 We repeat these here to aid readability. 1087 Encoded-Unicast address 1089 An Encoded-Unicast address takes the following format: 1091 0 1 2 3 1092 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 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Addr Family | Encoding Type | Unicast Address 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1097 Addr Family 1098 The PIM address family of the `Unicast Address' field of this 1099 address. 1101 Values of 0-127 are as assigned by the IANA for Internet Address 1102 Families in [11]. Values 128-250 are reserved to be assigned by 1103 the IANA for PIM-specific Address Families. Values 251 though 255 1104 are designated for private use. As there is no assignment 1105 authority for this space, collisions should be expected. 1107 Encoding Type 1108 The type of encoding used within a specific Address Family. The 1109 value `0' is reserved for this field, and represents the native 1110 encoding of the Address Family. 1112 Unicast Address 1113 The unicast address as represented by the given Address Family and 1114 Encoding Type. 1116 Encoded-Group address 1118 Encoded-Group addresses take the following format: 1120 0 1 2 3 1121 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 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Addr Family | Encoding Type |B| Reserved |Z| Mask Len | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Group multicast Address 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1128 Addr Family 1129 described above. 1131 Encoding Type 1132 described above. 1134 [B]IDIR bit 1135 When set, all BIDIR capable PIM routers will operate the protocol 1136 described in [2] for the specified group range. 1138 Reserved 1139 Transmitted as zero. Ignored upon receipt. 1141 Admin Scope [Z]one 1142 When set, this bit indicates that this group range is an 1143 administratively scoped range. 1145 Mask Len 1146 The Mask length field is 8 bits. The value is the number of 1147 contiguous one bits left justified used as a mask which, combined 1148 with the group address, describes a range of groups. It is less 1149 than or equal to the address length in bits for the given Address 1150 Family and Encoding Type. If the message is sent for a single 1151 group then the Mask length must equal the address length in bits 1152 for the given Address Family and Encoding Type. (e.g. 32 for IPv4 1153 native encoding and 128 for IPv6 native encoding). 1155 Group multicast Address 1156 Contains the group address. 1158 4.1. Bootstrap Message Format 1160 A bootstrap message may be divided up into 'semantic fragments' if the 1161 resulting IP datagram would exceed the maximum packet size boundaries. 1162 Basically, a single Bootstrap message can be sent as multiple semantic 1163 fragments (each in a separate IP datagram), so long as the fragment tags 1164 of all the semantic fragments comprising the message are the same. The 1165 format of a single non-fragmented message is the same as the one used 1166 for semantic fragments. 1168 The format of a single `fragment' is given below: 1170 0 1 2 3 1171 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 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 |PIM Ver| Type |N| Reserved | Checksum | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | Fragment Tag | Hash Mask Len | BSR Priority | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | BSR Address (Encoded-Unicast format) | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | Group Address 1 (Encoded-Group format) | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | RP Count 1 | Frag RP Cnt 1 | Reserved | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | RP Address 1 (Encoded-Unicast format) | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | RP1 Holdtime | RP1 Priority | Reserved | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | RP Address 2 (Encoded-Unicast format) | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | RP2 Holdtime | RP2 Priority | Reserved | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | . | 1192 | . | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | RP Address m (Encoded-Unicast format) | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | RPm Holdtime | RPm Priority | Reserved | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Group Address 2 (Encoded-Group format) | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | . | 1201 | . | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Group Address n (Encoded-Group format) | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | RP Count n | Frag RP Cnt n | Reserved | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | RP Address 1 (Encoded-Unicast format) | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | RP1 Holdtime | RP1 Priority | Reserved | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 | RP Address 2 (Encoded-Unicast format) | 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | RP2 Holdtime | RP2 Priority | Reserved | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | . | 1216 | . | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | RP Address m (Encoded-Unicast format) | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | RPm Holdtime | RPm Priority | Reserved | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 PIM Version, Reserved, Checksum 1224 Described in [1]. 1226 Type 1227 PIM Message Type. Value is 4 for a Bootstrap message. 1229 [N]o-forward bit 1230 When set, this bit means that the Bootstrap message fragment is not 1231 to be forwarded. 1233 Fragment Tag 1234 A randomly generated number, acts to distinguish the fragments 1235 belonging to different Bootstrap messages; fragments belonging to 1236 same Bootstrap message carry the same `Fragment Tag'. 1238 Hash Mask Len 1239 The length (in bits) of the mask to use in the hash function. For 1240 IPv4 we recommend a value of 30. For IPv6 we recommend a value of 1241 126. 1243 BSR Priority 1244 Contains the BSR priority value of the included BSR. This field is 1245 considered as a high order byte when comparing BSR addresses. BSRs 1246 should by default set this field to 64. Note that for historical 1247 reasons, the highest BSR priority is 255 (the higher the better), 1248 whereas the highest RP Priority (see below) is 0 (the lower the 1249 better). 1251 BSR Address 1252 The address of the bootstrap router for the domain. The format for 1253 this address is given in the Encoded-Unicast address in [1]. 1255 Group Address 1..n 1256 The group ranges (address and mask) with which the Candidate-RPs 1257 are associated. Format described in [1]. In a fragment containing 1258 admin scope ranges, the first group range in the fragment MUST 1259 satisfy the following conditions: it MUST have the Admin Scope bit 1260 set; for IPv4 it MUST be the group range for the entire admin scope 1261 range (this is the case even if there are no RPs in the RP-Set for 1262 the entire admin scope range - in this case the sub-ranges for the 1263 RP-Set are specified later in the fragment along with their RPs); 1264 for IPv6 the Mask Len MUST be at least 16 and have the scope ID of 1265 the admin scope range. 1267 RP Count 1..n 1268 The number of Candidate-RP addresses included in the whole 1269 Bootstrap message for the corresponding group range. A router does 1270 not replace its old RP-Set for a given group range until/unless it 1271 receives `RP-Count' addresses for that range; the addresses could 1272 be carried over several fragments. If only part of the RP-Set for 1273 a given group range was received, the router discards it, without 1274 updating that specific group range's RP-Set. 1276 Frag RP Cnt 1..m 1277 The number of Candidate-RP addresses included in this fragment of 1278 the Bootstrap message, for the corresponding group range. The 1279 `Frag RP Cnt' field facilitates parsing of the RP-Set for a given 1280 group range, when carried over more than one fragment. 1282 RP address 1..m 1283 The address of the Candidate-RPs, for the corresponding group 1284 range. The format for these addresses is given in the Encoded- 1285 Unicast address in [1]. 1287 RP1..m Holdtime 1288 The Holdtime (in seconds) for the corresponding RP. This field is 1289 copied from the `Holdtime' field of the associated RP stored at the 1290 BSR. 1292 RP1..m Priority 1293 The `Priority' of the corresponding RP and Encoded-Group Address. 1294 This field is copied from the `Priority' field stored at the BSR 1295 when receiving a C-RP-Adv message. The highest priority is `0' 1296 (i.e. unlike BSR priority, the lower the value of the `Priority' 1297 field, the better). Note that the priority is per RP per Group 1298 Address. 1300 Within a Bootstrap message, the BSR Address, all the Group Addresses and 1301 all the RP Addresses MUST be of the same address family. In addition, 1302 the address family of the fields in the message MUST be the same as the 1303 IP source and destination addresses of the packet. This permits maximum 1304 implementation flexibility for dual-stack IPv4/IPv6 routers. 1306 4.1.1. Semantic Fragmentation of BSMs 1308 Bootstrap messages may be split over several PIM Bootstrap Message 1309 Fragments (BSMF); this is known as semantic fragmentation. Each of 1310 these must be according to the above format. All fragments of a given 1311 Bootstrap message MUST have identical values for the Type, No-forward 1312 bit, Fragment Tag, Hash Mask Len, BSR Priority and BSR Address fields. 1313 That is, only the group-to-RP mappings may differ between fragments. 1315 This is useful if the BSM would otherwise exceed the MTU of the link the 1316 message will be forwarded over. If one relies purely on IP 1317 fragmentation, one would lose the entire message if one fragment is 1318 lost. By use of semantic fragmentation, one lost IP fragment will only 1319 cause the loss of the semantic fragment that the IP fragment was part 1320 of. As described below, a router only needs to receive all the RPs for 1321 a specific group range to update that range. This means that loss of a 1322 semantic fragment, due to an IP fragment getting lost, only affects the 1323 group ranges the lost semantic fragment contains information for. 1325 If the BSR can split up the BSM so that each group range (and all of its 1326 RP information) can fit entirely inside one BSMF, then it should do so. 1327 If a BSMF is lost, the state from the previous BSM for the group ranges 1328 from the missing BSMF will be retained. Each fragment that does arrive 1329 will update the RP information for the group ranges contained in that 1330 fragment, and the new group-to-RP mappings for those can be used 1331 immediately. The information from the missing fragment will be obtained 1332 when the next BSM is transmitted. 1334 If the list of RPs for a single group range is long, one may split the 1335 information across multiple BSMFs to avoid IP fragmentation. In this 1336 case, all the BSMFs comprising the information for that group range must 1337 be received before the group-to-RP mapping in use can be modified. This 1338 is the purpose of the RP Count field - a router receiving BSMFs from the 1339 same BSM (i.e. that have the same fragment tag) must wait until BSMFs 1340 providing RP Count RPs for that group range have been received before 1341 the new group-to-RP mapping can be used for that group range. If a 1342 single BSMF from such a large group range is lost, then that entire 1343 group range will have to wait until the next BSM is originated. Hence 1344 the benefit of using semantic fragmentation is in this case dubious. 1346 Next we need to consider how a BSR would remove group ranges. A router 1347 receiving a set of BSMFs cannot tell if a group range is missing. If it 1348 has seen a group range before, it must assume that that group range 1349 still exists, and that the BSMF describing it has been lost. It should 1350 retain this information for BS_Timeout. Thus for a BSR to remove a 1351 group range, it should include that group range, but with an RP Count of 1352 zero, and it should resend this information in each BSM for BS_Timeout. 1354 4.2. Candidate-RP-Advertisement Message Format 1356 Candidate-RP-Advertisement messages are periodically unicast from the C- 1357 RPs to the BSR. 1359 0 1 2 3 1360 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 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 |PIM Ver| Type | Reserved | Checksum | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | Prefix Count | Priority | Holdtime | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | RP Address (Encoded-Unicast format) | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | Group Address 1 (Encoded-Group format) | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | . | 1371 | . | 1372 | . | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | Group Address n (Encoded-Group format) | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 PIM Version, Reserved, Checksum 1378 Described in [1]. 1380 Type 1381 PIM Message Type. Value is 8 for a Candidate-RP-Advertisement 1382 message. 1384 Prefix Count 1385 The number of encoded group addresses included in the message; 1386 indicating the group range for which the C-RP is advertising. C- 1387 RPs MUST NOT send C-RP-Adv messages with a Prefix Count of `0'. 1389 Priority 1390 The `Priority' of the included RP, for the corresponding Encoded- 1391 Group Address (if any). The highest priority is `0' (i.e. the 1392 lower the value of the `Priority' field, the higher the priority). 1393 This field is stored at the BSR upon receipt along with the RP 1394 address and corresponding Encoded-Group Address. 1396 Holdtime 1397 The amount of time (in seconds) the advertisement is valid. This 1398 field allows advertisements to be aged out. This field should be 1399 set to 2.5 times C_RP_Adv_Period. 1401 RP Address 1402 The address of the interface to advertise as a Candidate RP. The 1403 format for this address is given in the Encoded-Unicast address in 1404 [1]. 1406 Group Address-1..n 1407 The group ranges for which the C-RP is advertising. Format 1408 described in Encoded-Group-Address in [1]. 1410 Within a Candidate-RP-Advertisement message, the RP Address and all the 1411 Group Addresses MUST be of the same address family. In addition, the 1412 address family of the fields in the message MUST be the same as the IP 1413 source and destination addresses of the packet. This permits maximum 1414 implementation flexibility for dual-stack IPv4/IPv6 routers. 1416 5. Timers and Timer Values 1418 Timer Name: Bootstrap Timer (BST(Z)) 1420 +---------------------+--------------------------+----------------------+ 1421 | Value Name | Value | Explanation | 1422 +---------------------+--------------------------+----------------------+ 1423 | BS_Period | Default: 60 seconds | Periodic interval | 1424 | | | with which BSMs | 1425 | | | are normally | 1426 | | | originated | 1427 +---------------------+--------------------------+----------------------+ 1428 | BS_Timeout | Default: 130 seconds | Interval after | 1429 | | | which a BSR is | 1430 | | | timed out if no | 1431 | | | BSM is received | 1432 | | | from that BSR | 1433 +---------------------+--------------------------+----------------------+ 1434 | BS_Min_Interval | Default: 10 seconds | Minimum interval | 1435 | | | with which BSMs | 1436 | | | may be originated | 1437 +---------------------+--------------------------+----------------------+ 1438 | BS_Rand_Override | see below | Randomized | 1439 | | | interval used to | 1440 | | | reduce control | 1441 | | | message overhead | 1442 | | | during BSR | 1443 | | | election | 1444 +---------------------+--------------------------+----------------------+ 1446 Note that BS_Timeout MUST be larger than BS_Period, even if their values 1447 are changed from the defaults. We recommend that BS_Timeout is set to 2 1448 times BS_Period plus 10 seconds. 1450 BS_Rand_Override is calculated using the following pseudocode, in which 1451 all values are in units of seconds. The values of BS_Rand_Override 1452 generated by this pseudocode are between 5 and 23 seconds, with smaller 1453 values generated if the C-BSR has a high bootstrap weight, and larger 1454 values generated if the C-BSR has a low bootstrap weight. 1456 BS_Rand_Override = 5 + priorityDelay + addrDelay 1458 where priorityDelay is given by: 1460 priorityDelay = 2 * log_2(1 + bestPriority - myPriority) 1462 and addrDelay is given by the following for IPv4: 1464 if (bestPriority == myPriority) { 1465 addrDelay = log_2(1 + bestAddr - myAddr) / 16 1466 } else { 1467 addrDelay = 2 - (myAddr / 2^31) 1468 } 1470 and addrDelay is given by the following for IPv6: 1472 if (bestPriority == myPriority) { 1473 addrDelay = log_2(1 + bestAddr - myAddr) / 64 1474 } else { 1475 addrDelay = 2 - (myAddr / 2^127) 1476 } 1478 and bestPriority is given by: 1480 bestPriority = max(storedPriority, myPriority) 1482 and bestAddr is given by: 1484 bestAddr = max(storedAddr, myAddr) 1486 and where myAddr is the Candidate-BSR's address, storedAddr is the 1487 stored BSR's address, myPriority is the Candidate-BSR's configured 1488 priority, and storedPriority is the stored BSR's priority. 1490 Timer Name: Scope Zone Expiry Timer (SZT(Z)) 1492 +----------------+-----------------------------+------------------------+ 1493 | Value Name | Value | Explanation | 1494 +----------------+-----------------------------+------------------------+ 1495 | SZ_Timeout | Default: 1300 seconds | Interval after | 1496 | | | which a scope zone | 1497 | | | is timed out if no | 1498 | | | BSM is received | 1499 | | | for that scope | 1500 | | | zone | 1501 +----------------+-----------------------------+------------------------+ 1503 Note that SZ_Timeout MUST be larger than BS_Timeout, even if their 1504 values are changed from the defaults. We recommend that SZ_Timeout is 1505 set to 10 times BS_Timeout. 1507 Timer Name: Group-to-C-RP mapping Expiry Timer (CGET(M,Z)) 1509 +--------------------------+--------------------+-----------------------+ 1510 | Value Name | Value | Explanation | 1511 +--------------------------+--------------------+-----------------------+ 1512 | C-RP Mapping Timeout | from message | Holdtime from C- | 1513 | | | RP-Adv message | 1514 +--------------------------+--------------------+-----------------------+ 1516 Timer Name: Group-to-RP mapping Expiry Timer (GET(M,Z)) 1518 +-------------------------+--------------------+------------------------+ 1519 | Value Name | Value | Explanation | 1520 +-------------------------+--------------------+------------------------+ 1521 | RP Mapping Timeout | from message | Holdtime from BSM | 1522 +-------------------------+--------------------+------------------------+ 1523 Timer Name: C-RP Advertisement Timer (CRPT) 1525 +---------------------+-------------------------+-----------------------+ 1526 | Value Name | Value | Explanation | 1527 +---------------------+-------------------------+-----------------------+ 1528 | C_RP_Adv_Period | Default: 60 seconds | Periodic interval | 1529 | | | with which C-RP- | 1530 | | | Adv messages are | 1531 | | | sent to a BSR | 1532 +---------------------+-------------------------+-----------------------+ 1533 | C_RP_Adv_Backoff | Default: 0-3 seconds | Whenever a | 1534 | | | triggered C_RP_Adv | 1535 | | | is sent, a new | 1536 | | | randomized value | 1537 | | | between 0 and 3s | 1538 | | | is used | 1539 +---------------------+-------------------------+-----------------------+ 1541 6. Security Considerations 1543 6.1. Possible Threats 1545 Threats affecting the PIM BSR mechanism are primarily of two forms: 1546 denial of service attacks, and traffic diversion attacks. An attacker 1547 that subverts the BSR mechanism can prevent multicast traffic from 1548 reaching the intended recipients, can divert multicast traffic to a 1549 place where they can monitor it, and can potentially flood third parties 1550 with traffic. 1552 Traffic can be prevented from reaching the intended recipients by one of 1553 two mechanisms: 1555 o Subverting a BSM, and specifying RPs that won't actually forward 1556 traffic. 1558 o Registering with the BSR as a C-RP, and then not forwarding 1559 traffic. 1561 Traffic can be diverted to a place where it can be monitored by both of 1562 the above mechanisms; in this case the RPs would forward the traffic, 1563 but are located so as to aid monitoring or man-in-the-middle attacks on 1564 the multicast traffic. 1566 A third party can be flooded by either of the above two mechanisms by 1567 specifying the third party as the RP, and register-encapsulated traffic 1568 will then be forwarded to them. 1570 6.2. Limiting Third-Party DoS Attacks 1572 The third party DoS attack above can be greatly reduced if PIM routers 1573 acting as DR do not continue to forward Register traffic to the RP in 1574 the presence of ICMP Protocol Unreachable or ICMP Host Unreachable 1575 responses. If a PIM router sending Register packets to an RP receives 1576 one of these responses to a data packet it has sent, it should rate- 1577 limit the transmission of future Register packets to that RP for a short 1578 period of time. 1580 As this does not affect interoperability, the precise details are left 1581 to the implementer to decide. However we note that a router 1582 implementing such rate limiting must only do so if the ICMP packet 1583 correctly echoes part of a Register packet that was sent to the RP. If 1584 this check were not made, then simply sending ICMP Unreachable packets 1585 to the DR with the source address of the RP spoofed would be sufficient 1586 to cause a denial-of-service attack on the multicast traffic originating 1587 from that DR. 1589 6.3. Bootstrap Message Security 1591 If a legitimate PIM router in a domain is compromised, there is little 1592 any security mechanism can do to prevent that router subverting PIM 1593 traffic in that domain. 1595 Implementations SHOULD provide a per interface configuration option 1596 where one can specify that no Bootstrap messages are to be sent out of 1597 or accepted on the interface. This should generally be configured on 1598 all PMBRs in order to not receive messages from neighboring domains. 1599 This avoids receiving legitimate messages with conflicting BSR 1600 information from other domains, and also prevents BSR attacks from 1601 neighboring domains. This option is also useful on leaf interfaces 1602 where there are only hosts present. However, the Security 1603 Considerations section of [1], state that there should be a mechanism 1604 for not accepting PIM Hello messages on leaf interfaces and messages are 1605 only accepted from valid PIM neighbors. There may however be additional 1606 issues with unicast Bootstrap messages, see below. In addition to 1607 dropping all multicast Bootstrap messages on PMBRs we also recommend 1608 configuring PMBRs (both towards other domains and on leaf interfaces) to 1609 drop all unicast PIM messages (Bootstrap message, Candidate RP 1610 Advertisement, PIM register and PIM register stop). 1612 6.3.1. Unicast Bootstrap Messages 1614 There are some possible security issues with unicast Bootstrap Messages. 1615 The Bootstrap Message Processing Checks prevent a router from accepting 1616 a Bootstrap message from outside of the PIM Domain, as the source 1617 address on Bootstrap messages must be an immediate PIM neighbor. There 1618 is however a small window of time after a reboot where a PIM router will 1619 accept a bad Bootstrap message unicast from an immediate neighbor, and 1620 it might be possible to unicast a Bootstrap message to a router during 1621 this interval from outside the domain, using the spoofed source address 1622 of a neighbor. The best way to protect against this is to use the above 1623 mentioned mechanism configuring border and leaf interfaces to drop all 1624 bootstrap messages, including unicast messages. This can also be 1625 prevented if PMBRs perform source-address filtering to prevent packets 1626 entering the PIM domain with IP source addresses that are infrastructure 1627 addresses in the PIM domain. 1629 The use of unicast Bootstrap messages is for backwards compatibility 1630 only. Due to the possible security implications, implementations 1631 supporting unicast Bootstrap messages SHOULD provide a configuration 1632 option for whether they are to be used. 1634 6.3.2. Multi-access subnets 1636 As mentioned above, implementations SHOULD provide a per interface 1637 configuration option so that leaf interfaces and interfaces facing other 1638 domains can be configured to drop all Bootstrap messages. In this 1639 section we will consider multi-access subnets where there are both 1640 multiple PIM routers in a PIM domain and also PIM routers outside the 1641 PIM domain or non-trusted hosts. On such subnets one should if possible 1642 configure the PMBRs to drop Bootstrap messages. This is possible 1643 provided that the routers in the PIM domain receive Bootstrap messages 1644 on other internal subnets. That is, for each of the routers on the 1645 multi-access subnet that are in our domain, the RPF interface for each 1646 of the candidate BSR addresses must be an internal interface (an 1647 interface not on a multi-access subnet). There are however network 1648 topologies where this is not possible. For such topologies, we 1649 recommend that IPsec AH is used to protect communication between the PIM 1650 routers in the domain, and that such routers are configured to drop and 1651 log communication attempts from any node that do not pass the 1652 authentication check. When all the PIM routers are under the same 1653 administrative control, this authentication may use a configured shared 1654 secret. In order to prevent replay attacks one will need to have one SA 1655 per sender using the sender address for SA lookup. The securing of 1656 interactions between PIM neighbors is discussed in more detail in the 1657 Security Considerations section of [1], and so we do not discuss the 1658 details further here. The same security mechanisms that can be used to 1659 secure PIM Join, Prune and Assert messages should also be used to secure 1660 Bootstrap messages. How exactly to secure PIM link-local messages is 1661 still being worked on by the PIM working group, see [10]. 1663 6.4. Candidate-RP-Advertisement Message Security 1665 Even if it is not possible to subvert Bootstrap messages, an attacker 1666 might be able to perform most of the same attacks by simply sending C- 1667 RP-Adv messages to the BSR specifying the attacker's choice of RPs. 1668 Thus it is necessary to control the sending of C-RP-Adv messages in 1669 essentially the same ways that we control Bootstrap messages. However, 1670 C-RP-Adv messages are unicast and normally travel multiple hops, so 1671 controlling them is more difficult. 1673 6.4.1. Non-Cryptographic Security of C-RP-Adv Messages 1675 We recommend that PMBRs are configured to drop C-RP-Adv messages. One 1676 might configure the PMBRs to drop all unicast PIM messages (Bootstrap 1677 message, Candidate RP Advertisement, PIM register and PIM register 1678 stop). PMBRs may also perform source-address filtering to prevent 1679 packets entering the PIM domain with IP source addresses that are 1680 infrastructure addresses in the PIM domain. We also recommend that 1681 implementations have a way of restricting which IP addresses the BSR 1682 accepts C-RP-Adv messages from. The BSR can then be configured to only 1683 accept C-RP-Adv messages from infrastructure addresses or the subset 1684 used for candidate RPs. 1686 If the unicast and multicast topologies are known to be congruent, the 1687 following checks should be made. On interfaces that are configured to 1688 be leaf subnets, all C-RP-Adv messages should be dropped. On multi- 1689 access subnets with multiple PIM routers and hosts that are not trusted, 1690 the router can at least check that the source MAC address is that of a 1691 valid PIM neighbor. 1693 6.4.2. Cryptographic Security of C-RP-Adv Messages 1695 For true security, we recommend that all C-RPs are configured to use 1696 IPsec authentication. The authentication process for a C-RP-Adv message 1697 between a C-RP and the BSR is identical to the authentication process 1698 for PIM Register messages between a DR and the relevant RP, except that 1699 there will normally be fewer C-RPs in a domain than there are DRs, so 1700 key management is a little simpler. We do not describe the details of 1701 this process further here, but refer to the Security Considerations 1702 section of [1]. Note that the use of cryptographic security for C-RP- 1703 Adv messages does not remove the need for the non-cryptographic 1704 mechanisms, as explained above. 1706 6.5. Denial of Service using IPsec 1708 An additional concern is that of Denial-of-Service attacks caused by 1709 sending high volumes of Bootstrap messages or C-RP-Adv messages with 1710 invalid IPsec authentication information. It is possible that these 1711 messages could overwhelm the CPU resources of the recipient. 1713 The non-cryptographic security mechanisms above restrict from where 1714 unicast Bootstrap messages and C-RP-Adv messages are accepted. In 1715 addition, we recommend that rate-limiting mechanisms can be configured, 1716 to be applied on receipt of unicast PIM packets. The rate-limiter MUST 1717 independently rate-limit different types of PIM packets - for example a 1718 flood of C-RP-Adv messages MUST NOT cause a rate limiter to drop low- 1719 rate Bootstrap messages. Such a rate-limiter might itself be used to 1720 cause a denial of service attack by causing valid packets to be dropped, 1721 but in practice this is more likely to constrain bad PIM messages. The 1722 rate limiter will prevent attacks on PIM from affecting other activity 1723 on the receiving router, such as unicast routing. 1725 7. Contributors 1727 Bill Fenner, Mark Handley, Roger Kermode and David Thaler have 1728 contributed greatly to this draft. They were authors of this draft up 1729 to version 03, and much of the current text comes from version 03. 1731 8. Acknowledgments 1733 PIM-SM was designed over many years by a large group of people, 1734 including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve 1735 Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, 1736 Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, 1737 Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish 1738 Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas and Hugh 1739 Holbrook. This BSR specification draws heavily on text from RFC 2362. 1741 Many members of the PIM Working Group have contributed comments and 1742 corrections for this document, including Christopher Thomas Brown, Ardas 1743 Cilingiroglu, Murthy Esakonu, Venugopal Hemige, Prashant Jhingran, 1744 Rishabh Parekh and Katta Sambasivarao. 1746 9. IANA Considerations 1748 This document has no actions for IANA. 1750 10. Normative References 1752 [1] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 1753 Independent Multicast - Sparse Mode (PIM-SM): Protocol 1754 Specification (Revised)", RFC 4601, August 2006. 1756 [2] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional 1757 Protocol Independent Multicast (BIDIR-PIM)", Internet Draft draft- 1758 ietf-pim-bidir-08.txt 1760 [3] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, July 1761 1998. 1763 [4] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill, "IPv6 1764 Scoped Address Architecture", RFC 4007, March 2005. 1766 [5] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC 1767 4291, February 2006. 1769 [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1770 Levels", BCP 14, RFC 2119, March 1997. 1772 11. Informative References 1774 [7] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode 1775 (PIM-SM): Protocol Specification", RFC 2362, June 1998 (now 1776 obsolete). 1778 [8] D. Kim, D. Meyer, H. Kilmer, D. Farinacci, "Anycast Rendevous Point 1779 (RP) mechanism using Protocol Independent Multicast (PIM) and 1780 Multicast Source Discovery Protocol (MSDP)", RFC 3446, January 1781 2003. 1783 [9] D. Farinacci, Y. Cai, "Anycast-RP Using Protocol Independent 1784 Multicast (PIM)", RFC 4610, August 2006 1786 [10] W. Atwood, S. Islam, "Security Issues in PIM-SM Link-local 1787 Messages", Internet Draft draft-ietf-pim-sm-linklocal-01, Work in 1788 Progress, July 2007. 1790 [11] IANA, "Address Family Numbers", linked from 1791 http://www.iana.org/numbers.html 1793 Authors' Addresses 1795 Nidhi Bhaskar 1796 Arastra, Inc. 1797 P.O. Box 10905 1798 Palo Alto, CA 94303 1799 USA 1800 nidhi@arastra.com 1801 Alexander Gall 1802 SWITCH 1803 Limmatquai 138 1804 P.O. Box 1805 CH-8021 Zurich 1806 Switzerland 1807 gall@switch.ch 1809 James Lingard 1810 Arastra, Inc. 1811 P.O. Box 10905 1812 Palo Alto, CA 94303 1813 USA 1814 jchl@arastra.com 1816 Stig Venaas 1817 UNINETT 1818 NO-7465 Trondheim 1819 Norway 1820 venaas@uninett.no 1822 Copyright Statement 1824 Copyright (C) The IETF Trust (2007). 1826 This document is subject to the rights, licenses and restrictions 1827 contained in BCP 78, and except as set forth therein, the authors retain 1828 all their rights. 1830 This document and the information contained herein are provided on an 1831 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 1832 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE 1833 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1834 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1835 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1836 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1838 Intellectual Property 1840 The IETF takes no position regarding the validity or scope of any 1841 Intellectual Property Rights or other rights that might be claimed to 1842 pertain to the implementation or use of the technology described in this 1843 document or the extent to which any license under such rights might or 1844 might not be available; nor does it represent that it has made any 1845 independent effort to identify any such rights. Information on the 1846 procedures with respect to rights in RFC documents can be found in BCP 1847 78 and BCP 79. 1849 Copies of IPR disclosures made to the IETF Secretariat and any 1850 assurances of licenses to be made available, or the result of an attempt 1851 made to obtain a general license or permission for the use of such 1852 proprietary rights by implementers or users of this specification can be 1853 obtained from the IETF on-line IPR repository at 1854 http://www.ietf.org/ipr. 1856 The IETF invites any interested party to bring to its attention any 1857 copyrights, patents or patent applications, or other proprietary rights 1858 that may cover technology that may be required to implement this 1859 standard. Please address the information to the IETF at ietf- 1860 ipr@ietf.org.