idnits 2.17.1 draft-ietf-pim-sm-bsr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 110 instances of too long lines in the document, the longest one being 3 characters 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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 534: '...mically learned. The interval MUST be...' RFC 2119 keyword, line 584: '...zones MAY be combined into a single me...' RFC 2119 keyword, line 588: '...herwise this bit MUST NOT be set. Thi...' RFC 2119 keyword, line 607: '...ng shut down, it SHOULD immediately se...' RFC 2119 keyword, line 790: '...erent scope zone MUST occupy a differe...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (20 July 2001) is 8316 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) == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-03 ** Obsolete normative reference: RFC 2362 (ref. '2') (Obsoleted by RFC 4601, RFC 5059) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 Bill Fenner/AT&T 3 draft-ietf-pim-sm-bsr-01.txt Mark Handley/ACIRI 4 Roger Kermode/Motorola 5 David Thaler/Microsoft 6 20 July 2001 7 Expires: January 2002 9 Bootstrap Router (BSR) Mechanism for PIM Sparse Mode 11 Status of this Document 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document is a product of the IETF PIM WG. Comments should be 32 addressed to the authors, or the WG's mailing list at 33 pim@catarina.usc.edu. 35 Abstract 37 This document specifies the Bootstrap Router (BSR) mechanism 38 for Protocol Independent Multicast - Sparse Mode (PIM-SM). 39 BSR is one way that a PIM-SM router can learn the set of 40 group-to-RP mappings required in order to function. The 41 mechanism is dynamic, largely self-configuring, and robust to 42 router failure. 44 Table of Contents 46 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 47 1.1. Overview of Bootstrap and RP Discovery for 48 Global Scope. . . . . . . . . . . . . . . . . . . . . . . 4 49 1.2. Administratively Scoped Multicast and BSR. . . . . . 5 50 2. BSR State and Timers. . . . . . . . . . . . . . . . . . 6 51 3. Bootstrap Router Election and RP-Set 52 Distribution . . . . . . . . . . . . . . . . . . . . . . . 8 53 3.1. Sending Candidate-RP-Advertisements. . . . . . . . . 15 54 3.2. Creating the RP-Set at the BSR . . . . . . . . . . . 16 55 3.3. Forwarding Bootstrap Messages. . . . . . . . . . . . 17 56 3.4. Receiving and Using the RP-Set . . . . . . . . . . . 17 57 4. Message Formats . . . . . . . . . . . . . . . . . . . . 17 58 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 19 59 4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 23 60 4.2. Candidate-RP-Advertisement Format. . . . . . . . . . 25 61 5. Default Values for Timers . . . . . . . . . . . . . . . 26 62 6. Security Considerations . . . . . . . . . . . . . . . . 27 63 6.1. Possible Threats . . . . . . . . . . . . . . . . . . 27 64 6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 28 65 6.3. BS Message Security. . . . . . . . . . . . . . . . . 28 66 6.4. C-RP-Advertisement Security. . . . . . . . . . . . . 30 67 6.5. Denial of Service using IPsec. . . . . . . . . . . . 30 68 7. Authors' Addresses. . . . . . . . . . . . . . . . . . . 31 69 8. References. . . . . . . . . . . . . . . . . . . . . . . 32 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . 32 72 1. Introduction 74 Note: this document assumes familiarity with the workings of Protocol 75 Independent Multicast - Sparse Mode, as defined in [1]. 77 For correct operation, every PIM Sparse-mode router within a PIM domain 78 must be able to map a particular global-scope multicast group address to 79 the same RP. If this is not the case then black holes may appear, where 80 some receivers in the domain cannot receive some groups. A domain in 81 this context is a contiguous set of routers that all implement PIM and 82 are configured to operate within a common boundary defined by PIM 83 Multicast Border Routers (PMBRs). PMBRs connect each PIM domain to the 84 rest of the internet. 86 A PIM domain may also broken up into multiple administrative scope 87 regions - these are regions where a border has been configured so that a 88 range of multicast groups will not be forwarded across that border. For 89 more information on Administratively Scoped IP Multicast, see RFC 2365. 90 The modified criteria for admin-scoped regions are that the region is 91 convex with respect to forwarding based on the MRIB, and that all PIM 92 routers within the same scope region map a particular scoped group to 93 the same RP within that region. 95 The PIM-SM specification does not mandate the use of a single mechanism 96 to provide routers with the information to perform the group-to-RP 97 mapping. This document describes the Bootstrap Router (BSR) mechanism. 98 BSR was first defined in RFC 2362 [2], which has since been obsoleted. 99 This document provides an updated specification of the BSR mechanism 100 from RFC 2362, and also extends it to cope with administratively scoped 101 region boundaries. 103 1.1. Overview of Bootstrap and RP Discovery for Global Scope 105 A small set of routers from a domain are configured as candidate 106 bootstrap routers (C-BSRs) and, through a simple election mechanism, a 107 single BSR is selected for that domain. A set of routers within a domain 108 are also configured as candidate RPs (C-RPs); typically these will be 109 the same routers that are configured as C-BSRs. Candidate RPs 110 periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to 111 the BSR of that domain, advertising their willingness to be an RP. A C- 112 RP-Adv message includes the address of the advertising C-RP, as well as 113 an optional list of group addresses and a mask length fields, indicating 114 the group prefix(es) for which the candidacy is advertised. The BSR then 115 includes a set of these Candidate-RPs (the RP-Set), along with their 116 corresponding group prefixes, in Bootstrap messages it periodically 117 originates. Bootstrap messages are distributed hop-by-hop throughout 118 the domain. 120 All the PIM routers in the domain receive and store Bootstrap messages 121 originated by the BSR. When a DR receives an indication of local 122 membership (typically from IGMP [3] or MLD [4]) or a data packet from a 123 directly connected host, for a group for which it has no forwarding 124 state, the DR uses a hash function to map the group address to one of 125 the C-RPs from the RP-Set whose group-prefix includes the group (see 126 [1]). The DR then sends a Join message towards that RP if the local host 127 joined the group, or it Register-encapsulates and unicasts the data 128 packet to the RP if the local host sent a packet to the group. 130 A Bootstrap message indicates liveness of the RPs included therein. If 131 an RP is included in the message, then it is tagged as `up' at the 132 routers; RPs not included in the message are removed from the list of 133 RPs over which the hash algorithm acts. Each router continues to use the 134 contents of the most recently received Bootstrap message from the BSR 135 until it accepts a new Bootstrap message. 137 If a PIM domain becomes partitioned, each area separated from the old 138 BSR will elect its own BSR, which will distribute an RP-Set containing 139 RPs that are reachable within that partition. When the partition heals, 140 another election will occur automatically and only one of the BSRs will 141 continue to send out Bootstrap messages. As is expected at the time of a 142 partition or healing, some disruption in packet delivery may occur. This 143 time will be on the order of the region's round-trip time and the 144 bootstrap router timeout value. 146 1.2. Administratively Scoped Multicast and BSR 148 Administratively Scoped IP Multicast, as defined in RFC 2365, permits a 149 network provider to configure scope boundaries at multicast routers. 150 Such a scope boundary consists of a range of multicast addresses 151 (expressed as an address and mask) that the router will not forward 152 across the boundary. For correct operation, such a scope zone border 153 must be complete and convex. By this we mean that there must be no path 154 from inside the scoped zone to outside it that does not pass through a 155 configured scope border router, and that the multicast capable path 156 between any arbitrary pair of multicast routers in the scope zone must 157 remain in the zone. 159 For PIM-SM using BSR to function correctly with admin scoping, there 160 must be a BSR and at least one C-RP within every admin scope region. 161 Admin scope zone boundaries must be configured at the Zone Border 162 Routers (ZBRs), as they need to filter PIM Join messages that might 163 inadvertently cross the border due to error conditions. In addition, at 164 least one C-BSR within the admin scope zone must be configured to be a 165 C-BSR for the admin scope zone's address range. 167 A separate BSR election will then take place (using bootstrap messages) 168 for every admin scope range (plus one for the global range). Admin 169 scope ranges are identified in the bootstrap message because the group 170 range is marked (using the "Admin Scope" bit, previously a "Reserved" 171 bit) to indicate that this is an administrative scope range, and not 172 just a range that a particular set of RPs are configured to handle. 174 Such admin scoped bootstrap message packets are flooded in the normal 175 way, but will not be forwarded by another ZBR across the boundary for 176 that scope zone (see Section 3.3 for the specifics of this). 178 We do not require that C-RPs within the scope zone be configured to know 179 about the scope zone, as they can learn of its existence from bootstrap 180 messages. However, we recommend that router vendors implement 181 configuration options that allow a C-RP to be configured to be a C-RP 182 for global scope only, for one of more admin scopes only, or for all 183 scopes, both global and admin scoped. We also recommend that the 184 default be that a C-RP is a C-RP for all scopes, both global and admin 185 scoped. 187 Unless configured otherwise, C-RPs discover the existence of the admin 188 scope zone and its group range from receiving a bootstrap message from 189 the scope zone's elected BSR containing the scope zone's group-range, 190 marked using the "Admin Scope" bit. A C-RP stores each elected BSR's 191 address and the admin scope range contained in its bootstrap message. 192 It separately unicasts Candidate-RP-Advertisement messages to the 193 appropriate BSR for every admin scope range within which it is willing 194 to serve as an RP. 196 All PIM routers within a PIM bootstrap domain where admin scope ranges 197 are in use must be capable of receiving bootstrap messages and storing 198 the winning BSR and RPset for all admin scope zones that apply. Thus 199 PIM routers that only implement RFC 2362 (which only allows one BSR per 200 domain) cannot be used in PIM domains where admin scope zones are 201 configured. 203 2. BSR State and Timers 205 A PIM-SM router implementing BSR holds the following state in addition 206 to the state needed for PIM-SM operation: 208 At all routers: 210 List of Active Scope Zones 211 Per Scope Zone: 213 Bootstrap State: 215 o Bootstrap Router's IP Address 217 o BSR Priority 219 o Bootstrap Timer (BST) 221 o List of Scope Group-Ranges for this BSR 223 RP Set 225 At a Candidate BSR: 227 Per Scope Zone: 229 o My state: One of "Candidate-BSR", "Pending-BSR", 230 "Elected-BSR" 232 At a router that is not a Candidate BSR: 234 Per Scope Zone: 236 My state: One of "Accept Any", "Accept Preferred" 238 Scope-Zone Expiry Timer: SZT(Z) 240 Bootstrap state is described in section 3, and the RP Set is described 241 in section 3.4. 243 The following timers are also required: 245 At the Bootstrap Router only: 247 Per Scope Zone (Z): 249 Per Candidate RP (C): 251 C-RP Expiry Timer: CET(C,Z) 253 At the C-RPs only: 255 C-RP Advertisement Timer: CRPT 257 3. Bootstrap Router Election and RP-Set Distribution 259 For simplicity, bootstrap messages (BSMs) are used in both the BSR 260 election and the RP-Set distribution mechanisms. 262 The state-machine for bootstrap messages depends on whether or not a 263 router has been configured to be a Candidate-BSR for a particular scope 264 zone. The per-scope-zone state-machine for a C-BSR is given below, 265 followed by the state-machine for a router that is not configured to be 266 a C-BSR. 268 Per-Scope-Zone Candidate-BSR State Machine 270 +-----------------------------------+ 271 | Figures omitted from text version | 272 +-----------------------------------+ 274 Figure 1: Per-Scope-Zone State-machine for a candidate BSR 276 In tabular form this state machine is: 278 +-----------------------------------------------------------------------+ 279 | When in C-BSR state | 280 +------------+-------------------+-------------------+------------------+ 281 | Event | Receive | BS Timer | Receive non- | 282 | | Preferred BSM | Expires | preferred BSM | 283 | | | | from Elected | 284 | | | | BSR | 285 +------------+-------------------+-------------------+------------------+ 286 | | -> C-BSR state | -> P-BSR state | -> P-BSR state | 287 | | Forward BSM; | Set BS Timer | Set BS Timer | 288 | Action | Store RP Set; | to | to | 289 | | Set BS Timer | rand_override | rand_override | 290 | | to BS Timeout | | | 291 +------------+-------------------+-------------------+------------------+ 292 +-----------------------------------------------------------------------+ 293 | When in P-BSR state | 294 +-------------+-------------------+------------------+------------------+ 295 | Event | Receive | BS Timer | Receive Non- | 296 | | Preferred BSM | Expires | preferred BSM | 297 +-------------+-------------------+------------------+------------------+ 298 | | -> C-BSR state | -> E-BSR state | -> P-BSR state | 299 | | Forward BSM; | Originate BSM; | | 300 | Action | Store RP Set; | Set BS Timer | | 301 | | Set BS Timer | to BS Period | | 302 | | to BS Timeout | | | 303 +-------------+-------------------+------------------+------------------+ 305 +-----------------------------------------------------------------------+ 306 | When in E-BSR state | 307 +-------------+-------------------+------------------+------------------+ 308 | Event | Receive | BS Timer | Receive Non- | 309 | | Preferred BSM | Expires | preferred BSM | 310 +-------------+-------------------+------------------+------------------+ 311 | | -> C-BSR state | -> E-BSR state | -> E-BSR state | 312 | | Forward BSM; | Originate BSM; | Originate BSM; | 313 | Action | Store RP Set; | Set BS Timer | Set BS Timer | 314 | | Set BS Timer | to BS Period | to BS Period | 315 | | to BS Timeout | | | 316 +-------------+-------------------+------------------+------------------+ 317 A candidate-BSR may be in one of three states for a particular scope 318 zone: 320 Candidate-BSR (C-BSR) 321 The router is a candidate to be the BSR for the scope zone, but 322 currently another router is the preferred BSR. 324 Pending-BSR (P-BSR) 325 The router is a candidate to be the BSR for the scope zone. 326 Currently no other router is the preferred BSR, but this router is 327 not yet the BSR. For comparisons with incoming BS messages, the 328 router treats itself as the BSR. This is a temporary state that 329 prevents rapid thrashing of the choice of BSR during BSR election. 331 Elected-BSR (E-BSR) 332 The router is the elected bootstrap router for the scope zone and 333 it must perform all the BSR functions. 335 On startup, the initial state for this configured scope zone is 336 "Pending-BSR"; the BS Timer is initialized to the BS Timeout value. 338 In addition to the three states, there is one timer: 340 o The bootstrap timer (BS Timer) - that is used to time out old 341 bootstrap router information, and used in the election process to 342 terminate P-BSR state. 344 Per-Scope-Zone State-machine for Non-Candidate-BSR Routers 346 +-----------------------------------+ 347 | Figures omitted from text version | 348 +-----------------------------------+ 350 Figure 2: Per-Scope-Zone State-machine for a router not configured as C-BSR 352 In tabular form this state machine is: 354 +-----------------------------------------------------------------------+ 355 | When in No Info state | 356 +--------------------+--------------------------------------------------+ 357 | Event | Receive BSM for unknown Admin Scope | 358 +--------------------+--------------------------------------------------+ 359 | | -> AP State | 360 | Action | Forward BSM; Store RP-Set; | 361 | | Set BS Timer to BS Timeout; | 362 | | Set SZ Timer to SZ Timeout | 363 +--------------------+--------------------------------------------------+ 365 +-----------------------------------------------------------------------+ 366 | When in Accept Any state | 367 +---------------+-----------------------------+-------------------------+ 368 | Event | Receive BSM | SZ Timer Expires | 369 +---------------+-----------------------------+-------------------------+ 370 | | -> AP State | -> No Info state | 371 | | Forward BSM; Store | cancel timers; | 372 | Action | RP-Set; Set BS | clear state | 373 | | Timer to BS | | 374 | | Timeout | | 375 +---------------+-----------------------------+-------------------------+ 376 +-----------------------------------------------------------------------+ 377 | When in Accept Preferred state | 378 +------------+-------------------+-------------------+------------------+ 379 | Event | Receive | BS Timer | Receive Non- | 380 | | Preferred BSM | Expires | preferred BSM | 381 +------------+-------------------+-------------------+------------------+ 382 | | -> AP State | -> AA State | -> AP State | 383 | | Forward BSM; | | | 384 | Action | Store RP-Set; | | | 385 | | Set BS Timer | | | 386 | | to BS Timeout | | | 387 +------------+-------------------+-------------------+------------------+ 389 A router that is not a candidate-BSR may be in one of three states: 391 No Info 392 The router has no information about this scope zone. This state 393 does not apply if the router is configured to know about this scope 394 zone, or for the global scope zone. When in this state, no state 395 information is held and no timers run that refer to this scope 396 zone. 398 Accept Any (AA) 399 The router does not know of an active BSR, and will accept the 400 first bootstrap message it sees as giving the new BSR's identity 401 and the RP-Set. If the router has an RP-Set cached from an 402 obsolete bootstrap message, it continues to use it. 404 Accept Preferred (AP) 405 The router knows the identity of the current BSR, and is using the 406 RP-Set provided by that BSR. Only bootstrap messages from that BSR 407 or from a C-BSR with higher weight than the current BSR will be 408 accepted. 410 On startup, the initial state for this scope zone is "Accept Any" for 411 routers that know about this scope zone, either through configuration or 412 because the scope zone is the global scope which always exists; the SZ 413 Timer is considered to be always running for such scope zones. For 414 routers that do not know about a particular scope zone, the initial 415 state is No Info; no timers exist for the scope zone. 417 In addition to the three states, there are two timers: 419 o The bootstrap timer (BS Timer) - that is used to time out old 420 bootstrap router information. 422 o The scope zone timer (SZ Timer) - that is used to time out the scope 423 zone itself if BS messages specifying this scope zone stop arriving. 425 Bootstrap Message Processing Checks 427 When a bootstrap message is received, the following initial checks must 428 be performed: 430 if ( (DirectlyConnected(BSM.src_ip_address) == FALSE) 431 OR (we have no Hello state for BSM.src_ip_address)) { 432 drop the BS message silently 433 } 434 if (BSM.dst_ip_address == ALL-PIM-ROUTERS group) { 435 if ( BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address) ) { 436 drop the BS message silently 437 } 438 } else if (BSM.dst_ip_address is one of my addresses) { 439 if ( (Any previous BSM for this scope has been accepted) { 440 #the packet was unicast, but this wasn't 441 #a quick refresh on startup 442 drop the BS message silently 443 } 444 } else { 445 drop the BS message silently 446 } 447 if (the interface the message arrived on is an Admin Scope 448 border for the BSM.first_group_address) { 449 drop the BS message silently 450 } 452 Basically, the packet must have come from a directly connected neighbor 453 for which we have active Hello state. It must have been sent to the 454 ALL-PIM-ROUTERS group by the correct upstream router towards the BSR 455 that originated the BS message, or the router must have no BSR state (it 456 just restarted) and have received the BS message by unicast. In 457 addition it must not have arrived on an interface that is a configured 458 admin scope border for the first group address contained in the BS 459 message. 461 BS State-machine Transition Events 463 If the bootstrap message passes the initial checks above without being 464 discarded, then it may cause a state transition event in one of the 465 above state-machines. For both candidate and non-candidate BSRs, the 466 following transition events are defined: 468 Receive Preferred BSM 469 A bootstrap message is received from a BSR that has greater 470 than or equal weight than the current BSR. In a router is in 471 P-BSR state, then it uses its own weight as that of the 472 current BSR. 474 The weighting for a BSR is the concatenation in fixed- 475 precision unsigned arithmetic of the BSR priority field from 476 the bootstrap message and the IP address of the BSR from the 477 bootstrap message (with the BSR priority taking the most- 478 significant bits and the IP address taking the least 479 significant bits). 481 Receive BSM 482 A bootstrap message is received, regardless of BSR weight. 483 A non-candidate BSM also has the following transition event defined: 485 Receive BSM for unknown Admin Scope 486 As "Receive BSM", except that the admin scope zone indicated 487 in the BSM was not previously known at this router. 489 BS State-machine Actions 491 The state-machines specify actions that include setting the BS timer to 492 the following values: 494 BS Period 495 The periodic interval with which bootstrap messages are 496 normally sent. The default value is 60 seconds. 498 BS Timeout 499 The interval after which bootstrap router state is timed out 500 if no bootstrap message from that router has been heard. The 501 default value is 2 times the BS Period plus 10 seconds, which 502 is 130 seconds. 504 Randomized Override Interval 505 The randomized interval during which a router avoids sending a 506 bootstrap message while it waits to see if another router has 507 a higher bootstrap weight. This interval is to reduce control 508 message overhead during BSR election. The following 509 pseudocode is proposed as an efficient implementation of this 510 "randomized" value: 512 Delay = 5 + 2 * log_2(1 + bestPriority - myPriority) 513 + AddrDelay 515 where myPriority is the Candidate-BSR's configured priority, 516 and bestPriority equals: 518 bestPriority = Max(storedPriority, myPriority) 520 and AddrDelay is given by the following: 522 if ( bestPriority == myPriority) { 523 AddrDelay = log_2(storedAddr - myAddr) / 16 524 } else { 525 AddrDelay = 2 - (myAddr / 2^31) 526 } 528 where myAddr is the Candidate-BSR's address, storedAddr is the 529 stored BSR's address, and storedPriority is the stored BSR's 530 priority. 532 SZ Period 533 The interval after which a router will time out an Admin Scope 534 zone that it has dynamically learned. The interval MUST be 535 larger than the BS Timeout. The default value is ten times 536 the BS Timeout, which is 1500 seconds. 538 In addition to setting the timers, the following actions may be 539 triggered by state-changes in the state-machines: 541 Forward BSM 542 The bootstrap message is forwarded out of all multicast- 543 capable interfaces, except the interface it was received on, 544 or where this would cause the BSM to cross an admin-scope 545 boundary for the scope zone indicated in the message. The 546 source IP address of the message is the forwarding router's IP 547 address on the interface the message is being forwarded from, 548 the destination address is ALL-PIM-ROUTERS, and the TTL of the 549 message is set to 1. 551 Originate BSM 552 A new bootstrap message is constructed by the BSR, giving the 553 BSR's address and BSR priority, and containing the BSR's 554 chosen RP-Set. The message is forwarded out of all multicast- 555 capable interfaces, except where this would cause the BSM to 556 cross an admin-scope boundary for the scope zone indicated in 557 the message. The IP source address of the message is the 558 originating router's IP address on the interface the message 559 is being forwarded from, the destination address is ALL-PIM- 560 ROUTERS, and the TTL of the message is set to 1. 562 Store RP Set 563 The RP-Set from the received bootstrap message is stored and 564 used by the router to decide the RP for each group that the 565 router has state for. Storing this RP Set may cause other 566 state-transitions to occur in the router. The BSR's IP 567 address and priority from the received bootstrap message are 568 also stored to be used to decide if future bootstrap messages 569 are preferred. 571 In addition to the above state-machine actions, a DR also unicasts a 572 stored copy of the Bootstrap message to each new PIM neighbor, i.e., 573 after the DR receives the neighbor's first Hello message, and sends a 574 Hello message in response. It does so even if the new neighbor becomes 575 the DR. 577 3.1. Sending Candidate-RP-Advertisements 579 Every C-RP periodically unicasts a C-RP-Adv to the BSR for that scope 580 zone to inform the BSR of the C-RP's willingness to function as an RP. 581 Unless configured otherwise, it does this for every Admin Scope zone for 582 which it has state, and for the global scope zone. If the same router 583 is the BSR for more than one scope zone, the C-RP-Adv for these scope 584 zones MAY be combined into a single message. 586 If the C-RP is a ZBR for an admin scope zone, then the Admin Scope bit 587 MUST be set in the C-RP-Adv messages it sends for that scope zone; 588 otherwise this bit MUST NOT be set. This information is currently only 589 used for logging purposes by the BSR, but might allow for future 590 extensions of the protocol. 592 The interval for sending these messages is subject to local 593 configuration at the C-RP, but must be smaller than the HoldTime in the 594 C-RP-Adv. 596 A Candidate-RP-Advertisement carries a list of group address and group 597 mask field pairs. This enables the C-RP router to restrict the 598 advertisement to certain prefixes or scopes of groups. If the C-RP 599 becomes an RP, it may enforce this scope acceptance when receiving 600 Registers or Join/Prune messages. 602 The C-RP priority field determines which C-RPs get selected by the BSR 603 to be in the RP Set. Note that a value of zero is the highest possible 604 priority. C-RPs should by default send C-RP-Adv messages with the 605 `Priority' field set to 192. 607 When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv to 608 the BSR for each scope for which it is currently serving as an RP; the 609 HoldTime in this C-RP-Adv message should be zero. The BSR will then 610 immediately time out the C-RP and generate a new BSR message removing 611 the shut down RP from the RPset. 613 3.2. Creating the RP-Set at the BSR 615 Upon receiving a C-RP-Adv, if the router is not the elected BSR, it 616 silently ignores the message. 618 If the router is the BSR, then it adds the RP address to its local pool 619 of candidate RPs. For each C-RP, the BSR holds the following 620 information: 622 IP address 623 The IP address of the C-RP. 625 Group Prefix and Mask list 626 The list of group prefixes and group masks from the C-RP 627 advertisement. 629 HoldTime 630 The HoldTime from the C-RP-Adv message. This is included 631 later in the RP-set information in the Bootstrap Message. 633 C-RP Expiry Timer 634 The C-RP-Expiry Timer is used to time out the state associated 635 with a C-RP when the BSR fails to receive C-RP-Advertisements 636 from it. The expiry timer is initialized to the HoldTime from 637 the RP's C-RP-Adv, and is reset to the HoldTime whenever a C- 638 RP-Adv is received from that C-RP. 640 C-RP Priority 641 The C-RP Priority is used to determine the subset of possible 642 RPs to use in the RP-Set. Smaller values are deemed to be of 643 higher priority than large ones. 645 When the C-RP Expiry Timer expires, the C-RP is removed from the pool of 646 available C-RPs. 648 The BSR uses the pool of C-RPs to construct the RP-Set which is included 649 in Bootstrap Messages and sent to all the routers in the PIM domain. 650 The BSR may apply a local policy to limit the number of Candidate RPs 651 included in the Bootstrap message. The BSR may override the prefix 652 indicated in a C-RP-Adv unless the `Priority' field from the C-RP-Adv is 653 less than 128. 655 The Bootstrap message is subdivided into sets of {group-prefix, RP- 656 Count, RP-addresses}. For each RP-address, the corresponding HoldTime 657 is included in the "RP-HoldTime" field. The format of the Bootstrap 658 message allows `semantic fragmentation', if the length of the original 659 Bootstrap message exceeds the packet maximum boundaries. However, we 660 recommend against configuring a large number of routers as C-RPs, to 661 reduce the semantic fragmentation required. 663 When an elected BSR is being shut down, it should immediately originate 664 a Bootstrap message listing its current RP set, but with the BSR 665 priority field set to the lowest priority value possible. This will 666 cause the election of a new BSR to happen more quickly. 668 3.3. Forwarding Bootstrap Messages 670 Bootstrap messages originate at the BSR, and are hop-by-hop forwarded by 671 intermediate routers if they pass the Bootstrap Message Processing 672 Check. Bootstrap messages are multicast to the `ALL-PIM-ROUTERS' group. 673 When a BS message is forwarded, it is forwarded out of every multicast- 674 capable interface which has PIM neighbors (excluding the one over which 675 the message was received). The exception to this is if the interface is 676 an administrative scope boundary for the admin scope zone indicated in 677 the first group address in the BS message packet. The IP source address 678 on the bootstrap message should be set to the forwarding router's IP 679 address on the interface the message is being forwarded from. Bootstrap 680 messages are always originated or forwarded with an IP TTL value of 1. 682 3.4. Receiving and Using the RP-Set 684 When a router receives and stores a new RP-Set, it checks if each of the 685 RPs referred to by existing state (i.e., by (*,G), (*,*,RP), or 686 (S,G,rpt) entries) is in the new RP-Set. 688 If an RP is not in the new RP-Set, that RP is considered unreachable and 689 the hash algorithm (see PIM-SM specification) is re-performed for each 690 group with locally active state that previously hashed to that RP. This 691 will cause those groups to be distributed among the remaining RPs. 693 If the new RP-Set contains a RP that was not previously in the RP-Set, 694 the hash value of the new RP is calculated for each group covered by the 695 new C-RP's Group-prefix. Any group for which the new RP's hash value is 696 greater than hash value of the group's previous RP is switched over to 697 the new RP. 699 4. Message Formats 701 BSR messages are PIM messages, as defined in [1]. The values of the PIM 702 message Type field for BSR messages are: 704 4 Bootstrap Message 705 8 Candidate-RP-Advertisement 707 In this section we use the following terms defined in the PIM-SM [1]: 709 o Encoded-Unicast format 711 o Encoded-Group format 713 We repeat these here to aid readability. 715 Encoded-Unicast address 717 An Encoded-Unicast address takes the following format: 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Addr Family | Encoding Type | Unicast Address 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 725 Addr Family 726 The PIM address family of the `Unicast Address' field of this 727 address. 729 Values of 0-127 are as assigned by the IANA for Internet Address 730 Families in [5]. Values 128-250 are reserved to be assigned by the 731 IANA for PIM-specific Address Families. Values 251 though 255 are 732 designated for private use. As there is no assignment authority 733 for this space, collisions should be expected. 735 Encoding Type 736 The type of encoding used within a specific Address Family. The 737 value `0' is reserved for this field, and represents the native 738 encoding of the Address Family. 740 Unicast Address 741 The unicast address as represented by the given Address Family and 742 Encoding Type. 744 Encoded-Group address 745 Encoded-Group addresses take the following format: 747 0 1 2 3 748 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 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Addr Family | Encoding Type | Reserved |Z| Mask Len | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Group multicast Address 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 755 Addr Family 756 described above. 758 Encoding Type 759 described above. 761 Reserved 762 Transmitted as zero. Ignored upon receipt. 764 Admin Scope [Z]one 765 When set, this bit indicates that this group address range is an 766 administratively scoped range. 768 Mask Len 769 The Mask length field is 8 bits. The value is the number of 770 contiguous one bits left justified used as a mask which, combined 771 with the group address, describes a range of groups. It is less 772 than or equal to the address length in bits for the given Address 773 Family and Encoding Type. If the message is sent for a single group 774 then the Mask length must equal the address length in bits for the 775 given Address Family and Encoding Type. (e.g. 32 for IPv4 native 776 encoding and 128 for IPv6 native encoding). 778 Group multicast Address 779 Contains the group address. 781 4.1. Bootstrap Message Format 783 A bootstrap message is divided up into `semantic fragments' if the 784 original message exceeds the maximum packet size boundaries. Basically, 785 a single bootstrap message can be sent as multiple packets (semantic 786 fragments), so long as the fragment tags of all the packets comprising 787 the message is the same. 789 If the bootstrap message contains information about more than one admin 790 scope zone, each different scope zone MUST occupy a different semantic 791 fragment. This allows Zone Border Routers for an admin scope zone to 792 not forward only those fragments that should not traverse the admin 793 scope boundary. 795 The format of a single `fragment' is given below: 797 0 1 2 3 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 |PIM Ver| Type | Reserved | Checksum | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Fragment Tag | Hash Mask len | BSR-priority | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | BSR Address (Encoded-Unicast format) | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Group Address 1 (Encoded-Group format) | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | RP Count 1 | Frag RP Cnt 1 | Reserved | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | RP Address 1 (Encoded-Unicast format) | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | RP1 Holdtime | RP1 Priority | Reserved | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | RP Address 2 (Encoded-Unicast format) | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | RP2 Holdtime | RP2 Priority | Reserved | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | . | 819 | . | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | RP Address m (Encoded-Unicast format) | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | RPm Holdtime | RPm Priority | Reserved | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Group Address 2 (Encoded-Group format) | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | . | 828 | . | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Group Address n (Encoded-Group format) | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | RP Count n | Frag RP Cnt n | Reserved | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | RP Address 1 (Encoded-Unicast format) | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | RP1 Holdtime | RP1 Priority | Reserved | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | RP Address 2 (Encoded-Unicast format) | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | RP2 Holdtime | RP2 Priority | Reserved | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | . | 843 | . | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | RP Address m (Encoded-Unicast format) | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | RPm Holdtime | RPm Priority | Reserved | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 PIM Version, Reserved, Checksum 851 Described in [1]. 853 Type PIM Message Type. Value is 8 for a Bootstrap Message. 855 Fragment Tag 856 A randomly generated number, acts to distinguish the fragments 857 belonging to different Bootstrap messages; fragments belonging to 858 same Bootstrap message carry the same `Fragment Tag'. 860 Hash Mask len 861 The length (in bits) of the mask to use in the hash function. For 862 IPv4 we recommend a value of 30. For IPv6 we recommend a value of 863 126. 865 BSR priority 866 Contains the BSR priority value of the included BSR. This field is 867 considered as a high order byte when comparing BSR addresses. Note 868 that for historical reasons, the highest BSR priority priority is 869 255 (the higher the better), whereas the highest RP Priority (see 870 below) is 0 (the lower the better). 872 Unicast BSR Address 873 The address of the bootstrap router for the domain. The format for 874 this address is given in the Encoded-Unicast address in [1]. 876 Group Address 1..n 877 The group prefix (address and mask) with which the Candidate RPs 878 are associated. Format described in [1]. In a fragment containing 879 admin scope ranges, the first group address in the fragment MUST be 880 the group range for the entire admin scope range, and this MUST 881 have the Admin Scope bit set. This is the case even if there are 882 no RPs in the RP set for the entire admin scope range - in this 883 case the sub-ranges for the RP set are specified later in the 884 fragment along with their RPs. 886 RP Count 1..n 887 The number of Candidate RP addresses included in the whole 888 Bootstrap message for the corresponding group prefix. A router does 889 not replace its old RP-Set for a given group prefix until/unless it 890 receives `RP-Count' addresses for that prefix; the addresses could 891 be carried over several fragments. If only part of the RP-Set for 892 a given group prefix was received, the router discards it, without 893 updating that specific group prefix's RP-Set. 895 Frag RP Cnt 1..m 896 The number of Candidate RP addresses included in this fragment of 897 the Bootstrap message, for the corresponding group prefix. The 898 `Frag RP-Cnt' field facilitates parsing of the RP-Set for a given 899 group prefix, when carried over more than one fragment. 901 RP address 1..m 902 The address of the Candidate RPs, for the corresponding group 903 prefix. The format for these addresses is given in the Encoded- 904 Unicast address in [1]. 906 RP1..m Holdtime 907 The Holdtime for the corresponding RP. This field is copied from 908 the `Holdtime' field of the associated RP stored at the BSR. 910 RP1..m Priority 911 The `Priority' of the corresponding RP and Encoded-Group Address. 912 This field is copied from the `Priority' field stored at the BSR 913 when receiving a Candidate-RP-Advertisement. The highest priority 914 is `0' (i.e. unlike BSR priority, the lower the value of the 915 `Priority' field, the better). Note that the priority is per RP 916 per Group Address. 918 4.1.1. Semantic Fragmentation of BSMs 920 Bootstrap messages may be split over several PIM Bootstrap Message 921 Fragment (BSMF) packets; this is known as semantic fragmentation. There 922 are two reasons for semantic fragmentation: 924 o The BSM would exceed the link MTU the packet will be forwarded 925 over. 927 o The BSM includes information about more than one admin scope zone. 929 Let us initially consider only the former case; the packet would be too 930 large because the set of group prefixes and the RPs for each group 931 prefix are too long to fit in one packet. The BSR will then split the 932 BSM across several BSMF packets; each of these must be a well-formed 933 BSMF packet in its own right. 935 If the BSR can split up the BSM so that different group prefixes (and 936 their RP information) can fit in different fragments, then it should do 937 so. If one of these BSMF packets is then lost, the state from the 938 previous BSM for the group-prefix from the missing packet will be 939 retained. Each fragment that does arrive will update the RP information 940 for the group-prefixes contained in that fragment, and the new group-to- 941 RP mapping for those can be used immediately. The information from the 942 missing fragment will be obtained when the BSM is next transmitted. In 943 this case, whilst the Fragment Tag must be set to the same value for all 944 BSMFs comprising a single BSM, the tag is not actually used by routers 945 receiving the BSM. 947 If the list of RPs for a single group-prefix is too long to fit in a 948 single BSMF packet, then that information must be split across multiple 949 BSMF packets. In this case, all the BSMF packets comprising the 950 information for that group-prefix must be received before the group-to- 951 RP mapping in use can be modified. This is the purpose of the RP Count 952 field - a router receiving BSMF packets from the same BSM (ie that have 953 the same fragment tag) must wait until the BSMFs providing RP Count RPs 954 for that group-prefix have been received before the new group-to-RP 955 mapping can be used for that group-prefix. In a single BSMF from such a 956 large group-prefix is lost, then that entire group-prefix will have to 957 wait until the next BSM is originated. 959 Next we need to consider how a BSR would remove group-prefixes from the 960 BSM. A router receiving a set of BSMFs cannot tell if a group-prefix is 961 missing. If it has seen a group-prefix before, it must assume that that 962 group-prefix still exists, and that the BSMF describing it has been 963 lost. It should retain this information for BS Timeout seconds. Thus 964 for a BSR to remove a group-prefix from the BSR, it should include that 965 group-prefix, but with a RP Count of zero, and it should resend this 966 information in each BSM for BS Timeout seconds. 968 Finally, we come to the case of fragments for the purpose of conveying 969 admin scope group-prefixes. In general, the information for each admin 970 scope range is independent of information about other admin scope 971 ranges. As no BSMF is allowed to convey information for more than one 972 admin scope range, then the procedure above also applies to BSMs that 973 are fragmented due to admin scoping. However, to time out all the state 974 for an entire admin scope zone requires waiting SZ Timeout rather than 975 BS Timeout, as admin scope zones are not expected to come and go 976 frequently. 978 4.2. Candidate-RP-Advertisement Format 980 Candidate-RP-Advertisements are periodically unicast from the C-RPs to 981 the BSR. 983 0 1 2 3 984 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 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 |PIM Ver| Type | Reserved | Checksum | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Prefix Cnt | Priority | Holdtime | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | RP Address (Encoded-Unicast format) | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Group Address 1 (Encoded-Group format) | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | . | 995 | . | 996 | . | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Group Address n (Encoded-Group format) | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 PIM Version, Reserved, Checksum 1002 Described in [1]. 1004 Type PIM Message Type. Value is 4 for a Candidate-RP-Advertisement 1005 Message. 1007 Prefix Cnt 1008 The number of encoded group addresses included in the message; 1009 indicating the group prefixes for which the C-RP is advertising. A 1010 Prefix Cnt of `0' implies all multicast groups, e.g. for IPv4 a 1011 prefix of 224.0.0.0 with mask length of 4. If the C-RP is not 1012 configured with Group-prefix information, the C-RP puts a default 1013 value of `0' in this field. 1015 Priority 1016 The `Priority' of the included RP, for the corresponding Encoded- 1017 Group Address (if any). highest priority is `0' (i.e. the lower 1018 the value of the `Priority' field, the higher the priority). This 1019 field is stored at the BSR upon receipt along with the RP address 1020 and corresponding Encoded-Group Address. 1022 Holdtime 1023 The amount of time the advertisement is valid. This field allows 1024 advertisements to be aged out. 1026 RP Address 1027 The address of the interface to advertise as a Candidate RP. The 1028 format for this address is given in the Encoded-Unicast address in 1029 [1]. 1031 Group Address-1..n 1032 The group prefixes for which the C-RP is advertising. Format 1033 described in Encoded-Group-Address in [1]. 1035 5. Default Values for Timers 1037 Timer Name: Bootstrap Timer (BST) 1039 +-------------------+--------------------------+------------------------+ 1040 | Value Name | Value | Explanation | 1041 +-------------------+--------------------------+------------------------+ 1042 | BS Period | Default: 60 secs | Period between | 1043 | | | bootstrap messages | 1044 +-------------------+--------------------------+------------------------+ 1045 | BS Timeout | 2 * BS_Period + 10 | Period after last | 1046 | | seconds | BS message before | 1047 | | | BSR is timed out | 1048 | | | and election | 1049 | | | begins | 1050 +-------------------+--------------------------+------------------------+ 1051 | rand_override | rand(0, 5.0 secs) | Suppression period | 1052 | | | in BSR election to | 1053 | | | prevent thrashing | 1054 +-------------------+--------------------------+------------------------+ 1056 Timer Name: C-RP Expiry Timer (CET(R)) 1058 +----------------+------------------+-----------------------------------+ 1059 | Value Name | Value | Explanation | 1060 +----------------+------------------+-----------------------------------+ 1061 | C-RP Timeout | from message | Hold time from C-RP-Adv message | 1062 +----------------+------------------+-----------------------------------+ 1064 C-RP Advertisement messages are sent periodically with period C-RP-Adv- 1065 Period. C-RP-Adv-Period defaults to 60 seconds. The holdtime to be 1066 specified in a C-RP-Adv message should be set to (2.5 * C-RP-Adv-Period 1067 ). 1069 Timer Name: C-RP Advertisement Timer (CRPT) 1071 +--------------------+--------------------------+-----------------------+ 1072 | Value Name | Value | Explanation | 1073 +--------------------+--------------------------+-----------------------+ 1074 | C-RP-Adv-Period | Default: 60 seconds | Period with which | 1075 | | | periodic C-RP | 1076 | | | Advertisements are | 1077 | | | sent to BSR | 1078 +--------------------+--------------------------+-----------------------+ 1080 Timer Name: Scope Zone Expiry Timer (SZT(Z)) 1082 +------------------------------------+--------------+-------------------+ 1083 |Value Name Value Explanation | | | 1084 +------------------------------------+--------------+-------------------+ 1085 |SZ Timeout |1500 seconds |Interval after | 1086 | | |which a scope zone | 1087 | | |will be timed out | 1088 | | |if the state is | 1089 | | |not refreshed | 1090 +------------------------------------+--------------+-------------------+ 1092 6. Security Considerations 1094 6.1. Possible Threats 1096 Threats affecting the PIM BSR mechanism are primarily of two forms: 1097 denial of service attacks, and traffic diversion attacks. An attacker 1098 that subverts the BSR mechanism can prevent multicast traffic from 1099 reaching the intended recipients, can divert multicast traffic to a 1100 place where they can monitor it, and can potentially flood third parties 1101 with traffic. 1103 Traffic can be prevented from reaching the intended recipients by one of 1104 two mechanisms: 1106 o Subverting a BSM, and specifying RPs that won't actually forward 1107 traffic. 1109 o Registering with the BSR as a C-RP, and then not forwarding 1110 traffic. 1112 Traffic can be diverted to a place where it can be monitored by both of 1113 the above mechanisms; in this case the RPs would forward the traffic, 1114 but are located so as to aid monitoring or man-in-the-middle attacks on 1115 the multicast traffic. 1117 A third party can be flooded by either of the above two mechanisms by 1118 specifying the third party as the RP, and register-encapsulated traffic 1119 will then be forwarded to them. 1121 6.2. Limiting Third-Party DoS Attacks 1123 The third party DoS attack above can be greatly reduced if PIM routers 1124 acting as DR do not continue to forward Register traffic to the RP in 1125 the presence of ICMP Protocol Unreachable or ICMP Host Unreachable 1126 responses. If a PIM router sending Register packets to an RP receives 1127 one of these responses to a data packet it has sent, it should rate- 1128 limit the transmission of future Register packets to that RP for a short 1129 period of time. 1131 As this does not affect interoperability, the precise details are left 1132 to the implementator to decide. However we note that a router 1133 implementing such rate limiting must only do so if the ICMP packet 1134 correctly echoes part of a Register packet that was sent to the RP. If 1135 this check were not made, then simply sending ICMP Unreachable packets 1136 to the DR with the source address of the RP spoofed would be sufficient 1137 to cause a denial-of-service attack on the multicast traffic originating 1138 from that DR. 1140 6.3. BS Message Security 1142 If a legitimate PIM router is compromised, there is little any security 1143 mechanism can do to prevent that router subverting PIM traffic in that 1144 domain. However we recommend that implementors provide a mechanism 1145 whereby a PIM router using the BSR mechanisms can be configured with the 1146 IP addresses of valid BSR routers, and that any BS Message from any 1147 other BSR should then be dropped and logged as a security issue. We 1148 also recommend that this not be enabled by default, as it makes the 1149 initial configuration of a PIM domain problematic - it is the sort of 1150 feature that might be enabled once the configuration of a domain has 1151 stabilized. 1153 The primary security requirement for BSR (as for PIM) is that it is 1154 possible to prevent hosts that are not legitimate PIM routers, either 1155 within or outside the domain, from subverting the BSR mechanism. 1157 The Bootstrap Message Processing Checks prevent a router from accepting 1158 a BS message from outside of the PIM Domain, as the source address on BS 1159 Messages must be an immediate PIM neighbor. There is however a small 1160 window of time after a reboot where a PIM router will accept a bad BS 1161 Message unicast from an immediate neighbor, and it might be possible to 1162 unicast a BS Message to a router during this interval from outside the 1163 domain, using the spoofed source address of a neighbor. This can be 1164 prevented if PMBRs perform source-address filtering to prevent packets 1165 entering the PIM domain with IP source addresses that are infrastructure 1166 addresses in the PIM domain. 1168 The principle threat to BS Message security comes from hosts within the 1169 PIM domain that attempt to subvert the BSR mechanism. They may be able 1170 to do this by sending PIM messages to their local router, or by 1171 unicasting a BS message to another PIM router during the brief interval 1172 after it has restarted. 1174 All BS Messages SHOULD carry the Router Alert IP option. If a PIM 1175 router receives a BS Message that does not carry the router alert 1176 option, it SHOULD drop it (a configuration option should also be 1177 provided to disable this check on a per-interface basic for backward 1178 compatibility with older PIM routers). The Router Alert option allows a 1179 PIM router to perform checks on unicast packets it would otherwise 1180 blindly forward. All PIM routers should check that packets with Router 1181 Alert that are not destined for the router itself are not PIM BootStrap 1182 messages. Any such packets should be dropped and logged as a possible 1183 security issue - it is never acceptable for a PIM BS message to travel 1184 multiple IP hops. 1186 Most hosts that are likely to attempt to subvert PIM BSR are likely to 1187 be located on leaf subnets. We recommend that implementors provide a 1188 configuration option that specifies an interface is a leaf subnet, and 1189 that no PIM packets are accepted on such interfaces. 1191 On multi-access subnets with multiple PIM routers and hosts that are not 1192 trusted, we recommend that IPsec AH is used to protect communication 1193 between PIM routers, and that such routers are configured to drop and 1194 log communication attempts from any host that do not pass the 1195 authentication check. When all the PIM routers are under the same 1196 administrative control, this authentication may use a configured shared 1197 secret. The securing of interactions between PIM neighbors is discussed 1198 in more detail in the Security Considerations section of [1], and so we 1199 do not discuss the details further here. The same security mechanisms 1200 than can be used to secure PIM Join, Prune and Assert messages should 1201 also be used to secure BS messages. 1203 6.4. C-RP-Advertisement Security 1205 Even if it is not possible to subvert BS Messages, an attacker might be 1206 able to perform most of the same attacks by simply sending C-RP-Adv 1207 messages to the BSR specifying the attacker's choice of RPs. Thus it is 1208 necessary to control the sending of C-RP-Adv messages in essentially the 1209 same ways that we control BS Messages. However, C-RP-Adv messages are 1210 unicast and normally travel multiple hops, so controlling them is a 1211 little harder. 1213 We specify that C-RP-Adv messages SHOULD also carry the Router Alert IP 1214 option, and that the BSR SHOULD by default drop and log C-RP-Adv 1215 messages that do not carry this option. Setting Router Alert on these 1216 packets is practical because the rate of C-RP-Adv messages should be 1217 very low, so the extra load on routers forwarding these packets will be 1218 insignificant. All PIM routers forwarding such a packet are then 1219 capable of checking whether the packet came from a valid neighbor. On 1220 interfaces that are configured to be leaf subnets, all C-RP-Adv messages 1221 should be dropped. On multi-access subnets with multiple PIM routers 1222 and hosts that are not trusted, the router can at least check that the 1223 source MAC address is that of a valid PIM neighbor. PMBRs should ensure 1224 that no C-RP-Adv messages enter the domain from an external neighbor. 1226 For true security, we recommend that all C-RPs are configured to use 1227 IPsec authentication. The authentication process for a C-RP-Adv message 1228 between a C-RP and the BSR is identical to the authentication process 1229 for PIM Register messages between a DR and the relevant RP, except that 1230 there will normally be fewer C-RPs in a domain than there are DRs, so 1231 key management is a little simpler. We do not describe the details of 1232 this process further here, but refer to the Security Considerations 1233 section of [1]. Note that the use of cryptographic security for C-RP- 1234 Advs does not remove the need for the non-cryptographic mechanisms, as 1235 explained below. 1237 6.5. Denial of Service using IPsec 1239 An additional concern is that of Denial-of-Service attacks caused by 1240 sending high volumes of BS Messages or C-RP-Adv messages with invalid 1241 IPsec authentication information. It is possible that these messages 1242 could overwhelm the CPU resources of the recipient. 1244 The non-cryptographic security mechanisms above prevent unicast BS 1245 messages from traveling multiple hops, and constrain who can originate 1246 such messages. However, it is obviously important that PIM Messages 1247 that are required to have Router Alert checked are checked for this 1248 option before the IPsec AH is checked. Thus the remaining vulnerability 1249 primarily exists for hosts on multi-access subnets containing more than 1250 one PIM router. A PIM router receiving PIM packets with Router Alert 1251 set from such a subnet should already be checking that the source MAC 1252 address is that of a valid PIM neighbor, but this is hardly strong 1253 security. In addition, we recommend that rate-limiting mechanisms can 1254 be configured, to be applied to the forwarding of unicast PIM packets 1255 containing Router Alert options. The rate-limiter MUST independently 1256 rate-limit different types of PIM packets - for example a flood of C-RP- 1257 Adv messages MUST NOT cause a rate limiter to drop low-rate BS Messages. 1258 Such a rate-limiter might itself be used to cause a denial of service 1259 attack by causing valid packets to be dropped, but in practice this is 1260 more likely to constrain bad PIM Messages close to their origin. In 1261 addition, the rate limiter will prevent attacks on PIM from affecting 1262 other activity on the destination router, such as unicast routing. 1264 7. Authors' Addresses 1266 Bill Fenner 1267 AT&T Labs - Research 1268 75 Willow Road 1269 Menlo Park, CA 94025 1270 fenner@research.att.com 1272 Mark Handley 1273 ACIRI/ICSI 1274 1947 Center St, Suite 600 1275 Berkeley, CA 94708 1276 mjh@aciri.org 1278 Roger Kermode 1279 Motorola Australian Research Centre 1280 Locked Bag 5028 1281 Botany NSW 1455, 1282 Australia 1283 Roger.Kermode@motorola.com 1285 David Thaler 1286 Microsoft Corporation 1287 One Microsoft Way 1288 Redmond, WA 98052 1289 dthaler@Exchange.Microsoft.com 1291 8. References 1293 [1] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 1294 Independent Multicast - Sparse Mode (PIM-SM): Protocol 1295 Specification (Revised)", Internet Draft draft-ietf-pim-sm- 1296 v2-new-03.ps 1298 [2] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode 1299 (PIM-SM): Protocol Specification", RFC 2362, June 1998 (now 1300 obsolete). 1302 [3] W. Fenner, "Internet Group Management Protocol, Version 2", RFC 1303 2236, Nov 1997. 1305 [4] S. Deering , W. Fenner , B. Haberman, "Multicast Listener Discovery 1306 (MLD) for IPv6", RFC 2710, Oct 1999. 1308 [5] IANA, "Address Family Numbers", linked from 1309 http://www.iana.org/numbers.html 1311 9. Acknowledgments 1313 PIM-SM was designed over many years by a large group of people, 1314 including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve 1315 Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, 1316 Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, 1317 Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish 1318 Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas and Hugh 1319 Holbrook. This BSR specification draws heavily on text from RFC 2362.