RFC 5059
Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)
RFC 5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) 🎀
okay bestie, this one is the Bootstrap Router (BSR) Mechanism for PIM, and it's giving main character energy 👑. It's an Internet standards track doc from January 2008 📅. The authors are N. Bhaskar (Arastra), A. Gall (SWITCH), J. Lingard (Arastra), and S. Venaas (UNINETT) 🫶. It obsoletes RFC 2362 and updates RFC 4601 ✨, so the BSR bits from the old spec got a glow-up here.
Status of This Memo 💅
This document is an Internet standards track protocol spec for the Internet community. It also asks for discussion and suggestions to make it better 💖. For the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🦋.
Abstract ✨
okay so this doc spells out the Bootstrap Router (BSR) mechanism for the PIM family of multicast routing protocols, the ones that use a Rendezvous Point so receivers can find out which sources are sending to a given multicast group 🧚. BSR is one way a multicast router can learn the group-to-RP mappings it needs to actually work 🔥. The mechanism is dynamic, mostly self-configuring, and robust to router failure 💜. literally the dream.
Table of Contents 🌸
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Protocol Overview ..........................................5
1.3. Administrative Scoping and BSR .............................6
2. BSR State and Timers ............................................8
3. Bootstrap Router Election and RP-Set Distribution ...............9
3.1. Bootstrap Router Election ..................................9
3.1.1. Per-Scope-Zone Candidate-BSR State Machine .........10
3.1.2. Per-Scope-Zone State Machine for
Non-Candidate-BSR Routers ..........................11
3.1.3. Bootstrap Message Processing Checks ................13
3.1.4. State Machine Transition Events ....................14
3.1.5. State Machine Actions ..............................15
3.2. Sending Candidate-RP-Advertisement Messages ...............17
3.3. Creating the RP-Set at the BSR ............................18
3.4. Forwarding Bootstrap Messages .............................21
3.5. Bootstrap Messages to New and Rebooting Routers ...........22
3.5.1. No-Forward Bootstrap Messages ......................23
3.5.2. Unicasting Bootstrap Messages ......................23
3.6. Receiving and Using the RP-Set ............................23
4. Message Formats ................................................24
4.1. Bootstrap Message Format ..................................26
4.1.1. Semantic Fragmentation of BSMs .....................30
4.2. Candidate-RP-Advertisement Message Format .................31
5. Timers and Timer Values ........................................33
6. Security Considerations ........................................36
6.1. Possible Threats ..........................................36
6.2. Limiting Third-Party DoS Attacks ..........................36
6.3. Bootstrap Message Security ................................37
6.3.1. Unicast Bootstrap Messages .........................37
6.3.2. Multi-Access Subnets ...............................38
6.4. Candidate-RP-Advertisement Message Security ...............38
6.4.1. Non-Cryptographic Security of C-RP-Adv Messages ....38
6.4.2. Cryptographic Security of C-RP-Adv Messages ........39
6.5. Denial of Service using IPsec .............................39
7. Contributors ...................................................40
8. Acknowledgments ................................................40
9. Normative References ...........................................40
10. Informative References ........................................411. Introduction ✨
okay so this doc assumes you already know your way around Protocol Independent Multicast - Sparse Mode (PIM-SM) [1] and Bidirectional Protocol Independent Multicast (BIDIR-PIM) [2] 🌈. You should also be comfy with Administratively Scoped IP Multicast [3] and the IPv6 Scoped Address Architecture [4] 💅.
For things to work right, every multicast router inside a PIM domain must be able to map a particular multicast group address to the same Rendezvous Point (RP) 🍓. The PIM specs don't force a single mechanism for handing routers the info they need to do that group-to-RP mapping 🦋.
This doc describes the PIM Bootstrap Router (BSR) mechanism. BSR is one way a multicast router can learn what it needs for group-to-RP mapping ✨. It's dynamic, largely self-configuring, and robust to router failure 💖.
BSR was first defined in RFC 2362 [7] as part of the original PIM-SM spec. That spec has since been obsoleted by RFC 4601 [1] 🎀. This doc gives an updated spec of the BSR mechanism from RFC 2362, and it also extends BSR so it can handle administratively scoped region boundaries and different flavors of routing protocols 🔥.
Throughout the doc, any mention of the PIM protocol family is limited to the RP-based subset, which is PIM-SM and BIDIR-PIM, unless it says otherwise 🧚.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [6] 👑.
1.1. Background 🌸
okay so a PIM domain is a contiguous set of routers that all run PIM and are configured to work inside a shared boundary set up by PIM Multicast Border Routers (PMBRs) 🫶. PMBRs are what connect each PIM domain to the rest of the Internet 🌐.
Every PIM multicast group needs to be tied to the IP address of a Rendezvous Point (RP) 💜. That address becomes the root of a group-specific distribution tree, and its branches reach every node in the domain that wants traffic sent to the group 🦋. Senders push packets into the tree so they reach all the connected receivers ✨. How that happens, and how packets move along the tree, depends on the specific routing protocol 🧚.
For all senders to reach all receivers, every router in the domain has to use the same mappings of group addresses to RP addresses 🔥. It's crucial, bestie 😭.
There's one exception. A PIM domain can be split up into multiple administrative scope regions, which are areas where a border has been set so a certain set of multicast groups won't be forwarded across it 🍓. In that case, all PIM routers inside the same scope region must map a particular scoped group to the same RP within that region 💅.
To figure out the RP for a multicast group, a PIM router keeps a collection of group-to-RP mappings called the RP-Set 🌈. Each group-to-RP mapping holds these elements:
- Multicast group range, expressed as an address and prefix length
- RP priority
- RP address
- Hash mask length
- SM / BIDIR flag
Generally, the group ranges of these mappings can overlap in arbitrary ways 🎀. So one multicast group might be covered by several group-to-RP mappings 🌸. When that happens, the router picks just one RP by running a deterministic algorithm, so every router in the domain makes the same choice 💖. This algorithm belongs to the spec of the individual routing protocols (and it can differ between them), not to the BSR spec 🦋. For example, PIM-SM [1] defines one such algorithm. It uses a hash function for the case where a group range has multiple RPs with the same priority, and the hash mask length feeds into that function 🧚.
There are a bunch of ways to set up these group-to-RP mappings. The simplest is to statically configure every router in the domain with the same info ✨. But static config doesn't scale well. And unless it's paired with Anycast-RP (see [8] and [9]), it doesn't automatically adapt to route around router or link failures 😭.
The BSR mechanism gives you a way to create viable group-to-RP mappings and spread them quickly to all the PIM routers in a domain 🔥. It's adaptive: if an RP becomes unreachable, that gets detected and the RP-Sets get modified so the unreachable RP stops being used 👑.
1.2. Protocol Overview ✨
okay so this bit is the chill, not-totally-official overview of BSR 💅 the real spec doesn't start until section 2, so think of this as the trailer 🎬
the big idea is that some PIM routers in a PIM domain get set up as potential RPs for the domain. we call those Candidate-RPs (C-RPs) 🧚 only some of the C-RPs end up as the actual RPs. some other PIM routers get set up as candidate bootstrap routers, called Candidate-BSRs (C-BSRs) 👑 one of those C-BSRs gets elected as the bootstrap router (BSR) for the domain, and every PIM router in the domain finds out who won through Bootstrap messages. then the C-RPs tell the elected BSR they're available. the BSR picks a subset of them and sends out the group-to-RP mappings to all the routers in the domain, again through Bootstrap messages 🫶
in more detail, there are four basic phases (in practice they can all be happening at the same time, which is very chaotic but very real 😭):
- BSR Election. Each Candidate-BSR originates Bootstrap messages (BSMs). Every BSM contains a BSR Priority field. Routers in the domain flood the BSMs throughout the domain. A C-BSR that hears about a higher-priority C-BSR than itself suppresses its sending of further BSMs for some period of time. The single C-BSR that's left becomes the elected BSR, and its BSMs tell all the other routers in the domain that it's the elected BSR 👑
- C-RP Advertisement. Each Candidate-RP in a domain sends periodic Candidate-RP-Advertisement (C-RP-Adv) messages to the elected BSR. A C-RP-Adv message includes the priority of the advertising C-RP, plus a list of group ranges the candidacy is advertised for. this is how the BSR learns about possible RPs that are up and reachable right now 👀
- RP-Set Formation. The BSR selects a subset of the C-RPs it got C-RP-Adv messages from to form the RP-Set. generally, it should do this so the RP-Set isn't so big that the routers in the domain can't all be informed about it, and isn't so small that the load gets overly concentrated on a few RPs 🍓 it should also try to make an RP-Set that doesn't change often ✨
- RP-Set Flooding. In future Bootstrap messages, the BSR includes the RP-Set information. Bootstrap messages get flooded through the domain, which makes sure the RP-Set quickly reaches all the routers in the domain 🚀 BSMs are originated periodically so everything stays consistent after a failure gets restored 🩹
when a PIM router gets a Bootstrap message, it adds the group-to-RP mappings in there to its pool of mappings from other sources (for example, static configuration). then it works out the final mappings of group addresses to RP addresses from that pool, following rules specific to the particular routing protocol, and uses that to build its multicast distribution trees 🌳
okay now the drama 🎭 if a PIM domain gets partitioned, each area cut off from the old BSR elects its own BSR, and each of those distributes an RP-Set with the RPs reachable inside that partition. when the partition heals, another election happens automatically and only one of the BSRs keeps sending out Bootstrap messages. during a partition or a heal, some disruption in packet delivery is expected to happen, which is giving "we knew this would happen" energy 😭 the length of the disruption is on the order of the region's round-trip time and the BS_Timeout value 💀
1.3. Administrative Scoping and BSR 🦋
the mechanism from the last section doesn't work when the PIM domain is split into administratively scoped regions. to handle that, we use the protocol changes described in this section 🎀
for the rest of this document, we'll say "scope zone," or just "zone," when we mean a connected region of topology at a given scope. for a more precise definition of scope zones, see [4], which stresses that scope zones are administratively configured 🌸
administrative scoping lets a PIM domain be divided into multiple admin-scope zones. each admin-scope zone is a convex connected set of PIM routers and is linked to a set of group addresses. the edge of an admin-scope zone is formed by Zone Border Routers (ZBRs). ZBRs are configured not to forward traffic for any of the scoped group addresses into or out of the scoped zone. super important: a given scope boundary always creates at least two scoped zones, one on each side 🙈
in IPv4, admin-scoped zones are tied to a set of addresses given by an address and a prefix length. in IPv6, they're tied to a set of addresses given by a single scope ID value. the set of addresses for a given scope ID value is defined in [5]. for example, a scope ID of 5 maps to the 16 IPv6 address ranges ff[0-f]5::/16 💜
there are some topological rules for admin-scope zones 🧐 the scope zone border must be complete and convex. what that means is there must be no path from the inside to the outside of the scoped zone that skips a configured scope border router, and the multicast capable path between any two multicast routers in the scope zone must stay in the zone.
administrative scoping makes BSR more complicated, because we don't want a PIM router inside a scoped zone to use an RP outside that zone 😤 so we have to modify the basic mechanism so that doesn't happen.
here's the fix: we run a separate copy of the basic BSR mechanism (from the previous section) inside each admin-scope zone of a PIM domain. so a separate BSR election happens for each admin-scope zone, a C-RP usually registers with the BSR of every admin-scope zone it's in, and every PIM router receives Bootstrap messages for every scope zone it's in. the Bootstrap messages a BSR sends for a particular scope zone have info about the RPs that should be used for the addresses tied to that zone 🌈
Bootstrap messages are marked to show which scope zone they belong to. those admin-scoped Bootstrap messages get flooded the normal way, but a ZBR won't forward them across the boundary of that scope zone 🚧
for BSR to work correctly with admin scoping, there must be at least one C-BSR inside each admin-scope zone, and there must be at least one C-RP configured as a C-RP for the set of group addresses tied to the scoped zone 🫶
even with admin scoping in use, a copy of the BSR mechanism still runs across the entire PIM domain, so RP info gets distributed for groups that aren't administratively scoped. we call this copy the non-scoped BSR. the copies that run for each admin-scope zone are called scoped BSR 🍰
only the C-BSRs and the ZBRs need to be configured to know the scope zones exist. everyone else, including the C-RPs, learns about them from Bootstrap messages ✨
all PIM routers in a PIM bootstrap domain that use admin-scope ranges must be able to receive Bootstrap messages and store the winning BSR and RP-Set for all the admin-scope zones that apply. so PIM routers that only implement RFC 2362, or only non-scoped BSR (which allows just one BSR per domain), can't be used inside the admin-scope zones of a PIM domain 🙅♀️ it's giving "you need the upgrade" energy 😭
2. BSR State and Timers 🧠
a PIM router implementing BSR holds the following state. it's a lot, but it's giving very organized 💅
RP-Set
Per Configured or Learned Scope Zone (Z):
At all routers:
Current Bootstrap Router's IP Address
Current Bootstrap Router's BSR Priority
Last BSM received from current BSR
Bootstrap Timer (BST(Z))
Per group-to-RP mapping (M):
Group-to-RP mapping Expiry Timer (GET(M,Z))
At a Candidate-BSR for Z:
My state: One of "Candidate-BSR", "Pending-BSR",
"Elected-BSR"
At a router that is not a Candidate-BSR for Z:
My state: One of "Accept Any", "Accept Preferred"
Scope-Zone Expiry Timer (SZT(Z))
At the current Bootstrap Router for Z only:
Per group-to-C-RP mapping (M):
Group-to-C-RP mapping Expiry Timer (CGET(M,Z))
At a C-RP only:
C-RP Advertisement Timer (CRPT)3. Bootstrap Router Election and RP-Set Distribution 🗳️
3.1. Bootstrap Router Election 👑
for simplicity, Bootstrap messages are used in both the BSR election and the RP-Set distribution mechanisms. one tool, two jobs, very efficient 🧚
each Bootstrap message says which scope it belongs to. if the Admin Scope Zone bit is set in the first group range in the Bootstrap message, the message is called a scoped BSM. if the Admin Scope Zone bit is not set in the first group range, the message is called a non-scoped BSM 🎀
in a scoped IPv4 BSM, the scope is given by the first group range in the message, which can be any sub-range of 224/4. in a scoped IPv6 BSM, the scope is given by the scope ID of the first group range, which must have a mask length of at least 16. for example, a group range of ff05::/16 with the Admin Scope Zone bit set means the Bootstrap message is for the scope with scope ID 5. if the mask length of the first group range in a scoped IPv6 BSM is less than 16, the message MUST be dropped and a warning SHOULD be logged 🚨 no cap, that one matters.
the state machine for Bootstrap messages depends on whether a router has been configured as a Candidate-BSR for a particular scope zone. the per-scope-zone state machine for a C-BSR is shown below, followed by the one for a router that isn't configured as a C-BSR 🔥
a key part of the election is that we attach a weight to each BSR 🫶 the weight of a BSR is defined as the concatenation, in fixed-precision unsigned arithmetic, of the BSR Priority field from the Bootstrap message and the IP address of the BSR from the Bootstrap message. the BSR Priority takes the most-significant bits and the IP address takes the least-significant bits. so priority is the first thing that matters, and the address is the tiebreaker, iykyk 😭💖
3.1.1. Per-Scope-Zone Candidate-BSR State Machine 🎀
Okay, bestie, this is the state machine a router runs for each scope zone when it's a Candidate-BSR. Read the tables like a little flowchart: each column is an event that can happen, and each cell says where the router goes next and what it does. 💅
+-------------------------------------------------------------------+
| When in C-BSR state |
+----------+-----------------+-------------------+------------------+
| Event | Receive | Bootstrap | Receive Non- |
| | Preferred BSM | Timer Expires | preferred BSM |
| | | | from Elected |
| | | | BSR |
+----------+-----------------+-------------------+------------------+
| | -> C-BSR state | -> P-BSR state | -> P-BSR state |
| | Forward BSM; | Set Bootstrap | Forward BSM; |
| Action | Store RP-Set; | Timer to | Set Bootstrap |
| | Set Bootstrap | BS_Rand_Override | Timer to |
| | Timer to | | BS_Rand_Override |
| | BS_Timeout | | |
+----------+-----------------+-------------------+------------------+
+-------------------------------------------------------------------+
| When in P-BSR state |
+-----------+------------------+------------------+-----------------+
| Event | Receive | Bootstrap | Receive Non- |
| | Preferred BSM | Timer Expires | preferred BSM |
+-----------+------------------+------------------+-----------------+
| | -> C-BSR state | -> E-BSR state | -> P-BSR state |
| | Forward BSM; | Originate BSM; | Forward BSM |
| Action | Store RP-Set; | Set Bootstrap | |
| | Set Bootstrap | Timer to | |
| | Timer to | BS_Period | |
| | BS_Timeout | | |
+-----------+------------------+------------------+-----------------+
+-------------------------------------------------------------------+
| When in E-BSR state |
+-----------+------------------+------------------+-----------------+
| Event | Receive | Bootstrap | Receive Non- |
| | Preferred BSM | Timer Expires | preferred BSM |
+-----------+------------------+------------------+-----------------+
| | -> C-BSR state | -> E-BSR state | -> E-BSR state |
| | Forward BSM; | Originate BSM; | Originate BSM; |
| Action | Store RP-Set; | Set Bootstrap | Set Bootstrap |
| | Set Bootstrap | Timer to | Timer to |
| | Timer to | BS_Period | BS_Period |
| | BS_Timeout | | |
+-----------+------------------+------------------+-----------------+A Candidate-BSR can be in one of three states for a particular scope zone. ✨
Candidate-BSR (C-BSR) The router wants to be the BSR for the scope zone, but right now some other router is the preferred BSR. 🌸
Pending-BSR (P-BSR) The router wants to be the BSR for the scope zone. Nobody else is the preferred BSR right now, but this router isn't the elected BSR yet either. This is a temporary state that stops the choice of BSR from thrashing back and forth during the election. 🦋
Elected-BSR (E-BSR) The router is the elected BSR for the scope zone, so it has to do all of the BSR jobs. 👑
There's also one timer in the mix. 🧚
- The Bootstrap Timer (BST): used to clear out old bootstrap router information, and used in the election to end the P-BSR state.
The starting state for a configured scope zone is "Pending-BSR", and the Bootstrap Timer gets set to BS_Rand_Override. This happens whether the router is a Candidate-BSR from the moment it starts up or it's reconfigured into one later. 💖
3.1.2. Per-Scope-Zone State Machine for Non-Candidate-BSR Routers 🌈
This state machine is for scope zones the router learns about from bootstrap messages. Scope zones that are set up explicitly on the router, plus the global zone, get a simpler version, and the differences are listed at the end of this section. 🍓
+-------------------------------------------------------------------+
| When in NoInfo state |
+--------------+----------------------------------------------------+
| Event | Receive BSM |
+--------------+----------------------------------------------------+
| | -> AP state |
| Action | Forward BSM; Store RP-Set; |
| | Set Bootstrap Timer to BS_Timeout |
+--------------+----------------------------------------------------+
+-------------------------------------------------------------------+
| When in Accept Any state |
+-------------+---------------------------+-------------------------+
| Event | Receive BSM | Scope-Zone Expiry |
| | | Timer Expires |
+-------------+---------------------------+-------------------------+
| | -> AP state | -> NoInfo state |
| | Forward BSM; Store | Remove scope zone |
| Action | RP-Set; Set | state |
| | Bootstrap Timer to | |
| | BS_Timeout | |
+-------------+---------------------------+-------------------------+
+-------------------------------------------------------------------+
| When in Accept Preferred state |
+---------+---------------------+------------------+----------------+
| Event | Receive Preferred | Bootstrap | Receive Non- |
| | BSM | Timer Expires | preferred BSM |
+---------+---------------------+------------------+----------------+
| | -> AP state | -> AA state | -> AP state |
| | Forward BSM; Store | Refresh RP- | |
| Action | RP-Set; Set | Set; Remove | |
| | Bootstrap Timer to | BSR state; Set | |
| | BS_Timeout | SZT to | |
| | | SZ_Timeout | |
+---------+---------------------+------------------+----------------+A router that isn't a Candidate-BSR can be in one of three states. 🦄
NoInfo The router knows nothing about this scope zone. In this state, no state info is stored and no timers for this scope zone are running. The state machine only really shows up when the router gets a scoped BSM for a scope it's never heard of. But since the router goes straight into the AA state no matter what, NoInfo kind of exists only in theory, which is why it isn't drawn in section 2. 🙈
Accept Any (AA) The router doesn't know of an active BSR, so it takes the first Bootstrap message it sees as the new BSR's identity and RP-Set. 🎯
Accept Preferred (AP) The router knows who the current BSR is and is using the RP-Set that BSR gave it. Only Bootstrap messages from that BSR, or from a C-BSR with higher weight than the current BSR, get accepted. 👑
There are two timers here. ⭐
- The Bootstrap Timer (BST): used to clear out old bootstrap router information.
- The Scope-Zone Expiry Timer (SZT): used to time out the scope zone itself when Bootstrap messages for it stop showing up.
The starting state for scope zones the router has no knowledge of is "NoInfo".
The state machine for explicitly configured scopes, plus the global scope (which always exists), is different from the one above in two ways. 🫶
- The "NoInfo" state doesn't exist.
- No SZT is kept. So the "Scope-Zone Expiry Timer Expires" event doesn't exist, and nothing happens with that timer.
The starting state for this state machine is "Accept Any". 💜
3.1.3. Bootstrap Message Processing Checks 🔍
Whenever a Bootstrap message comes in, the router has to run a bunch of initial checks first, and this is the order they go in. 🧚
if ((DirectlyConnected(BSM.src_ip_address) == FALSE) OR
(we have no Hello state for BSM.src_ip_address)) {
drop the Bootstrap message silently
}
if (BSM.dst_ip_address == ALL-PIM-ROUTERS) {
if (BSM.no_forward_bit == 0) {
if (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address)) {
drop the Bootstrap message silently
}
} else if ((any previous BSM for this scope has been accepted) OR
(more than BS_Period has elapsed since startup)) {
#only accept no-forward BSM if quick refresh on startup
drop the Bootstrap message silently
}
} else if ((Unicast BSM support enabled) AND
(BSM.dst_ip_address is one of my addresses)) {
if ((any previous BSM for this scope has been accepted) OR
(more than BS_Period has elapsed since startup)) {
#the packet was unicast, but this wasn't
#a quick refresh on startup
drop the Bootstrap message silently
}
} else {
drop the Bootstrap message silently
}
if (the interface the message arrived on is an admin scope
border for the BSM.first_group_address) {
drop the Bootstrap message silently
}Here's the big picture, bestie. ✨ The packet has to come from a directly connected neighbor that we have active Hello state for, and it has to be sent to the ALL-PIM-ROUTERS group. Unless it's a No-Forward BSM, it also has to come from the correct upstream router heading toward the BSR that started the Bootstrap message. If it is a No-Forward BSM, then we need to have restarted recently and have no BSR state for that admin scope. 🌸
Unicast BSMs are a separate case. If unicast BSM support is turned on, a unicast BSM only gets accepted when it's addressed to us, we've restarted recently, and we have no BSR state for that admin scope. 🦋
Last but not least, the message can't have arrived on an interface that's a configured admin-scope border for the first group address inside the Bootstrap message. Any of these failing means the message gets dropped silently, no drama. 🫧
3.1.4. State Machine Transition Events ✨
okay so if a Bootstrap message gets past the initial checks above without being discarded, it may cause a state transition event in one of the state machines above 💅 for both candidate and non-candidate BSRs, these transition events are defined:
- Receive Preferred BSM 🎀 A Bootstrap message comes in from a BSR with weight higher than or equal to the current BSR's. If a router is in P-BSR state, it uses its own weight as the current BSR's weight.
A Bootstrap message also counts as preferred if it's from the current BSR with a lower weight than the previous BSM it sent, as long as (if the router is a Candidate-BSR) the current BSR still has weight higher than or equal to the router's own. In this case the "Current Bootstrap Router's BSR Priority" state must be updated. (For lower weight, see the Non-preferred BSM from Elected BSR case.) 🫶
- Receive Non-preferred BSM 🙈 A Bootstrap message comes in from a BSR other than the current BSR, and that BSR has lower weight than the current BSR. If a router is in P-BSR state, it uses its own weight as the current BSR's weight.
- Receive Non-preferred BSM from Elected BSR 💀 A Bootstrap message comes in from the elected BSR, but the BSR Priority field in it has changed, so the currently elected BSR now has lower weight than the router itself. 😭
- Receive BSM 🧚 A Bootstrap message comes in, regardless of BSR weight. no cap, it's the catch-all ✨
On top of the transitions caused by receiving Bootstrap messages, a state machine transition also happens every time the Bootstrap Timer or the Scope-Zone Expiry Timer expires. iykyk 🦋
3.1.5. State Machine Actions 🌸
The state machines have actions, and those include setting the Bootstrap Timer and the Scope-Zone Expiry Timer to different values. Those values are defined in section 5 💖
Besides setting and cancelling timers, these actions can get triggered when the state machines change state:
- Forward BSM 🔥 A multicast Bootstrap message with the No-Forward bit cleared, that passes the Bootstrap Message Processing Checks, gets forwarded out of every interface with PIM neighbors (including the one it came in on). The exception is when that would make the BSM cross an admin-scope boundary for the scope zone named in the message. For the full details, see section 3.4 🧚
- Originate BSM 👑 The BSR builds a brand-new Bootstrap message that has its own address and BSR priority, plus its chosen RP-Set. The message goes out of every interface where PIM neighbors exist, with the same exception: it can't cross an admin-scope boundary for the scope zone named in the message. 🌈
- Store RP-Set 🍓 The router uses the group-to-RP mappings in a BSM to update its local RP-Set.
This action gets skipped for an empty BSM. A BSM is empty if it has no group ranges, or if it has only one group range where the Admin Scope Zone bit is set (a scoped BSM) and an RP count of zero. 🙃
If a mapping doesn't exist yet, it gets created, and its Group-to-RP mapping Expiry Timer (GET) is initialized with the holdtime from the BSM. ✨
If a mapping already exists, its GET gets set to the holdtime from the BSM. If that holdtime is zero, the mapping is removed right away. Also, for an existing mapping, the RP priority must be updated if it changed. 💅
Mappings for a group range also get removed immediately if they aren't in the received group range. So if there are existing group-to-RP mappings for a range where the RPs aren't in the received range, those mappings must be removed. no exceptions, bestie 😭
Every RP mapping tied to the BSM's scope zone gets updated with the new hash mask length from the received BSM. That includes RP mappings for all group ranges learned for this zone, not just the ranges in this one BSM. 🔥
On top of all that, the entire BSM is stored, so it can be used by the Refresh RP-Set action and to prime a new PIM neighbor (more on that below). 🫶
- Refresh RP-Set 🦋 When the Bootstrap Timer expires, the router takes the copy of the last BSM it received and refreshes its RP-Set using the Store RP-Set action, as if it had just received it. This raises the odds that the group-to-RP mappings won't expire while the new BSR is being elected. literally a lifesaver 🥹
- Remove BSR state 🥀 When the Bootstrap Timer expires, all the state tied to the current BSR gets removed: the address, the priority, the BST, and the saved last BSM (see section 2). This does not include any group-to-RP mappings. 💜
- Remove scope zone state 🧹 When the Scope-Zone Expiry Timer expires, all the state tied to that scope zone gets removed (see section 2). ✨
3.2. Sending Candidate-RP-Advertisement Messages 🎀
Every C-RP periodically unicasts a C-RP-Adv message to the BSR for each scope zone it has state for, to tell the BSR it's willing to function as an RP. These messages go out at an interval of C_RP_Adv_Period, except when a new BSR gets elected (more on that below) 🌸
When a new BSR is elected, the C-RP MUST send one to three C-RP-Adv messages, waiting a small randomized period, C_RP_Adv_Backoff, before sending each one. We recommend sending three because it's really important that the BSR quickly learns which RPs are active, and some packet loss may happen when a new BSR is elected due to network changes. One way to do it is to set the CRPT to C_RP_Adv_Backoff when the new BSR is elected, and also set a counter to 2. Whenever the CRPT expires, first send a C-RP-Adv message as usual. Then, if the counter is non-zero, decrement it and set the CRPT to C_RP_Adv_Backoff again instead of C_RP_Adv_Period. it's giving clockwork 🧚⏰
The Priority field in these messages is what the BSR uses to pick which C-RPs go in the RP-Set. Lower values mean higher priority, so a value of zero is the highest possible priority 👑 By default, C-RPs should send C-RP-Adv messages with the Priority field set to 192. ✨
When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv message to the BSR for each scope zone where it's currently serving as an RP. The Holdtime in that C-RP-Adv message should be zero. Then the BSR immediately times out the C-RP and generates a new Bootstrap message with the shut-down RP's holdtime set to 0. bye bye, RP 👋💀
A C-RP-Adv message carries a list of group address and group mask field pairs. That's how the C-RP says which group ranges it's willing to be the RP for. If the C-RP does become an RP, it may enforce this scope acceptance when it receives Register or Join/Prune messages. main character energy 🌈
A C-RP is configured with a list of group ranges it should advertise itself for, and it uses the algorithm below to figure out which ranges to send to a given BSR 🔥
For each group range R in the list, the C-RP advertises that range to the scoped BSR for the smallest scope that "contains" R. For IPv6, the containing scope is found by matching the scope identifier of the group range with the scope of the BSR. For IPv4, it's the longest-prefix match for R among the known admin-scope ranges. If no scope contains the group range, the C-RP includes it in the C-RP-Adv sent to the non-scoped BSR. If a non-scoped BSR isn't known, the range isn't included in any C-RP-Adv. 🧩
Also, for each IPv4 group range R in the list, for each scoped BSR whose scope range is strictly contained within R, the C-RP SHOULD by default advertise that BSR's scope range to that BSR. And for each IPv6 group range R in the list with a prefix length less than 16, the C-RP SHOULD by default advertise each sub-range of prefix length 16 to the scoped BSR with the matching scope ID. An implementation MAY supply a configuration option to prevent the behavior described in this paragraph, but such an option SHOULD be disabled by default. ⭐
For IPv6, the mask length of all group ranges in a C-RP-Adv message sent to a scoped BSR MUST be greater than or equal to 16. 💜
If the algorithm above finds no group ranges to advertise to the BSR for a particular scope zone, a C-RP-Adv message MUST NOT be sent to that BSR. A C-RP MUST NOT send a C-RP-Adv message with no group ranges in it. no empty messages allowed, periodt 🙅♀️
If the same router is the BSR for more than one scope zone, the C-RP-Adv messages for those scope zones MAY be combined into a single message. 🫶
If the C-RP is a ZBR for an admin-scope zone, the Admin Scope Zone bit MUST be set in the C-RP-Adv messages it sends for that scope zone. Otherwise, this bit MUST NOT be set. Right now the BSR only uses this info for logging purposes, but it might allow for future extensions of the protocol 🔮✨
3.3. Creating the RP-Set at the BSR 🎀
Okay so, when a router gets a C-RP-Adv message, it has to decide whether to accept each group range in it. For every group range, it checks if it's the elected BSR for any scope zone that contains that range, or if it's the elected non-scoped BSR. If yes, the range is accepted. If no, it gets ignored. Bestie, it's giving gatekeeper energy 💅
For security reasons, we recommend that implementations have a way to restrict which IP addresses the BSR accepts C-RP-Adv messages from, like access lists 🔒 For a scoped BSR, it may also be useful to specify which group ranges should be accepted ✨
If a group range is accepted, a group-to-C-RP mapping gets created for that range and the RP Address from the C-RP-Adv message.
If the mapping isn't already in the C-RP-Set, it gets added, and its Group-to-C-RP mapping Expiry Timer (CGET) is set to the holdtime from the C-RP-Adv message. Its priority is set to the Priority from that message 🌸
If the mapping is already in the C-RP-Set, it gets updated with the Priority from the C-RP-Adv message, and its CGET resets to the holdtime from that message. If the holdtime is zero, the mapping is removed from the C-RP-Set right away. Byeee 👋
The hash mask length is a global property of the BSR, so it's the same for every mapping the BSR manages 🦋
For compatibility with the previous version of the BSR specification, a C-RP-Adv message with no group ranges SHOULD be treated as though it contained the single group range ff00::/8 or 224/4. So, following the rule above, that group range gets accepted if and only if the router is the elected non-scoped BSR 🧚
When a CGET expires, the matching group-to-C-RP mapping is removed from the C-RP-Set. Gone, no cap 💀
The BSR builds the RP-Set from the C-RP-Set. It may apply a local policy to limit how many Candidate-RPs go into the RP-Set. The BSR may override the range indicated in a C-RP-Adv message, unless the Priority field from that message is less than 128 🍓
If the BSR learns about both BIDIR and PIM-SM Candidate-RPs for the same group range, it MUST only include RPs for one of the protocols in the BSMs. The default behavior SHOULD be to prefer BIDIR 💜
For inclusion in a BSM, the RP-Set gets split up into sets of {group-range, RP-Count, RP-addresses}. For each RP-address, the RP-Holdtime field is set to the Holdtime from the C-RP-Set, with a catch: it MUST be larger than BS_Period, and it SHOULD be larger than 2.5 times BS_Period to allow for some Bootstrap messages getting lost 🫶 If some holdtimes from the C-RP-Sets don't meet this constraint, the BSR MUST replace them with a value that does. The one exception is a holdtime of zero, which is used to immediately withdraw mappings 🙈
The Bootstrap message format allows "semantic fragmentation" if the original Bootstrap message is longer than the packet maximum boundaries. To keep the semantic fragmentation down, though, we recommend against configuring a large number of routers as C-RPs 😭
Normally, BSMs get originated at regular intervals according to the BS_Period timer. We also recommend originating a BSM whenever the RP-set to be announced in the BSMs changes. That usually happens when C-RP advertisements arrive from a new C-RP, or when a C-RP shuts down (a C-RP-Adv with a holdtime of zero). There MUST however be a minimum of BS_Min_Interval between each time a BSM is sent. Specifically, when a new BSR gets elected, it first sends one BSM (probably an empty one, since it hasn't gotten any C-RP advertisements yet), then waits at least BS_Min_Interval before sending a new one. During that wait, it's likely to have heard from all the usable C-RPs, since a C-RP should send one or more advertisements with small random delays of C_RP_Adv_Backoff when a new BSR gets elected 🌈 For this case in particular, where routers may not have a usable RP-set yet, we recommend originating a BSM as soon as BS_Min_Interval has passed. We suggest a BSR can do this in general too. One way to implement it is to decrease the Bootstrap Timer to BS_Min_Interval whenever the RP-set changes, while leaving the timer alone if it's already less than or equal to BS_Min_Interval ⭐
A BSR originates separate scoped BSMs for each scope zone it's the elected BSR for, and it also originates non-scoped BSMs if it's the elected non-scoped BSR 👑
Each group-to-C-RP mapping goes into precisely one of these BSMs. That's the scoped BSM for the narrowest scope containing the mapping's group range, if there is one. Otherwise it goes in the non-scoped BSM 🦋
A scoped BSM MUST have at least one group range, and the first group range in a scoped BSM MUST have the Admin Scope Zone bit set. That group range identifies the scope of the BSM. In a scoped IPv4 BSM, the first group range is the range corresponding to the scope of the BSM. In a scoped IPv6 BSM, the first group range can be any group range, subject to the general condition that all the group ranges in such a BSM MUST have a mask length of at least 16 and MUST have the same scope ID as the scope of the BSM 🌸
Apart from identifying the scope, the first group range in a scoped BSM gets treated like any other range when it comes to RP mappings. That means all mappings in the RP-set for this group range, if there are any, must be included in this first group range in the BSM. After that first range, the other group ranges in this scope (the ones with RP mappings) can show up in any order ✨
The Admin Scope Zone bit of every group range other than the first SHOULD be set to 0 on origination, and it MUST be ignored on receipt 🎀
When an elected BSR is being shut down, it should immediately originate a Bootstrap message that lists its current RP-Set, but with the BSR Priority field set to the lowest priority value possible. That makes the election of a new BSR happen faster 🏃♀️💨
3.4. Forwarding Bootstrap Messages 🦋
Generally, bootstrap messages originate at the BSR, and intermediate routers forward them hop-by-hop if they pass the Bootstrap Message Processing Checks. There are two exceptions. First, a bootstrap message isn't forwarded if its No-Forward bit is set; see section 3.5.1. Second, unicast BSMs (see section 3.5.2) are usually not forwarded. Implementers MAY, however, at their own discretion, choose to re-send a No-Forward or unicast BSM in a multicast BSM, which MUST have the No-Forward bit cleared. It's essential that the No-Forward bit is cleared, since no Reverse Path Forwarding (RPF) check gets performed by the receiver when it's set 🚨
When we say hop-by-hop forwarding, we mean the Bootstrap message itself gets forwarded, not the entire IP packet. Each hop builds an IP packet for each interface the BSM is going out of, and each packet contains the entire BSM that was received 🧚
When a Bootstrap message is forwarded, it goes out of every multicast-capable interface that has PIM neighbors, including the one it came in on. The exception is if the interface is an admin-scope boundary for the admin-scope zone named in the first group range of the Bootstrap message packet 💅
As an optimization, a router MAY choose not to forward a BSM out of the interface it was received on, if that interface is a point-to-point interface. On interfaces with multiple PIM neighbors, a router SHOULD forward an accepted BSM out of the interface it was received on. But if the number of PIM neighbors on that interface is large, the router MAY delay forwarding the BSM out of that interface by a small randomized interval to prevent message implosion 🌈 A configuration option MAY be provided to disable forwarding out of the interface a message was received on, but we recommend the default behavior is to forward out of that interface 🫶
Rationale: A BSM needs to be forwarded out of the interface it was received on (in addition to the other interfaces) because the routers on a LAN may not have consistent routing information. Say three routers on a LAN are A, B, and C, and at router B, RPF(BSR)==A, while at router C, RPF(BSR)==B. Then router A originally forwards the BSM onto the LAN, but router C will only accept it when router B re-forwards the message onto the LAN. If the underlying routing protocol configuration guarantees that the routers have consistent routing information, then forwarding out of the incoming interface may safely be disabled 🤓
A ZBR constrains all BSMs that are of equal or smaller scope than the configured boundary. That means the BSMs are not accepted from, originated on, or forwarded on the interfaces where the boundary is configured. For IPv6, the check compares the scope of the first range in the scoped BSM with the scope of the configured boundary. For IPv4, the first range in the scoped BSM is checked to see if it's contained in, or is the same as, the range of the configured boundary 💖
3.5. Bootstrap Messages to New and Rebooting Routers 🧚
When a Hello message comes in from a new neighbor, or a Hello message with a new GenID comes in from an existing neighbor, one router on the LAN sends a stored copy of the Bootstrap message for each admin-scope zone to the new or rebooting router. This lets new or rebooting routers learn the RP-Set quickly ⚡
This message SHOULD be sent as a No-Forward Bootstrap message; see section 3.5.1. For backwards compatibility, this message MAY instead, or in addition, be sent as a unicast Bootstrap message; see section 3.5.2. These messages MUST only be accepted at startup; see section 3.1.3 🛑
The router that does this is the Designated Router (DR) on the LAN. Or, if the new or rebooting router is the DR, it's the router that would be the DR if the new or rebooting router were excluded from the DR election process 👑
Before sending a Bootstrap message this way, the router must wait until it has sent a triggered Hello message on this interface. Otherwise, the new neighbor will discard the Bootstrap message, and nobody wants that 😭
3.5.1. No-Forward Bootstrap Messages 🙈
A No-Forward Bootstrap message is a bootstrap message that has the No-Forward bit set. All implementations SHOULD support sending No-Forward Bootstrap messages, and they SHOULD also accept them. The RPF check MUST NOT be performed in the BSM processing check for a No-Forward BSM; see section 3.1.3. These messages use the same source and destination addresses as the usual multicast Bootstrap messages 🍓
3.5.2. Unicasting Bootstrap Messages 💌
For backwards compatibility, implementations MAY support unicast Bootstrap messages. Whether to send unicast Bootstrap messages instead of or in addition to No-Forward Bootstrap messages, and whether to accept such messages, SHOULD be configurable. This message is unicast to the neighbor 🦋
3.6. Receiving and Using the RP-Set ✨
okay so the RP-Set the BSR keeps is what RP-based multicast routing protocols like PIM-SM and BIDIR-PIM actually run on 🫶 they can also get RP-Sets from other places. How the final group-to-RP mappings get worked out from these RP-Sets is NOT part of the BSR spec, so that's a whole other vibe 💅 Routing protocols generally need to recalculate their mappings whenever an RP-Set changes. How that change gets signalled to the routing protocol isn't in this spec either 🌸
Some group-to-RP mappings are for PIM-SM group ranges, and others are for BIDIR-PIM ranges 🦋 Routers that only support one of these protocols MUST NOT ignore the ranges marked for the other protocol. They also MUST NOT treat those ranges as belonging to the protocol they do support. Don't be that router, bestie 😭
If a mapping isn't in the RP-Set yet, it gets added, its Group-to-RP mapping Expiry Timer (GET) is set to the holdtime from the Bootstrap message, and its priority is set to the Priority from the Bootstrap message ⏰✨
If a mapping is already in the RP-Set, it gets updated with the Priority from the Bootstrap message and its GET is reset to the holdtime from the Bootstrap message. If the holdtime is zero, the mapping is removed from the RP-Set right away. Bye bye 👋💀
4. Message Formats 🎀
BSR messages are PIM messages, as defined in [1]. The values of the PIM Message Type field for BSR messages are:
4 Bootstrap
8 Candidate-RP-AdvertisementSame as every other PIM control message, BSR messages have IP protocol number 103 🧚
Candidate-RP-Advertisement messages are unicast to a BSR. Usually, Bootstrap messages are multicast with TTL 1 to the ALL-PIM-ROUTERS group, but in some situations (described in section 3.5.2) Bootstrap messages may be unicast to a specific PIM neighbor 💌
The IP source address used for Candidate-RP-Advertisement messages is a domain-wide reachable address. The IP source address used for Bootstrap messages (whether they're being originated or forwarded) is the link-local address of the interface the message is sent on, which is the same source address the router uses for the Hello messages it sends out that interface 🫧
The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS group is ff02::d 🌈
In this section, we use the following terms defined in the PIM-SM specification [1]:
- Encoded-Unicast format
- Encoded-Group format
We repeat these here to aid readability, because we love a good refresher 💜
Encoded-Unicast address
An Encoded-Unicast address takes the following format:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...Addr Family: this is the PIM address family of the 'Unicast Address' field. Values 0-127 are assigned by IANA for Internet Address Families in [11]. Values 128-250 are reserved for IANA to assign for PIM-specific Address Families. Values 251 through 255 are for private use. Since there's no assignment authority for that space, collisions should be expected 😬
Encoding Type: the type of encoding used within a specific Address Family. The value 0 is reserved for this field and represents the native encoding of the Address Family 🍓
Unicast Address: the unicast address, as represented by the given Address Family and Encoding Type 🦋
Encoded-Group address
Encoded-Group addresses take the following format:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type |B| Reserved |Z| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...Addr Family: described above 🔁
Encoding Type: described above 🔁
[B]IDIR bit: when set, all BIDIR-capable PIM routers will run the protocol described in [2] for the specified group range 🌊
Reserved: transmitted as zero, and ignored on receipt 🤍
Admin Scope [Z]one: when set, this bit says the group range is an administratively scoped range 🔒
Mask Len: the Mask length field is 8 bits. The value is the number of contiguous one bits that are left justified and used as a mask. When combined with the group address, it describes a range of groups. It's less than or equal to the address length in bits for the given Address Family and Encoding Type. If the message is sent for a single group, the Mask length must equal the address length in bits for the given Address Family and Encoding Type (for example, 32 for IPv4 native encoding and 128 for IPv6 native encoding) 🧮✨
Group multicast Address: contains the group address 🎯
4.1. Bootstrap Message Format 🎀
okay so a Bootstrap message can get chopped up into "semantic fragments" if the resulting IP datagram would be bigger than the maximum packet size boundaries 📦. Basically, one Bootstrap message can be sent as several semantic fragments (each in its own IP datagram), as long as all the fragments carry the same fragment tag 🏷️. And a message that isn't fragmented uses the exact same format as a fragment, so there's only one layout to learn 💅
here's what a single fragment looks like 👇
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type |N| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Tag | Hash Mask Len | BSR Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSR Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Count 1 | Frag RP Cnt 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1 Holdtime | RP1 Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2 Holdtime | RP2 Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm Holdtime | RPm Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 2 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address n (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Count n | Frag RP Cnt n | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1 Holdtime | RP1 Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2 Holdtime | RP2 Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm Holdtime | RPm Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PIM Version, Reserved, Checksum 🧾 Described in [1].
Type 🔢 This is the PIM Message Type. The value is 4 for a Bootstrap message.
[N]o-Forward bit 🚫 When this bit is set, the Bootstrap message fragment is not to be forwarded.
Fragment Tag 🏷️ This is a randomly generated number that tells apart the fragments from different Bootstrap messages. Fragments from the same Bootstrap message all carry the same Fragment Tag ✨
Hash Mask Len 🎭 This is the length (in bits) of the mask used in the hash function. For IPv4, we recommend a value of 30. For IPv6, we recommend a value of 126.
BSR Priority 👑 This holds the BSR priority value of the BSR that's included. This field counts as the high-order byte when BSR addresses get compared. BSRs should by default set this field to 64. Heads up: for historical reasons, the highest BSR priority is 255 (higher is better), but the highest RP Priority (see below) is 0 (lower is better). Opposite vibes, bestie 🙃
BSR Address 🏠 This is the address of the bootstrap router for the domain. Its format is the Encoded-Unicast address from [1].
Group Address 1..n 🌈 These are the group ranges (address and mask) that the Candidate-RPs are associated with. The format is described in [1]. In a fragment that has admin-scope ranges, the first group range in the fragment MUST satisfy the following conditions:
- it MUST have the Admin Scope Zone bit set;
- for IPv4, it MUST be the group range for the entire admin-scope range (this is required even if there are no RPs in the RP-Set for the entire admin-scope range. In that case, the sub-ranges for the RP-Set are specified later in the fragment, along with their RPs);
- for IPv6, the Mask Len MUST be at least 16 and have the scope ID of the admin-scope range.
RP Count 1..n 🔢 This is the number of Candidate-RP addresses included in the whole Bootstrap message for the matching group range. A router does not replace its old RP-Set for a given group range until/unless it receives 'RP-Count' addresses for that range. Those addresses could be spread across several fragments. If only part of the RP-Set for a given group range was received, the router throws it away without updating that group range's RP-Set 🗑️
Frag RP Cnt 1..m 🧩 This is the number of Candidate-RP addresses included in this fragment of the Bootstrap message, for the matching group range. The 'Frag RP Cnt' field helps with parsing the RP-Set for a given group range when it's carried over more than one fragment.
RP address 1..m 📍 These are the addresses of the Candidate-RPs for the matching group range. Their format is the Encoded-Unicast address from [1].
RP1..m Holdtime ⏳ This is the Holdtime (in seconds) for the matching RP. The value is copied from the 'Holdtime' field of the associated RP stored at the BSR.
RP1..m Priority 🥇 This is the 'Priority' of the matching RP and Encoded-Group Address. The value is copied from the 'Priority' field stored at the BSR when it receives a C-RP-Adv message. The highest priority is '0' (so unlike BSR priority, a lower 'Priority' value is better). Also, the priority is per RP and per Group Address, so it's not one-size-fits-all 💅
Within a Bootstrap message, the BSR Address, all the Group Addresses, and all the RP Addresses MUST be of the same address family. On top of that, the address family of the fields in the message MUST be the same as the IP source and destination addresses of the packet. This gives dual-stack IPv4/IPv6 routers maximum implementation flexibility 🦋
Stay consistent, bestie: one address family per message, matching the packet addresses. Mixing them up is a vibe-killer 💀
4.1.1. Semantic Fragmentation of BSMs 🧩
Bootstrap messages can be split over several PIM Bootstrap Message Fragments (BSMFs). This is called semantic fragmentation ✂️ Each of these has to follow the format above. All the fragments of a given Bootstrap message MUST have identical values for the Type, No-Forward bit, Fragment Tag, Hash Mask Len, BSR Priority, and BSR Address fields. So the only thing that can differ between fragments is the group-to-RP mappings 🌸
Why bother? If the BSM would be bigger than the MTU of the link it's going out on, you could just rely on IP fragmentation. But then losing a single IP fragment means losing the whole message 😭 With semantic fragmentation, a lost IP fragment only takes out the one semantic fragment it belonged to. As described below, a router only needs to receive all the RPs for a specific group range to update that range. So if a semantic fragment goes missing, only the group ranges that fragment contained get affected ✨
If the BSR can split the BSM so that each group range (and all of its RP information) fits entirely inside one BSMF, then it should do so. If a BSMF gets lost, the state from the previous BSM for the group ranges in the missing BSMF is kept. Every fragment that does arrive updates the RP information for the group ranges inside it, and those new group-to-RP mappings can be used right away 🚀 The info from the missing fragment comes back when the next BSM is sent.
If the list of RPs for one group range is really long, you can spread that info across multiple BSMFs so you don't end up with IP fragmentation. In this case, all the BSMFs holding info for that group range must be received before the group-to-RP mapping in use can change. That's what the RP Count field is for. A router that gets BSMFs from the same BSM (meaning they have the same fragment tag) has to wait until it has received BSMFs that provide RP Count RPs for that group range before the new group-to-RP mapping can be used for it ⏳ If a single BSMF from such a large group range gets lost, then that whole group range has to wait until the next BSM is originated. So in this case, honestly, the benefit of semantic fragmentation is pretty dubious 🙈
Now, how does a BSR remove group ranges? A router that gets a set of BSMFs can't tell whether a group range is missing. If it has seen a group range before, it has to assume that the group range still exists and that the BSMF describing it was lost. The router should keep this info for BS_Timeout. So for a BSR to remove a group range, it should include that group range with an RP Count of zero, and it should resend this info in each BSM for BS_Timeout 🧹 Main character removal energy 💅
4.2. Candidate-RP-Advertisement Message Format ✨
Okay bestie, so the C-RPs send Candidate-RP-Advertisement messages to the BSR on a regular schedule 📬. Each one is unicast, so it goes straight to the BSR. Here's the layout 👇
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Count | Priority | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address n (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PIM Version, Reserved, Checksum: these are described in [1] 📖.
Type: this is the PIM Message Type. The value is 8 for a Candidate-RP-Advertisement message 🎀.
Prefix Count: this is the number of Encoded-Group Addresses in the message, which tells you the group range the C-RP is advertising for 🌸. C-RPs MUST NOT send C-RP-Adv messages with a Prefix Count of '0'. No cap, that one is a hard rule 🙅♀️.
Priority: this is the priority of the included RP, for the matching Encoded-Group Address (if there is one) 👑. The highest priority is '0'. So the lower the Priority value, the higher the priority, which is kind of backwards but iconic. When the BSR gets the message, it stores this field along with the RP address and the Encoded-Group Address 💾.
Holdtime: this is how long (in seconds) the advertisement stays valid ⏳. That's what lets old advertisements age out. This field should be set to 2.5 times C_RP_Adv_Period.
RP Address: this is the address of the interface to advertise as a Candidate-RP 💅. The format is the Encoded-Unicast address from [1].
Group Address-1..n: these are the group ranges the C-RP is advertising 🦋. The format is the Encoded-Group-Address from [1].
Within a Candidate-RP-Advertisement message, the RP Address and all the Group Addresses MUST be of the same address family ✨. On top of that, the address family of the fields in the message MUST be the same as the IP source and destination addresses of the packet. This gives dual-stack IPv4/IPv6 routers maximum implementation flexibility, which is honestly so smart 🧚.
5. Timers and Timer Values ⏰
Timer Name: Bootstrap Timer (BST(Z))
+------------------+-------------------------+----------------------+
| Value Name | Value | Explanation |
+------------------+-------------------------+----------------------+
| BS_Period | Default: 60 seconds | Periodic interval |
| | | with which BSMs |
| | | are normally |
| | | originated |
+------------------+-------------------------+----------------------+
| BS_Timeout | Default: 130 seconds | Interval after |
| | | which a BSR is |
| | | timed out if no |
| | | BSM is received |
| | | from that BSR |
+------------------+-------------------------+----------------------+
| BS_Min_Interval | Default: 10 seconds | Minimum interval |
| | | with which BSMs |
| | | may be originated |
+------------------+-------------------------+----------------------+
| BS_Rand_Override | see below | Randomized |
| | | interval used to |
| | | reduce control |
| | | message overhead |
| | | during BSR |
| | | election |
+------------------+-------------------------+----------------------+Heads up, this timer table has the important stuff 🫶. Note that BS_Timeout MUST be larger than BS_Period, even if you change their values from the defaults. We recommend that BS_Timeout is set to 2 times BS_Period plus 10 seconds 💖.
BS_Rand_Override is calculated with the pseudocode below, where everything is in seconds 🧮. The values it spits out are between 5 and 23 seconds. You get smaller values if the C-BSR has a high bootstrap weight, and bigger values if it has a low bootstrap weight. Math girlies, this one's for you 🤓.
BS_Rand_Override = 5 + priorityDelay + addrDelay
where priorityDelay is given by:
priorityDelay = 2 * log_2(1 + bestPriority - myPriority)
and addrDelay is given by the following for IPv4:
if (bestPriority == myPriority) {
addrDelay = log_2(1 + bestAddr - myAddr) / 16
} else {
addrDelay = 2 - (myAddr / 2^31)
}
and addrDelay is given by the following for IPv6:
if (bestPriority == myPriority) {
addrDelay = log_2(1 + bestAddr - myAddr) / 64
} else {
addrDelay = 2 - (myAddr / 2^127)
}
and bestPriority is given by:
bestPriority = max(storedPriority, myPriority)
and bestAddr is given by:
bestAddr = max(storedAddr, myAddr)
and where myAddr is the Candidate-BSR's address, storedAddr is the
stored BSR's address, myPriority is the Candidate-BSR's configured
priority, and storedPriority is the stored BSR's priority.Timer Name: Scope Zone Expiry Timer (SZT(Z))
+---------------+---------------------------+-----------------------+
| Value Name | Value | Explanation |
+---------------+---------------------------+-----------------------+
| SZ_Timeout | Default: 1300 seconds | Interval after |
| | | which a scope zone |
| | | is timed out if no |
| | | BSM is received |
| | | for that scope |
| | | zone |
+---------------+---------------------------+-----------------------+Note that SZ_Timeout MUST be larger than BS_Timeout, even if you change their values from the defaults. We recommend that SZ_Timeout is set to 10 times BS_Timeout 🙌.
Timer Name: Group-to-C-RP mapping Expiry Timer (CGET(M,Z))
+------------------------+-------------------+----------------------+
| Value Name | Value | Explanation |
+------------------------+-------------------+----------------------+
| C-RP Mapping Timeout | from message | Holdtime from C- |
| | | RP-Adv message |
+------------------------+-------------------+----------------------+Timer Name: Group-to-RP mapping Expiry Timer (GET(M,Z))
+-----------------------+-------------------+-----------------------+
| Value Name | Value | Explanation |
+-----------------------+-------------------+-----------------------+
| RP Mapping Timeout | from message | Holdtime from BSM |
+-----------------------+-------------------+-----------------------+Timer Name: C-RP Advertisement Timer (CRPT)
+-------------------+------------------------+----------------------+
| Value Name | Value | Explanation |
+-------------------+------------------------+----------------------+
| C_RP_Adv_Period | Default: 60 seconds | Periodic interval |
| | | with which C-RP- |
| | | Adv messages are |
| | | sent to a BSR |
+-------------------+------------------------+----------------------+
| C_RP_Adv_Backoff | Default: 0-3 seconds | Whenever a |
| | | triggered C_RP_Adv |
| | | is sent, a new |
| | | randomized value |
| | | between 0 and 3 |
| | | is used |
+-------------------+------------------------+----------------------+6. Security Considerations 🛡️
6.1. Possible Threats
Okay, this part is serious, so read it carefully 😭. The threats against the PIM BSR mechanism come in two main flavours: denial-of-service (DoS) attacks and traffic-diversion attacks. An attacker who subverts the BSR mechanism can stop multicast traffic from reaching the intended recipients, divert multicast traffic somewhere they can watch it, and potentially flood third parties with traffic 💀.
Traffic can get blocked from reaching the intended recipients in one of two ways:
- Subverting a BSM, and specifying RPs that won't actually forward traffic.
- Registering with the BSR as a C-RP, and then not forwarding traffic.
Traffic can also be diverted to a place where it can be monitored, using either of the two methods above 👀. In this case the RPs do forward the traffic, but they're placed so that they help with monitoring or man-in-the-middle attacks on the multicast traffic.
A third party can be flooded by either of the two methods above. The attacker names the third party as the RP, and Register traffic then gets forwarded to that third party 🚨.
6.2. Limiting Third-Party DoS Attacks
The third-party DoS attack above can be greatly reduced if PIM routers acting as DR do not continue to forward Register traffic to the RP in the presence of ICMP Protocol Unreachable or ICMP Host Unreachable responses 🛑. If a PIM router sending Register packets to an RP gets one of these responses to a data packet it sent, it should rate-limit the transmission of future Register packets to that RP for a short period of time ⏸️.
As this does not affect interoperability, the precise details are left to the implementer to decide 🧑💻. However, we note that a router implementing such rate limiting must only do so if the ICMP packet correctly echoes part of a Register packet that was sent to the RP. If this check were not made, then simply sending ICMP Unreachable packets to the DR with the source address of the RP spoofed would be sufficient to cause a denial-of-service attack on the multicast traffic originating from that DR. Bestie, that's a whole vibe-killer 💔.
6.3. Bootstrap Message Security 🔐
okay bestie, real talk: if a legit PIM router in a domain gets compromised, there's basically nothing a security mechanism can do to stop it from messing with PIM traffic in that domain 😭💀. villain arc, no cap.
Implementations SHOULD provide a per-interface config option 🎛️ where you can say "no Bootstrap messages get sent out of or accepted on this interface" 🙅♀️. This should generally be set on all PMBRs so they don't receive messages from neighboring domains. That stops you from getting legit messages with conflicting BSR info from other domains, and it also blocks BSR attacks coming from neighbors 🛑. It's also handy on leaf interfaces where only hosts live. BUT the Security Considerations section of [1] says there should be a mechanism for not accepting PIM Hello messages on leaf interfaces, and that messages should only be accepted from valid PIM neighbors 🤓. There may be extra issues with unicast Bootstrap messages too (more on that below) 👀. So besides dropping all multicast Bootstrap messages on PMBRs, we also recommend configuring PMBRs (both towards other domains and on leaf interfaces) to drop all unicast PIM messages: Bootstrap message, Candidate-RP Advertisement, PIM register, and PIM register stop 💅.
6.3.1. Unicast Bootstrap Messages 📮
okay so there are some possible security issues with unicast Bootstrap messages 🙈. The Bootstrap Message Processing Checks stop a router from accepting a Bootstrap message from outside the PIM Domain, since the source address on Bootstrap messages must be an immediate PIM neighbor. BUT there's a small window of time after a reboot where a PIM router will accept a bad unicast Bootstrap message from an immediate neighbor 😬. During that interval, someone outside the domain might be able to unicast a Bootstrap message to the router, spoofing a neighbor's source address. The best way to protect against this is the mechanism we mentioned earlier: configure border and leaf interfaces to drop all Bootstrap messages, including unicast ones 🛡️. It can also be prevented if PMBRs do source-address filtering, so packets entering the PIM domain can't use IP source addresses that are infrastructure addresses in the PIM domain.
The use of unicast Bootstrap messages is for backwards compatibility only 🕰️. Because of the possible security implications, implementations supporting unicast Bootstrap messages SHOULD provide a configuration option for whether they're used at all.
6.3.2. Multi-Access Subnets 🚪
As we said above, implementations SHOULD provide a per-interface config option so leaf interfaces and interfaces facing other domains can be set to drop all Bootstrap messages. Now let's look at multi-access subnets, where you've got both multiple PIM routers in a PIM domain AND PIM routers outside the domain (or untrusted hosts) 👀. On these subnets, one should (if possible) configure the PMBRs to drop Bootstrap messages. This works as long as the routers in the PIM domain receive Bootstrap messages on other internal subnets. In other words, for each router on the multi-access subnet that's in our domain, the RPF interface for each Candidate-BSR address must be an internal interface (one that's not on a multi-access subnet) 🏠. BUT some network topologies make this impossible 😭. For those, we recommend that IPsec Authentication Header (AH) is used to protect communication between the PIM routers in the domain, and that those routers are configured to drop and log communication attempts from any nodes that fail the authentication check 🔒. When all the PIM routers are under the same administrative control, this authentication can use a configured shared secret 🤝. To prevent replay attacks, you'll need one security association (SA) per sender, and you use the sender address for SA lookup. How to secure interactions between PIM neighbors is covered in more detail in the Security Considerations section of [1], so we won't go deeper here. The same security mechanisms that can secure PIM Join, Prune, and Assert messages should also be used to secure Bootstrap messages. How exactly to secure PIM link-local messages is still being worked on by the PIM working group; see [10] 🧑💻.
6.4. Candidate-RP-Advertisement Message Security 📣
okay even if it's impossible to subvert Bootstrap messages, an attacker could still pull off most of the same attacks just by sending C-RP-Adv messages to the BSR and picking their own RPs 🙃. So we have to control who sends C-RP-Adv messages, pretty much the same way we control Bootstrap messages. The catch is that C-RP-Adv messages are unicast and usually travel multiple hops, so controlling them is harder 😤.
6.4.1. Non-Cryptographic Security of C-RP-Adv Messages 🧱
We recommend that PMBRs are configured to drop C-RP-Adv messages 🚫. You might configure PMBRs to drop all unicast PIM messages: Bootstrap message, Candidate-RP Advertisement, PIM register, and PIM register stop. PMBRs may also do source-address filtering, so packets entering the PIM domain can't use IP source addresses that are infrastructure addresses in the PIM domain. We also recommend that implementations have a way to restrict which IP addresses the BSR accepts C-RP-Adv messages from ✨. The BSR can then be configured to accept C-RP-Adv messages only from infrastructure addresses, or from the subset used for Candidate-RPs.
If the unicast and multicast topologies are known to be congruent, the following checks should be made 🧐. On interfaces configured as leaf subnets, all C-RP-Adv messages should be dropped. On multi-access subnets with multiple PIM routers and untrusted hosts, the router can at least check that the source Media Access Control (MAC) address belongs to a valid PIM neighbor 🪪.
6.4.2. Cryptographic Security of C-RP-Adv Messages 🔐
For true security, we recommend that all C-RPs are configured to use IPsec authentication 💪. The authentication process for a C-RP-Adv message between a C-RP and the BSR is identical to the one for PIM Register messages between a DR and the relevant RP. The difference is that there are normally fewer C-RPs in a domain than DRs, so key management is a little simpler 🗝️. We won't go into the details here. Instead, check the Security Considerations section of [1]. Also, using cryptographic security for C-RP-Adv messages does NOT remove the need for the non-cryptographic mechanisms we covered above 👑.
6.5. Denial of Service using IPsec 🌊
One more worry: denial-of-service attacks where someone floods the network with high volumes of Bootstrap messages or C-RP-Adv messages carrying invalid IPsec authentication info 😱. These messages could overwhelm the recipient's CPU 🔥.
The non-cryptographic security mechanisms above limit where unicast Bootstrap messages and C-RP-Adv messages can be accepted from 🚧. On top of that, we recommend that rate-limiting mechanisms can be configured, applied when unicast PIM packets are received 🎀. The rate-limiter MUST independently rate-limit different types of PIM packets. For example, a flood of C-RP-Adv messages MUST NOT cause the rate limiter to drop low-rate Bootstrap messages 🙅♀️. Such a rate-limiter could itself be abused to cause a denial-of-service attack by dropping valid packets, but in practice it's much more likely to constrain bad PIM messages 🗑️. And the rate-limiter stops attacks on PIM from hurting other activity on the receiving router, like unicast routing 🛣️.
7. Contributors 🫶
Bill Fenner, Mark Handley, Roger Kermode, and David Thaler have contributed hugely to this document 💖. They were authors up to version 03, and much of the current text comes from version 03 🌸.
8. Acknowledgments 🙏
PIM-SM was designed over many years by a big group of people 🧠, including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas, and Hugh Holbrook ⭐. This BSR specification draws heavily on text from RFC 2362 📚.
Many members of the PIM Working Group have contributed comments and corrections for this document, including Christopher Thomas Brown, Ardas Cilingiroglu, Murthy Esakonu, Venugopal Hemige, Prashant Jhingran, Rishabh Parekh, and Katta Sambasivarao 🥰.
9. Normative References 📖
[1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 4601, August 2006.
[2] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC
5015, October 2007.
[3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[4] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B.
Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[5] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.10. Informative References 🌈
[7] Estrin, D., et al., "Protocol Independent Multicast-Sparse Mode
(PIM-SM): Protocol Specification", RFC 2362, June 1998.
[8] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
Rendevous Point (RP) mechanism using Protocol Independent
Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)",
RFC 3446, January 2003.
[9] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent
Multicast (PIM)", RFC 4610, August 2006.
[10] Atwood, W. and S. Islam, "Security Issues in PIM-SM Link-local
Messages", Work in Progress, July 2007.
[11] IANA, "Address Family Numbers",
`<http://www.iana.org/assignments/address-family-numbers>`.Authors' Addresses 📮
Nidhi Bhaskar
Arastra, Inc.
P.O. Box 10905
Palo Alto, CA 94303
USA
EMail: nidhi@arastra.com
Alexander Gall
SWITCH
P.O. Box
CH-8021 Zurich
Switzerland
EMail: alexander.gall@switch.ch
James Lingard
Arastra, Inc.
P.O. Box 10905
Palo Alto, CA 94303
USA
EMail: jchl@arastra.com
Stig Venaas
UNINETT
NO-7465 Trondheim
Norway
EMail: venaas@uninett.noFull Copyright Statement ©️
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💜
Intellectual Property 💅
okay so the IETF is totally neutral here 🫶 they don't take a side on whether any intellectual property rights (IPR) that someone claims over the tech in this doc are valid, or how far those rights reach. they also don't promise they went looking for any of them. if you want the rules on rights for RFC docs, check out BCP 78 and BCP 79 📚
copies of IPR disclosures that were sent to the IETF Secretariat are a whole thing 🗂️ so are any promises of licenses, and so is the result of anyone trying to get a general license or permission to use proprietary rights for this spec. implementers and users can find all of that in the IETF's online IPR repository at http://www.ietf.org/ipr ✨
and if you're an interested party who knows about a copyright, patent, patent application, or other proprietary right that might cover tech you'd need to implement this standard, the IETF wants you to tell them 🦋 just send it to ietf-ipr@ietf.org 💖 no cap, the IETF really wants to hear about it, iykyk 🌸
📦 where this page comes from
- ietf: rfc5059 2008-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms