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