idnits 2.17.1 draft-ietf-pim-sm-bsr-02.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 652: '...mically learned. The interval MUST be...' RFC 2119 keyword, line 702: '...zones MAY be combined into a single me...' RFC 2119 keyword, line 706: '...herwise this bit MUST NOT be set. Thi...' RFC 2119 keyword, line 725: '...ng shut down, it SHOULD immediately se...' RFC 2119 keyword, line 910: '...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 (21 November 2001) is 8163 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 2362 (ref. '2') (Obsoleted by RFC 4601, RFC 5059) == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-03 -- 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-02.txt Mark Handley/ACIRI 4 Roger Kermode/Motorola 5 David Thaler/Microsoft 6 21 November 2001 7 Expires: May 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. General Overview and Background. . . . . . . . . . . 4 48 1.2. Overview of Bootstrap and RP Discovery for 49 Global Scope. . . . . . . . . . . . . . . . . . . . . . . 7 50 1.3. Administratively Scoped Multicast and BSR. . . . . . 7 51 2. BSR State and Timers. . . . . . . . . . . . . . . . . . 9 52 3. Bootstrap Router Election and RP-Set 53 Distribution . . . . . . . . . . . . . . . . . . . . . . . 10 54 3.1. Sending Candidate-RP-Advertisements. . . . . . . . . 17 55 3.2. Creating the RP-Set at the BSR . . . . . . . . . . . 18 56 3.3. Forwarding Bootstrap Messages. . . . . . . . . . . . 19 57 3.4. Receiving and Using the RP-Set . . . . . . . . . . . 19 58 4. Message Formats . . . . . . . . . . . . . . . . . . . . 20 59 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 22 60 4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 25 61 4.2. Candidate-RP-Advertisement Format. . . . . . . . . . 27 62 5. Default Values for Timers . . . . . . . . . . . . . . . 28 63 6. Security Considerations . . . . . . . . . . . . . . . . 29 64 6.1. Possible Threats . . . . . . . . . . . . . . . . . . 29 65 6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 30 66 6.3. BS Message Security. . . . . . . . . . . . . . . . . 30 67 6.4. C-RP-Advertisement Security. . . . . . . . . . . . . 32 68 6.5. Denial of Service using IPsec. . . . . . . . . . . . 32 69 7. Authors' Addresses. . . . . . . . . . . . . . . . . . . 33 70 8. References. . . . . . . . . . . . . . . . . . . . . . . 34 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . 34 73 1. Introduction 75 Note: this document assumes familiarity with the workings of Protocol 76 Independent Multicast - Sparse Mode, as defined in [3], and with 77 Administratively Scoped Multicast, as described in [6]. 79 For correct operation, every PIM Sparse-mode router within a PIM domain 80 must be able to map a particular global-scope multicast group address to 81 the same RP. If this is not the case then black holes may appear, where 82 some receivers in the domain cannot receive some groups. A domain in 83 this context is a contiguous set of routers that all implement PIM and 84 are configured to operate within a common boundary defined by PIM 85 Multicast Border Routers (PMBRs). PMBRs connect each PIM domain to the 86 rest of the internet. 88 A PIM domain may also broken up into multiple administrative scope 89 regions - these are regions where a border has been configured so that a 90 range of multicast groups will not be forwarded across that border. For 91 more information on Administratively Scoped IP Multicast, see RFC 2365. 92 The modified criteria for admin-scoped regions are that the region is 93 convex with respect to forwarding based on the MRIB, and that all PIM 94 routers within the same scope region map a particular scoped group to 95 the same RP within that region. 97 The PIM-SM specification does not mandate the use of a single mechanism 98 to provide routers with the information to perform the group-to-RP 99 mapping. This document describes the Bootstrap Router (BSR) mechanism. 100 BSR was first defined in RFC 2362 [2], which has since been obsoleted. 101 This document provides an updated specification of the BSR mechanism 102 from RFC 2362, and also extends it to cope with administratively scoped 103 region boundaries. 105 1.1. General Overview and Background 107 Every PIM-SM multicast group needs to be associated with the IP address 108 of a Rendezvous-Point (RP). When a new multicast sender starts sending, 109 its local Designated Router (DR) will encapsulate these data packets in 110 a PIM Register message and send them to the RP for that multicast group. 111 When a new multicast receiver joins, its local DR will send a PIM Join 112 message towards the RP for that multicast group. When any PIM router 113 sends a (*,G) Join message, it needs to know which is the next how 114 router towards the RP for G to send the message to. Also when a PIM 115 router is forwarding data packets using (*,G) state, it needs to know 116 which is the correct incoming interface for packets destined for G, as 117 it needs to reject any packets that arrive on other interfaces. Thus it 118 is important for all the PIM routers in a domain to be able to map each 119 multicast group to the correct RP address. 121 There are a number of ways that group-to-RP mapping can be done; the 122 simplest solution is for all the routers in the domain to be configured 123 with the same information. However, static configuration generally 124 doesn't scale well, and also does not dynamically adapt to route around 125 router or link failures. The mechanism specified in this document is 126 known as the PIM BootStrap Router mechanism, or BSR for short, and 127 provides a dynamic, adaptive mechanism to distribute group-to-RP mapping 128 information rapidly throughout a domain. 130 Before we discuss the BSR mechanism itself, we should understand the 131 rules a PIM-SM router will apply to the mapping information. 132 Irrespective of how it obtains the mapping information, a PIM-SM router 133 will have a mapping table containing multiple entries, each of which has 134 the following form: 136 o Multicast group range, expressed as an address and prefix length. 138 o RP Priority. 140 o IP address of RP. 142 In general, these mapping entries may overlap in arbitrary ways; a 143 particular multicast group may be covered by multiple mapping entries. 144 When this is the case, the router chooses only one of the entries by 145 applying a deterministic algorithm (specified in the PIM-SM protocol 146 specification) so that all routers in the domain make the same choice of 147 entry and hence apply the same group-to-RP mapping. 149 The BSR mechanism provides a way in which viable group-to-RP mappings 150 can be created and distributed to all the PIM-SM routers in a domain. 151 It is adaptive, in that if an RP becomes unreachable, this will be 152 detected and the mapping tables will be modified so that the unreachable 153 RP is no longer used, and the new tables will be rapidly distributed 154 throughout the domain. 156 The general idea behind the BSR-mechanism is that some of the PIM 157 routers within a PIM domain are configured to be potential RPs for the 158 domain. These are known as candidate-RPs (C-RPs). A subset of the C- 159 RPs will eventually be used as the actual RPs for the domain. In 160 addition, some of the PIM routers in the domain are configured as 161 candidate bootstrap routers (C-BSRs). One of these C-BSRs will be 162 elected to serve as the bootstrap router (BSR) for the domain, and all 163 the PIM routers in the domain will learn the result of this election 164 through Bootstrap messages. The C-RPs will them report their candidacy 165 to the elected BSR, which will choose a subset of the C-RPs to form the 166 actual set of RPs to the used. This RP-Set will then be distributed out 167 to all the routers in the domain through Bootstrap messages. 169 The mechanism is complicated slightly by the presence of 170 administratively-scoped multicast regions within the PIM-SM domain. An 171 admin-scope region is a convex connected set of PIM routers surrounded 172 by an admin-scope boundary. The boundary specifies a range of multicast 173 addresses that will not be forwarded into or out of the scoped region. 174 This complicates BSR because we do not want a PIM router within the 175 scoped region to use an RP outside the scoped region (or vice-versa). 176 Thus we need to modify the basic mechanism to ensure that this doesn't 177 happen - this is done by electing a BSR for every admin-scope region 178 within a PIM domain, and also a global BSR for the whole PIM domain. C- 179 RPs typically register multiple times; once to the BSR of every admin 180 scope zone the C-RP is in. For the remainder of this overview we will 181 ignore admin-scope regions, and concentrate on the global BSR and its 182 role. Within each scope zone, the BSR for that zone acts in a similar 183 manner to how the global BSR acts for the whole domain. 185 There are four basic phases to the BSR mechanism (although in practice 186 all phases may by occurring simultaneously): 188 1. BSR election. Each Candidate-BSR originates bootstrap messages 189 (BSMs). Every BSM contains a BSR priority field. Routers within 190 the domain flood the BSMs throughout the domain. A C-BSR that 191 hears about a higher-priority C-BSR than itself then suppresses its 192 sending of further BSMs for some period of time. The single 193 remaining C-BSR becomes the elected BSR, and its BSMs inform all 194 the other routers in the domain that it is the elected BSR. 196 2. C-RP advertisement. Each Candidate-RP within a domain sends 197 periodic Candidate-RP-Advertisement (C-RP-Adv) messages to the 198 elected BSR. In this way, the BSR learns about possible RPs that 199 are currently up and reachable. 201 3. C-RP-Set Formation. The BSR selects a subset of the C-RPs that it 202 has heard C-RP-Adv messages from to form the RP-Set. In general it 203 should do this in such a way that the RP-Set is neither too large 204 to inform all the routers in the domain about, nor too small so 205 that load is overly concentrated on some RPs. It should also 206 attempt to produce an RP-Set that does not change frequently. 208 4. RP-Set Flooding. In future bootstrap messages, the BSR includes 209 the RP-Set information. As bootstrap messages are flooded rapidly 210 through the domain, this ensures that the RP-Set rapidly reaches 211 all the routers in the domain. BSMs are originated periodically to 212 ensure consistency after failure restoration. 214 In the following sections we discuss more details about BSR for global 215 scope and for admin scoping, before specifying the protocol starting in 216 section 2. 218 1.2. Overview of Bootstrap and RP Discovery for Global Scope 220 A small set of routers from a domain are configured as candidate 221 bootstrap routers (C-BSRs) and, through a simple election mechanism, a 222 single BSR is selected for that domain. A set of routers within a domain 223 are also configured as candidate RPs (C-RPs); typically these will be 224 the same routers that are configured as C-BSRs. Candidate RPs 225 periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to 226 the BSR of that domain, advertising their willingness to be an RP. A C- 227 RP-Adv message includes the address of the advertising C-RP, as well as 228 an optional list of group addresses and a mask length fields, indicating 229 the group prefix(es) for which the candidacy is advertised. The BSR then 230 includes a set of these Candidate-RPs (the RP-Set), along with their 231 corresponding group prefixes, in Bootstrap messages it periodically 232 originates. Bootstrap messages are distributed hop-by-hop throughout 233 the domain. 235 All the PIM routers in the domain receive and store Bootstrap messages 236 originated by the BSR. When a DR receives an indication of local 237 membership (typically from IGMP [4] or MLD [1]) or a data packet from a 238 directly connected host, for a group for which it has no forwarding 239 state, the DR uses a hash function to map the group address to one of 240 the C-RPs from the RP-Set whose group-prefix includes the group (see 241 [3]). The DR then sends a Join message towards that RP if the local host 242 joined the group, or it Register-encapsulates and unicasts the data 243 packet to the RP if the local host sent a packet to the group. 245 A Bootstrap message indicates liveness of the RPs included therein. If 246 an RP is included in the message, then it is tagged as `up' at the 247 routers; RPs not included in the message are removed from the list of 248 RPs over which the hash algorithm acts. Each router continues to use the 249 contents of the most recently received Bootstrap message from the BSR 250 until it accepts a new Bootstrap message. 252 If a PIM domain becomes partitioned, each area separated from the old 253 BSR will elect its own BSR, which will distribute an RP-Set containing 254 RPs that are reachable within that partition. When the partition heals, 255 another election will occur automatically and only one of the BSRs will 256 continue to send out Bootstrap messages. As is expected at the time of a 257 partition or healing, some disruption in packet delivery may occur. This 258 time will be on the order of the region's round-trip time and the 259 bootstrap router timeout value. 261 1.3. Administratively Scoped Multicast and BSR 263 Administratively Scoped IP Multicast, as defined in RFC 2365, permits a 264 network provider to configure scope boundaries at multicast routers. 266 Such a scope boundary consists of a range of multicast addresses 267 (expressed as an address and mask) that the router will not forward 268 across the boundary. For correct operation, such a scope zone border 269 must be complete and convex. By this we mean that there must be no path 270 from inside the scoped zone to outside it that does not pass through a 271 configured scope border router, and that the multicast capable path 272 between any arbitrary pair of multicast routers in the scope zone must 273 remain in the zone. 275 For PIM-SM using BSR to function correctly with admin scoping, there 276 must be a BSR and at least one C-RP within every admin scope region. 277 Admin scope zone boundaries must be configured at the Zone Border 278 Routers (ZBRs), as they need to filter PIM Join messages that might 279 inadvertently cross the border due to error conditions. In addition, at 280 least one C-BSR within the admin scope zone must be configured to be a 281 C-BSR for the admin scope zone's address range. 283 A separate BSR election will then take place (using bootstrap messages) 284 for every admin scope range (plus one for the global range). Admin 285 scope ranges are identified in the bootstrap message because the group 286 range is marked (using the "Admin Scope" bit, previously a "Reserved" 287 bit) to indicate that this is an administrative scope range, and not 288 just a range that a particular set of RPs are configured to handle. 290 Such admin scoped bootstrap message packets are flooded in the normal 291 way, but will not be forwarded by another ZBR across the boundary for 292 that scope zone (see Section 3.3 for the specifics of this). 294 We do not require that C-RPs within the scope zone be configured to know 295 about the scope zone, as they can learn of its existence from bootstrap 296 messages. However, we recommend that router vendors implement 297 configuration options that allow a C-RP to be configured to be a C-RP 298 for global scope only, for one of more admin scopes only, or for all 299 scopes, both global and admin scoped. We also recommend that the 300 default be that a C-RP is a C-RP for all scopes, both global and admin 301 scoped. 303 Unless configured otherwise, C-RPs discover the existence of the admin 304 scope zone and its group range from receiving a bootstrap message from 305 the scope zone's elected BSR containing the scope zone's group-range, 306 marked using the "Admin Scope" bit. A C-RP stores each elected BSR's 307 address and the admin scope range contained in its bootstrap message. 308 It separately unicasts Candidate-RP-Advertisement messages to the 309 appropriate BSR for every admin scope range within which it is willing 310 to serve as an RP. 312 All PIM routers within a PIM bootstrap domain where admin scope ranges 313 are in use must be capable of receiving bootstrap messages and storing 314 the winning BSR and RPset for all admin scope zones that apply. Thus 315 PIM routers that only implement RFC 2362 (which only allows one BSR per 316 domain) cannot be used in PIM domains where admin scope zones are 317 configured. 319 2. BSR State and Timers 321 A PIM-SM router implementing BSR holds the following state in addition 322 to the state needed for PIM-SM operation: 324 At all routers: 326 List of Active Scope Zones 328 Per Scope Zone: 330 Bootstrap State: 332 o Bootstrap Router's IP Address 334 o BSR Priority 336 o Bootstrap Timer (BST) 338 o List of Scope Group-Ranges for this BSR 340 RP Set 342 At a Candidate BSR: 344 Per Scope Zone: 346 o My state: One of "Candidate-BSR", "Pending-BSR", 347 "Elected-BSR" 349 At a router that is not a Candidate BSR: 351 Per Scope Zone: 353 My state: One of "Accept Any", "Accept Preferred" 355 Scope-Zone Expiry Timer: SZT(Z) 357 Bootstrap state is described in section 3, and the RP Set is described 358 in section 3.4. 360 The following timers are also required: 362 At the Bootstrap Router only: 364 Per Scope Zone (Z): 366 Per Candidate RP (C): 368 C-RP Expiry Timer: CET(C,Z) 370 At the C-RPs only: 372 C-RP Advertisement Timer: CRPT 374 3. Bootstrap Router Election and RP-Set Distribution 376 For simplicity, bootstrap messages (BSMs) are used in both the BSR 377 election and the RP-Set distribution mechanisms. 379 The state-machine for bootstrap messages depends on whether or not a 380 router has been configured to be a Candidate-BSR for a particular scope 381 zone. The per-scope-zone state-machine for a C-BSR is given below, 382 followed by the state-machine for a router that is not configured to be 383 a C-BSR. 385 Per-Scope-Zone Candidate-BSR State Machine 387 +-----------------------------------+ 388 | Figures omitted from text version | 389 +-----------------------------------+ 391 Figure 1: Per-Scope-Zone State-machine for a candidate BSR 393 In tabular form this state machine is: 395 +-----------------------------------------------------------------------+ 396 | When in C-BSR state | 397 +------------+-------------------+-------------------+------------------+ 398 | Event | Receive | BS Timer | Receive non- | 399 | | Preferred BSM | Expires | preferred BSM | 400 | | | | from Elected | 401 | | | | BSR | 402 +------------+-------------------+-------------------+------------------+ 403 | | -> C-BSR state | -> P-BSR state | -> P-BSR state | 404 | | Forward BSM; | Set BS Timer | Set BS Timer | 405 | Action | Store RP Set; | to | to | 406 | | Set BS Timer | rand_override | rand_override | 407 | | to BS Timeout | | | 408 +------------+-------------------+-------------------+------------------+ 410 +-----------------------------------------------------------------------+ 411 | When in P-BSR state | 412 +-------------+-------------------+------------------+------------------+ 413 | Event | Receive | BS Timer | Receive Non- | 414 | | Preferred BSM | Expires | preferred BSM | 415 +-------------+-------------------+------------------+------------------+ 416 | | -> C-BSR state | -> E-BSR state | -> P-BSR state | 417 | | Forward BSM; | Originate BSM; | | 418 | Action | Store RP Set; | Set BS Timer | | 419 | | Set BS Timer | to BS Period | | 420 | | to BS Timeout | | | 421 +-------------+-------------------+------------------+------------------+ 423 +-----------------------------------------------------------------------+ 424 | When in E-BSR state | 425 +-------------+-------------------+------------------+------------------+ 426 | Event | Receive | BS Timer | Receive Non- | 427 | | Preferred BSM | Expires | preferred BSM | 428 +-------------+-------------------+------------------+------------------+ 429 | | -> C-BSR state | -> E-BSR state | -> E-BSR state | 430 | | Forward BSM; | Originate BSM; | Originate BSM; | 431 | Action | Store RP Set; | Set BS Timer | Set BS Timer | 432 | | Set BS Timer | to BS Period | to BS Period | 433 | | to BS Timeout | | | 434 +-------------+-------------------+------------------+------------------+ 435 A candidate-BSR may be in one of three states for a particular scope 436 zone: 438 Candidate-BSR (C-BSR) 439 The router is a candidate to be the BSR for the scope zone, but 440 currently another router is the preferred BSR. 442 Pending-BSR (P-BSR) 443 The router is a candidate to be the BSR for the scope zone. 444 Currently no other router is the preferred BSR, but this router is 445 not yet the BSR. For comparisons with incoming BS messages, the 446 router treats itself as the BSR. This is a temporary state that 447 prevents rapid thrashing of the choice of BSR during BSR election. 449 Elected-BSR (E-BSR) 450 The router is the elected bootstrap router for the scope zone and 451 it must perform all the BSR functions. 453 On startup, the initial state for this configured scope zone is 454 "Pending-BSR"; the BS Timer is initialized to the BS Timeout value. 456 In addition to the three states, there is one timer: 458 o The bootstrap timer (BS Timer) - that is used to time out old 459 bootstrap router information, and used in the election process to 460 terminate P-BSR state. 462 Per-Scope-Zone State-machine for Non-Candidate-BSR Routers 464 +-----------------------------------+ 465 | Figures omitted from text version | 466 +-----------------------------------+ 468 Figure 2: Per-Scope-Zone State-machine for a router not configured as C-BSR 470 In tabular form this state machine is: 472 +-----------------------------------------------------------------------+ 473 | When in No Info state | 474 +--------------------+--------------------------------------------------+ 475 | Event | Receive BSM for unknown Admin Scope | 476 +--------------------+--------------------------------------------------+ 477 | | -> AP State | 478 | Action | Forward BSM; Store RP-Set; | 479 | | Set BS Timer to BS Timeout; | 480 | | Set SZ Timer to SZ Timeout | 481 +--------------------+--------------------------------------------------+ 482 +-----------------------------------------------------------------------+ 483 | When in Accept Any state | 484 +---------------+-----------------------------+-------------------------+ 485 | Event | Receive BSM | SZ Timer Expires | 486 +---------------+-----------------------------+-------------------------+ 487 | | -> AP State | -> No Info state | 488 | | Forward BSM; Store | cancel timers; | 489 | Action | RP-Set; Set BS | clear state | 490 | | Timer to BS | | 491 | | Timeout | | 492 +---------------+-----------------------------+-------------------------+ 494 +-----------------------------------------------------------------------+ 495 | When in Accept Preferred state | 496 +------------+-------------------+-------------------+------------------+ 497 | Event | Receive | BS Timer | Receive Non- | 498 | | Preferred BSM | Expires | preferred BSM | 499 +------------+-------------------+-------------------+------------------+ 500 | | -> AP State | -> AA State | -> AP State | 501 | | Forward BSM; | | | 502 | Action | Store RP-Set; | | | 503 | | Set BS Timer | | | 504 | | to BS Timeout | | | 505 +------------+-------------------+-------------------+------------------+ 507 A router that is not a candidate-BSR may be in one of three states: 509 No Info 510 The router has no information about this scope zone. This state 511 does not apply if the router is configured to know about this scope 512 zone, or for the global scope zone. When in this state, no state 513 information is held and no timers run that refer to this scope 514 zone. 516 Accept Any (AA) 517 The router does not know of an active BSR, and will accept the 518 first bootstrap message it sees as giving the new BSR's identity 519 and the RP-Set. If the router has an RP-Set cached from an 520 obsolete bootstrap message, it continues to use it. 522 Accept Preferred (AP) 523 The router knows the identity of the current BSR, and is using the 524 RP-Set provided by that BSR. Only bootstrap messages from that BSR 525 or from a C-BSR with higher weight than the current BSR will be 526 accepted. 528 On startup, the initial state for this scope zone is "Accept Any" for 529 routers that know about this scope zone, either through configuration or 530 because the scope zone is the global scope which always exists; the SZ 531 Timer is considered to be always running for such scope zones. For 532 routers that do not know about a particular scope zone, the initial 533 state is No Info; no timers exist for the scope zone. 535 In addition to the three states, there are two timers: 537 o The bootstrap timer (BS Timer) - that is used to time out old 538 bootstrap router information. 540 o The scope zone timer (SZ Timer) - that is used to time out the scope 541 zone itself if BS messages specifying this scope zone stop arriving. 543 Bootstrap Message Processing Checks 545 When a bootstrap message is received, the following initial checks must 546 be performed: 548 if ( (DirectlyConnected(BSM.src_ip_address) == FALSE) 549 OR (we have no Hello state for BSM.src_ip_address)) { 550 drop the BS message silently 551 } 552 if (BSM.dst_ip_address == ALL-PIM-ROUTERS group) { 553 if ( BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address) ) { 554 drop the BS message silently 555 } 556 } else if (BSM.dst_ip_address is one of my addresses) { 557 if ( (Any previous BSM for this scope has been accepted) { 558 #the packet was unicast, but this wasn't 559 #a quick refresh on startup 560 drop the BS message silently 561 } 562 } else { 563 drop the BS message silently 564 } 565 if (the interface the message arrived on is an Admin Scope 566 border for the BSM.first_group_address) { 567 drop the BS message silently 568 } 570 Basically, the packet must have come from a directly connected neighbor 571 for which we have active Hello state. It must have been sent to the 572 ALL-PIM-ROUTERS group by the correct upstream router towards the BSR 573 that originated the BS message, or the router must have no BSR state (it 574 just restarted) and have received the BS message by unicast. In 575 addition it must not have arrived on an interface that is a configured 576 admin scope border for the first group address contained in the BS 577 message. 579 BS State-machine Transition Events 581 If the bootstrap message passes the initial checks above without being 582 discarded, then it may cause a state transition event in one of the 583 above state-machines. For both candidate and non-candidate BSRs, the 584 following transition events are defined: 586 Receive Preferred BSM 587 A bootstrap message is received from a BSR that has greater 588 than or equal weight than the current BSR. In a router is in 589 P-BSR state, then it uses its own weight as that of the 590 current BSR. 592 The weighting for a BSR is the concatenation in fixed- 593 precision unsigned arithmetic of the BSR priority field from 594 the bootstrap message and the IP address of the BSR from the 595 bootstrap message (with the BSR priority taking the most- 596 significant bits and the IP address taking the least 597 significant bits). 599 Receive BSM 600 A bootstrap message is received, regardless of BSR weight. 601 A non-candidate BSM also has the following transition event defined: 603 Receive BSM for unknown Admin Scope 604 As "Receive BSM", except that the admin scope zone indicated 605 in the BSM was not previously known at this router. 607 BS State-machine Actions 609 The state-machines specify actions that include setting the BS timer to 610 the following values: 612 BS Period 613 The periodic interval with which bootstrap messages are 614 normally sent. The default value is 60 seconds. 616 BS Timeout 617 The interval after which bootstrap router state is timed out 618 if no bootstrap message from that router has been heard. The 619 default value is 2 times the BS Period plus 10 seconds, which 620 is 130 seconds. 622 Randomized Override Interval 623 The randomized interval during which a router avoids sending a 624 bootstrap message while it waits to see if another router has 625 a higher bootstrap weight. This interval is to reduce control 626 message overhead during BSR election. The following 627 pseudocode is proposed as an efficient implementation of this 628 "randomized" value: 630 Delay = 5 + 2 * log_2(1 + bestPriority - myPriority) 631 + AddrDelay 633 where myPriority is the Candidate-BSR's configured priority, 634 and bestPriority equals: 636 bestPriority = Max(storedPriority, myPriority) 638 and AddrDelay is given by the following: 640 if ( bestPriority == myPriority) { 641 AddrDelay = log_2(storedAddr - myAddr) / 16 642 } else { 643 AddrDelay = 2 - (myAddr / 2^31) 644 } 646 where myAddr is the Candidate-BSR's address, storedAddr is the 647 stored BSR's address, and storedPriority is the stored BSR's 648 priority. 650 SZ Period 651 The interval after which a router will time out an Admin Scope 652 zone that it has dynamically learned. The interval MUST be 653 larger than the BS Timeout. The default value is ten times 654 the BS Timeout, which is 1500 seconds. 656 In addition to setting the timers, the following actions may be 657 triggered by state-changes in the state-machines: 659 Forward BSM 660 The bootstrap message is forwarded out of all multicast- 661 capable interfaces, except the interface it was received on, 662 or where this would cause the BSM to cross an admin-scope 663 boundary for the scope zone indicated in the message. The 664 source IP address of the message is the forwarding router's IP 665 address on the interface the message is being forwarded from, 666 the destination address is ALL-PIM-ROUTERS, and the TTL of the 667 message is set to 1. 669 Originate BSM 670 A new bootstrap message is constructed by the BSR, giving the 671 BSR's address and BSR priority, and containing the BSR's 672 chosen RP-Set. The message is forwarded out of all multicast- 673 capable interfaces, except where this would cause the BSM to 674 cross an admin-scope boundary for the scope zone indicated in 675 the message. The IP source address of the message is the 676 originating router's IP address on the interface the message 677 is being forwarded from, the destination address is ALL-PIM- 678 ROUTERS, and the TTL of the message is set to 1. 680 Store RP Set 681 The RP-Set from the received bootstrap message is stored and 682 used by the router to decide the RP for each group that the 683 router has state for. Storing this RP Set may cause other 684 state-transitions to occur in the router. The BSR's IP 685 address and priority from the received bootstrap message are 686 also stored to be used to decide if future bootstrap messages 687 are preferred. 689 In addition to the above state-machine actions, a DR also unicasts a 690 stored copy of the Bootstrap message to each new PIM neighbor, i.e., 691 after the DR receives the neighbor's first Hello message, and sends a 692 Hello message in response. It does so even if the new neighbor becomes 693 the DR. 695 3.1. Sending Candidate-RP-Advertisements 697 Every C-RP periodically unicasts a C-RP-Adv to the BSR for that scope 698 zone to inform the BSR of the C-RP's willingness to function as an RP. 699 Unless configured otherwise, it does this for every Admin Scope zone for 700 which it has state, and for the global scope zone. If the same router 701 is the BSR for more than one scope zone, the C-RP-Adv for these scope 702 zones MAY be combined into a single message. 704 If the C-RP is a ZBR for an admin scope zone, then the Admin Scope bit 705 MUST be set in the C-RP-Adv messages it sends for that scope zone; 706 otherwise this bit MUST NOT be set. This information is currently only 707 used for logging purposes by the BSR, but might allow for future 708 extensions of the protocol. 710 The interval for sending these messages is subject to local 711 configuration at the C-RP, but must be smaller than the HoldTime in the 712 C-RP-Adv. 714 A Candidate-RP-Advertisement carries a list of group address and group 715 mask field pairs. This enables the C-RP router to restrict the 716 advertisement to certain prefixes or scopes of groups. If the C-RP 717 becomes an RP, it may enforce this scope acceptance when receiving 718 Registers or Join/Prune messages. 720 The C-RP priority field determines which C-RPs get selected by the BSR 721 to be in the RP Set. Note that a value of zero is the highest possible 722 priority. C-RPs should by default send C-RP-Adv messages with the 723 `Priority' field set to 192. 725 When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv to 726 the BSR for each scope for which it is currently serving as an RP; the 727 HoldTime in this C-RP-Adv message should be zero. The BSR will then 728 immediately time out the C-RP and generate a new BSR message removing 729 the shut down RP from the RPset. 731 3.2. Creating the RP-Set at the BSR 733 Upon receiving a C-RP-Adv, if the router is not the elected BSR, it 734 silently ignores the message. 736 If the router is the BSR, then it adds the RP address to its local pool 737 of candidate RPs. For each C-RP, the BSR holds the following 738 information: 740 IP address 741 The IP address of the C-RP. 743 Group Prefix and Mask list 744 The list of group prefixes and group masks from the C-RP 745 advertisement. 747 HoldTime 748 The HoldTime from the C-RP-Adv message. This is included 749 later in the RP-set information in the Bootstrap Message. 751 C-RP Expiry Timer 752 The C-RP-Expiry Timer is used to time out the state associated 753 with a C-RP when the BSR fails to receive C-RP-Advertisements 754 from it. The expiry timer is initialized to the HoldTime from 755 the RP's C-RP-Adv, and is reset to the HoldTime whenever a C- 756 RP-Adv is received from that C-RP. 758 C-RP Priority 759 The C-RP Priority is used to determine the subset of possible 760 RPs to use in the RP-Set. Smaller values are deemed to be of 761 higher priority than large ones. 763 When the C-RP Expiry Timer expires, the C-RP is removed from the pool of 764 available C-RPs. 766 The BSR uses the pool of C-RPs to construct the RP-Set which is included 767 in Bootstrap Messages and sent to all the routers in the PIM domain. 768 The BSR may apply a local policy to limit the number of Candidate RPs 769 included in the Bootstrap message. The BSR may override the prefix 770 indicated in a C-RP-Adv unless the `Priority' field from the C-RP-Adv is 771 less than 128. 773 The Bootstrap message is subdivided into sets of {group-prefix, RP- 774 Count, RP-addresses}. For each RP-address, the corresponding HoldTime 775 is included in the "RP-HoldTime" field. The format of the Bootstrap 776 message allows `semantic fragmentation', if the length of the original 777 Bootstrap message exceeds the packet maximum boundaries. However, we 778 recommend against configuring a large number of routers as C-RPs, to 779 reduce the semantic fragmentation required. 781 When an elected BSR is being shut down, it should immediately originate 782 a Bootstrap message listing its current RP set, but with the BSR 783 priority field set to the lowest priority value possible. This will 784 cause the election of a new BSR to happen more quickly. 786 3.3. Forwarding Bootstrap Messages 788 Bootstrap messages originate at the BSR, and are hop-by-hop forwarded by 789 intermediate routers if they pass the Bootstrap Message Processing 790 Check. Bootstrap messages are multicast to the `ALL-PIM-ROUTERS' group. 791 When a BS message is forwarded, it is forwarded out of every multicast- 792 capable interface which has PIM neighbors (excluding the one over which 793 the message was received). The exception to this is if the interface is 794 an administrative scope boundary for the admin scope zone indicated in 795 the first group address in the BS message packet. The IP source address 796 on the bootstrap message should be set to the forwarding router's IP 797 address on the interface the message is being forwarded from. Bootstrap 798 messages are always originated or forwarded with an IP TTL value of 1. 800 3.4. Receiving and Using the RP-Set 802 When a router receives and stores a new RP-Set, it checks if each of the 803 RPs referred to by existing state (i.e., by (*,G), (*,*,RP), or 804 (S,G,rpt) entries) is in the new RP-Set. 806 If an RP is not in the new RP-Set, that RP is considered unreachable and 807 the hash algorithm (see PIM-SM specification) is re-performed for each 808 group with locally active state that previously hashed to that RP. This 809 will cause those groups to be distributed among the remaining RPs. 811 If the new RP-Set contains a RP that was not previously in the RP-Set, 812 the hash value of the new RP is calculated for each group covered by the 813 new C-RP's Group-prefix. Any group for which the new RP's hash value is 814 greater than hash value of the group's previous RP is switched over to 815 the new RP. 817 4. Message Formats 819 BSR messages are PIM messages, as defined in [3]. The values of the PIM 820 message Type field for BSR messages are: 822 4 Bootstrap Message 824 8 Candidate-RP-Advertisement 826 In this section we use the following terms defined in the PIM-SM [3]: 828 o Encoded-Unicast format 830 o Encoded-Group format 832 We repeat these here to aid readability. 834 Encoded-Unicast address 836 An Encoded-Unicast address takes the following format: 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Addr Family | Encoding Type | Unicast Address 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 844 Addr Family 845 The PIM address family of the `Unicast Address' field of this 846 address. 848 Values of 0-127 are as assigned by the IANA for Internet Address 849 Families in [5]. Values 128-250 are reserved to be assigned by the 850 IANA for PIM-specific Address Families. Values 251 though 255 are 851 designated for private use. As there is no assignment authority 852 for this space, collisions should be expected. 854 Encoding Type 855 The type of encoding used within a specific Address Family. The 856 value `0' is reserved for this field, and represents the native 857 encoding of the Address Family. 859 Unicast Address 860 The unicast address as represented by the given Address Family and 861 Encoding Type. 863 Encoded-Group address 865 Encoded-Group addresses take the following format: 867 0 1 2 3 868 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 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Addr Family | Encoding Type | Reserved |Z| Mask Len | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Group multicast Address 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 875 Addr Family 876 described above. 878 Encoding Type 879 described above. 881 Reserved 882 Transmitted as zero. Ignored upon receipt. 884 Admin Scope [Z]one 885 When set, this bit indicates that this group address range is an 886 administratively scoped range. 888 Mask Len 889 The Mask length field is 8 bits. The value is the number of 890 contiguous one bits left justified used as a mask which, combined 891 with the group address, describes a range of groups. It is less 892 than or equal to the address length in bits for the given Address 893 Family and Encoding Type. If the message is sent for a single group 894 then the Mask length must equal the address length in bits for the 895 given Address Family and Encoding Type. (e.g. 32 for IPv4 native 896 encoding and 128 for IPv6 native encoding). 898 Group multicast Address 899 Contains the group address. 901 4.1. Bootstrap Message Format 903 A bootstrap message is divided up into `semantic fragments' if the 904 original message exceeds the maximum packet size boundaries. Basically, 905 a single bootstrap message can be sent as multiple packets (semantic 906 fragments), so long as the fragment tags of all the packets comprising 907 the message is the same. 909 If the bootstrap message contains information about more than one admin 910 scope zone, each different scope zone MUST occupy a different semantic 911 fragment. This allows Zone Border Routers for an admin scope zone to 912 not forward only those fragments that should not traverse the admin 913 scope boundary. 915 The format of a single `fragment' is given below: 917 0 1 2 3 918 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 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 |PIM Ver| Type | Reserved | Checksum | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Fragment Tag | Hash Mask len | BSR-priority | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | BSR Address (Encoded-Unicast format) | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Group Address 1 (Encoded-Group format) | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | RP Count 1 | Frag RP Cnt 1 | Reserved | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | RP Address 1 (Encoded-Unicast format) | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | RP1 Holdtime | RP1 Priority | Reserved | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | RP Address 2 (Encoded-Unicast format) | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | RP2 Holdtime | RP2 Priority | Reserved | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | . | 939 | . | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | RP Address m (Encoded-Unicast format) | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | RPm Holdtime | RPm Priority | Reserved | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Group Address 2 (Encoded-Group format) | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | . | 948 | . | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Group Address n (Encoded-Group format) | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | RP Count n | Frag RP Cnt n | Reserved | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | RP Address 1 (Encoded-Unicast format) | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | RP1 Holdtime | RP1 Priority | Reserved | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | RP Address 2 (Encoded-Unicast format) | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | RP2 Holdtime | RP2 Priority | Reserved | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | . | 963 | . | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | RP Address m (Encoded-Unicast format) | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | RPm Holdtime | RPm Priority | Reserved | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 PIM Version, Reserved, Checksum 971 Described in [3]. 973 Type PIM Message Type. Value is 8 for a Bootstrap Message. 975 Fragment Tag 976 A randomly generated number, acts to distinguish the fragments 977 belonging to different Bootstrap messages; fragments belonging to 978 same Bootstrap message carry the same `Fragment Tag'. 980 Hash Mask len 981 The length (in bits) of the mask to use in the hash function. For 982 IPv4 we recommend a value of 30. For IPv6 we recommend a value of 983 126. 985 BSR priority 986 Contains the BSR priority value of the included BSR. This field is 987 considered as a high order byte when comparing BSR addresses. Note 988 that for historical reasons, the highest BSR priority priority is 989 255 (the higher the better), whereas the highest RP Priority (see 990 below) is 0 (the lower the better). 992 Unicast BSR Address 993 The address of the bootstrap router for the domain. The format for 994 this address is given in the Encoded-Unicast address in [3]. 996 Group Address 1..n 997 The group prefix (address and mask) with which the Candidate RPs 998 are associated. Format described in [3]. In a fragment containing 999 admin scope ranges, the first group address in the fragment MUST be 1000 the group range for the entire admin scope range, and this MUST 1001 have the Admin Scope bit set. This is the case even if there are 1002 no RPs in the RP set for the entire admin scope range - in this 1003 case the sub-ranges for the RP set are specified later in the 1004 fragment along with their RPs. 1006 RP Count 1..n 1007 The number of Candidate RP addresses included in the whole 1008 Bootstrap message for the corresponding group prefix. A router does 1009 not replace its old RP-Set for a given group prefix until/unless it 1010 receives `RP-Count' addresses for that prefix; the addresses could 1011 be carried over several fragments. If only part of the RP-Set for 1012 a given group prefix was received, the router discards it, without 1013 updating that specific group prefix's RP-Set. 1015 Frag RP Cnt 1..m 1016 The number of Candidate RP addresses included in this fragment of 1017 the Bootstrap message, for the corresponding group prefix. The 1018 `Frag RP-Cnt' field facilitates parsing of the RP-Set for a given 1019 group prefix, when carried over more than one fragment. 1021 RP address 1..m 1022 The address of the Candidate RPs, for the corresponding group 1023 prefix. The format for these addresses is given in the Encoded- 1024 Unicast address in [3]. 1026 RP1..m Holdtime 1027 The Holdtime for the corresponding RP. This field is copied from 1028 the `Holdtime' field of the associated RP stored at the BSR. 1030 RP1..m Priority 1031 The `Priority' of the corresponding RP and Encoded-Group Address. 1032 This field is copied from the `Priority' field stored at the BSR 1033 when receiving a Candidate-RP-Advertisement. The highest priority 1034 is `0' (i.e. unlike BSR priority, the lower the value of the 1035 `Priority' field, the better). Note that the priority is per RP 1036 per Group Address. 1038 4.1.1. Semantic Fragmentation of BSMs 1040 Bootstrap messages may be split over several PIM Bootstrap Message 1041 Fragment (BSMF) packets; this is known as semantic fragmentation. There 1042 are two reasons for semantic fragmentation: 1044 o The BSM would exceed the link MTU the packet will be forwarded 1045 over. 1047 o The BSM includes information about more than one admin scope zone. 1049 Let us initially consider only the former case; the packet would be too 1050 large because the set of group prefixes and the RPs for each group 1051 prefix are too long to fit in one packet. The BSR will then split the 1052 BSM across several BSMF packets; each of these must be a well-formed 1053 BSMF packet in its own right. 1055 If the BSR can split up the BSM so that different group prefixes (and 1056 their RP information) can fit in different fragments, then it should do 1057 so. If one of these BSMF packets is then lost, the state from the 1058 previous BSM for the group-prefix from the missing packet will be 1059 retained. Each fragment that does arrive will update the RP information 1060 for the group-prefixes contained in that fragment, and the new group-to- 1061 RP mapping for those can be used immediately. The information from the 1062 missing fragment will be obtained when the BSM is next transmitted. In 1063 this case, whilst the Fragment Tag must be set to the same value for all 1064 BSMFs comprising a single BSM, the tag is not actually used by routers 1065 receiving the BSM. 1067 If the list of RPs for a single group-prefix is too long to fit in a 1068 single BSMF packet, then that information must be split across multiple 1069 BSMF packets. In this case, all the BSMF packets comprising the 1070 information for that group-prefix must be received before the group-to- 1071 RP mapping in use can be modified. This is the purpose of the RP Count 1072 field - a router receiving BSMF packets from the same BSM (ie that have 1073 the same fragment tag) must wait until the BSMFs providing RP Count RPs 1074 for that group-prefix have been received before the new group-to-RP 1075 mapping can be used for that group-prefix. In a single BSMF from such a 1076 large group-prefix is lost, then that entire group-prefix will have to 1077 wait until the next BSM is originated. 1079 Next we need to consider how a BSR would remove group-prefixes from the 1080 BSM. A router receiving a set of BSMFs cannot tell if a group-prefix is 1081 missing. If it has seen a group-prefix before, it must assume that that 1082 group-prefix still exists, and that the BSMF describing it has been 1083 lost. It should retain this information for BS Timeout seconds. Thus 1084 for a BSR to remove a group-prefix from the BSR, it should include that 1085 group-prefix, but with a RP Count of zero, and it should resend this 1086 information in each BSM for BS Timeout seconds. 1088 Finally, we come to the case of fragments for the purpose of conveying 1089 admin scope group-prefixes. In general, the information for each admin 1090 scope range is independent of information about other admin scope 1091 ranges. As no BSMF is allowed to convey information for more than one 1092 admin scope range, then the procedure above also applies to BSMs that 1093 are fragmented due to admin scoping. However, to time out all the state 1094 for an entire admin scope zone requires waiting SZ Timeout rather than 1095 BS Timeout, as admin scope zones are not expected to come and go 1096 frequently. 1098 4.2. Candidate-RP-Advertisement Format 1100 Candidate-RP-Advertisements are periodically unicast from the C-RPs to 1101 the BSR. 1103 0 1 2 3 1104 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 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 |PIM Ver| Type | Reserved | Checksum | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | Prefix Cnt | Priority | Holdtime | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | RP Address (Encoded-Unicast format) | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | Group Address 1 (Encoded-Group format) | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | . | 1115 | . | 1116 | . | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | Group Address n (Encoded-Group format) | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 PIM Version, Reserved, Checksum 1122 Described in [3]. 1124 Type PIM Message Type. Value is 4 for a Candidate-RP-Advertisement 1125 Message. 1127 Prefix Cnt 1128 The number of encoded group addresses included in the message; 1129 indicating the group prefixes for which the C-RP is advertising. A 1130 Prefix Cnt of `0' implies all multicast groups, e.g. for IPv4 a 1131 prefix of 224.0.0.0 with mask length of 4. If the C-RP is not 1132 configured with Group-prefix information, the C-RP puts a default 1133 value of `0' in this field. 1135 Priority 1136 The `Priority' of the included RP, for the corresponding Encoded- 1137 Group Address (if any). highest priority is `0' (i.e. the lower 1138 the value of the `Priority' field, the higher the priority). This 1139 field is stored at the BSR upon receipt along with the RP address 1140 and corresponding Encoded-Group Address. 1142 Holdtime 1143 The amount of time the advertisement is valid. This field allows 1144 advertisements to be aged out. 1146 RP Address 1147 The address of the interface to advertise as a Candidate RP. The 1148 format for this address is given in the Encoded-Unicast address in 1149 [3]. 1151 Group Address-1..n 1152 The group prefixes for which the C-RP is advertising. Format 1153 described in Encoded-Group-Address in [3]. 1155 5. Default Values for Timers 1157 Timer Name: Bootstrap Timer (BST) 1159 +-------------------+--------------------------+------------------------+ 1160 | Value Name | Value | Explanation | 1161 +-------------------+--------------------------+------------------------+ 1162 | BS Period | Default: 60 secs | Period between | 1163 | | | bootstrap messages | 1164 +-------------------+--------------------------+------------------------+ 1165 | BS Timeout | 2 * BS_Period + 10 | Period after last | 1166 | | seconds | BS message before | 1167 | | | BSR is timed out | 1168 | | | and election | 1169 | | | begins | 1170 +-------------------+--------------------------+------------------------+ 1171 | rand_override | rand(0, 5.0 secs) | Suppression period | 1172 | | | in BSR election to | 1173 | | | prevent thrashing | 1174 +-------------------+--------------------------+------------------------+ 1176 Timer Name: C-RP Expiry Timer (CET(R)) 1178 +----------------+------------------+-----------------------------------+ 1179 | Value Name | Value | Explanation | 1180 +----------------+------------------+-----------------------------------+ 1181 | C-RP Timeout | from message | Hold time from C-RP-Adv message | 1182 +----------------+------------------+-----------------------------------+ 1184 C-RP Advertisement messages are sent periodically with period C-RP-Adv- 1185 Period. C-RP-Adv-Period defaults to 60 seconds. The holdtime to be 1186 specified in a C-RP-Adv message should be set to (2.5 * C-RP-Adv-Period 1187 ). 1189 Timer Name: C-RP Advertisement Timer (CRPT) 1191 +--------------------+--------------------------+-----------------------+ 1192 | Value Name | Value | Explanation | 1193 +--------------------+--------------------------+-----------------------+ 1194 | C-RP-Adv-Period | Default: 60 seconds | Period with which | 1195 | | | periodic C-RP | 1196 | | | Advertisements are | 1197 | | | sent to BSR | 1198 +--------------------+--------------------------+-----------------------+ 1200 Timer Name: Scope Zone Expiry Timer (SZT(Z)) 1202 +------------------------------------+--------------+--------------------+ 1203 |Value Name Value Explanation | | | 1204 +------------------------------------+--------------+--------------------+ 1205 |SZ Timeout | 1500 seconds | Interval after | 1206 | | | which a scope zone | 1207 | | | will be timed out | 1208 | | | if the state is | 1209 | | | not refreshed | 1210 +------------------------------------+--------------+--------------------+ 1212 6. Security Considerations 1214 6.1. Possible Threats 1216 Threats affecting the PIM BSR mechanism are primarily of two forms: 1217 denial of service attacks, and traffic diversion attacks. An attacker 1218 that subverts the BSR mechanism can prevent multicast traffic from 1219 reaching the intended recipients, can divert multicast traffic to a 1220 place where they can monitor it, and can potentially flood third parties 1221 with traffic. 1223 Traffic can be prevented from reaching the intended recipients by one of 1224 two mechanisms: 1226 o Subverting a BSM, and specifying RPs that won't actually forward 1227 traffic. 1229 o Registering with the BSR as a C-RP, and then not forwarding 1230 traffic. 1232 Traffic can be diverted to a place where it can be monitored by both of 1233 the above mechanisms; in this case the RPs would forward the traffic, 1234 but are located so as to aid monitoring or man-in-the-middle attacks on 1235 the multicast traffic. 1237 A third party can be flooded by either of the above two mechanisms by 1238 specifying the third party as the RP, and register-encapsulated traffic 1239 will then be forwarded to them. 1241 6.2. Limiting Third-Party DoS Attacks 1243 The third party DoS attack above can be greatly reduced if PIM routers 1244 acting as DR do not continue to forward Register traffic to the RP in 1245 the presence of ICMP Protocol Unreachable or ICMP Host Unreachable 1246 responses. If a PIM router sending Register packets to an RP receives 1247 one of these responses to a data packet it has sent, it should rate- 1248 limit the transmission of future Register packets to that RP for a short 1249 period of time. 1251 As this does not affect interoperability, the precise details are left 1252 to the implementator to decide. However we note that a router 1253 implementing such rate limiting must only do so if the ICMP packet 1254 correctly echoes part of a Register packet that was sent to the RP. If 1255 this check were not made, then simply sending ICMP Unreachable packets 1256 to the DR with the source address of the RP spoofed would be sufficient 1257 to cause a denial-of-service attack on the multicast traffic originating 1258 from that DR. 1260 6.3. BS Message Security 1262 If a legitimate PIM router is compromised, there is little any security 1263 mechanism can do to prevent that router subverting PIM traffic in that 1264 domain. However we recommend that implementors provide a mechanism 1265 whereby a PIM router using the BSR mechanisms can be configured with the 1266 IP addresses of valid BSR routers, and that any BS Message from any 1267 other BSR should then be dropped and logged as a security issue. We 1268 also recommend that this not be enabled by default, as it makes the 1269 initial configuration of a PIM domain problematic - it is the sort of 1270 feature that might be enabled once the configuration of a domain has 1271 stabilized. 1273 The primary security requirement for BSR (as for PIM) is that it is 1274 possible to prevent hosts that are not legitimate PIM routers, either 1275 within or outside the domain, from subverting the BSR mechanism. 1277 The Bootstrap Message Processing Checks prevent a router from accepting 1278 a BS message from outside of the PIM Domain, as the source address on BS 1279 Messages must be an immediate PIM neighbor. There is however a small 1280 window of time after a reboot where a PIM router will accept a bad BS 1281 Message unicast from an immediate neighbor, and it might be possible to 1282 unicast a BS Message to a router during this interval from outside the 1283 domain, using the spoofed source address of a neighbor. This can be 1284 prevented if PMBRs perform source-address filtering to prevent packets 1285 entering the PIM domain with IP source addresses that are infrastructure 1286 addresses in the PIM domain. 1288 The principle threat to BS Message security comes from hosts within the 1289 PIM domain that attempt to subvert the BSR mechanism. They may be able 1290 to do this by sending PIM messages to their local router, or by 1291 unicasting a BS message to another PIM router during the brief interval 1292 after it has restarted. 1294 All BS Messages SHOULD carry the Router Alert IP option. If a PIM 1295 router receives a BS Message that does not carry the router alert 1296 option, it SHOULD drop it (a configuration option should also be 1297 provided to disable this check on a per-interface basic for backward 1298 compatibility with older PIM routers). The Router Alert option allows a 1299 PIM router to perform checks on unicast packets it would otherwise 1300 blindly forward. All PIM routers should check that packets with Router 1301 Alert that are not destined for the router itself are not PIM BootStrap 1302 messages. Any such packets should be dropped and logged as a possible 1303 security issue - it is never acceptable for a PIM BS message to travel 1304 multiple IP hops. 1306 Most hosts that are likely to attempt to subvert PIM BSR are likely to 1307 be located on leaf subnets. We recommend that implementors provide a 1308 configuration option that specifies an interface is a leaf subnet, and 1309 that no PIM packets are accepted on such interfaces. 1311 On multi-access subnets with multiple PIM routers and hosts that are not 1312 trusted, we recommend that IPsec AH is used to protect communication 1313 between PIM routers, and that such routers are configured to drop and 1314 log communication attempts from any host that do not pass the 1315 authentication check. When all the PIM routers are under the same 1316 administrative control, this authentication may use a configured shared 1317 secret. The securing of interactions between PIM neighbors is discussed 1318 in more detail in the Security Considerations section of [3], and so we 1319 do not discuss the details further here. The same security mechanisms 1320 than can be used to secure PIM Join, Prune and Assert messages should 1321 also be used to secure BS messages. 1323 6.4. C-RP-Advertisement Security 1325 Even if it is not possible to subvert BS Messages, an attacker might be 1326 able to perform most of the same attacks by simply sending C-RP-Adv 1327 messages to the BSR specifying the attacker's choice of RPs. Thus it is 1328 necessary to control the sending of C-RP-Adv messages in essentially the 1329 same ways that we control BS Messages. However, C-RP-Adv messages are 1330 unicast and normally travel multiple hops, so controlling them is a 1331 little harder. 1333 We specify that C-RP-Adv messages SHOULD also carry the Router Alert IP 1334 option, and that the BSR SHOULD by default drop and log C-RP-Adv 1335 messages that do not carry this option. Setting Router Alert on these 1336 packets is practical because the rate of C-RP-Adv messages should be 1337 very low, so the extra load on routers forwarding these packets will be 1338 insignificant. All PIM routers forwarding such a packet are then 1339 capable of checking whether the packet came from a valid neighbor. On 1340 interfaces that are configured to be leaf subnets, all C-RP-Adv messages 1341 should be dropped. On multi-access subnets with multiple PIM routers 1342 and hosts that are not trusted, the router can at least check that the 1343 source MAC address is that of a valid PIM neighbor. PMBRs should ensure 1344 that no C-RP-Adv messages enter the domain from an external neighbor. 1346 For true security, we recommend that all C-RPs are configured to use 1347 IPsec authentication. The authentication process for a C-RP-Adv message 1348 between a C-RP and the BSR is identical to the authentication process 1349 for PIM Register messages between a DR and the relevant RP, except that 1350 there will normally be fewer C-RPs in a domain than there are DRs, so 1351 key management is a little simpler. We do not describe the details of 1352 this process further here, but refer to the Security Considerations 1353 section of [3]. Note that the use of cryptographic security for C-RP- 1354 Advs does not remove the need for the non-cryptographic mechanisms, as 1355 explained below. 1357 6.5. Denial of Service using IPsec 1359 An additional concern is that of Denial-of-Service attacks caused by 1360 sending high volumes of BS Messages or C-RP-Adv messages with invalid 1361 IPsec authentication information. It is possible that these messages 1362 could overwhelm the CPU resources of the recipient. 1364 The non-cryptographic security mechanisms above prevent unicast BS 1365 messages from traveling multiple hops, and constrain who can originate 1366 such messages. However, it is obviously important that PIM Messages 1367 that are required to have Router Alert checked are checked for this 1368 option before the IPsec AH is checked. Thus the remaining vulnerability 1369 primarily exists for hosts on multi-access subnets containing more than 1370 one PIM router. A PIM router receiving PIM packets with Router Alert 1371 set from such a subnet should already be checking that the source MAC 1372 address is that of a valid PIM neighbor, but this is hardly strong 1373 security. In addition, we recommend that rate-limiting mechanisms can 1374 be configured, to be applied to the forwarding of unicast PIM packets 1375 containing Router Alert options. The rate-limiter MUST independently 1376 rate-limit different types of PIM packets - for example a flood of C-RP- 1377 Adv messages MUST NOT cause a rate limiter to drop low-rate BS Messages. 1378 Such a rate-limiter might itself be used to cause a denial of service 1379 attack by causing valid packets to be dropped, but in practice this is 1380 more likely to constrain bad PIM Messages close to their origin. In 1381 addition, the rate limiter will prevent attacks on PIM from affecting 1382 other activity on the destination router, such as unicast routing. 1384 7. Authors' Addresses 1386 Bill Fenner 1387 AT&T Labs - Research 1388 75 Willow Road 1389 Menlo Park, CA 94025 1390 fenner@research.att.com 1392 Mark Handley 1393 ACIRI/ICSI 1394 1947 Center St, Suite 600 1395 Berkeley, CA 94708 1396 mjh@aciri.org 1398 Roger Kermode 1399 Motorola Australian Research Centre 1400 Locked Bag 5028 1401 Botany NSW 1455, 1402 Australia 1403 Roger.Kermode@motorola.com 1405 David Thaler 1406 Microsoft Corporation 1407 One Microsoft Way 1408 Redmond, WA 98052 1409 dthaler@Microsoft.com 1411 8. References 1413 [1] S. Deering , W. Fenner , B. Haberman, "Multicast Listener Discovery 1414 (MLD) for IPv6", RFC 2710, Oct 1999. 1416 [2] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode 1417 (PIM-SM): Protocol Specification", RFC 2362, June 1998 (now 1418 obsolete). 1420 [3] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 1421 Independent Multicast - Sparse Mode (PIM-SM): Protocol 1422 Specification (Revised)", Internet Draft draft-ietf-pim-sm- 1423 v2-new-03.ps 1425 [4] W. Fenner, "Internet Group Management Protocol, Version 2", RFC 1426 2236, Nov 1997. 1428 [5] IANA, "Address Family Numbers", linked from 1429 http://www.iana.org/numbers.html 1431 [6] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, Jul 1432 1998. 1434 9. Acknowledgments 1436 PIM-SM was designed over many years by a large group of people, 1437 including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve 1438 Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, 1439 Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, 1440 Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish 1441 Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas and Hugh 1442 Holbrook. This BSR specification draws heavily on text from RFC 2362.