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