idnits 2.17.1 draft-ietf-pim-sm-bsr-04.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1567. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1557), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 == The page length should not exceed 58 lines per page, but there was 35 longer pages, the longest (page 10) being 75 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 120 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 348: '...-directional PIM MUST NOT ignore these...' RFC 2119 keyword, line 349: '...ranges. They MUST NOT treat them as h...' RFC 2119 keyword, line 693: '...mically learned. The interval MUST be...' RFC 2119 keyword, line 760: '...zones MAY be combined into a single me...' RFC 2119 keyword, line 764: '...herwise this bit MUST NOT be set. Thi...' (12 more instances...) 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 (18 July 2004) is 7221 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) == Unused Reference: '4' is defined on line 1518, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1525, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-09 == Outdated reference: A later version (-09) exists of draft-ietf-pim-bidir-06 -- Obsolete informational reference (is this intentional?): RFC 2362 (ref. '5') (Obsoleted by RFC 4601, RFC 5059) Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 6 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-04.txt Alexander Gall/SWITCH 4 Stig Venaas/UNINETT 5 18 July 2004 6 Expires: January 2005 8 Bootstrap Router (BSR) Mechanism for PIM 10 Status of this Document 12 By submitting this Internet-Draft, I certify that any applicable patent 13 or other IPR claims of which I am aware have been disclosed, or will be 14 disclosed, and any of which I become aware will be disclosed, in 15 accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other groups 19 may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than a "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This document is a product of the IETF PIM WG. Comments should be 33 addressed to the authors, or the WG's mailing list at 34 pim@catarina.usc.edu. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 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 protocol) family that use the 45 concept of a Rendezvous Point as a means for receivers to 46 discover the sources that send to a particular multicast 47 group. BSR is one way that a multicast router can learn the 48 set of group-to-RP mappings required in order to function. 49 The mechanism is dynamic, largely self-configuring, and robust 50 to router failure. 52 Table of Contents 54 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. General Overview and Background. . . . . . . . . . . 4 56 1.2. Overview of Bootstrap and RP Discovery for 57 Global Scope. . . . . . . . . . . . . . . . . . . . . . . 7 58 1.3. Administratively Scoped Multicast and BSR. . . . . . 8 59 1.4. Bi-directional PIM . . . . . . . . . . . . . . . . . 9 60 2. BSR State and Timers. . . . . . . . . . . . . . . . . . 9 61 3. Bootstrap Router Election and RP-Set 62 Distribution . . . . . . . . . . . . . . . . . . . . . . . 10 63 3.1. Sending Candidate-RP-Advertisements. . . . . . . . . 19 64 3.2. Creating the RP-Set at the BSR . . . . . . . . . . . 20 65 3.3. Forwarding Bootstrap Messages. . . . . . . . . . . . 21 66 3.4. Receiving and Using the RP-Set . . . . . . . . . . . 22 67 4. Message Formats . . . . . . . . . . . . . . . . . . . . 22 68 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 25 69 4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 28 70 4.2. Candidate-RP-Advertisement Format. . . . . . . . . . 30 71 5. Default Values for Timers . . . . . . . . . . . . . . . 31 72 6. Security Considerations . . . . . . . . . . . . . . . . 32 73 6.1. Possible Threats . . . . . . . . . . . . . . . . . . 32 74 6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 33 75 6.3. BS Message Security. . . . . . . . . . . . . . . . . 33 76 6.4. C-RP-Advertisement Security. . . . . . . . . . . . . 35 77 6.5. Denial of Service using IPsec. . . . . . . . . . . . 36 78 7. Contributors. . . . . . . . . . . . . . . . . . . . . . 36 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 36 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . 37 81 10. Normative References . . . . . . . . . . . . . . . . . 37 82 11. Informative References . . . . . . . . . . . . . . . . 37 83 12. Authors' Addresses . . . . . . . . . . . . . . . . . . 37 85 List of Figures 87 Figure 1. Per-Scope-Zone State-machine for a candi- 88 date BSR . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 Figure 2. Per-Scope-Zone State-machine for a router 90 not configured as C-BSR. . . . . . . . . . . . . . . . . . 13 92 1. Introduction 94 This document assumes familiarity with the workings of Rendezvous Point- 95 based multicast routing protocols in the PIM protocol family, in 96 particular with Protocol Independent Multicast - Sparse Mode (PIM-SM), 97 as defined in [1], and Bi-directional Protocol Independent Multicast 98 (BIDIR-PIM), as defined in [3], as well as with Administratively Scoped 99 Multicast, as described in [2]. 101 Throughout the document, any reference to the PIM protocol family is 102 restricted to the subset of RP-based protocols unless stated otherwise. 104 For correct operation, every multicast router within a PIM domain must 105 be able to map a particular multicast group address to the same RP. If 106 this is not the case then black holes may appear, where some receivers 107 in the domain cannot receive some groups. A PIM domain in this context 108 is a contiguous set of routers that all implement the multicast routing 109 protocol and are configured to operate within a common boundary defined 110 by PIM Multicast Border Routers (PMBRs). PMBRs connect each PIM domain 111 to the rest of the internet. 113 A PIM domain may also be broken up into multiple administrative scope 114 regions - these are regions where a border has been configured so that a 115 range of multicast groups will not be forwarded across that border. For 116 more information on Administratively Scoped IP Multicast, see RFC 2365 117 [2]. The modified criteria for admin-scoped regions are that the region 118 is convex with respect to forwarding based on the MRIB, and that all PIM 119 routers within the same scope region map a particular scoped group to 120 the same RP within that region. 122 The PIM specifications do not mandate the use of a single mechanism to 123 provide routers with the information to perform the group-to-RP mapping. 124 This document describes the Bootstrap Router (BSR) mechanism. BSR was 125 first defined in RFC 2362 [5], which has since been obsoleted. This 126 document provides an updated specification of the BSR mechanism from RFC 127 2362, and also extends it to cope with administratively scoped region 128 boundaries and different flavours of routing protocols. 130 1.1. General Overview and Background 132 Every PIM multicast group needs to be associated with the IP address of 133 a Rendezvous Point (RP). This address is used to build a group-specific 134 distribution tree rooted at that address whose branches extend to all 135 nodes in the domain that want to receive traffic sent to the group. 136 Senders inject packets into the tree in such a manner that they reach 137 all connected receivers. How this is done and how the packets are 138 forwarded along the distribution tree depends on the particular routing 139 protocol. 141 For all senders to reach all receivers, it is crucial that there exists 142 a single distribution tree. This can only be achieved when all routers 143 in the domain use the same mappings of group addresses to RP addresses. 145 There are a number of ways how such group-to-RP mappings can be 146 established. The simplest solution is for all the routers in the domain 147 to be statically configured with the same information. However, static 148 configuration generally doesn't scale well, and also does not 149 dynamically adapt to route around router or link failures. The 150 mechanism specified in this document is known as the PIM BootStrap 151 Router mechanism, or BSR for short, and provides a dynamic, adaptive 152 mechanism to distribute group-to-RP mapping information rapidly 153 throughout a domain. 155 A group-to-RP mapping contains the following elements. 157 o Multicast group range, expressed as an address and prefix length 159 o RP Priority 161 o <<<<<<< bsr.nrf IP address of RP. 163 o RP Holdtime ======= IP address of RP 165 o RP Holdtime >>>>>>> 1.49 167 o Hash mask length 169 The collection of all group-to-RP mappings known to a router at any 170 point in time is called the RP-set. The router that assumes the role of 171 the BSR maintains a logically distinct RP-set called the C-RP-set, from 172 which it constructs the actual RP-set as explained below. 174 In general, these mapping entries may overlap in arbitrary ways; a 175 particular multicast group may be covered by multiple mapping entries. 176 When this is the case, the router chooses only one of the entries by 177 applying a deterministic algorithm so that all routers in the domain 178 make the same choice and hence apply the same group-to-RP mapping. It 179 is important to note that this algorithm is part of the specification of 180 the individual routing protocols (and may differ among them), not of the 181 BSR specification. 183 The BSR mechanism provides a way in which viable group-to-RP mappings 184 can be created and distributed to all the PIM routers in a domain. It 185 is adaptive, in that if an RP becomes unreachable, this will be detected 186 and the mapping tables will be modified so that the unreachable RP is no 187 longer used, and the new tables will be rapidly distributed throughout 188 the domain. 190 The general idea behind the BSR-mechanism is that some of the PIM 191 routers within a PIM domain are configured to be potential RPs for the 192 domain. These are known as candidate-RPs (C-RPs). A subset of the C- 193 RPs will eventually be used as the actual RPs for the domain. In 194 addition, some of the PIM routers in the domain are configured as 195 candidate bootstrap routers (C-BSRs). One of these C-BSRs will be 196 elected to serve as the bootstrap router (BSR) for the domain, and all 197 the PIM routers in the domain will learn the result of this election 198 through Bootstrap messages. The C-RPs will then report their candidacy 199 to the elected BSR, which stores the group-to-C-RP mappings in its C-RP- 200 set. It will chose a subset of these mappings as the actual RP-set and 201 distribute it to all the routers in the domain through Bootstrap 202 messages. 204 The mechanism is complicated slightly by the presence of 205 administratively-scoped multicast regions within the PIM domain. An 206 admin-scope region is a convex connected set of PIM routers surrounded 207 by an admin-scope boundary. The boundary specifies a range of multicast 208 addresses that will not be forwarded into or out of the scoped region. 209 This complicates BSR because we do not want a PIM router within the 210 scoped region to use an RP outside the scoped region (or vice-versa). 211 Thus we need to modify the basic mechanism to ensure that this doesn't 212 happen - this is done by electing a BSR for every admin-scope region 213 within a PIM domain, and also a global BSR for the whole PIM domain. C- 214 RPs typically register multiple times; once to the BSR of every admin 215 scope zone the C-RP is in. For the remainder of this overview we will 216 ignore admin-scope regions, and concentrate on the global BSR and its 217 role. Within each scope zone, the BSR for that zone acts in a similar 218 manner to how the global BSR acts for the whole domain. 220 There are four basic phases to the BSR mechanism (although in practice 221 all phases may be occurring simultaneously): 223 1. BSR election. Each Candidate-BSR originates bootstrap messages 224 (BSMs). Every BSM contains a BSR priority field. Routers within 225 the domain flood the BSMs throughout the domain. A C-BSR that 226 hears about a higher-priority C-BSR than itself then suppresses its 227 sending of further BSMs for some period of time. The single 228 remaining C-BSR becomes the elected BSR, and its BSMs inform all 229 the other routers in the domain that it is the elected BSR. 231 2. C-RP advertisement. Each Candidate-RP within a domain sends 232 periodic Candidate-RP-Advertisement (C-RP-Adv) messages to the 233 elected BSR. In this way, the BSR learns about possible RPs that 234 are currently up and reachable. 236 3. C-RP-Set Formation. The BSR selects a subset of the C-RPs that it 237 has received C-RP-Adv messages from to form the RP-Set. In general 238 it should do this in such a way that the RP-Set is neither too 239 large to inform all the routers in the domain about, nor too small 240 so that load is overly concentrated on some RPs. It should also 241 attempt to produce an RP-Set that does not change frequently. 243 4. RP-Set Flooding. In future bootstrap messages, the BSR includes 244 the RP-Set information. As bootstrap messages are flooded rapidly 245 through the domain, this ensures that the RP-Set rapidly reaches 246 all the routers in the domain. BSMs are originated periodically to 247 ensure consistency after failure restoration. 249 When a PIM router receives a Bootstrap message, it adds the group- 250 to-RP mappings contained therein to its pool of mappings obtained 251 from other sources (e.g. static configuration). It calculates the 252 final mappings of group addresses to RP addresses from this pool 253 according to rules specific to the particular routing protocol and 254 uses that information to construct multicast distribution trees. 256 In the following sections we discuss more details about BSR for global 257 scope and for admin scoping, before specifying the protocol starting in 258 section 2. 260 1.2. Overview of Bootstrap and RP Discovery for Global Scope 262 A small set of routers from a domain are configured as candidate 263 bootstrap routers (C-BSRs) and, through a simple election mechanism, a 264 single BSR is selected for that domain. A set of routers within a 265 domain are also configured as candidate RPs (C-RPs); typically these 266 will be the same routers that are configured as C-BSRs. Candidate RPs 267 periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to 268 the BSR of that domain, advertising their willingness to be an RP. A C- 269 RP-Adv message includes the address of the advertising C-RP, as well as 270 an optional list of group addresses and mask length fields, indicating 271 the group prefix(es) for which the candidacy is advertised. The BSR 272 then includes a set of these Candidate-RPs (the RP-Set), along with 273 their corresponding group prefixes, in Bootstrap messages it 274 periodically originates. Bootstrap messages are distributed hop-by-hop 275 throughout the domain. 277 If a PIM domain becomes partitioned, each area separated from the old 278 BSR will elect its own BSR, which will distribute an RP-Set containing 279 RPs that are reachable within that partition. When the partition heals, 280 another election will occur automatically and only one of the BSRs will 281 continue to send out Bootstrap messages. As is expected at the time of 282 a partition or healing, some disruption in packet delivery may occur. 283 This time will be on the order of the region's round-trip time and the 284 bootstrap router timeout value. 286 1.3. Administratively Scoped Multicast and BSR 288 Administratively Scoped IP Multicast, as defined in RFC 2365 [2], 289 permits a network provider to configure scope boundaries at multicast 290 routers. Such a scope boundary consists of a range of multicast 291 addresses (expressed as an address and mask) that the router will not 292 forward across the boundary. For correct operation, such a scope zone 293 border must be complete and convex. By this we mean that there must be 294 no path from inside the scoped zone to outside it that does not pass 295 through a configured scope border router, and that the multicast capable 296 path between any arbitrary pair of multicast routers in the scope zone 297 must remain in the zone. 299 For BSR to function correctly with admin scoping, there must be a BSR 300 and at least one C-RP within every admin scope region. Admin scope zone 301 boundaries must be configured at the Zone Border Routers (ZBRs), as they 302 need to filter PIM Join messages that might inadvertently cross the 303 border due to error conditions. In addition, at least one C-BSR within 304 the admin scope zone must be configured to be a C-BSR for the admin 305 scope zone's address range. 307 A separate BSR election will then take place (using bootstrap messages) 308 for every admin scope range (plus one for the global range). Admin 309 scope ranges are identified in the bootstrap message because the group 310 range is marked (using the "Admin Scope" bit, previously a "Reserved" 311 bit) to indicate that this is an administrative scope range, and not 312 just a range that a particular set of RPs are configured to handle. 314 Such admin scoped bootstrap message packets are flooded in the normal 315 way, but will not be forwarded by another ZBR across the boundary for 316 that scope zone (see Section 3.3 for the specifics of this). 318 We do not require that C-RPs within the scope zone be configured to know 319 about the scope zone, as they can learn of its existence from bootstrap 320 messages. However, we recommend that router vendors implement 321 configuration options that allow a C-RP to be configured to be a C-RP 322 for global scope only, for one of more admin scopes only, or for all 323 scopes, both global and admin scoped. We also recommend that the 324 default be that a C-RP is a C-RP for all scopes, both global and admin 325 scoped. 327 Unless configured otherwise, C-RPs discover the existence of the admin 328 scope zone and its group range from receiving a bootstrap message from 329 the scope zone's elected BSR containing the scope zone's group-range, 330 marked using the "Admin Scope" bit. A C-RP stores each elected BSR's 331 address and the admin scope range contained in its bootstrap message. 332 It separately unicasts Candidate-RP-Advertisement messages to the 333 appropriate BSR for every admin scope range within which it is willing 334 to serve as an RP. 336 All PIM routers within a PIM bootstrap domain where admin scope ranges 337 are in use must be capable of receiving bootstrap messages and storing 338 the winning BSR and RP-set for all admin scope zones that apply. Thus 339 PIM routers that only implement RFC 2362 (which only allows one BSR per 340 domain) cannot be used in PIM domains where admin scope zones are 341 configured. 343 1.4. Bi-directional PIM 345 Routers doing Bi-directional PIM [3] need group-to-RP mappings similar 346 to PIM-SM. Group ranges for use by Bi-directional PIM are identified in 347 bootstrap messages by a "Bi-dir" bit (previously a "Reserved" bit). 348 Routers that don't support Bi-directional PIM MUST NOT ignore these 349 ranges. They MUST NOT treat them as having the default mode, i.e. PIM- 350 SM. 352 2. BSR State and Timers 354 A PIM router implementing BSR holds the following state 356 At all routers: 358 List of Active Scope Zones 360 Per Scope Zone: 362 Bootstrap State: 364 o Bootstrap Router's IP Address 366 o BSR Priority 368 o Bootstrap Timer (BST) 370 o Last BSM received from this BSR 372 RP-Set 374 At a Candidate BSR: 376 Per Scope Zone: 378 o My state: One of "Candidate-BSR", "Pending-BSR", 379 "Elected-BSR" 381 At a router that is not a Candidate BSR: 383 Per Scope Zone: 385 My state: One of "Accept Any", "Accept Preferred" 387 Scope-Zone Expiry Timer: SZT(Z) 389 Bootstrap state is described in section 3, and the RP-Set is described 390 in section 3.4. 392 The following timers are also required: 394 At the Bootstrap Router only: 396 Per Scope Zone (Z): 398 Per group-to-C-RP mapping (M): 400 Group-to-C-RP mapping Expiry Timer: CGET(M,Z) 402 At the C-RPs only: 404 C-RP Advertisement Timer: CRPT 406 At all routers: 408 Per Scope Zone (Z): 410 Per group-to-RP mapping (M): 412 Group-to-RP mapping Expiry Timer: GET(M,Z) 414 3. Bootstrap Router Election and RP-Set Distribution 416 For simplicity, bootstrap messages (BSMs) are used in both the BSR 417 election and the RP-Set distribution mechanisms. 419 The state-machine for bootstrap messages depends on whether or not a 420 router has been configured to be a Candidate-BSR for a particular scope 421 zone. The per-scope-zone state-machine for a C-BSR is given below, 422 followed by the state-machine for a router that is not configured to be 423 a C-BSR. 425 Per-Scope-Zone Candidate-BSR State Machine 427 Figure 1: Per-Scope-Zone State-machine for a candidate BSR in tabular form 429 +-----------------------------------------------------------------------+ 430 | When in C-BSR state | 431 +------------+-------------------+-------------------+------------------+ 432 | Event | Receive | BS Timer | Receive non- | 433 | | Preferred BSM | Expires | preferred BSM | 434 | | | | from Elected | 435 | | | | BSR | 436 +------------+-------------------+-------------------+------------------+ 437 | | -> C-BSR state | -> P-BSR state | -> P-BSR state | 438 | | Forward BSM; | Set BS Timer | Set BS Timer | 439 | Action | Store RP-Set; | to | to | 440 | | Set BS Timer | rand_override | rand_override | 441 | | to BS Timeout | | | 442 +------------+-------------------+-------------------+------------------+ 444 +-----------------------------------------------------------------------+ 445 | When in P-BSR state | 446 +-------------+-------------------+------------------+------------------+ 447 | Event | Receive | BS Timer | Receive Non- | 448 | | Preferred BSM | Expires | preferred BSM | 449 +-------------+-------------------+------------------+------------------+ 450 | | -> C-BSR state | -> E-BSR state | -> P-BSR state | 451 | | Forward BSM; | Originate BSM; | | 452 | Action | Store RP-Set; | Set BS Timer | | 453 | | Set BS Timer | to BS Period | | 454 | | to BS Timeout | | | 455 +-------------+-------------------+------------------+------------------+ 457 +-----------------------------------------------------------------------+ 458 | When in E-BSR state | 459 +-------------+-------------------+------------------+------------------+ 460 | Event | Receive | BS Timer | Receive Non- | 461 | | Preferred BSM | Expires | preferred BSM | 462 +-------------+-------------------+------------------+------------------+ 463 | | -> C-BSR state | -> E-BSR state | -> E-BSR state | 464 | | Forward BSM; | Originate BSM; | Originate BSM; | 465 | Action | Store RP-Set; | Set BS Timer | Set BS Timer | 466 | | Set BS Timer | to BS Period | to BS Period | 467 | | to BS Timeout | | | 468 +-------------+-------------------+------------------+------------------+ 469 A candidate-BSR may be in one of three states for a particular scope 470 zone: 472 Candidate-BSR (C-BSR) 473 The router is a candidate to be the BSR for the scope zone, but 474 currently another router is the preferred BSR. 476 Pending-BSR (P-BSR) 477 The router is a candidate to be the BSR for the scope zone. 478 Currently no other router is the preferred BSR, but this router is 479 not yet the BSR. For comparisons with incoming BS messages, the 480 router treats itself as the BSR. This is a temporary state that 481 prevents rapid thrashing of the choice of BSR during BSR election. 483 Elected-BSR (E-BSR) 484 The router is the elected bootstrap router for the scope zone and 485 it must perform all the BSR functions. 487 On startup, the initial state for this configured scope zone is 488 "Pending-BSR"; the BS Timer is initialized to the BS Timeout value. 490 In addition to the three states, there is one timer: 492 o The bootstrap timer (BS Timer) - that is used to time out old 493 bootstrap router information, and used in the election process to 494 terminate P-BSR state. 496 Per-Scope-Zone State-machine for Non-Candidate-BSR Routers 498 Figure 2: Per-Scope-Zone State-machine for a router not configured as C- 499 BSR in tabular form 501 +-----------------------------------------------------------------------+ 502 | When in NoInfo state | 503 +--------------------+--------------------------------------------------+ 504 | Event | Receive BSM for unknown Admin Scope | 505 +--------------------+--------------------------------------------------+ 506 | | -> AP State | 507 | Action | Forward BSM; Store RP-Set; | 508 | | Set BS Timer to BS Timeout; | 509 | | Set SZ Timer to SZ Timeout | 510 +--------------------+--------------------------------------------------+ 512 +-----------------------------------------------------------------------+ 513 | When in Accept Any state | 514 +---------------+-----------------------------+-------------------------+ 515 | Event | Receive BSM | SZ Timer Expires | 516 +---------------+-----------------------------+-------------------------+ 517 | | -> AP State | -> NoInfo state | 518 | | Forward BSM; Store | cancel timers; | 519 | | RP-Set; Set BS | clear state | 520 | Action | Timer to BS | | 521 | | Timeout; Set SZ | | 522 | | Timer to SZ | | 523 | | Timeout | | 524 +---------------+-----------------------------+-------------------------+ 526 +-----------------------------------------------------------------------+ 527 | When in Accept Preferred state | 528 +------------+--------------------+------------------+------------------+ 529 | Event | Receive | BS Timer | Receive Non- | 530 | | Preferred BSM | Expires | preferred BSM | 531 +------------+--------------------+------------------+------------------+ 532 | | -> AP State | -> AA State | -> AP State | 533 | | Forward BSM; | Refresh RP- | | 534 | | Store RP-Set; | set; Remove | | 535 | Action | Set BS Timer | BSR state | | 536 | | to BS Timeout; | | | 537 | | Set SZ Timer | | | 538 | | to SZ Timeout | | | 539 +------------+--------------------+------------------+------------------+ 540 A router that is not a candidate-BSR may be in one of three states: 542 NoInfo 543 The router has no information about this scope zone. This state 544 does not apply if the router is configured to know about this scope 545 zone, or for the global scope zone. When in this state, no state 546 information is held and no timers run that refer to this scope 547 zone. 549 Accept Any (AA) 550 The router does not know of an active BSR, and will accept the 551 first bootstrap message it sees as giving the new BSR's identity 552 and the RP-Set. 554 Accept Preferred (AP) 555 The router knows the identity of the current BSR, and is using the 556 RP-Set provided by that BSR. Only bootstrap messages from that BSR 557 or from a C-BSR with higher weight than the current BSR will be 558 accepted. 560 On startup, the initial state for this scope zone is "Accept Any" for 561 routers that know about this scope zone, either through configuration or 562 because the scope zone is the global scope which always exists; the SZ 563 Timer is considered to be always running for such scope zones. For 564 routers that do not know about a particular scope zone, the initial 565 state is NoInfo; no timers exist for the scope zone. 567 In addition to the three states, there are two timers: 569 o The bootstrap timer (BS Timer) - that is used to time out old 570 bootstrap router information. 572 o The scope zone timer (SZ Timer) - that is used to time out the scope 573 zone itself if BS messages specifying this scope zone stop arriving. 575 Bootstrap Message Processing Checks 577 When a bootstrap message is received, the following initial checks must 578 be performed: 580 if ( (DirectlyConnected(BSM.src_ip_address) == FALSE) 581 OR (we have no Hello state for BSM.src_ip_address)) { 582 drop the BS message silently 583 } 584 if (BSM.dst_ip_address == ALL-PIM-ROUTERS group) { 585 if ( BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address) ) { 586 drop the BS message silently 587 } 588 } else if (BSM.dst_ip_address is one of my addresses) { 589 if (Any previous BSM for this scope has been accepted) { 590 #the packet was unicast, but this wasn't 591 #a quick refresh on startup 592 drop the BS message silently 593 } 594 } else { 595 drop the BS message silently 596 } 597 if (the interface the message arrived on is an Admin Scope 598 border for the BSM.first_group_address) { 599 drop the BS message silently 600 } 602 Basically, the packet must have come from a directly connected neighbor 603 for which we have active Hello state. It must have been sent to the 604 ALL-PIM-ROUTERS group by the correct upstream router towards the BSR 605 that originated the BS message, or the router must have no BSR state for 606 that admin scope (it just restarted) and have received the BS message by 607 unicast. In addition it must not have arrived on an interface that is a 608 configured admin scope border for the first group address contained in 609 the BS message. 611 BS State-machine Transition Events 613 If the bootstrap message passes the initial checks above without being 614 discarded, then it may cause a state transition event in one of the 615 above state-machines. For both candidate and non-candidate BSRs, the 616 following transition events are defined: 618 Receive Preferred BSM 619 A bootstrap message is received from a BSR that has greater 620 than or equal weight than the current BSR. If a router is in 621 P-BSR state, then it uses its own weight as that of the 622 current BSR. 624 The weighting for a BSR is the concatenation in fixed- 625 precision unsigned arithmetic of the BSR priority field from 626 the bootstrap message and the IP address of the BSR from the 627 bootstrap message (with the BSR priority taking the most- 628 significant bits and the IP address taking the least 629 significant bits). 631 Receive BSM 632 A bootstrap message is received, regardless of BSR weight. 634 A non-candidate BSR also has the following transition event defined: 636 Receive BSM for unknown Admin Scope 637 As "Receive BSM", except that the admin scope zone indicated 638 in the BSM was not previously known at this router. 640 BS State-machine Actions 642 The state-machines specify actions that include setting the BS timer to 643 the following values: 645 BS Period 646 The periodic interval with which bootstrap messages are 647 normally sent. The default value is 60 seconds. 649 BS Timeout 650 The interval after which bootstrap router state is timed out 651 if no bootstrap message from that router has been heard. The 652 default value is 2 times the BS Period plus 10 seconds, which 653 is 130 seconds. 655 Randomized Override Interval 656 The randomized interval during which a router avoids sending a 657 bootstrap message while it waits to see if another router has 658 a higher bootstrap weight. This interval is to reduce control 659 message overhead during BSR election. The following 660 pseudocode is proposed as an efficient implementation of this 661 "randomized" value: 663 Delay = 5 + 2 * log_2(1 + bestPriority - myPriority) 664 + AddrDelay 666 where myPriority is the Candidate-BSR's configured priority, 667 and bestPriority equals: 669 bestPriority = Max(storedPriority, myPriority) 671 and AddrDelay is given by the following for IPv4: 673 if ( bestPriority == myPriority) { 674 AddrDelay = log_2(storedAddr - myAddr) / 16 675 } else { 676 AddrDelay = 2 - (myAddr / 2^31) 677 } 679 and AddrDelay is given by the following for IPv6: 681 if ( bestPriority == myPriority) { 682 AddrDelay = log_2(storedAddr - myAddr) / 64 683 } else { 684 AddrDelay = 2 - (myAddr / 2^127) 685 } 687 where myAddr is the Candidate-BSR's address, storedAddr is the 688 stored BSR's address, and storedPriority is the stored BSR's 689 priority. 691 SZ Timeout 692 The interval after which a router will time out an Admin Scope 693 zone that it has dynamically learned. The interval MUST be 694 larger than the BS Timeout. The default value is ten times 695 the BS Timeout, which is 1300 seconds. 697 In addition to setting the timers, the following actions may be 698 triggered by state-changes in the state-machines: 700 Forward BSM 701 A bootstrap message that passes the Bootstrap Message 702 Processing Checks is forwarded out of all interfaces with PIM 703 neighbors (including the interface it is received on), except 704 where this would cause the BSM to cross an admin-scope 705 boundary for the scope zone indicated in the message. For 706 details, see section 3.3. 708 Originate BSM 709 A new bootstrap message is constructed by the BSR, giving the 710 BSR's address and BSR priority, and containing the BSR's 711 chosen RP-Set. The message is forwarded out of all multicast- 712 capable interfaces, except where this would cause the BSM to 713 cross an admin-scope boundary for the scope zone indicated in 714 the message. The IP source address of the message is the 715 originating router's IP address on the interface the message 716 is being forwarded from, the destination address is ALL-PIM- 717 ROUTERS, and the TTL of the message is set to 1. 719 Store RP-Set 720 The router uses the group-to-RP mappings contained in a BSM to 721 update its local RP-set. 723 If a mapping does not yet exist, it is created and the 724 associated group-to-RP mapping expiry timer (GET) is 725 initialized with the holdtime from the BSM. 727 If a mapping already exists, its GET is set to the holdtime 728 from the BSM. If the holdtime is zero, the mapping is removed 729 immediately. 731 In addition, the entire BSM is stored for use in the action 732 Refresh RP-Set and to prime a new PIM neighbor as described 733 below. 735 Refresh RP-Set 736 When the BS Timer expires, the router uses the copy of the 737 last BSM that it has received to refresh its RP-set according 738 to the action Store RP-Set as if it had just received it. 739 This will increase the chance that the group-to-RP mappings 740 will not expire during the election of the new BSR. 742 Remove BSR state 743 When the BS Timer expires, all state associated with the 744 current BSR is removed (see section 2). Note that this does 745 not include any group-to-RP mappings. 747 In addition to the above state-machine actions, a DR also unicasts a 748 stored copy of the Bootstrap message to each new PIM neighbor, i.e., 749 after the DR receives the neighbor's first Hello message, and sends a 750 Hello message in response. It does so even if the new neighbor becomes 751 the DR. 753 3.1. Sending Candidate-RP-Advertisements 755 Every C-RP periodically unicasts a C-RP-Adv to the BSR for that scope 756 zone to inform the BSR of the C-RP's willingness to function as an RP. 757 Unless configured otherwise, it does this for every Admin Scope zone for 758 which it has state, and for the global scope zone. If the same router 759 is the BSR for more than one scope zone, the C-RP-Adv for these scope 760 zones MAY be combined into a single message. 762 If the C-RP is a ZBR for an admin scope zone, then the Admin Scope bit 763 MUST be set in the C-RP-Adv messages it sends for that scope zone; 764 otherwise this bit MUST NOT be set. This information is currently only 765 used for logging purposes by the BSR, but might allow for future 766 extensions of the protocol. 768 The interval for sending these messages is subject to local 769 configuration at the C-RP, but must be smaller than the HoldTime in the 770 C-RP-Adv. 772 [NOTE: possible optimization: prime the CRPT with a small random value 773 when a new BSR is elected. This will allow the newly elected BSR to 774 learn group mappings fast.] 776 A Candidate-RP-Advertisement carries a list of group address and group 777 mask field pairs. This enables the C-RP router to restrict the 778 advertisement to certain prefixes or scopes of groups. If the C-RP 779 becomes an RP, it may enforce this scope acceptance when receiving 780 Registers or Join/Prune messages. 782 The C-RP priority field determines which C-RPs get selected by the BSR 783 to be in the RP-Set. Note that a value of zero is the highest possible 784 priority. C-RPs should by default send C-RP-Adv messages with the 785 `Priority' field set to 192. 787 When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv to 788 the BSR for each scope for which it is currently serving as an RP; the 789 HoldTime in this C-RP-Adv message should be zero. The BSR will then 790 immediately time out the C-RP and generate a new BSR message removing 791 the shut down RP from the RP-set. 793 [NOTE: Should a new BSM be sent immediately when C-RP-Adv with HoldTime 794 of 0 is received? Need to clarify.] 796 [NOTE: what happens if the message becomes too large to fit in a single 797 packet? With the per-mapping timers, it's not a problem to send several 798 advertisements. We need to say something about this.] 800 3.2. Creating the RP-Set at the BSR 802 Upon receiving a C-RP-Adv, if the router is not the elected BSR, it 803 silently ignores the message. 805 If the router is the BSR, it creates a group-to-C-RP mapping for every 806 group range in the C-RP-Adv. These mappings have identical values for 807 the C-RP address, C-RP priority and holdtime. The hash mask length is a 808 global property of the BSR and is therefore the same for all mappings 809 managed by the BSR. 811 [NOTE: This is substantially different from version 03, where state was 812 kept per C-RP. The behaviour is the same if a C-RP always sends all 813 advertisements in a single message. However, there seems to be no 814 requirement for this (and the case where all advertisements don't fit in 815 a single message seems not to be covered). Keeping state per group 816 mapping allows a C-RP to send C-RP-Advs in chunks and even allows for 817 different holdtimes for different group ranges (which may or may not be 818 useful) while being compatible with the old version.] 820 Every mapping that is not part of the C-RP-set is added to the C-RP-set 821 and the associated group-to-C-RP mapping expiry timer (CGET) is 822 initialized to the holdtime. 824 If a mapping already exists (i.e. the C-RP-set contains a mapping with 825 identical group-range and C-RP-address), it is updated with the 826 information from the BSM and its associated CGET is reset to the 827 holdtime from the BSM. If the holdtime is zero, the mapping is 828 immediately removed from the C-RP-set. 830 When a CGET expires, the corresponding group-to-C-RP mapping is removed 831 from the C-RP-set. 833 The BSR constructs the RP-set from the C-RP-set. It may apply a local 834 policy to limit the number of Candidate RPs included in the RP-set. The 835 BSR may override the prefix indicated in a C-RP-Adv unless the 836 `Priority' field from the C-RP-Adv is less than 128. 838 For inclusion in a BSM, the RP-set is subdivided into sets of {group- 839 prefix, RP-Count, RP-addresses}. For each RP-address, the corresponding 840 HoldTime is included in the "RP-HoldTime" field. The format of the 841 Bootstrap message allows `semantic fragmentation', if the length of the 842 original Bootstrap message exceeds the packet maximum boundaries. 843 However, we recommend against configuring a large number of routers as 844 C-RPs, to reduce the semantic fragmentation required. 846 When an elected BSR is being shut down, it should immediately originate 847 a Bootstrap message listing its current RP-Set, but with the BSR 848 priority field set to the lowest priority value possible. This will 849 cause the election of a new BSR to happen more quickly. 851 3.3. Forwarding Bootstrap Messages 853 Bootstrap messages originate at the BSR, and are hop-by-hop forwarded by 854 intermediate routers if they pass the Bootstrap Message Processing 855 Check. Bootstrap messages are multicast to the `ALL-PIM-ROUTERS' group. 856 When a BS message is forwarded, it is forwarded out of every multicast- 857 capable interface which has PIM neighbors (including the one over which 858 the message was received). The exception to this is if the interface is 859 an administrative scope boundary for the admin scope zone indicated in 860 the first group address in the BS message packet. The IP source address 861 on the bootstrap message should be set to the forwarding router's IP 862 address on the interface the message is being forwarded from. Bootstrap 863 messages are always originated or forwarded with an IP TTL value of 1. 865 As an optimization, a router MAY choose not to forward a BSM out of the 866 interface the message was received on if that interface is a point-to- 867 point interface. On interfaces with multiple PIM neighbors, a router 868 SHOULD forward an accepted BSM onto the interface that BSM was received 869 on, but if the number of PIM neighbors on that interface is large, it 870 MAY delay forwarding a BSM onto that interface by a small randomized 871 interval to prevent message implosion. A configuration option MAY be 872 provided to disable forwarding onto the interface a message was received 873 on, but we recommend that the default behavior is to forward onto that 874 interface. 876 Rationale: A BSM needs to be forwarded onto the interface the message 877 was received on (in addition to the other interfaces) because the 878 routers on a LAN may not have consistent routing information. If three 879 routers on a LAN are A, B, and C, and at router B RPF(BSR)==A and at 880 router C RPF(BSR)==B, then router A originally forwards the BSM onto the 881 LAN, but router C will only accept it when router B re-forwards the 882 message onto the LAN. If the underlying routing protocol configuration 883 guarantees that the routers have consistent routing information, then 884 forwarding onto the incoming interface may safely be disabled. 886 3.4. Receiving and Using the RP-Set 888 [NOTE: what should go into this section? It doesn't make sense to 889 repeat what is said in the "Store RP-set" action.] 891 The RP-set maintained by BSR is used by RP-based multicast routing 892 protocols like PIM-SM and Bi-directional PIM. These protocols may 893 obtain RP-sets from other sources as well. How the final group-to-RP 894 mappings are obtained from these RP-sets is not part of the BSR 895 specification. In general, the routing protocols need to re-calculate 896 the mappings when any of their RP-sets change. How such a change is 897 signalled to the routing protocol is also not part of the present 898 specification. 900 4. Message Formats 902 BSR messages are PIM messages, as defined in [1]. The values of the PIM 903 message Type field for BSR messages are: 905 4 Bootstrap Message 907 8 Candidate-RP-Advertisement 908 In this section we use the following terms defined in the PIM-SM [1]: 910 o Encoded-Unicast format 912 o Encoded-Group format 914 We repeat these here to aid readability. 916 Encoded-Unicast address 918 An Encoded-Unicast address takes the following format: 920 0 1 2 3 921 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 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Addr Family | Encoding Type | Unicast Address 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 926 Addr Family 927 The PIM address family of the `Unicast Address' field of this 928 address. 930 Values of 0-127 are as assigned by the IANA for Internet Address 931 Families in [7]. Values 128-250 are reserved to be assigned by the 932 IANA for PIM-specific Address Families. Values 251 though 255 are 933 designated for private use. As there is no assignment authority 934 for this space, collisions should be expected. 936 Encoding Type 937 The type of encoding used within a specific Address Family. The 938 value `0' is reserved for this field, and represents the native 939 encoding of the Address Family. 941 Unicast Address 942 The unicast address as represented by the given Address Family and 943 Encoding Type. 945 Encoded-Group address 946 Encoded-Group addresses take the following format: 948 0 1 2 3 949 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 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Addr Family | Encoding Type |B| Reserved |Z| Mask Len | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Group multicast Address 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 956 Addr Family 957 described above. 959 Encoding Type 960 described above. 962 [B]IDIR bit 963 When set, all BIDIR capable PIM routers will operate the protocol 964 described in [3] for the specified group range. 966 Reserved 967 Transmitted as zero. Ignored upon receipt. 969 Admin Scope [Z]one 970 When set, this bit indicates that this group address range is an 971 administratively scoped range. 973 Mask Len 974 The Mask length field is 8 bits. The value is the number of 975 contiguous one bits left justified used as a mask which, combined 976 with the group address, describes a range of groups. It is less 977 than or equal to the address length in bits for the given Address 978 Family and Encoding Type. If the message is sent for a single group 979 then the Mask length must equal the address length in bits for the 980 given Address Family and Encoding Type. (e.g. 32 for IPv4 native 981 encoding and 128 for IPv6 native encoding). 983 Group multicast Address 984 Contains the group address. 986 4.1. Bootstrap Message Format 988 A bootstrap message is divided up into `semantic fragments' if the 989 original message exceeds the maximum packet size boundaries. Basically, 990 a single bootstrap message can be sent as multiple packets (semantic 991 fragments), so long as the fragment tags of all the packets comprising 992 the message is the same. 994 If the bootstrap message contains information about more than one admin 995 scope zone, each different scope zone MUST occupy a different semantic 996 fragment. This allows Zone Border Routers for an admin scope zone to 997 not forward only those fragments that should not traverse the admin 998 scope boundary. 1000 The format of a single `fragment' is given below: 1002 0 1 2 3 1003 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 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 |PIM Ver| Type | Reserved | Checksum | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Fragment Tag | Hash Mask len | BSR-priority | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | BSR Address (Encoded-Unicast format) | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Group Address 1 (Encoded-Group format) | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | RP Count 1 | Frag RP Cnt 1 | Reserved | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | RP Address 1 (Encoded-Unicast format) | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | RP1 Holdtime | RP1 Priority | Reserved | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | RP Address 2 (Encoded-Unicast format) | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | RP2 Holdtime | RP2 Priority | Reserved | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | . | 1024 | . | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | RP Address m (Encoded-Unicast format) | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | RPm Holdtime | RPm Priority | Reserved | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Group Address 2 (Encoded-Group format) | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | . | 1033 | . | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Group Address n (Encoded-Group format) | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | RP Count n | Frag RP Cnt n | Reserved | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | RP Address 1 (Encoded-Unicast format) | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | RP1 Holdtime | RP1 Priority | Reserved | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | RP Address 2 (Encoded-Unicast format) | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | RP2 Holdtime | RP2 Priority | Reserved | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | . | 1048 | . | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | RP Address m (Encoded-Unicast format) | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | RPm Holdtime | RPm Priority | Reserved | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 PIM Version, Reserved, Checksum 1056 Described in [1]. 1058 Type PIM Message Type. Value is 4 for a Bootstrap Message. 1060 Fragment Tag 1061 A randomly generated number, acts to distinguish the fragments 1062 belonging to different Bootstrap messages; fragments belonging to 1063 same Bootstrap message carry the same `Fragment Tag'. 1065 Hash Mask len 1066 The length (in bits) of the mask to use in the hash function. For 1067 IPv4 we recommend a value of 30. For IPv6 we recommend a value of 1068 126. 1070 BSR priority 1071 Contains the BSR priority value of the included BSR. This field is 1072 considered as a high order byte when comparing BSR addresses. Note 1073 that for historical reasons, the highest BSR priority is 255 (the 1074 higher the better), whereas the highest RP Priority (see below) is 1075 0 (the lower the better). 1077 BSR Address 1078 The address of the bootstrap router for the domain. The format for 1079 this address is given in the Encoded-Unicast address in [1]. 1081 Group Address 1..n 1082 The group prefix (address and mask) with which the Candidate RPs 1083 are associated. Format described in [1]. In a fragment containing 1084 admin scope ranges, the first group address in the fragment MUST be 1085 the group range for the entire admin scope range, and this MUST 1086 have the Admin Scope bit set. This is the case even if there are 1087 no RPs in the RP-Set for the entire admin scope range - in this 1088 case the sub-ranges for the RP-Set are specified later in the 1089 fragment along with their RPs. 1091 RP Count 1..n 1092 The number of Candidate RP addresses included in the whole 1093 Bootstrap message for the corresponding group prefix. A router does 1094 not replace its old RP-Set for a given group prefix until/unless it 1095 receives `RP-Count' addresses for that prefix; the addresses could 1096 be carried over several fragments. If only part of the RP-Set for 1097 a given group prefix was received, the router discards it, without 1098 updating that specific group prefix's RP-Set. 1100 Frag RP Cnt 1..m 1101 The number of Candidate RP addresses included in this fragment of 1102 the Bootstrap message, for the corresponding group prefix. The 1103 `Frag RP Cnt' field facilitates parsing of the RP-Set for a given 1104 group prefix, when carried over more than one fragment. 1106 RP address 1..m 1107 The address of the Candidate RPs, for the corresponding group 1108 prefix. The format for these addresses is given in the Encoded- 1109 Unicast address in [1]. 1111 RP1..m Holdtime 1112 The Holdtime for the corresponding RP. This field is copied from 1113 the `Holdtime' field of the associated RP stored at the BSR. 1115 RP1..m Priority 1116 The `Priority' of the corresponding RP and Encoded-Group Address. 1117 This field is copied from the `Priority' field stored at the BSR 1118 when receiving a Candidate-RP-Advertisement. The highest priority 1119 is `0' (i.e. unlike BSR priority, the lower the value of the 1120 `Priority' field, the better). Note that the priority is per RP 1121 per Group Address. 1123 4.1.1. Semantic Fragmentation of BSMs 1125 Bootstrap messages may be split over several PIM Bootstrap Message 1126 Fragment (BSMF) packets; this is known as semantic fragmentation. There 1127 are two reasons for semantic fragmentation: 1129 o The BSM would exceed the link MTU the packet will be forwarded 1130 over. 1132 o The BSM includes information about more than one admin scope zone. 1134 Let us initially consider only the former case; the packet would be too 1135 large because the set of group prefixes and the RPs for each group 1136 prefix are too long to fit in one packet. The BSR will then split the 1137 BSM across several BSMF packets; each of these must be a well-formed 1138 BSMF packet in its own right. 1140 If the BSR can split up the BSM so that different group prefixes (and 1141 their RP information) can fit in different fragments, then it should do 1142 so. If one of these BSMF packets is then lost, the state from the 1143 previous BSM for the group-prefix from the missing packet will be 1144 retained. Each fragment that does arrive will update the RP information 1145 for the group-prefixes contained in that fragment, and the new group-to- 1146 RP mapping for those can be used immediately. The information from the 1147 missing fragment will be obtained when the BSM is next transmitted. In 1148 this case, whilst the Fragment Tag must be set to the same value for all 1149 BSMFs comprising a single BSM, the tag is not actually used by routers 1150 receiving the BSM. 1152 If the list of RPs for a single group-prefix is too long to fit in a 1153 single BSMF packet, then that information must be split across multiple 1154 BSMF packets. In this case, all the BSMF packets comprising the 1155 information for that group-prefix must be received before the group-to- 1156 RP mapping in use can be modified. This is the purpose of the RP Count 1157 field - a router receiving BSMF packets from the same BSM (ie that have 1158 the same fragment tag) must wait until the BSMFs providing RP Count RPs 1159 for that group-prefix have been received before the new group-to-RP 1160 mapping can be used for that group-prefix. If a single BSMF from such a 1161 large group-prefix is lost, then that entire group-prefix will have to 1162 wait until the next BSM is originated. 1164 Next we need to consider how a BSR would remove group-prefixes from the 1165 BSM. A router receiving a set of BSMFs cannot tell if a group-prefix is 1166 missing. If it has seen a group-prefix before, it must assume that that 1167 group-prefix still exists, and that the BSMF describing it has been 1168 lost. It should retain this information for BS Timeout seconds. Thus 1169 for a BSR to remove a group-prefix from the BSR, it should include that 1170 group-prefix, but with a RP Count of zero, and it should resend this 1171 information in each BSM for BS Timeout seconds. 1173 Finally, we come to the case of fragments for the purpose of conveying 1174 admin scope group-prefixes. In general, the information for each admin 1175 scope range is independent of information about other admin scope 1176 ranges. As no BSMF is allowed to convey information for more than one 1177 admin scope range, then the procedure above also applies to BSMs that 1178 are fragmented due to admin scoping. However, to time out all the state 1179 for an entire admin scope zone requires waiting SZ Timeout rather than 1180 BS Timeout, as admin scope zones are not expected to come and go 1181 frequently. 1183 4.2. Candidate-RP-Advertisement Format 1185 Candidate-RP-Advertisements are periodically unicast from the C-RPs to 1186 the BSR. 1188 0 1 2 3 1189 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 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 |PIM Ver| Type | Reserved | Checksum | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | Prefix Count | Priority | Holdtime | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | RP Address (Encoded-Unicast format) | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | Group Address 1 (Encoded-Group format) | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | . | 1200 | . | 1201 | . | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Group Address n (Encoded-Group format) | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 PIM Version, Reserved, Checksum 1207 Described in [1]. 1209 Type PIM Message Type. Value is 8 for a Candidate-RP-Advertisement 1210 Message. 1212 Prefix Count 1213 The number of encoded group addresses included in the message; 1214 indicating the group prefixes for which the C-RP is advertising. A 1215 Prefix Count of `0' implies all multicast groups, e.g. for IPv4 a 1216 prefix of 224.0.0.0 with mask length of 4. If the C-RP is not 1217 configured with Group-prefix information, the C-RP puts a default 1218 value of `0' in this field. 1220 Priority 1221 The `Priority' of the included RP, for the corresponding Encoded- 1222 Group Address (if any). highest priority is `0' (i.e. the lower 1223 the value of the `Priority' field, the higher the priority). This 1224 field is stored at the BSR upon receipt along with the RP address 1225 and corresponding Encoded-Group Address. 1227 Holdtime 1228 The amount of time the advertisement is valid. This field allows 1229 advertisements to be aged out. 1231 RP Address 1232 The address of the interface to advertise as a Candidate RP. The 1233 format for this address is given in the Encoded-Unicast address in 1234 [1]. 1236 Group Address-1..n 1237 The group prefixes for which the C-RP is advertising. Format 1238 described in Encoded-Group-Address in [1]. 1240 5. Default Values for Timers 1242 Timer Name: Bootstrap Timer (BST) 1244 +-------------------+--------------------------+------------------------+ 1245 | Value Name | Value | Explanation | 1246 +-------------------+--------------------------+------------------------+ 1247 | BS Period | Default: 60 secs | Period between | 1248 | | | originating | 1249 | | | bootstrap messages | 1250 +-------------------+--------------------------+------------------------+ 1251 | BS Timeout | 2 * BS_Period + 10 | Period after last | 1252 | | seconds | BS message before | 1253 | | | BSR is timed out | 1254 | | | and election | 1255 | | | begins | 1256 +-------------------+--------------------------+------------------------+ 1257 | rand_override | rand(0, 5.0 secs) | Suppression period | 1258 | | | in BSR election to | 1259 | | | prevent thrashing | 1260 +-------------------+--------------------------+------------------------+ 1262 Timer Name: Group-to-C-RP apping Expiry Timer (CGET(M,Z)) 1264 +----------------------+--------------+---------------------------------+ 1265 |Value Name |Value | Explanation | 1266 +----------------------+--------------+---------------------------------+ 1267 |C-RP Mapping Timeout |from message | Hold time from C-RP-Adv message | 1268 +----------------------+--------------+---------------------------------+ 1270 C-RP Advertisement messages are sent periodically with period C-RP-Adv- 1271 Period. C-RP-Adv-Period defaults to 60 seconds. The holdtime to be 1272 specified in a C-RP-Adv message should be set to (2.5 * C-RP-Adv-Period 1273 ). This timer is used for group-to-C-RP mappings in the C-RP-set at the 1274 BSR. 1276 Timer Name: Group-to-RP mapping Expiry Timer (GET(M,Z)) 1278 +------------------------+--------------------+-------------------------+ 1279 | Value Name | Value | Explanation | 1280 +------------------------+--------------------+-------------------------+ 1281 | RP Mapping Timeout | from message | Hold time from BSM | 1282 +------------------------+--------------------+-------------------------+ 1284 This timer is identical to CGET, except that it applies to the mappings 1285 in the RP-set rather than the C-RP-set. 1287 Timer Name: C-RP Advertisement Timer (CRPT) 1289 +--------------------+--------------------------+-----------------------+ 1290 | Value Name | Value | Explanation | 1291 +--------------------+--------------------------+-----------------------+ 1292 | C-RP-Adv-Period | Default: 60 seconds | Period with which | 1293 | | | periodic C-RP | 1294 | | | Advertisements are | 1295 | | | sent to BSR | 1296 +--------------------+--------------------------+-----------------------+ 1298 Timer Name: Scope Zone Expiry Timer (SZT(Z)) 1300 +------------------------------------+--------------+--------------------+ 1301 |Value Name Value Explanation | | | 1302 +------------------------------------+--------------+--------------------+ 1303 |SZ Timeout | 1300 seconds | Interval after | 1304 | | | which a scope zone | 1305 | | | will be timed out | 1306 | | | if the state is | 1307 | | | not refreshed | 1308 +------------------------------------+--------------+--------------------+ 1310 6. Security Considerations 1312 6.1. Possible Threats 1314 Threats affecting the PIM BSR mechanism are primarily of two forms: 1315 denial of service attacks, and traffic diversion attacks. An attacker 1316 that subverts the BSR mechanism can prevent multicast traffic from 1317 reaching the intended recipients, can divert multicast traffic to a 1318 place where they can monitor it, and can potentially flood third parties 1319 with traffic. 1321 Traffic can be prevented from reaching the intended recipients by one of 1322 two mechanisms: 1324 o Subverting a BSM, and specifying RPs that won't actually forward 1325 traffic. 1327 o Registering with the BSR as a C-RP, and then not forwarding 1328 traffic. 1330 Traffic can be diverted to a place where it can be monitored by both of 1331 the above mechanisms; in this case the RPs would forward the traffic, 1332 but are located so as to aid monitoring or man-in-the-middle attacks on 1333 the multicast traffic. 1335 A third party can be flooded by either of the above two mechanisms by 1336 specifying the third party as the RP, and register-encapsulated traffic 1337 will then be forwarded to them. 1339 6.2. Limiting Third-Party DoS Attacks 1341 The third party DoS attack above can be greatly reduced if PIM routers 1342 acting as DR do not continue to forward Register traffic to the RP in 1343 the presence of ICMP Protocol Unreachable or ICMP Host Unreachable 1344 responses. If a PIM router sending Register packets to an RP receives 1345 one of these responses to a data packet it has sent, it should rate- 1346 limit the transmission of future Register packets to that RP for a short 1347 period of time. 1349 As this does not affect interoperability, the precise details are left 1350 to the implementor to decide. However we note that a router 1351 implementing such rate limiting must only do so if the ICMP packet 1352 correctly echoes part of a Register packet that was sent to the RP. If 1353 this check were not made, then simply sending ICMP Unreachable packets 1354 to the DR with the source address of the RP spoofed would be sufficient 1355 to cause a denial-of-service attack on the multicast traffic originating 1356 from that DR. 1358 6.3. BS Message Security 1360 If a legitimate PIM router is compromised, there is little any security 1361 mechanism can do to prevent that router subverting PIM traffic in that 1362 domain. However we recommend that implementors provide a mechanism 1363 whereby a PIM router using the BSR mechanisms can be configured with the 1364 IP addresses of valid BSR routers, and that any BS Message from any 1365 other BSR should then be dropped and logged as a security issue. We 1366 also recommend that this not be enabled by default, as it makes the 1367 initial configuration of a PIM domain problematic - it is the sort of 1368 feature that might be enabled once the configuration of a domain has 1369 stabilized. 1371 The primary security requirement for BSR (as for PIM) is that it is 1372 possible to prevent hosts that are not legitimate PIM routers, either 1373 within or outside the domain, from subverting the BSR mechanism. 1375 The Bootstrap Message Processing Checks prevent a router from accepting 1376 a BS message from outside of the PIM Domain, as the source address on BS 1377 Messages must be an immediate PIM neighbor. There is however a small 1378 window of time after a reboot where a PIM router will accept a bad BS 1379 Message unicast from an immediate neighbor, and it might be possible to 1380 unicast a BS Message to a router during this interval from outside the 1381 domain, using the spoofed source address of a neighbor. This can be 1382 prevented if PMBRs perform source-address filtering to prevent packets 1383 entering the PIM domain with IP source addresses that are infrastructure 1384 addresses in the PIM domain. 1386 The principal threat to BS Message security comes from hosts within the 1387 PIM domain that attempt to subvert the BSR mechanism. They may be able 1388 to do this by sending PIM messages to their local router, or by 1389 unicasting a BS message to another PIM router during the brief interval 1390 after it has restarted. 1392 All BS Messages SHOULD carry the Router Alert IP option. If a PIM 1393 router receives a BS Message that does not carry the router alert 1394 option, it SHOULD drop it (a configuration option should also be 1395 provided to disable this check on a per-interface basic for backward 1396 compatibility with older PIM routers). The Router Alert option allows a 1397 PIM router to perform checks on unicast packets it would otherwise 1398 blindly forward. All PIM routers should check that packets with Router 1399 Alert that are not destined for the router itself are not PIM Bootstrap 1400 messages. Any such packets should be dropped and logged as a possible 1401 security issue - it is never acceptable for a PIM BS message to travel 1402 multiple IP hops. 1404 Most hosts that are likely to attempt to subvert PIM BSR are likely to 1405 be located on leaf subnets. We recommend that implementors provide a 1406 configuration option that specifies an interface is a leaf subnet, and 1407 that no PIM packets are accepted on such interfaces. 1409 On multi-access subnets with multiple PIM routers and hosts that are not 1410 trusted, we recommend that IPsec AH is used to protect communication 1411 between PIM routers, and that such routers are configured to drop and 1412 log communication attempts from any host that do not pass the 1413 authentication check. When all the PIM routers are under the same 1414 administrative control, this authentication may use a configured shared 1415 secret. The securing of interactions between PIM neighbors is discussed 1416 in more detail in the Security Considerations section of [1], and so we 1417 do not discuss the details further here. The same security mechanisms 1418 that can be used to secure PIM Join, Prune and Assert messages should 1419 also be used to secure BS messages. 1421 6.4. C-RP-Advertisement Security 1423 Even if it is not possible to subvert BS Messages, an attacker might be 1424 able to perform most of the same attacks by simply sending C-RP-Adv 1425 messages to the BSR specifying the attacker's choice of RPs. Thus it is 1426 necessary to control the sending of C-RP-Adv messages in essentially the 1427 same ways that we control BS Messages. However, C-RP-Adv messages are 1428 unicast and normally travel multiple hops, so controlling them is a 1429 little harder. 1431 We specify that C-RP-Adv messages SHOULD also carry the Router Alert IP 1432 option, and that the BSR SHOULD by default drop and log C-RP-Adv 1433 messages that do not carry this option. Setting Router Alert on these 1434 packets is practical because the rate of C-RP-Adv messages should be 1435 very low, so the extra load on routers forwarding these packets will be 1436 insignificant. All PIM routers forwarding such a packet are then 1437 capable of checking whether the packet came from a valid neighbor. On 1438 interfaces that are configured to be leaf subnets, all C-RP-Adv messages 1439 should be dropped. On multi-access subnets with multiple PIM routers 1440 and hosts that are not trusted, the router can at least check that the 1441 source MAC address is that of a valid PIM neighbor. PMBRs should ensure 1442 that no C-RP-Adv messages enter the domain from an external neighbor. 1444 For true security, we recommend that all C-RPs are configured to use 1445 IPsec authentication. The authentication process for a C-RP-Adv message 1446 between a C-RP and the BSR is identical to the authentication process 1447 for PIM Register messages between a DR and the relevant RP, except that 1448 there will normally be fewer C-RPs in a domain than there are DRs, so 1449 key management is a little simpler. We do not describe the details of 1450 this process further here, but refer to the Security Considerations 1451 section of [1]. Note that the use of cryptographic security for C-RP- 1452 Advs does not remove the need for the non-cryptographic mechanisms, as 1453 explained below. 1455 6.5. Denial of Service using IPsec 1457 An additional concern is that of Denial-of-Service attacks caused by 1458 sending high volumes of BS Messages or C-RP-Adv messages with invalid 1459 IPsec authentication information. It is possible that these messages 1460 could overwhelm the CPU resources of the recipient. 1462 The non-cryptographic security mechanisms above prevent unicast BS 1463 messages from traveling multiple hops, and constrain who can originate 1464 such messages. However, it is obviously important that PIM Messages 1465 that are required to have Router Alert checked are checked for this 1466 option before the IPsec AH is checked. Thus the remaining vulnerability 1467 primarily exists for hosts on multi-access subnets containing more than 1468 one PIM router. A PIM router receiving PIM packets with Router Alert 1469 set from such a subnet should already be checking that the source MAC 1470 address is that of a valid PIM neighbor, but this is hardly strong 1471 security. In addition, we recommend that rate-limiting mechanisms can 1472 be configured, to be applied to the forwarding of unicast PIM packets 1473 containing Router Alert options. The rate-limiter MUST independently 1474 rate-limit different types of PIM packets - for example a flood of C-RP- 1475 Adv messages MUST NOT cause a rate limiter to drop low-rate BS Messages. 1476 Such a rate-limiter might itself be used to cause a denial of service 1477 attack by causing valid packets to be dropped, but in practice this is 1478 more likely to constrain bad PIM Messages close to their origin. In 1479 addition, the rate limiter will prevent attacks on PIM from affecting 1480 other activity on the destination router, such as unicast routing. 1482 7. Contributors 1484 Bill Fenner, Mark Handley, Roger Kermode and David Thaler have 1485 contributed greatly to this draft. They were authors of this draft up 1486 to version 03. Most of the current text is identical to 03. 1488 8. Acknowledgments 1490 PIM-SM was designed over many years by a large group of people, 1491 including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve 1492 Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, 1493 Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, 1494 Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish 1495 Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas and Hugh 1496 Holbrook. This BSR specification draws heavily on text from RFC 2362. 1498 9. IANA Considerations 1500 This document has no actions for IANA. 1502 10. Normative References 1504 [1] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 1505 Independent Multicast - Sparse Mode (PIM-SM): Protocol 1506 Specification (Revised)", Internet Draft draft-ietf-pim-sm- 1507 v2-new-09.ps 1509 [2] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, Jul 1510 1998. 1512 [3] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional 1513 Protocol Independent Multicast (BIDIR-PIM)", Internet Draft draft- 1514 ietf-pim-bidir-06.txt 1516 11. Informative References 1518 [4] S. Deering , W. Fenner , B. Haberman, "Multicast Listener Discovery 1519 (MLD) for IPv6", RFC 2710, Oct 1999. 1521 [5] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode 1522 (PIM-SM): Protocol Specification", RFC 2362, June 1998 (now 1523 obsolete). 1525 [6] W. Fenner, "Internet Group Management Protocol, Version 2", RFC 1526 2236, Nov 1997. 1528 [7] IANA, "Address Family Numbers", linked from 1529 http://www.iana.org/numbers.html 1531 12. Authors' Addresses 1533 Nidhi Bhaskar 1534 Cisco Systems 1535 170 W. Tasman Drive 1536 San Jose, CA 95134 1537 USA 1538 nbhaskar@cisco.com 1539 Alexander Gall 1540 SWITCH 1541 Limmatquai 138 1542 P.O. Box 1543 CH-8021 Zurich 1544 Switzerland 1545 gall@switch.ch 1547 Stig Venaas 1548 UNINETT 1549 NO-7465 Trondheim 1550 Norway 1551 venaas@uninett.no 1553 Copyright Statement 1555 Copyright (C) The Internet Society (2004). This document is subject to 1556 the rights, licenses and restrictions contained in BCP 78, and except as 1557 set forth therein, the authors retain all their rights. 1559 Disclaimer of Validity 1561 This document and the information contained herein are provided on an 1562 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 1563 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1564 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1565 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1566 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1567 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.