draft-ietf-pim-sm-bsr-00.txt   draft-ietf-pim-sm-bsr-01.txt 
Internet Engineering Task Force PIM WG Internet Engineering Task Force PIM WG
INTERNET-DRAFT Bill Fenner/AT&T INTERNET-DRAFT Bill Fenner/AT&T
draft-ietf-pim-sm-bsr-00.txt Mark Handley/ACIRI draft-ietf-pim-sm-bsr-01.txt Mark Handley/ACIRI
Roger Kermode/Motorola
David Thaler/Microsoft David Thaler/Microsoft
23 February 2001 20 July 2001
Expires: August 2001 Expires: January 2002
Bootstrap Router (BSR) Mechanism for PIM Sparse Mode Bootstrap Router (BSR) Mechanism for PIM Sparse Mode
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
skipping to change at page 1, line 38 skipping to change at page 1, line 39
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a product of the IETF PIM WG. Comments should be This document is a product of the IETF PIM WG. Comments should be
addressed to the authors, or the WG's mailing list at addressed to the authors, or the WG's mailing list at
pim@catarina.usc.edu. pim@catarina.usc.edu.
Abstract Abstract
This document specifies the Bootstrap Router (BSR) mechanism This document specifies the Bootstrap Router (BSR) mechanism
for PIM Sparse Mode. BSR is one way that a PIM-SM router can for Protocol Independent Multicast - Sparse Mode (PIM-SM).
learn the set of group-to-RP mappings required in order to BSR is one way that a PIM-SM router can learn the set of
function. The mechanism is dynamic, largely self-configuring, group-to-RP mappings required in order to function. The
and robust to router failure. mechanism is dynamic, largely self-configuring, and robust to
router failure.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview of Bootstrap and RP Discovery . . . . . . . 3 1.1. Overview of Bootstrap and RP Discovery for
1.2. Administratively Scoped Multicast. . . . . . . . . . 4 Global Scope. . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Administratively Scoped Multicast and BSR. . . . . . 5
2. BSR State and Timers. . . . . . . . . . . . . . . . . . 6 2. BSR State and Timers. . . . . . . . . . . . . . . . . . 6
3. Bootstrap Router Election and RP-Set 3. Bootstrap Router Election and RP-Set
Distribution . . . . . . . . . . . . . . . . . . . . . . . 7 Distribution . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Sending Candidate-RP-Advertisements. . . . . . . . . 15 3.1. Sending Candidate-RP-Advertisements. . . . . . . . . 15
3.2. Creating the RP-Set at the BSR . . . . . . . . . . . 16 3.2. Creating the RP-Set at the BSR . . . . . . . . . . . 16
3.3. Forwarding Bootstrap Messages. . . . . . . . . . . . 17 3.3. Forwarding Bootstrap Messages. . . . . . . . . . . . 17
3.4. Receiving and Using the RP-Set . . . . . . . . . . . 17 3.4. Receiving and Using the RP-Set . . . . . . . . . . . 17
4. Message Formats . . . . . . . . . . . . . . . . . . . . 18 4. Message Formats . . . . . . . . . . . . . . . . . . . . 17
4.1. Bootstrap Message Format . . . . . . . . . . . . . . 20 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 19
4.2. Candidate-RP-Advertisement Format. . . . . . . . . . 23 4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 23
5. Default Values for Timers . . . . . . . . . . . . . . . 25 4.2. Candidate-RP-Advertisement Format. . . . . . . . . . 25
6. Authors' Addresses. . . . . . . . . . . . . . . . . . . 26 5. Default Values for Timers . . . . . . . . . . . . . . . 26
7. References. . . . . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . 27
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 27 6.1. Possible Threats . . . . . . . . . . . . . . . . . . 27
6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 28
6.3. BS Message Security. . . . . . . . . . . . . . . . . 28
6.4. C-RP-Advertisement Security. . . . . . . . . . . . . 30
6.5. Denial of Service using IPsec. . . . . . . . . . . . 30
7. Authors' Addresses. . . . . . . . . . . . . . . . . . . 31
8. References. . . . . . . . . . . . . . . . . . . . . . . 32
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
For correct operation, every PIM router within a PIM domain must be able Note: this document assumes familiarity with the workings of Protocol
to map a particular multicast group address to the same RP. If this is Independent Multicast - Sparse Mode, as defined in [1].
not the case then black holes may appear, where some receivers in the
domain cannot receive some groups. A domain in this context is a
contiguous set of routers that all implement PIM and are configured to
operate within a common boundary defined by PIM Multicast Border Routers
(PMBRs). PMBRs connect each PIM domain to the rest of the internet.
A notable exception to this is where a PIM domain is broken up into For correct operation, every PIM Sparse-mode router within a PIM domain
multiple administrative scope regions - these are regions where a border must be able to map a particular global-scope multicast group address to
has been configured so that a range of multicast groups will not be the same RP. If this is not the case then black holes may appear, where
forwarded across that border. For more information on Administratively some receivers in the domain cannot receive some groups. A domain in
Scoped IP Multicast, see RFC 2365. The modified criteria for admin- this context is a contiguous set of routers that all implement PIM and
scoped regions are that the region is convex with respect to forwarding are configured to operate within a common boundary defined by PIM
based on the MRIB, and that all PIM routers within the scope region map Multicast Border Routers (PMBRs). PMBRs connect each PIM domain to the
a particular scoped group to the same RP within that region. rest of the internet.
A PIM domain may also broken up into multiple administrative scope
regions - these are regions where a border has been configured so that a
range of multicast groups will not be forwarded across that border. For
more information on Administratively Scoped IP Multicast, see RFC 2365.
The modified criteria for admin-scoped regions are that the region is
convex with respect to forwarding based on the MRIB, and that all PIM
routers within the same scope region map a particular scoped group to
the same RP within that region.
The PIM-SM specification does not mandate the use of a single mechanism The PIM-SM specification does not mandate the use of a single mechanism
to provide routers with the information to perform the group-to-RP to provide routers with the information to perform the group-to-RP
mapping. This document describes the Bootstrap Router (BSR) mechanism. mapping. This document describes the Bootstrap Router (BSR) mechanism.
BSR was first defined in RFC 2362, which has since been obsoleted. This BSR was first defined in RFC 2362 [2], which has since been obsoleted.
document provides an updated specification of the BSR mechanism from RFC This document provides an updated specification of the BSR mechanism
2362, and also extends it to cope with administratively scoped region from RFC 2362, and also extends it to cope with administratively scoped
boundaries. region boundaries.
1.1. Overview of Bootstrap and RP Discovery 1.1. Overview of Bootstrap and RP Discovery for Global Scope
A small set of routers from a domain are configured as candidate A small set of routers from a domain are configured as candidate
bootstrap routers (C-BSRs) and, through a simple election mechanism, a bootstrap routers (C-BSRs) and, through a simple election mechanism, a
single BSR is selected for that domain. A set of routers within a domain single BSR is selected for that domain. A set of routers within a domain
are also configured as candidate RPs (C-RPs); typically these will be are also configured as candidate RPs (C-RPs); typically these will be
the same routers that are configured as C-BSRs. Candidate RPs the same routers that are configured as C-BSRs. Candidate RPs
periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to
the BSR of that domain, advertising their willingness to be an RP. A C- the BSR of that domain, advertising their willingness to be an RP. A C-
RP-Adv message includes the address of the advertising C-RP, as well as RP-Adv message includes the address of the advertising C-RP, as well as
an optional list of group addresses and a mask length fields, indicating an optional list of group addresses and a mask length fields, indicating
skipping to change at page 3, line 47 skipping to change at page 5, line 4
are also configured as candidate RPs (C-RPs); typically these will be are also configured as candidate RPs (C-RPs); typically these will be
the same routers that are configured as C-BSRs. Candidate RPs the same routers that are configured as C-BSRs. Candidate RPs
periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to
the BSR of that domain, advertising their willingness to be an RP. A C- the BSR of that domain, advertising their willingness to be an RP. A C-
RP-Adv message includes the address of the advertising C-RP, as well as RP-Adv message includes the address of the advertising C-RP, as well as
an optional list of group addresses and a mask length fields, indicating an optional list of group addresses and a mask length fields, indicating
the group prefix(es) for which the candidacy is advertised. The BSR then the group prefix(es) for which the candidacy is advertised. The BSR then
includes a set of these Candidate-RPs (the RP-Set), along with their includes a set of these Candidate-RPs (the RP-Set), along with their
corresponding group prefixes, in Bootstrap messages it periodically corresponding group prefixes, in Bootstrap messages it periodically
originates. Bootstrap messages are distributed hop-by-hop throughout originates. Bootstrap messages are distributed hop-by-hop throughout
the domain. the domain.
All the PIM routers in the domain receive and store Bootstrap messages All the PIM routers in the domain receive and store Bootstrap messages
originated by the BSR. When a DR gets a indication of local membership originated by the BSR. When a DR receives an indication of local
membership (typically from IGMP [3] or MLD [4]) or a data packet from a
from IGMP or a data packet from a directly connected host, for a group directly connected host, for a group for which it has no forwarding
for which it has no forwarding state, the DR uses a hash function to map state, the DR uses a hash function to map the group address to one of
the group address to one of the C-RPs from the RP-Set whose group-prefix the C-RPs from the RP-Set whose group-prefix includes the group (see
includes the group (see RFC xxxx). The DR then sends a Join message [1]). The DR then sends a Join message towards that RP if the local host
towards that RP if the local host joined the group, or it Register- joined the group, or it Register-encapsulates and unicasts the data
encapsulates and unicasts the data packet to the RP if the local host packet to the RP if the local host sent a packet to the group.
sent a packet to the group.
A Bootstrap message indicates liveness of the RPs included therein. If A Bootstrap message indicates liveness of the RPs included therein. If
an RP is included in the message, then it is tagged as `up' at the an RP is included in the message, then it is tagged as `up' at the
routers; RPs not included in the message are removed from the list of routers; RPs not included in the message are removed from the list of
RPs over which the hash algorithm acts. Each router continues to use the RPs over which the hash algorithm acts. Each router continues to use the
contents of the most recently received Bootstrap message from the BSR contents of the most recently received Bootstrap message from the BSR
until it receives a new Bootstrap message. until it accepts a new Bootstrap message.
If a PIM domain becomes partitioned, each area separated from the old If a PIM domain becomes partitioned, each area separated from the old
BSR will elect its own BSR, which will distribute an RP-Set containing BSR will elect its own BSR, which will distribute an RP-Set containing
RPs that are reachable within that partition. When the partition heals, RPs that are reachable within that partition. When the partition heals,
another election will occur automatically and only one of the BSRs will another election will occur automatically and only one of the BSRs will
continue to send out Bootstrap messages. As is expected at the time of a continue to send out Bootstrap messages. As is expected at the time of a
partition or healing, some disruption in packet delivery may occur. This partition or healing, some disruption in packet delivery may occur. This
time will be on the order of the region's round-trip time and the time will be on the order of the region's round-trip time and the
bootstrap router timeout value. bootstrap router timeout value.
1.2. Administratively Scoped Multicast 1.2. Administratively Scoped Multicast and BSR
Administratively Scoped IP Multicast, as defined in RFC 2365, permits a Administratively Scoped IP Multicast, as defined in RFC 2365, permits a
network provider to configure scope boundaries at multicast routers. network provider to configure scope boundaries at multicast routers.
Such a scope boundary consists of a range of multicast addresses Such a scope boundary consists of a range of multicast addresses
(expressed as an address and mask) that the router will not forward (expressed as an address and mask) that the router will not forward
across the boundary. For correct operation, such a scope zone border across the boundary. For correct operation, such a scope zone border
must be complete and convex. By this we mean that there must be no path must be complete and convex. By this we mean that there must be no path
from inside the scoped zone to outside it that does not pass through a from inside the scoped zone to outside it that does not pass through a
configured scope border router, and that the multicast capable path configured scope border router, and that the multicast capable path
between any arbitrary pair of multicast routers in the scope zone must between any arbitrary pair of multicast routers in the scope zone must
remain in the zone. remain in the zone.
For PIM-SM using BSR to function correctly with admin scoping, there For PIM-SM using BSR to function correctly with admin scoping, there
must be a BSR and at least one C-RP within every admin scope region. must be a BSR and at least one C-RP within every admin scope region.
Admin scope zone boundaries must be configured at the Zone Border Admin scope zone boundaries must be configured at the Zone Border
Routers (ZBRs), as they need to filter PIM Join messages that might Routers (ZBRs), as they need to filter PIM Join messages that might
inadvertantly cross the border due to error conditions. However we do inadvertently cross the border due to error conditions. In addition, at
not wish any other router within the scope zone to require manual least one C-BSR within the admin scope zone must be configured to be a
configuration as this creates further possibilities for error, and makes
the configuration of large scope zones difficult. If all the C-BSR and
C-RP routers within a scope zone are ZBRs, then there is no problem, but
this may not the the desired case. Thus whilst we also permit interior
C-BSRs and C-RPs to be configured for the admin scope zone, we would C-BSR for the admin scope zone's address range.
also require a mechanism by which all C-BSRs and C-RPs inside an admin
scope zone can automatically learn of the existence of the scope zone.
We do this by requiring all ZBRs to be both C-BSRs and C-RPs for the A separate BSR election will then take place (using bootstrap messages)
scoped group range, although the default priority should be the lowest for every admin scope range (plus one for the global range). Admin
possible. A ZBR that does not know of a higher-priority BSR advertising scope ranges are identified in the bootstrap message because the group
RPs for the scope zone will therefore originate its own Bootstrap range is marked (using the "Admin Scope" bit, previously a "Reserved"
message, initially only containing itself as a possible RP for the bit) to indicate that this is an administrative scope range, and not
scoped group range. The group-range field in the ZBRs bootstrap message just a range that a particular set of RPs are configured to handle.
is marked (using the "Admin Scope" bit, previously a "Reserved" bit) to
indicate that this is an administrative scope range, and not just a
range that a particular set of RPs are configured to handle. Such a
bootstrap message is flooded in the normal way, but will not be
forwarded by another ZBR across the boundary for that scope zone (see
Section 3.3 for the specifics of this).
When a C-BSR within the scope zone receives such a Bootstrap message, it Such admin scoped bootstrap message packets are flooded in the normal
stores state for the admin scope range contained in the message. A way, but will not be forwarded by another ZBR across the boundary for
separate BSR election will then take place for every admin scope range that scope zone (see Section 3.3 for the specifics of this).
(plus one for the global range).
When a C-RP within the scope zone receives such a Bootstrap message, it We do not require that C-RPs within the scope zone be configured to know
also stores state for the admin scope range contained in the message. about the scope zone, as they can learn of its existence from bootstrap
It separately unicasts Candidate-RP-Advertisement messages to the BSR messages. However, we recommend that router vendors implement
for every admin scope range within which it is willing to serve as an configuration options that allow a C-RP to be configured to be a C-RP
RP. Unless configured otherwise, all candidate RPs are willing to serve for global scope only, for one of more admin scopes only, or for all
as RPs for all groups in all ranges. scopes, both global and admin scoped. We also recommend that the
default be that a C-RP is a C-RP for all scopes, both global and admin
scoped.
ZBRs are also C-RPs for the admin scope zone; they also learn of the Unless configured otherwise, C-RPs discover the existence of the admin
current BSR for the admin scope range from receiving a Bootstrap scope zone and its group range from receiving a bootstrap message from
message, and so they must also send a Candidate-RP-Advertisement message the scope zone's elected BSR containing the scope zone's group-range,
to the BSR for the scope range. However, unlike an internal C-RP, a ZBR marked using the "Admin Scope" bit. A C-RP stores each elected BSR's
sets the "Admin Scope" bit in the group-range field in its C-RP address and the admin scope range contained in its bootstrap message.
advertisement. When the BSR receives such a C-RP-Adv message, it It separately unicasts Candidate-RP-Advertisement messages to the
updates the scope zone keepalive timer; if this timer ever expires the appropriate BSR for every admin scope range within which it is willing
BSR stops being the BSR for that admin scope zone and flushes all state to serve as an RP.
concerned with the scope zone. In this way, if all the ZBRs are
configured to no longer be ZBRs, then the BSR will eventually time out
the zone.
Note that so long as at least one reachable internal BSR and C-RP is All PIM routers within a PIM bootstrap domain where admin scope ranges
configured within the scope zone to have better-than-minimum priority, are in use must be capable of receiving bootstrap messages and storing
then by default the ZBRs themselves will never actually be used as the winning BSR and RPset for all admin scope zones that apply. Thus
either the BSR or an RP for the scope zone despite being a C-BSR and C- PIM routers that only implement RFC 2362 (which only allows one BSR per
RP. domain) cannot be used in PIM domains where admin scope zones are
configured.
2. BSR State and Timers 2. BSR State and Timers
A PIM-SM router implementing BSR holds the following state in addition A PIM-SM router implementing BSR holds the following state in addition
to the state needed for PIM-SM operation: to the state needed for PIM-SM operation:
At all routers: At all routers:
List of Active Scope Zones List of Active Scope Zones
Per Scope Zone: Per Scope Zone:
Scope-Zone Expiry Timer: SZT(Z)
Bootstrap State: Bootstrap State:
o Bootstrap Router's IP Address o Bootstrap Router's IP Address
o BSR Priority o BSR Priority
o Bootstrap Timer (BST) o Bootstrap Timer (BST)
o List of Scope Group-Ranges for this BSR o List of Scope Group-Ranges for this BSR
skipping to change at page 6, line 41 skipping to change at page 7, line 29
Per Scope Zone: Per Scope Zone:
o My state: One of "Candidate-BSR", "Pending-BSR", o My state: One of "Candidate-BSR", "Pending-BSR",
"Elected-BSR" "Elected-BSR"
At a router that is not a Candidate BSR: At a router that is not a Candidate BSR:
Per Scope Zone: Per Scope Zone:
o My state: One of "Accept Any", "Accept Preferred" My state: One of "Accept Any", "Accept Preferred"
Scope-Zone Expiry Timer: SZT(Z)
Bootstrap state is described in section 3, and the RP Set is described Bootstrap state is described in section 3, and the RP Set is described
in section 3.4. in section 3.4.
The following timers are also required: The following timers are also required:
At the Bootstrap Router only: At the Bootstrap Router only:
Per Scope Zone (Z): Per Scope Zone (Z):
skipping to change at page 7, line 19 skipping to change at page 8, line 11
At the C-RPs only: At the C-RPs only:
C-RP Advertisement Timer: CRPT C-RP Advertisement Timer: CRPT
3. Bootstrap Router Election and RP-Set Distribution 3. Bootstrap Router Election and RP-Set Distribution
For simplicity, bootstrap messages (BSMs) are used in both the BSR For simplicity, bootstrap messages (BSMs) are used in both the BSR
election and the RP-Set distribution mechanisms. election and the RP-Set distribution mechanisms.
The state-machine for bootstrap messages depends on whether or not a The state-machine for bootstrap messages depends on whether or not a
router has been configured to be a Candidate-BSR. The state-machine for router has been configured to be a Candidate-BSR for a particular scope
a C-BSR is given below, followed by the state-machine for a router that zone. The per-scope-zone state-machine for a C-BSR is given below,
is not configured to be a C-BSR. followed by the state-machine for a router that is not configured to be
a C-BSR.
Candidate-BSR State Machine Per-Scope-Zone Candidate-BSR State Machine
+-----------------------------------+ +-----------------------------------+
| Figures omitted from text version | | Figures omitted from text version |
+-----------------------------------+ +-----------------------------------+
Figure 1: State-machine for a candidate BSR Figure 1: Per-Scope-Zone State-machine for a candidate BSR
In tabular form this state machine is: In tabular form this state machine is:
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in No Info state |
+---------+-------------------------------+-----------------------------+
| Event | Receive Preferred BSM for | Receive Non-Preferred BSM |
| | unknown Admin Scope | for unknown Admin Scope |
+---------+-------------------------------+-----------------------------+
| | -> C-BSR state | -> P-BSR state |
| Action | Forward BSM; | Forward BSM; |
| | Store RP Set; | Store RP Set; |
| | Set BS Timer to BS Timeout | Set BS Timer to BS Timeout |
+---------+-------------------------------+-----------------------------+
+-----------------------------------------------------------------------+
| When in C-BSR state | | When in C-BSR state |
+------------+-------------------+-------------------+------------------+ +------------+-------------------+-------------------+------------------+
| Event | Receive | BS Timer | Receive BSM | | Event | Receive | BS Timer | Receive non- |
| | Preferred BSM | Expires | from BSR with | | | Preferred BSM | Expires | preferred BSM |
| | | | Admin Scope | | | | | from Elected |
| | | | bit cleared | | | | | BSR |
+------------+-------------------+-------------------+------------------+ +------------+-------------------+-------------------+------------------+
| | -> C-BSR state | -> P-BSR state | -> No Info | | | -> C-BSR state | -> P-BSR state | -> P-BSR state |
| | | | state | | | Forward BSM; | Set BS Timer | Set BS Timer |
| Action | Forward BSM; | Set BS Timer | cancel timers, | | Action | Store RP Set; | to | to |
| | Store RP Set; | to | clear state | | | Set BS Timer | rand_override | rand_override |
| | Set BS Timer | rand_override | |
| | to BS Timeout | | | | | to BS Timeout | | |
+------------+-------------------+-------------------+------------------+ +------------+-------------------+-------------------+------------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in P-BSR state | | When in P-BSR state |
+------------+-------------------+-------------------+------------------+ +-------------+-------------------+------------------+------------------+
| Event | Receive | BS Timer | Receive BSM | | Event | Receive | BS Timer | Receive Non- |
| | Preferred BSM | Expires | from BSR with | | | Preferred BSM | Expires | preferred BSM |
| | | | Admin Scope | +-------------+-------------------+------------------+------------------+
| | | | bit cleared | | | -> C-BSR state | -> E-BSR state | -> P-BSR state |
+------------+-------------------+-------------------+------------------+ | | Forward BSM; | Originate BSM; | |
| | -> C-BSR state | -> E-BSR state | -> No Info | | Action | Store RP Set; | Set BS Timer | |
| | | | state | | | Set BS Timer | to BS Period | |
| | Forward BSM; | Originate BSM; | cancel timers, | | | to BS Timeout | | |
| Action | Store RP Set; | Set BS Timer | clear state | +-------------+-------------------+------------------+------------------+
| | Set BS Timer | to BS Period; | |
| | to BS Timeout | Set SZ Timer | |
| | | to SZ Period | |
+------------+-------------------+-------------------+------------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in E-BSR state | | When in E-BSR state |
+----------+---------------+--------------+--------------+--------------+ +-------------+-------------------+------------------+------------------+
|Event | Receive | BS Timer | SZ Timer | Receive C- | | Event | Receive | BS Timer | Receive Non- |
| | Preferred | Expires | Expires | RP-Adv for | | | Preferred BSM | Expires | preferred BSM |
| | BSM | | | this Admin | +-------------+-------------------+------------------+------------------+
| | | | | Scope | | | -> C-BSR state | -> E-BSR state | -> E-BSR state |
+----------+---------------+--------------+--------------+--------------+ | | Forward BSM; | Originate BSM; | Originate BSM; |
| | -> C-BSR | -> E-BSR | -> No Info | -> E-BSR | | Action | Store RP Set; | Set BS Timer | Set BS Timer |
| | state | state | state | state | | | Set BS Timer | to BS Period | to BS Period |
| | Forward BSM; | Originate | Originate | Set SZ Timer | | | to BS Timeout | | |
|Action | Store RP | BSM; Set BS | BSM with | to SZ | +-------------+-------------------+------------------+------------------+
| | Set; Set BS | Timer to BS | Admin Scope | Timeout | A candidate-BSR may be in one of three states for a particular scope
| | Timer to BS | Period | bit cleared | |
| | Timeout | | | |
+----------+---------------+--------------+--------------+--------------+
A candidate-BSR may be in one of four states for a particular scope
zone: zone:
No Info
The router has no information about this scope zone. This state
does not apply if the router is configured to know about this scope
zone, or for the global scope zone. When in this state, no state
information is held and no timers run that refer to this scope
zone.
Candidate-BSR (C-BSR) Candidate-BSR (C-BSR)
The router is a candidate to be a BSR, but currently another router The router is a candidate to be the BSR for the scope zone, but
is the preferred BSR. currently another router is the preferred BSR.
Pending-BSR (P-BSR) Pending-BSR (P-BSR)
The router is a candidate to be a BSR. Currently no other router The router is a candidate to be the BSR for the scope zone.
is the preferred BSR, but this router is not yet the BSR. For Currently no other router is the preferred BSR, but this router is
comparisons with incoming BS messages, the router treats itself as not yet the BSR. For comparisons with incoming BS messages, the
the BSR. This is a temporary state that prevents rapid thrashing router treats itself as the BSR. This is a temporary state that
of the choice of BSR during BSR election. prevents rapid thrashing of the choice of BSR during BSR election.
Elected-BSR (E-BSR) Elected-BSR (E-BSR)
The router is the elected bootstrap router and it must perform all The router is the elected bootstrap router for the scope zone and
the BSR functions. it must perform all the BSR functions.
On startup, the initial state for this scope zone is "Pending-BSR" for On startup, the initial state for this configured scope zone is
routers that know about this scope zone, either through configuration or "Pending-BSR"; the BS Timer is initialized to the BS Timeout value.
because the scope zone is the global scope which always exists; the BS
Timer is initialized to the BS Timeout value. For routers that do not
know about a particular scope zone, the initial state is No Info; no
timers exist for the scope zone.
In addition to the four states, there are two timers: In addition to the three states, there is one timer:
o The bootstrap timer (BS Timer) - that is used to time out old o The bootstrap timer (BS Timer) - that is used to time out old
bootstrap router information, and used in the election process to bootstrap router information, and used in the election process to
terminate P-BSR state. terminate P-BSR state.
o The scope zone timer (SZ Timer) - that is used to time out the scope Per-Scope-Zone State-machine for Non-Candidate-BSR Routers
zone itself at an Elected BSR if no C-RP-Adv messages arrive from the
Zone Border Routers.
State-machine for Non-Candidate-BSR Routers
+-----------------------------------+ +-----------------------------------+
| Figures omitted from text version | | Figures omitted from text version |
+-----------------------------------+ +-----------------------------------+
Figure 2: State-machine for a router not configured as C-BSR Figure 2: Per-Scope-Zone State-machine for a router not configured as C-BSR
In tabular form this state machine is: In tabular form this state machine is:
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in No Info state | | When in No Info state |
+--------------------+--------------------------------------------------+ +--------------------+--------------------------------------------------+
| Event | Receive BSM for unknown Admin Scope | | Event | Receive BSM for unknown Admin Scope |
+--------------------+--------------------------------------------------+ +--------------------+--------------------------------------------------+
| | -> AP State | | | -> AP State |
| Action | Forward BSM; Store RP-Set; | | Action | Forward BSM; Store RP-Set; |
skipping to change at page 11, line 7 skipping to change at page 11, line 7
+---------------+-----------------------------+-------------------------+ +---------------+-----------------------------+-------------------------+
| | -> AP State | -> No Info state | | | -> AP State | -> No Info state |
| | Forward BSM; Store | cancel timers; | | | Forward BSM; Store | cancel timers; |
| Action | RP-Set; Set BS | clear state | | Action | RP-Set; Set BS | clear state |
| | Timer to BS | | | | Timer to BS | |
| | Timeout | | | | Timeout | |
+---------------+-----------------------------+-------------------------+ +---------------+-----------------------------+-------------------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in Accept Preferred state | | When in Accept Preferred state |
+-----------+------------------+-----------------+----------------------+ +------------+-------------------+-------------------+------------------+
| Event | Receive | BS Timer | Receive BSM from | | Event | Receive | BS Timer | Receive Non- |
| | Preferred BSM | Expires | BSR with Admin | | | Preferred BSM | Expires | preferred BSM |
| | | | Scope bit cleared | +------------+-------------------+-------------------+------------------+
+-----------+------------------+-----------------+----------------------+ | | -> AP State | -> AA State | -> AP State |
| | -> AP State | -> AA State | -> No Info state | | | Forward BSM; | | |
| | Forward BSM; | | cancel | | Action | Store RP-Set; | | |
| Action | Store RP-Set; | | timers;clear | | | Set BS Timer | | |
| | Set BS Timer | | state |
| | to BS Timeout | | | | | to BS Timeout | | |
+-----------+------------------+-----------------+----------------------+ +------------+-------------------+-------------------+------------------+
A router that is not a candidate-BSR may be in one of three states: A router that is not a candidate-BSR may be in one of three states:
No Info No Info
The router has no information about this scope zone. This state The router has no information about this scope zone. This state
does not apply if the router is configured to know about this scope does not apply if the router is configured to know about this scope
zone, or for the global scope zone. When in this state, no state zone, or for the global scope zone. When in this state, no state
information is held and no timers run that refer to this scope information is held and no timers run that refer to this scope
zone. zone.
skipping to change at page 12, line 13 skipping to change at page 12, line 10
bootstrap router information. bootstrap router information.
o The scope zone timer (SZ Timer) - that is used to time out the scope o The scope zone timer (SZ Timer) - that is used to time out the scope
zone itself if BS messages specifying this scope zone stop arriving. zone itself if BS messages specifying this scope zone stop arriving.
Bootstrap Message Processing Checks Bootstrap Message Processing Checks
When a bootstrap message is received, the following initial checks must When a bootstrap message is received, the following initial checks must
be performed: be performed:
if ( (DirectlyConnected(BSM.src_ip_address) == FALSE)
OR (we have no Hello state for BSM.src_ip_address)) {
drop the BS message silently
}
if (BSM.dst_ip_address == ALL-PIM-ROUTERS group) { if (BSM.dst_ip_address == ALL-PIM-ROUTERS group) {
if ( BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address) ) { if ( BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address) ) {
drop the BS message silently drop the BS message silently
} }
} else if (BSM.dst_ip_address is one of my addresses) { } else if (BSM.dst_ip_address is one of my addresses) {
if ( (No previous BSM received) if ( (Any previous BSM for this scope has been accepted) {
OR (DirectlyConnected(BSM.src_ip_address) == FALSE) ) {
#the packet was unicast, but this wasn't #the packet was unicast, but this wasn't
#a quick refresh on startup #a quick refresh on startup
drop the BS message silently drop the BS message silently
} }
} else { } else {
drop the BS message silently drop the BS message silently
} }
if (the interface the message arrived on is an Admin Scope if (the interface the message arrived on is an Admin Scope
border for the BSM.first_group_address) { border for the BSM.first_group_address) {
drop the BS message silently drop the BS message silently
} }
Basically, the packet must have been sent to the ALL-PIM-ROUTERS group Basically, the packet must have come from a directly connected neighbor
by the correct upstream router towards the BSR that originated the BS for which we have active Hello state. It must have been sent to the
message, or the router must have no BSR state (it just restarted) and ALL-PIM-ROUTERS group by the correct upstream router towards the BSR
have received the BS message by unicast from a directly connected that originated the BS message, or the router must have no BSR state (it
neighbor. In addition it must not have arrived on an interface that is just restarted) and have received the BS message by unicast. In
a configured admin scope border for the first group address contained in addition it must not have arrived on an interface that is a configured
the BS message. admin scope border for the first group address contained in the BS
message.
BS State-machine Transition Events BS State-machine Transition Events
If the bootstrap message passes the initial checks above without being If the bootstrap message passes the initial checks above without being
discarded, then it may cause a state transition event in one of the discarded, then it may cause a state transition event in one of the
above state-machines. For both candidate and non-candidate BSRs, the above state-machines. For both candidate and non-candidate BSRs, the
following transition events are defined: following transition events are defined:
Receive Preferred BSM Receive Preferred BSM
A bootstrap message is received from a BSR that has greater A bootstrap message is received from a BSR that has greater
skipping to change at page 13, line 14 skipping to change at page 13, line 15
The weighting for a BSR is the concatenation in fixed- The weighting for a BSR is the concatenation in fixed-
precision unsigned arithmetic of the BSR priority field from precision unsigned arithmetic of the BSR priority field from
the bootstrap message and the IP address of the BSR from the the bootstrap message and the IP address of the BSR from the
bootstrap message (with the BSR priority taking the most- bootstrap message (with the BSR priority taking the most-
significant bits and the IP address taking the least significant bits and the IP address taking the least
significant bits). significant bits).
Receive BSM Receive BSM
A bootstrap message is received, regardless of BSR weight. A bootstrap message is received, regardless of BSR weight.
A non-candidate BSM also has the following transition event defined:
Receive BSM from BSR with Admin Scope bit cleared Receive BSM for unknown Admin Scope
The scope is not the global scope; it is an admin scope that As "Receive BSM", except that the admin scope zone indicated
was previously learned from receiving a bootstrap message that in the BSM was not previously known at this router.
had the Admin Scope bit set for this scope. Now a bootstrap
message is received for this scope range from the BSR, but the
Admin Scope bit is cleared indicating that the BSR has timed
out the entire scope zone.
Receive C-RP-Adv for this Admin Scope
The scope is not the global scope; it is an admin scope range.
A C-RP-Adv message arrives with the Admin Scope bit set for
this scope range. This indicates that the sender of the C-RP-
Adv (normally a ZBR for the scope zone) believes the scope
zone is still active.
BS State-machine Actions BS State-machine Actions
The state-machines specify actions that include setting the BS timer to The state-machines specify actions that include setting the BS timer to
the following values: the following values:
BS Period BS Period
The periodic interval with which bootstrap messages are The periodic interval with which bootstrap messages are
normally sent. The default value is 60 seconds. normally sent. The default value is 60 seconds.
BS Timeout BS Timeout
The interval after which bootstrap router state is timed out The interval after which bootstrap router state is timed out
if no bootstrap message from that router has been heard. The if no bootstrap message from that router has been heard. The
default value is 2.5 times the BS Period, which is 150 default value is 2 times the BS Period plus 10 seconds, which
seconds. is 130 seconds.
Randomized Override Interval Randomized Override Interval
The randomized interval during which a router avoids sending a The randomized interval during which a router avoids sending a
bootstrap message while it waits to see if another router has bootstrap message while it waits to see if another router has
a higher bootstrap weight. This interval is to reduce control a higher bootstrap weight. This interval is to reduce control
message overhead during BSR election. The following message overhead during BSR election. The following
pseudocode is proposed as an efficient implementation of this pseudocode is proposed as an efficient implementation of this
"randomized" value: "randomized" value:
Delay = 5 + 2 * log_2(1 + bestPriority - myPriority) Delay = 5 + 2 * log_2(1 + bestPriority - myPriority)
+ AddrDelay + AddrDelay
where myPriority is the Candidate-BSR's configured priority, where myPriority is the Candidate-BSR's configured priority,
and bestPriority equals: and bestPriority equals:
bestPriority = Max(storedPriority, myPriority) bestPriority = Max(storedPriority, myPriority)
and AddrDelay is given by the following: and AddrDelay is given by the following:
if ( bestPriority == myPriority) { if ( bestPriority == myPriority) {
AddrDelay = log_2(bestAddr - myAddr) / 16 AddrDelay = log_2(storedAddr - myAddr) / 16
} else { } else {
AddrDelay = 2 - (myAddr / 2^31) AddrDelay = 2 - (myAddr / 2^31)
} }
where myAddr is the Candidate-BSR's address, and bestAddr is where myAddr is the Candidate-BSR's address, storedAddr is the
the stored BSR's address. stored BSR's address, and storedPriority is the stored BSR's
priority.
SZ Period SZ Period
The interval after which a router will time out an Admin Scope The interval after which a router will time out an Admin Scope
zone that it has dynamically learned. The interval MUST be zone that it has dynamically learned. The interval MUST be
larger than the C-RP-Adv period and the BS Timeout. The larger than the BS Timeout. The default value is ten times
default value is ten times the BS Timeout, which is 1500 the BS Timeout, which is 1500 seconds.
seconds.
In addition to setting the timer, the following actions may be triggered In addition to setting the timers, the following actions may be
by state-changes in the state-machines: triggered by state-changes in the state-machines:
Forward BSM Forward BSM
The bootstrap message is forwarded out of all multicast- The bootstrap message is forwarded out of all multicast-
capable interfaces except the interface it was received on. capable interfaces, except the interface it was received on,
The source IP address of the message is the forwarding or where this would cause the BSM to cross an admin-scope
router's IP address on the interface the message is being boundary for the scope zone indicated in the message. The
forwarded from, the destination address is ALL-PIM-ROUTERS, source IP address of the message is the forwarding router's IP
and the TTL of the message is set to 1. address on the interface the message is being forwarded from,
the destination address is ALL-PIM-ROUTERS, and the TTL of the
message is set to 1.
Originate BSM Originate BSM
A new bootstrap message is constructed by the BSR, giving the A new bootstrap message is constructed by the BSR, giving the
BSR's address and BSR priority, and containing the BSR's BSR's address and BSR priority, and containing the BSR's
chosen RP-Set. The message is forwarded out of all multicast- chosen RP-Set. The message is forwarded out of all multicast-
capable interfaces. The IP source address of the message is capable interfaces, except where this would cause the BSM to
the forwarding router's IP address on the interface the cross an admin-scope boundary for the scope zone indicated in
message is being forwarded from, the destination address is the message. The IP source address of the message is the
ALL-PIM-ROUTERS, and the TTL of the message is set to 1. originating router's IP address on the interface the message
is being forwarded from, the destination address is ALL-PIM-
Originate BSM with Admin Scope Bit Cleared ROUTERS, and the TTL of the message is set to 1.
The action is the same as "Originate BSM", except that
although this scope zone is an Admin Scope zone, the group
range field for the scope zone has the Admin Scope bit
cleared. This serves as a signal that the scope zone is no
longer in existence.
Store RP Set Store RP Set
The RP-Set from the received bootstrap message is stored and The RP-Set from the received bootstrap message is stored and
used by the router to decide the RP for each group that the used by the router to decide the RP for each group that the
router has state for. Storing this RP Set may cause other router has state for. Storing this RP Set may cause other
state-transitions to occur in the router. The BSR's IP state-transitions to occur in the router. The BSR's IP
address and priority from the received bootstrap message are address and priority from the received bootstrap message are
also stored to be used to decide if future bootstrap messages also stored to be used to decide if future bootstrap messages
are preferred. are preferred.
In addition to the above state-machine actions, a DR also unicasts a In addition to the above state-machine actions, a DR also unicasts a
stored copy of the Bootstrap message to each new PIM neighbor, i.e., stored copy of the Bootstrap message to each new PIM neighbor, i.e.,
after the DR receives the neighbor's first Hello message. It does so after the DR receives the neighbor's first Hello message, and sends a
even if the new neighbor becomes the DR. Hello message in response. It does so even if the new neighbor becomes
the DR.
3.1. Sending Candidate-RP-Advertisements 3.1. Sending Candidate-RP-Advertisements
Every C-RP periodically unicasts a C-RP-Adv to the BSR for that scope Every C-RP periodically unicasts a C-RP-Adv to the BSR for that scope
zone to inform the BSR of the C-RP's willingness to function as an RP. zone to inform the BSR of the C-RP's willingness to function as an RP.
Unless configured otherwise, it does this for every Admin Scope zone for Unless configured otherwise, it does this for every Admin Scope zone for
which it has state, and for the global scope zone. If the same router which it has state, and for the global scope zone. If the same router
is BSR for more than one scope zone, the C-RP-Adv for these scope zones is the BSR for more than one scope zone, the C-RP-Adv for these scope
MAY be combined into a single message. zones MAY be combined into a single message.
If the C-RP is a ZBR for an admin scope zone, then the Admin Scope bit If the C-RP is a ZBR for an admin scope zone, then the Admin Scope bit
MUST be set in the C-RP-Adv messages it sends for that scope zone; MUST be set in the C-RP-Adv messages it sends for that scope zone;
otherwise this bit MUST NOT be set. otherwise this bit MUST NOT be set. This information is currently only
used for logging purposes by the BSR, but might allow for future
extensions of the protocol.
The interval for sending these messages is subject to local The interval for sending these messages is subject to local
configuration at the C-RP, but must be smaller than the HoldTime in the configuration at the C-RP, but must be smaller than the HoldTime in the
C-RP-Adv. C-RP-Adv.
A Candidate-RP-Advertisement carries a list of group address and group A Candidate-RP-Advertisement carries a list of group address and group
mask field pairs. This enables the C-RP router to limit the mask field pairs. This enables the C-RP router to restrict the
advertisement to certain prefixes or scopes of groups. If the C-RP advertisement to certain prefixes or scopes of groups. If the C-RP
becomes an RP, it may enforce this scope acceptance when receiving becomes an RP, it may enforce this scope acceptance when receiving
Registers or Join/Prune messages. Registers or Join/Prune messages.
The C-RP priority field determines which C-RPs get selected by the BSR The C-RP priority field determines which C-RPs get selected by the BSR
to be in the RP Set. Note that a value of zero is the highest possible to be in the RP Set. Note that a value of zero is the highest possible
priority. C-RPs should by default send C-RP-Adv messages with the priority. C-RPs should by default send C-RP-Adv messages with the
`Priority' field set to `192'. ZBRs that do not wish to serve as an RP `Priority' field set to 192.
except under failure conditions should default to sending C-RP-Adv
messages with the `Priority' field set to `255'.
When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv to When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv to
the BSR for each scope for which it is currently serving as an RP; the the BSR for each scope for which it is currently serving as an RP; the
HoldTime in this C-RP-Adv message should be zero. The BSR will then HoldTime in this C-RP-Adv message should be zero. The BSR will then
immediately time out the C-RP and generate a new BSR message removing immediately time out the C-RP and generate a new BSR message removing
the shutdown RP from the RPset. the shutdown RP from the RPset.
3.2. Creating the RP-Set at the BSR 3.2. Creating the RP-Set at the BSR
Upon receiving a C-RP-Adv, if the router is not the elected BSR, it Upon receiving a C-RP-Adv, if the router is not the elected BSR, it
skipping to change at page 16, line 35 skipping to change at page 16, line 26
Group Prefix and Mask list Group Prefix and Mask list
The list of group prefixes and group masks from the C-RP The list of group prefixes and group masks from the C-RP
advertisement. advertisement.
HoldTime HoldTime
The HoldTime from the C-RP-Adv message. This is included The HoldTime from the C-RP-Adv message. This is included
later in the RP-set information in the Bootstrap Message. later in the RP-set information in the Bootstrap Message.
C-RP Expiry Timer C-RP Expiry Timer
The C-RP-Expiry Timer is used to time out the C-RP when the The C-RP-Expiry Timer is used to time out the state associated
BSR fails to receive C-RP-Advertisements from it. The expiry with a C-RP when the BSR fails to receive C-RP-Advertisements
timer is initialized to the HoldTime from the RP's C-RP-Adv, from it. The expiry timer is initialized to the HoldTime from
and is reset to the HoldTime whenever a C-RP-Adv is received the RP's C-RP-Adv, and is reset to the HoldTime whenever a C-
from that C-RP. RP-Adv is received from that C-RP.
C-RP Priority C-RP Priority
The C-RP Priority is used to determine the subset of possible The C-RP Priority is used to determine the subset of possible
RPs to use in the RP-Set. RPs to use in the RP-Set. Smaller values are deemed to be of
higher priority than large ones.
When the C-RP Expiry Timer expires, the C-RP is removed from the pool of When the C-RP Expiry Timer expires, the C-RP is removed from the pool of
available C-RPs. available C-RPs.
The BSR uses the pool of C-RPs to construct the RP-Set which is included The BSR uses the pool of C-RPs to construct the RP-Set which is included
in Bootstrap Messages and sent to all the routers in the PIM domain. in Bootstrap Messages and sent to all the routers in the PIM domain.
The BSR may apply a local policy to limit the number of Candidate RPs The BSR may apply a local policy to limit the number of Candidate RPs
included in the Bootstrap message. The BSR may override the prefix included in the Bootstrap message. The BSR may override the prefix
indicated in a C-RP-Adv unless the `Priority' field from the C-RP-Adv is indicated in a C-RP-Adv unless the `Priority' field from the C-RP-Adv is
less than 128. less than 128.
The Bootstrap message is subdivided into sets of group-prefix,RP- The Bootstrap message is subdivided into sets of {group-prefix, RP-
Count,RP-addresses. For each RP-address, the corresponding HoldTime is Count, RP-addresses}. For each RP-address, the corresponding HoldTime
included in the "RP-HoldTime" field. The format of the Bootstrap is included in the "RP-HoldTime" field. The format of the Bootstrap
message allows `semantic fragmentation', if the length of the original message allows `semantic fragmentation', if the length of the original
Bootstrap message exceeds the packet maximum boundaries. However, we Bootstrap message exceeds the packet maximum boundaries. However, we
recommend against configuring a large number of routers as C-RPs, to recommend against configuring a large number of routers as C-RPs, to
reduce the semantic fragmentation required. reduce the semantic fragmentation required.
When an elected BSR is being shut down, it should immediately orginate a When an elected BSR is being shut down, it should immediately originate
Bootstrap message listing its current RP set, but with the BSR priority a Bootstrap message listing its current RP set, but with the BSR
field set to the lowest priority value possible. This will cause the priority field set to the lowest priority value possible. This will
election of a new BSR to happen more quickly. cause the election of a new BSR to happen more quickly.
3.3. Forwarding Bootstrap Messages 3.3. Forwarding Bootstrap Messages
Bootstrap messages originate at the BSR, and are forwarded by Bootstrap messages originate at the BSR, and are hop-by-hop forwarded by
intermediate routers if they pass the Bootstrap Message Processing intermediate routers if they pass the Bootstrap Message Processing
Check. Bootstrap messages are multicast to the `ALL-PIM-ROUTERS' group. Check. Bootstrap messages are multicast to the `ALL-PIM-ROUTERS' group.
When A BS message is forwarded, it is forwarded out of every multicast- When a BS message is forwarded, it is forwarded out of every multicast-
capable interface which has PIM neighbors (excluding the one over which capable interface which has PIM neighbors (excluding the one over which
the message was received). The exception to this is if the interface is the message was received). The exception to this is if the interface is
an adminstrative scope boundary for the admin scope zone indicated in an administrative scope boundary for the admin scope zone indicated in
the first group address in the BS message packet. Bootstrap messages the first group address in the BS message packet. The IP source address
are always originated or forwarded with an IP TTL value of 1. on the bootstrap message should be set to the forwarding router's IP
address on the interface the message is being forwarded from. Bootstrap
messages are always originated or forwarded with an IP TTL value of 1.
3.4. Receiving and Using the RP-Set 3.4. Receiving and Using the RP-Set
When a router receives and stores a new RP-Set, it checks if each of the When a router receives and stores a new RP-Set, it checks if each of the
RPs referred to by existing state (i.e., by (*,G), (*,*,RP), or RPs referred to by existing state (i.e., by (*,G), (*,*,RP), or
(S,G,rpt) entries) is in the new RP-Set. (S,G,rpt) entries) is in the new RP-Set.
If an RP is not in the new RP-Set, that RP is considered unreachable and If an RP is not in the new RP-Set, that RP is considered unreachable and
the hash algorithm (see PIM-SM specification) is re-performed for each the hash algorithm (see PIM-SM specification) is re-performed for each
group with locally active state that previously hashed to that RP. This group with locally active state that previously hashed to that RP. This
will cause those groups to be distributed among the remaining RPs. will cause those groups to be distributed among the remaining RPs.
If the new RP-Set contains a RP that was not previously in the RP-Set, If the new RP-Set contains a RP that was not previously in the RP-Set,
the hash value of the new RP is calculated for each group covered by the the hash value of the new RP is calculated for each group covered by the
new C-RP's Group-prefix. Any group for which the new RP's hash value is new C-RP's Group-prefix. Any group for which the new RP's hash value is
greater than hash value of the group's previous RP is switched over to greater than hash value of the group's previous RP is switched over to
the new RP. the new RP.
4. Message Formats 4. Message Formats
BSR messages are PIM messages, as defined in RFC xxxx. The values of BSR messages are PIM messages, as defined in [1]. The values of the PIM
the PIM message Type field for BSR messages are: message Type field for BSR messages are:
4 Bootstrap Message 4 Bootstrap Message
8 Candidate-RP-Advertisement 8 Candidate-RP-Advertisement
In this section we use the following terms defined in the PIM-SM In this section we use the following terms defined in the PIM-SM [1]:
specification in RFC xxxx:
o Encoded-Unicast format o Encoded-Unicast format
o Encoded-Group format o Encoded-Group format
We repeat these here to aid readability. We repeat these here to aid readability.
Encoded-Unicast address Encoded-Unicast address
An Encoded-Unicast address takes the following format: An Encoded-Unicast address takes the following format:
skipping to change at page 18, line 38 skipping to change at page 18, line 30
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 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 | Encoding Type | Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family Addr Family
The PIM address family of the `Unicast Address' field of this The PIM address family of the `Unicast Address' field of this
address. address.
Values of 0-127 are as assigned by the IANA for Internet Address Values of 0-127 are as assigned by the IANA for Internet Address
Families in [1]. Values 128-250 are reserved to be assigned by the Families in [5]. Values 128-250 are reserved to be assigned by the
IANA for PIM-specific Address Families. Values 251 though 255 are IANA for PIM-specific Address Families. Values 251 though 255 are
designated for private use. As there is no assignment authority designated for private use. As there is no assignment authority
for this space, collisions should be expected. for this space, collisions should be expected.
Encoding Type Encoding Type
The type of encoding used within a specific Address Family. The The type of encoding used within a specific Address Family. The
value `0' is reserved for this field, and represents the native value `0' is reserved for this field, and represents the native
encoding of the Address Family. encoding of the Address Family.
Unicast Address Unicast Address
skipping to change at page 19, line 28 skipping to change at page 19, line 26
described above. described above.
Encoding Type Encoding Type
described above. described above.
Reserved Reserved
Transmitted as zero. Ignored upon receipt. Transmitted as zero. Ignored upon receipt.
Admin Scope [Z]one Admin Scope [Z]one
When set, this bit indicates that this group address range is an When set, this bit indicates that this group address range is an
adminstratively scoped range. administratively scoped range.
Mask Len Mask Len
The Mask length field is 8 bits. The value is the number of The Mask length field is 8 bits. The value is the number of
contiguous one bits left justified used as a mask which, combined contiguous one bits left justified used as a mask which, combined
with the group address, describes a range of groups. It is less with the group address, describes a range of groups. It is less
than or equal to the address length in bits for the given Address 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 Family and Encoding Type. If the message is sent for a single group
then the Mask length must equal the address length in bits for the then the Mask length must equal the address length in bits for the
given Address Family and Encoding Type. (e.g. 32 for IPv4 native given Address Family and Encoding Type. (e.g. 32 for IPv4 native
encoding and 128 for IPv6 native encoding). encoding and 128 for IPv6 native encoding).
Group multicast Address Group multicast Address
Contains the group address. Contains the group address.
4.1. Bootstrap Message Format 4.1. Bootstrap Message Format
A bootstrap message is divided up into `semantic fragments', if the A bootstrap message is divided up into `semantic fragments' if the
original message exceeds the maximum packet size boundaries. Basically, original message exceeds the maximum packet size boundaries. Basically,
a single bootstrap message can be sent as multiple packets (semantic a single bootstrap message can be sent as multiple packets (semantic
fragments), so long as the fragment tage of all the packets comprising fragments), so long as the fragment tags of all the packets comprising
the message is the same. the message is the same.
If the bootstrap message contains information about more than one admin If the bootstrap message contains information about more than one admin
scope zone, each different scope zone MUST occupy a different semantic scope zone, each different scope zone MUST occupy a different semantic
fragment. This allows Zone Border Routers for an admin scope zone to fragment. This allows Zone Border Routers for an admin scope zone to
not forward only those fragments that should not traverse the admin not forward only those fragments that should not traverse the admin
scope boundary. scope boundary.
The format of a single `fragment' is given below: The format of a single `fragment' is given below:
skipping to change at page 22, line 11 skipping to change at page 22, line 11
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address m (Encoded-Unicast format) | | RP Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm Holdtime | RPm Priority | Reserved | | RPm Holdtime | RPm Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Reserved, Checksum PIM Version, Reserved, Checksum
Described in RFC xxxx. Described in [1].
Type PIM Message Type. Value is 8 for a Bootstrap Message. Type PIM Message Type. Value is 8 for a Bootstrap Message.
Fragment Tag Fragment Tag
A randomly generated number, acts to distinguish the fragments A randomly generated number, acts to distinguish the fragments
belonging to different Bootstrap messages; fragments belonging to belonging to different Bootstrap messages; fragments belonging to
same Bootstrap message carry the same `Fragment Tag'. same Bootstrap message carry the same `Fragment Tag'.
Hash Mask len Hash Mask len
The length (in bits) of the mask to use in the hash function. For The length (in bits) of the mask to use in the hash function. For
skipping to change at page 22, line 34 skipping to change at page 22, line 34
BSR priority BSR priority
Contains the BSR priority value of the included BSR. This field is Contains the BSR priority value of the included BSR. This field is
considered as a high order byte when comparing BSR addresses. Note considered as a high order byte when comparing BSR addresses. Note
that for historical reasons, the highest BSR priority priority is that for historical reasons, the highest BSR priority priority is
255 (the higher the better), whereas the highest RP Priority (see 255 (the higher the better), whereas the highest RP Priority (see
below) is 0 (the lower the better). below) is 0 (the lower the better).
Unicast BSR Address Unicast BSR Address
The address of the bootstrap router for the domain. The format for The address of the bootstrap router for the domain. The format for
this address is given in the Encoded-Unicast address in RFC xxxx. this address is given in the Encoded-Unicast address in [1].
Group Address 1..n Group Address 1..n
The group prefix (address and mask) with which the Candidate RPs The group prefix (address and mask) with which the Candidate RPs
are associated. Format described in RFC xxxx. In a fragment are associated. Format described in [1]. In a fragment containing
containing admin scope ranges, the first group address in the admin scope ranges, the first group address in the fragment MUST be
fragment MUST be the group range for the entire admin scope range, the group range for the entire admin scope range, and this MUST
and this MUST have the Admin Scope bit set. This is the case even have the Admin Scope bit set. This is the case even if there are
if there are no RPs in the RP set for the entire admin scope range no RPs in the RP set for the entire admin scope range - in this
- in this case the sub-ranges for the RP set are specified later in case the sub-ranges for the RP set are specified later in the
the fragment along with their RPs. fragment along with their RPs.
RP Count 1..n RP Count 1..n
The number of Candidate RP addresses included in the whole The number of Candidate RP addresses included in the whole
Bootstrap message for the corresponding group prefix. A router does Bootstrap message for the corresponding group prefix. A router does
not replace its old RP-Set for a given group prefix until/unless it not replace its old RP-Set for a given group prefix until/unless it
receives `RP-Count' addresses for that prefix; the addresses could receives `RP-Count' addresses for that prefix; the addresses could
be carried over several fragments. If only part of the RP-Set for be carried over several fragments. If only part of the RP-Set for
a given group prefix was received, the router discards it, without a given group prefix was received, the router discards it, without
updating that specific group prefix's RP-Set. updating that specific group prefix's RP-Set.
Frag RP Cnt 1..m Frag RP Cnt 1..m
The number of Candidate RP addresses included in this fragment of The number of Candidate RP addresses included in this fragment of
the Bootstrap message, for the corresponding group prefix. The the Bootstrap message, for the corresponding group prefix. The
`Frag RP-Cnt' field facilitates parsing of the RP-Set for a given `Frag RP-Cnt' field facilitates parsing of the RP-Set for a given
group prefix, when carried over more than one fragment. group prefix, when carried over more than one fragment.
RP address 1..m RP address 1..m
The address of the Candidate RPs, for the corresponding group The address of the Candidate RPs, for the corresponding group
prefix. The format for these addresses is given in the Encoded- prefix. The format for these addresses is given in the Encoded-
Unicast address in RFC xxxx. Unicast address in [1].
RP1..m Holdtime RP1..m Holdtime
The Holdtime for the corresponding RP. This field is copied from The Holdtime for the corresponding RP. This field is copied from
the `Holdtime' field of the associated RP stored at the BSR. the `Holdtime' field of the associated RP stored at the BSR.
RP1..m Priority RP1..m Priority
The `Priority' of the corresponding RP and Encoded-Group Address. The `Priority' of the corresponding RP and Encoded-Group Address.
This field is copied from the `Priority' field stored at the BSR This field is copied from the `Priority' field stored at the BSR
when receiving a Candidate-RP-Advertisement. The highest priority when receiving a Candidate-RP-Advertisement. The highest priority
is `0' (i.e. unlike BSR priority, the lower the value of the is `0' (i.e. unlike BSR priority, the lower the value of the
`Priority' field, the better). Note that the priority is per RP `Priority' field, the better). Note that the priority is per RP
per Group Address. per Group Address.
4.1.1. Semantic Fragmentation of BSMs
Bootstrap messages may be split over several PIM Bootstrap Message
Fragment (BSMF) packets; this is known as semantic fragmentation. There
are two reasons for semantic fragmentation:
o The BSM would exceed the link MTU the packet will be forwarded
over.
o The BSM includes information about more than one admin scope zone.
Let us initially consider only the former case; the packet would be too
large because the set of group prefixes and the RPs for each group
prefix are too long to fit in one packet. The BSR will then split the
BSM across several BSMF packets; each of these must be a well-formed
BSMF packet in its own right.
If the BSR can split up the BSM so that different group prefixes (and
their RP information) can fit in different fragments, then it should do
so. If one of these BSMF packets is then lost, the state from the
previous BSM for the group-prefix from the missing packet will be
retained. Each fragment that does arrive will update the RP information
for the group-prefixes contained in that fragment, and the new group-to-
RP mapping for those can be used immediately. The information from the
missing fragment will be obtained when the BSM is next transmitted. In
this case, whilst the Fragment Tag must be set to the same value for all
BSMFs comprising a single BSM, the tag is not actually used by routers
receiving the BSM.
If the list of RPs for a single group-prefix is too long to fit in a
single BSMF packet, then that information must be split across multiple
BSMF packets. In this case, all the BSMF packets comprising the
information for that group-prefix must be received before the group-to-
RP mapping in use can be modified. This is the purpose of the RP Count
field - a router receiving BSMF packets from the same BSM (ie that have
the same fragment tag) must wait until the BSMFs providing RP Count RPs
for that group-prefix have been received before the new group-to-RP
mapping can be used for that group-prefix. In a single BSMF from such a
large group-prefix is lost, then that entire group-prefix will have to
wait until the next BSM is originated.
Next we need to consider how a BSR would remove group-prefixes from the
BSM. A router receiving a set of BSMFs cannot tell if a group-prefix is
missing. If it has seen a group-prefix before, it must assume that that
group-prefix still exists, and that the BSMF describing it has been
lost. It should retain this information for BS Timeout seconds. Thus
for a BSR to remove a group-prefix from the BSR, it should include that
group-prefix, but with a RP Count of zero, and it should resend this
information in each BSM for BS Timeout seconds.
Finally, we come to the case of fragments for the purpose of conveying
admin scope group-prefixes. In general, the information for each admin
scope range is independent of information about other admin scope
ranges. As no BSMF is allowed to convey information for more than one
admin scope range, then the procedure above also applies to BSMs that
are fragmented due to admin scoping. However, to time out all the state
for an entire admin scope zone requires waiting SZ Timeout rather than
BS Timeout, as admin scope zones are not expected to come and go
frequently.
4.2. Candidate-RP-Advertisement Format 4.2. Candidate-RP-Advertisement Format
Candidate-RP-Advertisements are periodically unicast from the C-RPs to Candidate-RP-Advertisements are periodically unicast from the C-RPs to
the BSR. the BSR.
0 1 2 3 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 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 | |PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 29 skipping to change at page 25, line 29
| Group Address 1 (Encoded-Group format) | | Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address n (Encoded-Group format) | | Group Address n (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Reserved, Checksum PIM Version, Reserved, Checksum
Described in RFC xxxx. Described in [1].
Type PIM Message Type. Value is 4 for a Candidate-RP-Advertisement Type PIM Message Type. Value is 4 for a Candidate-RP-Advertisement
Message. Message.
Prefix Cnt Prefix Cnt
The number of encoded group addresses included in the message; The number of encoded group addresses included in the message;
indicating the group prefixes for which the C-RP is advertising. A indicating the group prefixes for which the C-RP is advertising. A
Prefix Cnt of `0' implies all multicast groups, e.g. for IPv4 a Prefix Cnt of `0' implies all multicast groups, e.g. for IPv4 a
prefix of 224.0.0.0 with mask length of 4. If the C-RP is not prefix of 224.0.0.0 with mask length of 4. If the C-RP is not
configured with Group-prefix information, the C-RP puts a default configured with Group-prefix information, the C-RP puts a default
skipping to change at page 25, line 12 skipping to change at page 26, line 12
field is stored at the BSR upon receipt along with the RP address field is stored at the BSR upon receipt along with the RP address
and corresponding Encoded-Group Address. and corresponding Encoded-Group Address.
Holdtime Holdtime
The amount of time the advertisement is valid. This field allows The amount of time the advertisement is valid. This field allows
advertisements to be aged out. advertisements to be aged out.
RP Address RP Address
The address of the interface to advertise as a Candidate RP. The The address of the interface to advertise as a Candidate RP. The
format for this address is given in the Encoded-Unicast address in format for this address is given in the Encoded-Unicast address in
RFC xxxx. [1].
Group Address-1..n Group Address-1..n
The group prefixes for which the C-RP is advertising. Format The group prefixes for which the C-RP is advertising. Format
described in Encoded-Group-Address in RFC xxxx. described in Encoded-Group-Address in [1].
5. Default Values for Timers 5. Default Values for Timers
Timer Name: Bootstrap Timer (BST) Timer Name: Bootstrap Timer (BST)
+----------------------+------------------------+-----------------------+ +-------------------+--------------------------+------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
+----------------------+------------------------+-----------------------+ +-------------------+--------------------------+------------------------+
| BS Period | Default: 60 secs | Period between | | BS Period | Default: 60 secs | Period between |
| | | bootstrap messages | | | | bootstrap messages |
+----------------------+------------------------+-----------------------+ +-------------------+--------------------------+------------------------+
| BS Timeout | 2 * BS_Period + 10 | Period after last | | BS Timeout | 2 * BS_Period + 10 | Period after last |
| | seconds | BS message before | | | seconds | BS message before |
| | | BSR is timed out | | | | BSR is timed out |
| | | and election | | | | and election |
| | | begins | | | | begins |
+----------------------+------------------------+-----------------------+ +-------------------+--------------------------+------------------------+
| BS randomized | rand(0, 5.0 secs) | Suppression period | | rand_override | rand(0, 5.0 secs) | Suppression period |
| override interval | | in BSR election to | | | | in BSR election to |
| | | prevent thrashing | | | | prevent thrashing |
+----------------------+------------------------+-----------------------+ +-------------------+--------------------------+------------------------+
Timer Name: C-RP Expiry Timer (CET(R)) Timer Name: C-RP Expiry Timer (CET(R))
+----------------+------------------+-----------------------------------+ +----------------+------------------+-----------------------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
+----------------+------------------+-----------------------------------+ +----------------+------------------+-----------------------------------+
| C-RP Timeout | from message | Hold time from C-RP-Adv message | | C-RP Timeout | from message | Hold time from C-RP-Adv message |
+----------------+------------------+-----------------------------------+ +----------------+------------------+-----------------------------------+
C-RP Advertisement messages are sent periodically with period C-RP-Adv- C-RP Advertisement messages are sent periodically with period C-RP-Adv-
skipping to change at page 26, line 33 skipping to change at page 27, line 30
+------------------------------------+--------------+-------------------+ +------------------------------------+--------------+-------------------+
|Value Name Value Explanation | | | |Value Name Value Explanation | | |
+------------------------------------+--------------+-------------------+ +------------------------------------+--------------+-------------------+
|SZ Timeout |1500 seconds |Interval after | |SZ Timeout |1500 seconds |Interval after |
| | |which a scope zone | | | |which a scope zone |
| | |will be timed out | | | |will be timed out |
| | |if the state is | | | |if the state is |
| | |not refreshed | | | |not refreshed |
+------------------------------------+--------------+-------------------+ +------------------------------------+--------------+-------------------+
6. Authors' Addresses 6. Security Considerations
6.1. Possible Threats
Threats affecting the PIM BSR mechanism are primarily of two forms:
denial of service attacks, and traffic diversion attacks. An attacker
that subverts the BSR mechanism can prevent multicast traffic from
reaching the intended recipients, can divert multicast traffic to a
place where they can monitor it, and can potentially flood third parties
with traffic.
Traffic can be prevented from reaching the intended recipients by one of
two mechanisms:
o Subverting a BSM, and specifying RPs that won't actually forward
traffic.
o Registering with the BSR as a C-RP, and then not forwarding
traffic.
Traffic can be diverted to a place where it can be monitored by both of
the above mechanisms; in this case the RPs would forward the traffic,
but are located so as to aid monitoring or man-in-the-middle attacks on
the multicast traffic.
A third party can be flooded by either of the above two mechanisms by
specifying the third party as the RP, and register-encapsulated traffic
will then be forwarded to them.
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 receives
one of these responses to a data packet it has 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 implementator 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.
6.3. BS Message Security
If a legitimate PIM router is compromised, there is little any security
mechanism can do to prevent that router subverting PIM traffic in that
domain. However we recommend that implementors provide a mechanism
whereby a PIM router using the BSR mechanisms can be configured with the
IP addresses of valid BSR routers, and that any BS Message from any
other BSR should then be dropped and logged as a security issue. We
also recommend that this not be enabled by default, as it makes the
initial configuration of a PIM domain problematic - it is the sort of
feature that might be enabled once the configuration of a domain has
stabilized.
The primary security requirement for BSR (as for PIM) is that it is
possible to prevent hosts that are not legitimate PIM routers, either
within or outside the domain, from subverting the BSR mechanism.
The Bootstrap Message Processing Checks prevent a router from accepting
a BS message from outside of the PIM Domain, as the source address on BS
Messages must be an immediate PIM neighbor. There is however a small
window of time after a reboot where a PIM router will accept a bad BS
Message unicast from an immediate neighbor, and it might be possible to
unicast a BS Message to a router during this interval from outside the
domain, using the spoofed source address of a neighbor. This can be
prevented if PMBRs perform source-address filtering to prevent packets
entering the PIM domain with IP source addresses that are infrastructure
addresses in the PIM domain.
The principle threat to BS Message security comes from hosts within the
PIM domain that attempt to subvert the BSR mechanism. They may be able
to do this by sending PIM messages to their local router, or by
unicasting a BS message to another PIM router during the brief interval
after it has restarted.
All BS Messages SHOULD carry the Router Alert IP option. If a PIM
router receives a BS Message that does not carry the router alert
option, it SHOULD drop it (a configuration option should also be
provided to disable this check on a per-interface basic for backward
compatibility with older PIM routers). The Router Alert option allows a
PIM router to perform checks on unicast packets it would otherwise
blindly forward. All PIM routers should check that packets with Router
Alert that are not destined for the router itself are not PIM BootStrap
messages. Any such packets should be dropped and logged as a possible
security issue - it is never acceptable for a PIM BS message to travel
multiple IP hops.
Most hosts that are likely to attempt to subvert PIM BSR are likely to
be located on leaf subnets. We recommend that implementors provide a
configuration option that specifies an interface is a leaf subnet, and
that no PIM packets are accepted on such interfaces.
On multi-access subnets with multiple PIM routers and hosts that are not
trusted, we recommend that IPsec AH is used to protect communication
between PIM routers, and that such routers are configured to drop and
log communication attempts from any host that do not pass the
authentication check. When all the PIM routers are under the same
administrative control, this authentication may use a configured shared
secret. The securing of interactions between PIM neighbors is discussed
in more detail in the Security Considerations section of [1], and so we
do not discuss the details further here. The same security mechanisms
than can be used to secure PIM Join, Prune and Assert messages should
also be used to secure BS messages.
6.4. C-RP-Advertisement Security
Even if it is not possible to subvert BS Messages, an attacker might be
able to perform most of the same attacks by simply sending C-RP-Adv
messages to the BSR specifying the attacker's choice of RPs. Thus it is
necessary to control the sending of C-RP-Adv messages in essentially the
same ways that we control BS Messages. However, C-RP-Adv messages are
unicast and normally travel multiple hops, so controlling them is a
little harder.
We specify that C-RP-Adv messages SHOULD also carry the Router Alert IP
option, and that the BSR SHOULD by default drop and log C-RP-Adv
messages that do not carry this option. Setting Router Alert on these
packets is practical because the rate of C-RP-Adv messages should be
very low, so the extra load on routers forwarding these packets will be
insignificant. All PIM routers forwarding such a packet are then
capable of checking whether the packet came from a valid neighbor. On
interfaces that are configured to be leaf subnets, all C-RP-Adv messages
should be dropped. On multi-access subnets with multiple PIM routers
and hosts that are not trusted, the router can at least check that the
source MAC address is that of a valid PIM neighbor. PMBRs should ensure
that no C-RP-Adv messages enter the domain from an external neighbor.
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 authentication process
for PIM Register messages between a DR and the relevant RP, except that
there will normally be fewer C-RPs in a domain than there are DRs, so
key management is a little simpler. We do not describe the details of
this process further here, but refer to the Security Considerations
section of [1]. Note that the use of cryptographic security for C-RP-
Advs does not remove the need for the non-cryptographic mechanisms, as
explained below.
6.5. Denial of Service using IPsec
An additional concern is that of Denial-of-Service attacks caused by
sending high volumes of BS Messages or C-RP-Adv messages with invalid
IPsec authentication information. It is possible that these messages
could overwhelm the CPU resources of the recipient.
The non-cryptographic security mechanisms above prevent unicast BS
messages from traveling multiple hops, and constrain who can originate
such messages. However, it is obviously important that PIM Messages
that are required to have Router Alert checked are checked for this
option before the IPsec AH is checked. Thus the remaining vulnerability
primarily exists for hosts on multi-access subnets containing more than
one PIM router. A PIM router receiving PIM packets with Router Alert
set from such a subnet should already be checking that the source MAC
address is that of a valid PIM neighbor, but this is hardly strong
security. In addition, we recommend that rate-limiting mechanisms can
be configured, to be applied to the forwarding of unicast PIM packets
containing Router Alert options. The rate-limiter MUST independently
rate-limit different types of PIM packets - for example a flood of C-RP-
Adv messages MUST NOT cause a rate limiter to drop low-rate BS Messages.
Such a rate-limiter might itself be used to cause a denial of service
attack by causing valid packets to be dropped, but in practice this is
more likely to constrain bad PIM Messages close to their origin. In
addition, the rate limiter will prevent attacks on PIM from affecting
other activity on the destination router, such as unicast routing.
7. Authors' Addresses
Bill Fenner Bill Fenner
AT&T Labs - Research AT&T Labs - Research
75 Willow Road 75 Willow Road
Menlo Park, CA 94025 Menlo Park, CA 94025
fenner@research.att.com fenner@research.att.com
Mark Handley Mark Handley
ACIRI/ICSI ACIRI/ICSI
1947 Center St, Suite 600 1947 Center St, Suite 600
Berkeley, CA 94708 Berkeley, CA 94708
mjh@aciri.org mjh@aciri.org
Roger Kermode
Motorola Australian Research Centre
Locked Bag 5028
Botany NSW 1455,
Australia
Roger.Kermode@motorola.com
David Thaler David Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
dthaler@Exchange.Microsoft.com dthaler@Exchange.Microsoft.com
7. References 8. References
[1] IANA, "Address Family Numbers", linked from [1] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Internet Draft draft-ietf-pim-sm-
v2-new-03.ps
[2] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode
(PIM-SM): Protocol Specification", RFC 2362, June 1998 (now
obsolete).
[3] W. Fenner, "Internet Group Management Protocol, Version 2", RFC
2236, Nov 1997.
[4] S. Deering , W. Fenner , B. Haberman, "Multicast Listener Discovery
(MLD) for IPv6", RFC 2710, Oct 1999.
[5] IANA, "Address Family Numbers", linked from
http://www.iana.org/numbers.html http://www.iana.org/numbers.html
8. Acknowledgments 9. Acknowledgments
PIM-SM was designed over many years by a large group of people, PIM-SM was designed over many years by a large group of people,
including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve
Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri,
Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern,
Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish
Chandranmenon, and Pavlin Radoslavov. This BSR specification draws Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas and Hugh
heavily on text from RFC 2362. Holbrook. This BSR specification draws heavily on text from RFC 2362.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/