draft-ietf-pim-sm-bsr-10.txt   draft-ietf-pim-sm-bsr-11.txt 
Internet Engineering Task Force PIM WG Internet Engineering Task Force PIM WG
INTERNET-DRAFT Nidhi Bhaskar/Cisco INTERNET-DRAFT Nidhi Bhaskar/Arastra
draft-ietf-pim-sm-bsr-10.txt Alexander Gall/SWITCH draft-ietf-pim-sm-bsr-11.txt Alexander Gall/SWITCH
James Lingard/Arastra James Lingard/Arastra
Stig Venaas/UNINETT Stig Venaas/UNINETT
9 February 2007 Expires: January 2008
Expires: August 2007
Bootstrap Router (BSR) Mechanism for PIM Bootstrap Router (BSR) Mechanism for PIM
Status of this Document Status of this Document
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware will been or will be disclosed, and any of which he or she becomes aware will
be disclosed, in accordance with Section 6 of BCP 79. be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 3, line 11 skipping to change at page 3, line 11
mappings required in order to function. The mechanism is mappings required in order to function. The mechanism is
dynamic, largely self-configuring, and robust to router dynamic, largely self-configuring, and robust to router
failure. failure.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 5
1.1. Background . . . . . . . . . . . . . . . . . . . . . 5 1.1. Background . . . . . . . . . . . . . . . . . . . . . 5
1.2. Protocol Overview. . . . . . . . . . . . . . . . . . 7 1.2. Protocol Overview. . . . . . . . . . . . . . . . . . 7
1.3. Administrative Scoping and BSR . . . . . . . . . . . 8 1.3. Administrative Scoping and BSR . . . . . . . . . . . 8
2. BSR State and Timers. . . . . . . . . . . . . . . . . . 9 2. BSR State and Timers. . . . . . . . . . . . . . . . . . 10
3.1. Bootstrap Router Election and RP-Set 3. Bootstrap Router Election and RP-Set
Distribution . . . . . . . . . . . . . . . . . . . . 11 Distribution. . . . . . . . . . . . . . . . . . . . . . 11
3.1. Bootstrap Router Election. . . . . . . . . . . . . . 11 3.1. Bootstrap Router Election. . . . . . . . . . . . . . 11
3.1.1. Per-Scope-Zone Candidate-BSR State 3.1.1. Per-Scope-Zone Candidate-BSR State
Machine . . . . . . . . . . . . . . . . . . . . . 11 Machine . . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Per-Scope-Zone State Machine for Non- 3.1.2. Per-Scope-Zone State Machine for Non-
Candidate-BSR Routers . . . . . . . . . . . . . . 13 Candidate-BSR Routers . . . . . . . . . . . . . . 13
3.1.3. Bootstrap Message Processing Checks . . . . . . . 15 3.1.3. Bootstrap Message Processing Checks . . . . . . . 15
3.1.4. State Machine Transition Events . . . . . . . . . 16 3.1.4. State Machine Transition Events . . . . . . . . . 16
3.1.5. State Machine Actions . . . . . . . . . . . . . . 17 3.1.5. State Machine Actions . . . . . . . . . . . . . . 17
3.2. Sending Candidate-RP-Advertisement Messages. . . . . 18 3.2. Sending Candidate-RP-Advertisement Messages. . . . . 19
3.3. Creating the RP-Set at the BSR . . . . . . . . . . . 20 3.3. Creating the RP-Set at the BSR . . . . . . . . . . . 21
3.4. Forwarding Bootstrap Messages. . . . . . . . . . . . 22 3.4. Forwarding Bootstrap Messages. . . . . . . . . . . . 23
3.5. Bootstrap Messages to New and Rebooting 3.5. Bootstrap Messages to New and Rebooting
Routers. . . . . . . . . . . . . . . . . . . . . . . 23 Routers. . . . . . . . . . . . . . . . . . . . . . . 24
3.5.1. No-Forward Bootstrap Messages . . . . . . . . . . 24 3.5.1. No-Forward Bootstrap Messages . . . . . . . . . . 25
3.5.2. Unicasting Bootstrap Messages . . . . . . . . . . 24 3.5.2. Unicasting Bootstrap Messages . . . . . . . . . . 25
3.6. Receiving and Using the RP-Set . . . . . . . . . . . 24 3.6. Receiving and Using the RP-Set . . . . . . . . . . . 25
4. Message Formats . . . . . . . . . . . . . . . . . . . . 24 4. Message Formats . . . . . . . . . . . . . . . . . . . . 25
4.1. Bootstrap Message Format . . . . . . . . . . . . . . 27 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 28
4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 31 4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 31
4.2. Candidate-RP-Advertisement Message Format. . . . . . 32 4.2. Candidate-RP-Advertisement Message Format. . . . . . 33
5. Timers and Timer Values . . . . . . . . . . . . . . . . 34 5. Timers and Timer Values . . . . . . . . . . . . . . . . 35
6. Security Considerations . . . . . . . . . . . . . . . . 37 6. Security Considerations . . . . . . . . . . . . . . . . 38
6.1. Possible Threats . . . . . . . . . . . . . . . . . . 37 6.1. Possible Threats . . . . . . . . . . . . . . . . . . 38
6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 38 6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 39
6.3. Bootstrap Message Security . . . . . . . . . . . . . 38 6.3. Bootstrap Message Security . . . . . . . . . . . . . 39
6.3.1. Rejecting Bootstrap Messages from Invalid 6.3.1. Rejecting Bootstrap Messages from Invalid
Neighbors . . . . . . . . . . . . . . . . . . . . 39 Neighbors . . . . . . . . . . . . . . . . . . . . 40
6.4. Candidate-RP-Advertisement Message Security. . . . . 39 6.4. Candidate-RP-Advertisement Message Security. . . . . 40
6.4.1. Non-Cryptographic Security of C-RP-Adv 6.4.1. Non-Cryptographic Security of C-RP-Adv
Messages. . . . . . . . . . . . . . . . . . . . . 39 Messages. . . . . . . . . . . . . . . . . . . . . 41
6.4.2. Cryptographic Security of C-RP-Adv 6.4.2. Cryptographic Security of C-RP-Adv
Messages. . . . . . . . . . . . . . . . . . . . . 40 Messages. . . . . . . . . . . . . . . . . . . . . 41
6.5. Denial of Service using IPsec. . . . . . . . . . . . 40 6.5. Denial of Service using IPsec. . . . . . . . . . . . 41
7. Contributors. . . . . . . . . . . . . . . . . . . . . . 41 7. Contributors. . . . . . . . . . . . . . . . . . . . . . 42
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 41 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 42
9. IANA Considerations . . . . . . . . . . . . . . . . . . 41 9. IANA Considerations . . . . . . . . . . . . . . . . . . 42
10. Normative References . . . . . . . . . . . . . . . . . 41 10. Normative References . . . . . . . . . . . . . . . . . 42
11. Informative References . . . . . . . . . . . . . . . . 42 11. Informative References . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This document assumes some familiarity with the concepts of Protocol This document assumes some familiarity with the concepts of Protocol
Independent Multicast - Sparse Mode (PIM-SM), as defined in [1], and Bi- Independent Multicast - Sparse Mode (PIM-SM), as defined in [1], and Bi-
directional Protocol Independent Multicast (BIDIR-PIM), as defined in directional Protocol Independent Multicast (BIDIR-PIM), as defined in
[2], as well as with Administratively Scoped IP Multicast, as described [2], as well as with Administratively Scoped IP Multicast, as described
in [3], and the IPv6 Scoped Address Architecture, described in [4]. in [3], and the IPv6 Scoped Address Architecture, described in [4].
For correct operation, every multicast router within a PIM domain must For correct operation, every multicast router within a PIM domain must
be able to map a particular multicast group address to the same be able to map a particular multicast group address to the same
Rendezvous Point (RP). The PIM specifications do not mandate the use of Rendezvous Point (RP). The PIM specifications do not mandate the use of
a single mechanism to provide routers with the information to perform a single mechanism to provide routers with the information to perform
this group-to-RP mapping. this group-to-RP mapping.
This document describes the PIM Bootstrap Router (BSR) mechanism. BSR This document describes the PIM Bootstrap Router (BSR) mechanism. BSR
is one way that a multicast router can learn the information required to is one way that a multicast router can learn the information required to
perform the group-to-RP mapping. The mechanism is dynamic, largely perform the group-to-RP mapping. The mechanism is dynamic, largely
self-configuring, and robust to router failure. self-configuring, and robust to router failure.
BSR was first defined in RFC 2362 [7], which has since been obsoleted. BSR was first defined in RFC 2362 [7] as part of the original PIM-SM
This document provides an updated specification of the BSR mechanism specification, which has been obsoleted by RFC 4601 [1]. This document
from RFC 2362, and also extends it to cope with administratively scoped provides an updated specification of the BSR mechanism from RFC 2362,
region boundaries and different flavors of routing protocols. and also extends it to cope with administratively scoped region
boundaries and different flavors of routing protocols.
Throughout the document, any reference to the PIM protocol family is Throughout the document, any reference to the PIM protocol family is
restricted to the subset of RP-based protocols, namely PIM-SM and BIDIR- restricted to the subset of RP-based protocols, namely PIM-SM and BIDIR-
PIM, unless stated otherwise. PIM, unless stated otherwise.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [6]. document are to be interpreted as described in RFC 2119 [6].
1.1. Background 1.1. Background
skipping to change at page 8, line 29 skipping to change at page 8, line 29
This time will be on the order of the region's round-trip time and the This time will be on the order of the region's round-trip time and the
BS_Timeout value. BS_Timeout value.
1.3. Administrative Scoping and BSR 1.3. Administrative Scoping and BSR
The mechanism described in the previous section does not work when the The mechanism described in the previous section does not work when the
PIM domain is divided into administratively scoped regions. To handle PIM domain is divided into administratively scoped regions. To handle
this situation, we use the protocol modifications described in this this situation, we use the protocol modifications described in this
section. section.
In the remainder of this document we will use the term scope zone, or
simply zone, when we are talking about a connected region of topology of
a given scope. For a more precise definition of scope zones, see [4]
emphasize that the scope zones are administratively configured.
Administrative scoping permits a PIM domain to be divided into multiple Administrative scoping permits a PIM domain to be divided into multiple
admin-scope regions. Each admin-scope region is a convex connected set admin-scope zones. Each admin-scope zone is a convex connected set of
of PIM routers, and is associated with a set of group addresses. The PIM routers, and is associated with a set of group addresses. The
boundary of the admin-scope region is formed by Zone Border Routers boundary of the admin-scope zone is formed by Zone Border Routers
(ZBRs). ZBRs are configured not to forward traffic for any of the (ZBRs). ZBRs are configured not to forward traffic for any of the
scoped group addresses into or out of the scoped region. It is scoped group addresses into or out of the scoped zone. It is important
important to note that a given scope boundary always creates at least to note that a given scope boundary always creates at least two scoped
two scoped regions: one on either side of the boundary. zones: one on either side of the boundary.
In IPv4, administratively scoped regions are associated with a set of In IPv4, administratively scoped zones are associated with a set of
addresses given by an address and a prefix length. In IPv6, addresses given by an address and a prefix length. In IPv6,
administratively scoped regions are associated with a set of addresses administratively scoped zones are associated with a set of addresses
given by a single scope ID value. The set of addresses corresponding to given by a single scope ID value. The set of addresses corresponding to
a given scope ID value is defined in [5]. For example, a scope ID of 5 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. maps to the 16 IPv6 address ranges ff[0-f]5::/16.
There are certain topological restrictions on admin-scope regions. The There are certain topological restrictions on admin-scope zones. The
scope zone border must be complete and convex. By this we mean that scope zone border must be complete and convex. By this we mean that
there must be no path from inside the scoped zone to outside it that there must be no path from inside the scoped zone to outside it that
does not pass through a configured scope border router, and that the does not pass through a configured scope border router, and that the
multicast capable path between any arbitrary pair of multicast routers multicast capable path between any arbitrary pair of multicast routers
in the scope zone must remain in the zone. in the scope zone must remain in the zone.
Administrative scoping complicates BSR because we do not want a PIM Administrative scoping complicates BSR because we do not want a PIM
router within the scoped region to use an RP outside the scoped region. router within the scoped zone to use an RP outside the scoped zone.
Thus we need to modify the basic mechanism to ensure that this doesn't Thus we need to modify the basic mechanism to ensure that this doesn't
happen. happen.
This is done by running a separate copy of the basic BSR mechanism, as This is done by running a separate copy of the basic BSR mechanism, as
described in the previous section, within each admin scope region of a described in the previous section, within each admin scope zone of a PIM
PIM domain. Thus a separate BSR election takes place for each admin- domain. Thus a separate BSR election takes place for each admin-scope
scope region, a C-RP typically registers to the BSR of every admin scope zone, a C-RP typically registers to the BSR of every admin scope zone it
zone it is in, and every PIM router receives Bootstrap messages for is in, and every PIM router receives Bootstrap messages for every scope
every scope zone it is in. The Bootstrap messages sent by the BSR for a zone it is in. The Bootstrap messages sent by the BSR for a particular
particular scope zone contain information about the RPs that should be scope zone contain information about the RPs that should be used for the
used for the set of addresses associated with that scope zone. set of addresses associated with that scope zone.
Bootstrap messages are marked to indicate which scope zone they belong Bootstrap messages are marked to indicate which scope zone they belong
to. Such admin scoped Bootstrap messages are flooded in the normal way, to. Such admin scoped Bootstrap messages are flooded in the normal way,
but will not be forwarded by a ZBR across the boundary for that scope but will not be forwarded by a ZBR across the boundary for that scope
zone. zone.
For the BSR mechanism to function correctly with admin scoping, within For the BSR mechanism to function correctly with admin scoping, within
each admin scope region there must be at least one C-BSR, and at least each admin scope zone there must be at least one C-BSR, and at least one
one C-RP that is configured to be a C-RP for the set of group addresses C-RP that is configured to be a C-RP for the set of group addresses
associated with the scoped region. associated with the scoped zone.
Even when administrative scoping is used, a copy of the BSR mechanism is Even when administrative scoping is used, a copy of the BSR mechanism is
still used across the entire PIM domain, in order to distribute RP still used across the entire PIM domain, in order to distribute RP
information for groups that are not administratively scoped. We call information for groups that are not administratively scoped. We call
this copy of the mechanism Non-Scoped BSR. The copies of the mechanism this copy of the mechanism Non-Scoped BSR. The copies of the mechanism
run for each admin-scope region are called Scoped BSR. run for each admin-scope zone are called Scoped BSR.
Only the C-BSRs and the ZBRs need to be configured to know about the Only the C-BSRs and the ZBRs need to be configured to know about the
existence of the scope zones. Other routers, including the C-RPs, learn existence of the scope zones. Other routers, including the C-RPs, learn
of their existence from Bootstrap messages. of their existence from Bootstrap messages.
All PIM routers within a PIM bootstrap domain where admin scope ranges All PIM routers within a PIM bootstrap domain where admin scope ranges
are in use must be capable of receiving Bootstrap messages and storing are in use must be capable of receiving Bootstrap messages and storing
the winning BSR and RP-Set for all admin scope zones that apply. Thus the winning BSR and RP-Set for all admin scope zones that apply. Thus
PIM routers that only implement RFC 2362 or Non-Scoped BSR (which only PIM routers that only implement RFC 2362 or Non-Scoped BSR (which only
allows one BSR per domain) cannot be used within the admin-scope regions allows one BSR per domain) cannot be used within the admin-scope zones
of a PIM domain. of a PIM domain.
2. BSR State and Timers 2. BSR State and Timers
A PIM router implementing BSR holds the following state. A PIM router implementing BSR holds the following state.
RP-Set RP-Set
Per Configured or Learned Scope Zone (Z): Per Configured or Learned Scope Zone (Z):
At all routers: At all routers:
Current Bootstrap Router's IP Address Current Bootstrap Router's IP Address
Current Bootstrap Router's BSR Priority Current Bootstrap Router's BSR Priority
Last BSM received from current BSR Last BSM received from current BSR
skipping to change at page 13, line 18 skipping to change at page 13, line 18
information, and used in the election process to terminate P-BSR information, and used in the election process to terminate P-BSR
state. state.
The initial state for this configured scope zone is "Pending-BSR"; the The initial state for this configured scope zone is "Pending-BSR"; the
Bootstrap Timer is initialized to BS_Rand_Override. This is the case Bootstrap Timer is initialized to BS_Rand_Override. This is the case
both if the router is a Candidate BSR at startup, and if reconfigured to both if the router is a Candidate BSR at startup, and if reconfigured to
become one later. become one later.
3.1.2. Per-Scope-Zone State Machine for Non-Candidate-BSR Routers 3.1.2. Per-Scope-Zone State Machine for Non-Candidate-BSR Routers
The following state machine is used for scope zones which are discovered
by the router from bootstrap messages. A simplified state machine is
used for scope zones which are explicitely configured on the router and
for the global zone. The differences are listed at the end of this
section.
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in NoInfo state | | When in NoInfo state |
+---------------------+-------------------------------------------------+ +---------------------+-------------------------------------------------+
| Event | Receive BSM | | Event | Receive BSM |
+---------------------+-------------------------------------------------+ +---------------------+-------------------------------------------------+
| | -> AP state | | | -> AP state |
| Action | Forward BSM; Store RP-Set; | | Action | Forward BSM; Store RP-Set; |
| | Set Bootstrap Timer to BS_Timeout; | | | Set Bootstrap Timer to BS_Timeout |
| | Set SZT to SZ_Timeout |
+---------------------+-------------------------------------------------+ +---------------------+-------------------------------------------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in Accept Any state | | When in Accept Any state |
+---------------+----------------------------+--------------------------+ +---------------+----------------------------+--------------------------+
| Event | Receive BSM | Scope-Zone Expiry | | Event | Receive BSM | Scope-Zone Expiry |
| | | Timer Expires | | | | Timer Expires |
+---------------+----------------------------+--------------------------+ +---------------+----------------------------+--------------------------+
| | -> AP state | -> NoInfo state | | | -> AP state | -> NoInfo state |
| | Forward BSM; Store | Cancel timers; | | | Forward BSM; Store | Remove scope zone |
| Action | RP-Set; Set | Clear state | | Action | RP-Set; Set | state |
| | Bootstrap Timer to | | | | Bootstrap Timer to | |
| | BS_Timeout; Set | | | | BS_Timeout | |
| | SZT to SZ_Timeout | |
+---------------+----------------------------+--------------------------+ +---------------+----------------------------+--------------------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in Accept Preferred state | | When in Accept Preferred state |
+----------+-----------------------+------------------+-----------------+ +----------+----------------------+-------------------+-----------------+
| Event | Receive Preferred | Bootstrap | Receive Non- | | Event | Receive Preferred | Bootstrap | Receive Non- |
| | BSM | Timer Expires | preferred BSM | | | BSM | Timer Expires | preferred BSM |
+----------+-----------------------+------------------+-----------------+ +----------+----------------------+-------------------+-----------------+
| | -> AP state | -> AA state | -> AP state | | | -> AP state | -> AA state | -> AP state |
| | Forward BSM; Store | Refresh RP- | | | | Forward BSM; Store | Refresh RP- | |
| Action | RP-Set; Set | Set; Remove | | | Action | RP-Set; Set | Set; Remove | |
| | Bootstrap Timer to | BSR state | | | | Bootstrap Timer to | BSR state; Set | |
| | BS_Timeout; Set SZT | | | | | BS_Timeout | SZT to | |
| | to SZ_Timeout | | | | | | SZ_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:
NoInfo NoInfo
The router has no information about this scope zone. This state The router has no information about this scope zone. When in this
does not apply if the router is configured to know about this scope state, no state information is held and no timers run that refer to
zone, or for the global scope zone. When in this state, no state this scope zone. Conceptually, the state machine is only
information is held and no timers run that refer to this scope instantiated when the router receives a scoped BSM for a scope
zone. about which it has no prior knowledge. However, because the router
immediately transitions to the AA state unconditionally, the NoInfo
state can be considered to be virtual in a certain sense. For this
reason, it is omitted from the description in section 2.
Accept Any (AA) Accept Any (AA)
The router does not know of an active BSR, and will accept the The router does not know of an active BSR, and will accept the
first Bootstrap message it sees as giving the new BSR's identity first Bootstrap message it sees as giving the new BSR's identity
and the RP-Set. and the RP-Set.
Accept Preferred (AP) Accept Preferred (AP)
The router knows the identity of the current BSR, and is using the The router knows the identity of the current BSR, and is using the
RP-Set provided by that BSR. Only Bootstrap messages from that BSR RP-Set provided by that BSR. Only Bootstrap messages from that BSR
or from a C-BSR with higher weight than the current BSR will be or from a C-BSR with higher weight than the current BSR will be
accepted. accepted.
In addition to the three states, there are two timers: In addition to the three states, there are two timers:
o The Bootstrap Timer (BST) - used to time out old bootstrap router o The Bootstrap Timer (BST) - used to time out old bootstrap router
information. information.
o The Scope-Zone Expiry Timer (SZT) - used to time out the scope zone o The Scope-Zone Expiry Timer (SZT) - used to time out the scope zone
itself if Bootstrap messages specifying this scope zone stop arriving. itself if Bootstrap messages specifying this scope zone stop arriving.
On startup, the initial state for this scope zone is "Accept Any" for The initial state for scope zones about which the router has no
routers that know about this scope zone, either through configuration or knowledge is "NoInfo".
because the scope zone is the global scope which always exists; the
Scope-Zone Expiry Timer is considered to be always running for such The state machine used for scopes which have been configured explicitely
scope zones. For routers that do not know about a particular scope on the router and for the global scope, which always exists, differs
zone, the initial state is NoInfo; no timers exist for the scope zone. from the state machine above as follows.
o The "NoInfo" state doesn't exist.
o No SZT is maintained. Hence, the event "Scope-Zone Expiry Timer
Expires" does not exist and no actions with regard to this timer
are executed.
The initial state for this state machine is "Accept Any".
3.1.3. Bootstrap Message Processing Checks 3.1.3. 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 if ((DirectlyConnected(BSM.src_ip_address) == FALSE) OR
(we have no Hello state for BSM.src_ip_address)) { (we have no Hello state for BSM.src_ip_address)) {
drop the Bootstrap message silently drop the Bootstrap message silently
} }
skipping to change at page 16, line 33 skipping to change at page 17, line 29
from Elected BSR case.) from Elected BSR case.)
The weight of a BSR is defined to be the concatenation in The weight of a BSR is defined to be the concatenation in
fixed-precision unsigned arithmetic of the BSR Priority field fixed-precision unsigned arithmetic of the BSR Priority field
from the Bootstrap message and the IP address of the BSR from from the Bootstrap message and the IP address of the BSR from
the Bootstrap message (with the BSR Priority taking the most- the 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 Non-preferred BSM Receive Non-preferred BSM
A Bootstrap message is received from a BSR that has lower A Bootstrap message is received from a BSR other than the
weight than the current BSR. If a router is in P-BSR state, current BSR that has lower weight than the current BSR. If a
then it uses its own weight as that of the current BSR. router is in P-BSR state, then it uses its own weight as that
of the current BSR.
Receive Non-preferred BSM from Elected BSR Receive Non-preferred BSM from Elected BSR
A Bootstrap message is received from the elected BSR, but the A Bootstrap message is received from the elected BSR, but the
BSR Priority field in the received message has changed, so BSR Priority field in the received message has changed, so
that now the currently elected BSR has lower weight that the that now the currently elected BSR has lower weight than the
router itself. router itself.
Receive BSM Receive BSM
A Bootstrap message is received, regardless of BSR weight. A Bootstrap message is received, regardless of BSR weight.
In addition to state machine transitions caused by the receipt of In addition to state machine transitions caused by the receipt of
Bootstrap messages, a state machine transition takes place each time the Bootstrap messages, a state machine transition takes place each time the
Bootstrap Timer or Scope-Zone Expiry Timer expires. Bootstrap Timer or Scope-Zone Expiry Timer expires.
3.1.5. State Machine Actions 3.1.5. State Machine Actions
skipping to change at page 18, line 25 skipping to change at page 19, line 19
Refresh RP-Set Refresh RP-Set
When the Bootstrap Timer expires, the router uses the copy of When the Bootstrap Timer expires, the router uses the copy of
the last BSM that it has received to refresh its RP-Set the last BSM that it has received to refresh its RP-Set
according to the action Store RP-Set as if it had just according to the action Store RP-Set as if it had just
received it. This will increase the chance that the group-to- received it. This will increase the chance that the group-to-
RP mappings will not expire during the election of the new RP mappings will not expire during the election of the new
BSR. BSR.
Remove BSR state Remove BSR state
When the Bootstrap Timer expires, all state associated with When the Bootstrap Timer expires, all state associated with
the current BSR is removed (see section 2). Note that this the current BSR is removed (address, priority, BST and saved
does not include any group-to-RP mappings. last BSM, see section 2). Note that this does not include any
group-to-RP mappings.
Remove scope zone state
When the Scop-Zone Expiry Timer expires, all state associated
with the scope zone is removed (see section 2).
3.2. Sending Candidate-RP-Advertisement Messages 3.2. Sending Candidate-RP-Advertisement Messages
Every C-RP periodically unicasts a C-RP-Adv message to the BSR for each Every C-RP periodically unicasts a C-RP-Adv message to the BSR for each
scope zone for which it has state, to inform the BSR of the C-RP's scope zone for which it has state, to inform the BSR of the C-RP's
willingness to function as an RP. These messages are sent with an willingness to function as an RP. These messages are sent with an
interval of C_RP_Adv_Period, except when a new BSR is elected, see interval of C_RP_Adv_Period, except when a new BSR is elected, see
below. below.
When a new BSR is elected, the C-RP MUST send one to three C-RP-Adv When a new BSR is elected, the C-RP MUST send one to three C-RP-Adv
skipping to change at page 19, line 4 skipping to change at page 19, line 51
C_RP_Adv_Backoff when the new BSR is elected, as well as setting a C_RP_Adv_Backoff when the new BSR is elected, as well as setting a
counter to 2. Whenever the CRPT expires, we first send a C-RP-Adv counter to 2. Whenever the CRPT expires, we first send a C-RP-Adv
message as usual. Next, if the counter is non-zero, it is decremented message as usual. Next, if the counter is non-zero, it is decremented
and the CRPT is again set to C_RP_Adv_Backoff instead of and the CRPT is again set to C_RP_Adv_Backoff instead of
C_RP_Adv_Period. C_RP_Adv_Period.
The Priority field in these messages is used by the BSR to select which The Priority field in these messages is used by the BSR to select which
C-RPs to include in the RP-Set. Note that lower values of this field C-RPs to include in the RP-Set. Note that lower values of this field
indicate higher priorities, so that a value of zero is the highest indicate higher priorities, so that a value of zero is the highest
possible priority. C-RPs should by default send C-RP-Adv messages with possible priority. C-RPs should by default send C-RP-Adv messages with
the Priority field set to 192. the Priority field set to 192.
When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv
message to the BSR for each scope zone for which it is currently serving message to the BSR for each scope zone for which it is currently serving
as an RP; the Holdtime in this C-RP-Adv message should be zero. The BSR as an RP; the Holdtime in this C-RP-Adv message should be zero. The BSR
will then immediately time out the C-RP and generate a new Bootstrap will then immediately time out the C-RP and generate a new Bootstrap
message with the shut down RP holdtime set to 0. message with the shut down RP holdtime set to 0.
A C-RP-Adv message carries a list of group address and group mask field A C-RP-Adv message carries a list of group address and group mask field
pairs. This enables the C-RP to specify the group prefixes for which it pairs. This enables the C-RP to specify the group ranges for which it
is willing to be the RP. If the C-RP becomes an RP, it may enforce this is willing to be the RP. If the C-RP becomes an RP, it may enforce this
scope acceptance when receiving Register or Join/Prune messages. scope acceptance when receiving Register or Join/Prune messages.
A C-RP is configured with a list of group ranges for which it should A C-RP is configured with a list of group ranges for which it should
advertise itself as the C-RP. A C-RP uses the following algorithm to advertise itself as the C-RP. A C-RP uses the following algorithm to
determine which ranges to send to a given BSR. determine which ranges to send to a given BSR.
For each group range R in the list, the C-RP advertises that range to 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 the scoped BSR for the smallest scope that "contains" R. For IPv6, the
containing scope is determined by matching the scope identifier of the containing scope is determined by matching the scope identifier of the
skipping to change at page 20, line 50 skipping to change at page 21, line 48
C-RP-Adv message with no group ranges SHOULD be treated as though it C-RP-Adv message with no group ranges SHOULD be treated as though it
contained the single group range ff00::/8 or 224/4. Therefore, contained the single group range ff00::/8 or 224/4. Therefore,
according to the rule above, this group range will be accepted if and according to the rule above, this group range will be accepted if and
only if the router is elected as the non-scoped BSR. only if the router is elected as the non-scoped BSR.
When a CGET expires, the corresponding group-to-C-RP mapping is removed When a CGET expires, the corresponding group-to-C-RP mapping is removed
from the C-RP-Set. from the C-RP-Set.
The BSR constructs the RP-Set from the C-RP-Set. It may apply a local The BSR constructs the RP-Set from the C-RP-Set. It may apply a local
policy to limit the number of Candidate-RPs included in the RP-Set. The policy to limit the number of Candidate-RPs included in the RP-Set. The
BSR may override the prefix indicated in a C-RP-Adv message unless the BSR may override the range indicated in a C-RP-Adv message unless the
`Priority' field from the C-RP-Adv message is less than 128. `Priority' field from the C-RP-Adv message is less than 128.
If the BSR learns of both BIDIR and PIM-SM Candidate-RPs for the same If the BSR learns of both BIDIR and PIM-SM Candidate-RPs for the same
group range, the BSR MUST only include RPs for one of the protocols in group range, the BSR MUST only include RPs for one of the protocols in
the BSMs. The default behavior SHOULD be to prefer BIDIR. the BSMs. The default behavior SHOULD be to prefer BIDIR.
For inclusion in a BSM, the RP-Set is subdivided into sets of {group- For inclusion in a BSM, the RP-Set is subdivided into sets of {group-
prefix, RP-Count, RP-addresses}. For each RP-address, the "RP-Holdtime" range, RP-Count, RP-addresses}. For each RP-address, the "RP-Holdtime"
field is set to the Holdtime from the C-RP-Set, subject to the field is set to the Holdtime from the C-RP-Set, subject to the
constraint that it MUST be larger than BS_Period and SHOULD be larger constraint that it MUST be larger than BS_Period and SHOULD be larger
than 2.5 times BS_Period to allow for some Bootstrap messages getting than 2.5 times BS_Period to allow for some Bootstrap messages getting
lost. If some holdtimes from the C-RP-Sets do not satisfy this lost. If some holdtimes from the C-RP-Sets do not satisfy this
constraint, the BSR MUST replace those holdtimes with a value satisfying constraint, the BSR MUST replace those holdtimes with a value satisfying
the constraint. An exception to this is the holdtime of zero which is the constraint. An exception to this is the holdtime of zero which is
used to immediately withdraw mappings. used to immediately withdraw mappings.
The format of the Bootstrap message allows `semantic fragmentation', if The format of the Bootstrap message allows `semantic fragmentation', if
the length of the original Bootstrap message exceeds the packet maximum the length of the original Bootstrap message exceeds the packet maximum
skipping to change at page 22, line 50 skipping to change at page 23, line 47
By hop-by-hop forwarding, we mean that the bootstrap message itself is By hop-by-hop forwarding, we mean that the bootstrap message itself is
forwarded, not the entire IP packet. Each hop constructs an IP packet forwarded, not the entire IP packet. Each hop constructs an IP packet
for each of the interfaces the BSM is to be forwarded out of; each for each of the interfaces the BSM is to be forwarded out of; each
packet containing the entire BSM that was received. packet containing the entire BSM that was received.
When a Bootstrap message is forwarded, it is forwarded out of every When a Bootstrap message is forwarded, it is forwarded out of every
multicast-capable interface which has PIM neighbors (including the one multicast-capable interface which has PIM neighbors (including the one
over which the message was received). The exception to this is if the over which the message was received). The exception to this is if the
interface is an administrative scope boundary for the admin scope zone interface is an administrative scope boundary for the admin scope zone
indicated in the first group address in the Bootstrap message packet. indicated in the first group range in the Bootstrap message packet.
As an optimization, a router MAY choose not to forward a BSM out of the As an optimization, a router MAY choose not to forward a BSM out of the
interface the message was received on if that interface is a point-to- interface the message was received on if that interface is a point-to-
point interface. On interfaces with multiple PIM neighbors, a router point interface. On interfaces with multiple PIM neighbors, a router
SHOULD forward an accepted BSM onto the interface that BSM was received SHOULD forward an accepted BSM onto the interface that BSM was received
on, but if the number of PIM neighbors on that interface is large, it on, but if the number of PIM neighbors on that interface is large, it
MAY delay forwarding a BSM onto that interface by a small randomized MAY delay forwarding a BSM onto that interface by a small randomized
interval to prevent message implosion. A configuration option MAY be interval to prevent message implosion. A configuration option MAY be
provided to disable forwarding onto the interface a message was received provided to disable forwarding onto the interface a message was received
on, but we recommend that the default behavior is to forward onto that on, but we recommend that the default behavior is to forward onto that
interface. interface.
Rationale: A BSM needs to be forwarded onto the interface the message Rationale: A BSM needs to be forwarded onto the interface the message
was received on (in addition to the other interfaces) because the was received on (in addition to the other interfaces) because the
routers on a LAN may not have consistent routing information. If three routers on a LAN may not have consistent routing information. If three
skipping to change at page 24, line 42 skipping to change at page 25, line 38
general, the routing protocols need to re-calculate the mappings when general, the routing protocols need to re-calculate the mappings when
any of their RP-Sets change. How such a change is signalled to the any of their RP-Sets change. How such a change is signalled to the
routing protocol is also not part of the present specification. routing protocol is also not part of the present specification.
Some group-to-RP mappings in the RP-Set indicate group ranges for which Some group-to-RP mappings in the RP-Set indicate group ranges for which
PIM-SM should be used; others indicate group ranges for use with BIDIR- PIM-SM should be used; others indicate group ranges for use with BIDIR-
PIM. Routers that only support one of these protocols MUST NOT ignore PIM. Routers that only support one of these protocols MUST NOT ignore
ranges indicated as being for the other protocol. They MUST NOT treat ranges indicated as being for the other protocol. They MUST NOT treat
them as being for the protocol they support. them as being for the protocol they support.
If a mapping is not already part of the RP-Set, it is added to the RP-
Set and the associated Group-to-RP mapping Expiry Timer (GET) is
initialized to the holdtime from the Bootstrap Message. Its priority is
set to the Priority from the Bootstrap Message.
If a mapping is already part of the RP-Set, it is updated with the
Priority from the Bootstrap Message and its associated GET is reset to
the holdtime from the Bootsrap Message. If the holdtime is zero, the
mapping is removed from the RP-Set immediately.
4. Message Formats 4. Message Formats
BSR messages are PIM messages, as defined in [1]. BSR messages are PIM messages, as defined in [1]. The values of the PIM
The values of the PIM Message Type field for BSR messages are: Message Type field for BSR messages are:
4 Bootstrap 4 Bootstrap
8 Candidate-RP-Advertisement 8 Candidate-RP-Advertisement
As with all other PIM control messages, BSR messages have IP protocol As with all other PIM control messages, BSR messages have IP protocol
number 103. number 103.
Candidate-RP-Advertisement messages are unicast to a BSR. Usually, Candidate-RP-Advertisement messages are unicast to a BSR. Usually,
Bootstrap messages are multicast with TTL 1 to the ALL-PIM-ROUTERS Bootstrap messages are multicast with TTL 1 to the ALL-PIM-ROUTERS
skipping to change at page 25, line 44 skipping to change at page 26, line 51
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 [10]. Values 128-250 are reserved to be assigned by Families in [11]. Values 128-250 are reserved to be assigned by
the IANA for PIM-specific Address Families. Values 251 though 255 the IANA for PIM-specific Address Families. Values 251 though 255
are designated for private use. As there is no assignment are designated for private use. As there is no assignment
authority for this space, collisions should be expected. authority 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 26, line 36 skipping to change at page 27, line 43
described above. described above.
[B]IDIR bit [B]IDIR bit
When set, all BIDIR capable PIM routers will operate the protocol When set, all BIDIR capable PIM routers will operate the protocol
described in [2] for the specified group range. described in [2] for the specified group range.
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 range is an
administratively 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 Family and Encoding Type. If the message is sent for a single
group then the Mask length must equal the address length in bits group then the Mask length must equal the address length in bits
for the given Address Family and Encoding Type. (e.g. 32 for IPv4 for the given Address Family and Encoding Type. (e.g. 32 for IPv4
skipping to change at page 29, line 28 skipping to change at page 30, line 28
to be forwarded. to be forwarded.
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
IPv4 we recommend a value of 30. For IPv6 we recommend a value of IPv4 we recommend a value of 30. For IPv6 we recommend a value of
126. This field SHOULD be the same for all fragments belonging to 126.
the same Bootstrap message.
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. BSRs considered as a high order byte when comparing BSR addresses. BSRs
should by default set this field to 64. Note that for historical should by default set this field to 64. Note that for historical
reasons, the highest BSR priority is 255 (the higher the better), reasons, the highest BSR priority is 255 (the higher the better),
whereas the highest RP Priority (see below) is 0 (the lower the whereas the highest RP Priority (see below) is 0 (the lower the
better). better).
BSR Address 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 [1]. 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 ranges (address and mask) with which the Candidate-RPs
are associated. Format described in [1]. In a fragment containing are associated. Format described in [1]. In a fragment containing
admin scope ranges, the first group address in the fragment MUST admin scope ranges, the first group range in the fragment MUST
satisfy the following conditions: it MUST have the Admin Scope bit satisfy the following conditions: it MUST have the Admin Scope bit
set; for IPv4 it MUST be the group range for the entire admin scope set; for IPv4 it MUST be the group range for the entire admin scope
range (this is the case even if there are no RPs in the RP-Set for range (this is the case even if there are no RPs in the RP-Set for
the entire admin scope range - in this case the sub-ranges for the the entire admin scope range - in this case the sub-ranges for the
RP-Set are specified later in the fragment along with their RPs); 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 for IPv6 the Mask Len MUST be at least 16 and have the scope ID of
the admin scope range. the admin scope range.
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 Bootstrap message for the corresponding group range. A router does
does not replace its old RP-Set for a given group prefix not replace its old RP-Set for a given group range until/unless it
until/unless it receives `RP-Count' addresses for that prefix; the receives `RP-Count' addresses for that range; the addresses could
addresses could be carried over several fragments. If only part of be carried over several fragments. If only part of the RP-Set for
the RP-Set for a given group prefix was received, the router a given group range was received, the router discards it, without
discards it, without updating that specific group prefix's RP-Set. updating that specific group range'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 range. 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 range, 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- range. The format for these addresses is given in the Encoded-
Unicast address in [1]. Unicast address in [1].
RP1..m Holdtime RP1..m Holdtime
The Holdtime (in seconds) for the corresponding RP. This field is The Holdtime (in seconds) for the corresponding RP. This field is
copied from the `Holdtime' field of the associated RP stored at the copied from the `Holdtime' field of the associated RP stored at the
BSR. 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
skipping to change at page 31, line 9 skipping to change at page 32, line 4
Within a Bootstrap message, the BSR Address, all the Group Addresses and Within a Bootstrap message, the BSR Address, all the Group Addresses and
all the RP Addresses MUST be of the same address family. In addition, all the RP Addresses MUST be of the same address family. In addition,
the address family of the fields in the message MUST be the same as the the address family of the fields in the message MUST be the same as the
IP source and destination addresses of the packet. This permits maximum IP source and destination addresses of the packet. This permits maximum
implementation flexibility for dual-stack IPv4/IPv6 routers. implementation flexibility for dual-stack IPv4/IPv6 routers.
4.1.1. Semantic Fragmentation of BSMs 4.1.1. Semantic Fragmentation of BSMs
Bootstrap messages may be split over several PIM Bootstrap Message Bootstrap messages may be split over several PIM Bootstrap Message
Fragments (BSMF); this is known as semantic fragmentation. Each of Fragments (BSMF); this is known as semantic fragmentation. Each of
these must be according to the above format.
these must be according to the above format. All 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.
That is, only the group-to-RP mappings may differ between fragments.
This is useful if the BSM would otherwise exceed the MTU of the link the This is useful if the BSM would otherwise exceed the MTU of the link the
message will be forwarded over. If one relies purely on IP message will be forwarded over. If one relies purely on IP
fragmentation, one would lose the entire message if one fragment is fragmentation, one would lose the entire message if one fragment is
lost. By use of semantic fragmentation, one lost IP fragment will only lost. By use of semantic fragmentation, one lost IP fragment will only
cause the loss of the semantic fragment that the IP fragment was part cause the loss of the semantic fragment that the IP fragment was part
of. As described below, a router only needs to receive all the RPs for of. As described below, a router only needs to receive all the RPs for
a specific group range to update that range. This means that loss of a a specific group range to update that range. This means that loss of a
semantic fragment, due to an IP fragment getting lost, only affects the semantic fragment, due to an IP fragment getting lost, only affects the
group ranges the lost semantic fragment contains information for. group ranges the lost semantic fragment contains information for.
If the BSR can split up the BSM so that each group prefix (and all of If the BSR can split up the BSM so that each group range (and all of its
its RP information) can fit entirely inside one BSMF, then it should do RP information) can fit entirely inside one BSMF, then it should do so.
so. If a BSMF is lost, the state from the previous BSM for the group- If a BSMF is lost, the state from the previous BSM for the group ranges
prefixes from the missing BSMF will be retained. Each fragment that from the missing BSMF will be retained. Each fragment that does arrive
does arrive will update the RP information for the group-prefixes will update the RP information for the group ranges contained in that
contained in that fragment, and the new group-to-RP mappings for those fragment, and the new group-to-RP mappings for those can be used
can be used immediately. The information from the missing fragment will immediately. The information from the missing fragment will be obtained
be obtained when the next BSM is transmitted. when the next BSM is transmitted.
If the list of RPs for a single group-prefix is long, one may split the If the list of RPs for a single group range is long, one may split the
information across multiple BSMFs to avoid IP fragmentation. In this information across multiple BSMFs to avoid IP fragmentation. In this
case, all the BSMFs comprising the information for that group-prefix case, all the BSMFs comprising the information for that group range must
must be received before the group-to-RP mapping in use can be modified. be received before the group-to-RP mapping in use can be modified. This
This is the purpose of the RP Count field - a router receiving BSMFs is the purpose of the RP Count field - a router receiving BSMFs from the
from the same BSM (i.e. that have the same fragment tag) must wait until same BSM (i.e. that have the same fragment tag) must wait until BSMFs
BSMFs providing RP Count RPs for that group-prefix have been received providing RP Count RPs for that group range have been received before
before the new group-to-RP mapping can be used for that group-prefix. the new group-to-RP mapping can be used for that group range. If a
If a single BSMF from such a large group-prefix is lost, then that single BSMF from such a large group range is lost, then that entire
entire group-prefix will have to wait until the next BSM is originated. group range will have to wait until the next BSM is originated. Hence
Hence the benefit of using semantic fragmentation is in this case the benefit of using semantic fragmentation is in this case dubious.
dubious.
Next we need to consider how a BSR would remove group-prefixes from the Next we need to consider how a BSR would remove group ranges. A router
BSM. A router receiving a set of BSMFs cannot tell if a group-prefix is receiving a set of BSMFs cannot tell if a group range is missing. If it
missing. If it has seen a group-prefix before, it must assume that that has seen a group range before, it must assume that that group range
group-prefix still exists, and that the BSMF describing it has been still exists, and that the BSMF describing it has been lost. It should
lost. It should retain this information for BS_Timeout. Thus for a BSR retain this information for BS_Timeout. Thus for a BSR to remove a
to remove a group-prefix from the BSR, it should include that group- group range, it should include that group range, but with an RP Count of
prefix, but with a RP Count of zero, and it should resend this zero, and it should resend this information in each BSM for BS_Timeout.
information in each BSM for BS_Timeout.
4.2. Candidate-RP-Advertisement Message Format 4.2. Candidate-RP-Advertisement Message Format
Candidate-RP-Advertisement messages are periodically unicast from the C- Candidate-RP-Advertisement messages are periodically unicast from the C-
RPs to the BSR. RPs to 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 32, line 37 skipping to change at page 33, line 37
PIM Version, Reserved, Checksum PIM Version, Reserved, Checksum
Described in [1]. Described in [1].
Type Type
PIM Message Type. Value is 8 for a Candidate-RP-Advertisement PIM Message Type. Value is 8 for a Candidate-RP-Advertisement
message. message.
Prefix Count Prefix Count
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. indicating the group range for which the C-RP is advertising. C-
C-RPs MUST NOT send C-RP-Adv messages with a Prefix Count of `0'. RPs MUST NOT send C-RP-Adv messages with a Prefix Count of `0'.
Priority Priority
The `Priority' of the included RP, for the corresponding Encoded- The `Priority' of the included RP, for the corresponding Encoded-
Group Address (if any). The highest priority is `0' (i.e. the Group Address (if any). The highest priority is `0' (i.e. the
lower the value of the `Priority' field, the higher the priority). lower the value of the `Priority' field, the higher the priority).
This field is stored at the BSR upon receipt along with the RP This field is stored at the BSR upon receipt along with the RP
address and corresponding Encoded-Group Address. address and corresponding Encoded-Group Address.
Holdtime Holdtime
The amount of time (in seconds) the advertisement is valid. This The amount of time (in seconds) the advertisement is valid. This
field allows advertisements to be aged out. This field should be field allows advertisements to be aged out. This field should be
set to 2.5 times C_RP_Adv_Period. set to 2.5 times C_RP_Adv_Period.
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
[1]. [1].
Group Address-1..n Group Address-1..n
The group prefixes for which the C-RP is advertising. Format The group ranges for which the C-RP is advertising. Format
described in Encoded-Group-Address in [1]. described in Encoded-Group-Address in [1].
Within a Candidate-RP-Advertisement message, the RP Address and all the Within a Candidate-RP-Advertisement message, the RP Address and all the
Group Addresses MUST be of the same address family. In addition, the Group Addresses MUST be of the same address family. In addition, the
address family of the fields in the message MUST be the same as the IP address family of the fields in the message MUST be the same as the IP
source and destination addresses of the packet. This permits maximum source and destination addresses of the packet. This permits maximum
implementation flexibility for dual-stack IPv4/IPv6 routers. implementation flexibility for dual-stack IPv4/IPv6 routers.
5. Timers and Timer Values 5. Timers and Timer Values
skipping to change at page 38, line 30 skipping to change at page 39, line 30
to the DR with the source address of the RP spoofed would be sufficient 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 to cause a denial-of-service attack on the multicast traffic originating
from that DR. from that DR.
6.3. Bootstrap Message Security 6.3. Bootstrap Message Security
If a legitimate PIM router is compromised, there is little any 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 mechanism can do to prevent that router subverting PIM traffic in that
domain. However we recommend that implementers provide a mechanism domain. However we recommend that implementers provide a mechanism
whereby a PIM router using the BSR mechanisms can be configured with the whereby a PIM router using the BSR mechanisms can be configured with the
IP addresses of valid BSR routers, and that any Bootstrap message from IP addresses of valid BSR routers, and that any Bootstrap message with a
any other BSR should then be dropped and logged as a security issue. We non-valid BSR address should be dropped and logged as a security issue.
also recommend that this not be enabled by default, as it makes the Due to the RPF check of the BSR address, it will not be trivial to
initial configuration of a PIM domain problematic - it is the sort of inject messages with a spoofed BSR address. We recommend not to enable
feature that might be enabled once the configuration of a domain has this mechanism by default, as it makes the initial configuration of a
PIM domain problematic - it is the sort of feature that the
administrator might enable once the configuration of a domain has
stabilized. stabilized.
The primary security requirement for BSR (as for PIM) is that it is The primary security requirement for BSR (as for PIM) is that it is
possible to prevent hosts that are not legitimate PIM routers, either possible to prevent hosts that are not legitimate PIM routers, either
within or outside the domain, from subverting the BSR mechanism. within or outside the domain, from subverting the BSR mechanism.
The Bootstrap Message Processing Checks prevent a router from accepting The Bootstrap Message Processing Checks prevent a router from accepting
a Bootstrap message from outside of the PIM Domain, as the source a Bootstrap message from outside of the PIM Domain, as the source
address on Bootstrap messages must be an immediate PIM neighbor. There address on Bootstrap messages must be an immediate PIM neighbor. There
is however a small window of time after a reboot where a PIM router will is however a small window of time after a reboot where a PIM router will
skipping to change at page 39, line 31 skipping to change at page 40, line 33
be located on leaf subnets. We recommend that implementers provide a be located on leaf subnets. We recommend that implementers provide a
configuration option that specifies an interface is a leaf subnet, and configuration option that specifies an interface is a leaf subnet, and
that no PIM packets are accepted on such interfaces. that no PIM packets are accepted on such interfaces.
On multi-access subnets with multiple PIM routers and hosts that are not On multi-access subnets with multiple PIM routers and hosts that are not
trusted, we recommend that IPsec AH is used to protect communication trusted, we recommend that IPsec AH is used to protect communication
between PIM routers, and that such routers are configured to drop and between PIM routers, and that such routers are configured to drop and
log communication attempts from any host that do not pass the log communication attempts from any host that do not pass the
authentication check. When all the PIM routers are under the same authentication check. When all the PIM routers are under the same
administrative control, this authentication may use a configured shared administrative control, this authentication may use a configured shared
secret. The securing of interactions between PIM neighbors is discussed secret. In order to prevent replay attacks one will need to have one SA
in more detail in the Security Considerations section of [1], and so we per sender using the sender address for SA lookup. The securing of
do not discuss the details further here. The same security mechanisms interactions between PIM neighbors is discussed in more detail in the
that can be used to secure PIM Join, Prune and Assert messages should Security Considerations section of [1], and so we do not discuss the
also be used to secure Bootstrap messages. details further here. The same security mechanisms that can be used to
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 6.4. Candidate-RP-Advertisement Message Security
Even if it is not possible to subvert Bootstrap messages, an attacker Even if it is not possible to subvert Bootstrap messages, an attacker
might be able to perform most of the same attacks by simply sending C- 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. 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 Thus it is necessary to control the sending of C-RP-Adv messages in
essentially the same ways that we control Bootstrap messages. However, essentially the same ways that we control Bootstrap messages. However,
C-RP-Adv messages are unicast and normally travel multiple hops, so C-RP-Adv messages are unicast and normally travel multiple hops, so
controlling them is more difficult. controlling them is more difficult.
skipping to change at page 40, line 30 skipping to change at page 41, line 36
For true security, we recommend that all C-RPs are configured to use For true security, we recommend that all C-RPs are configured to use
IPsec authentication. The authentication process for a C-RP-Adv message IPsec authentication. The authentication process for a C-RP-Adv message
between a C-RP and the BSR is identical to the authentication process 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 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 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 key management is a little simpler. We do not describe the details of
this process further here, but refer to the Security Considerations this process further here, but refer to the Security Considerations
section of [1]. Note that the use of cryptographic security for C-RP- section of [1]. Note that the use of cryptographic security for C-RP-
Adv messages does not remove the need for the non-cryptographic Adv messages does not remove the need for the non-cryptographic
mechanisms, as explained below. mechanisms, as explained above.
6.5. Denial of Service using IPsec 6.5. Denial of Service using IPsec
An additional concern is that of Denial-of-Service attacks caused by An additional concern is that of Denial-of-Service attacks caused by
sending high volumes of Bootstrap messages or C-RP-Adv messages with sending high volumes of Bootstrap messages or C-RP-Adv messages with
invalid IPsec authentication information. It is possible that these invalid IPsec authentication information. It is possible that these
messages could overwhelm the CPU resources of the recipient. messages could overwhelm the CPU resources of the recipient.
The non-cryptographic security mechanisms above restrict from where The non-cryptographic security mechanisms above restrict from where
unicast Bootstrap messages and C-RP-Adv messages are accepted. In unicast Bootstrap messages and C-RP-Adv messages are accepted. In
addition, we recommend that rate-limiting mechanisms can be configured, addition, we recommend that rate-limiting mechanisms can be configured,
to be applied to receival of unicast PIM packets. The rate-limiter MUST to be applied on receipt of unicast PIM packets. The rate-limiter MUST
independently rate-limit different types of PIM packets - for example a 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- flood of C-RP-Adv messages MUST NOT cause a rate limiter to drop low-
rate Bootstrap messages. Such a rate-limiter might itself be used to rate Bootstrap messages. Such a rate-limiter might itself be used to
cause a denial of service attack by causing valid packets to be dropped, 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. The but in practice this is more likely to constrain bad PIM messages. The
rate limiter will prevent attacks on PIM from affecting other activity rate limiter will prevent attacks on PIM from affecting other activity
on the receiving router, such as unicast routing. on the receiving router, such as unicast routing.
7. Contributors 7. Contributors
Bill Fenner, Mark Handley, Roger Kermode and David Thaler have Bill Fenner, Mark Handley, Roger Kermode and David Thaler have
contributed greatly to this draft. They were authors of this draft up contributed greatly to this draft. They were authors of this draft up
to version 03, and much of the current text comes from version 03. to version 03, and much of the current text comes from version 03.
skipping to change at page 41, line 40 skipping to change at page 42, line 44
10. Normative References 10. Normative References
[1] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol [1] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 4601, August 2006. Specification (Revised)", RFC 4601, August 2006.
[2] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional [2] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional
Protocol Independent Multicast (BIDIR-PIM)", Internet Draft draft- Protocol Independent Multicast (BIDIR-PIM)", Internet Draft draft-
ietf-pim-bidir-08.txt ietf-pim-bidir-08.txt
[3] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, Jul [3] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, July
1998. 1998.
[4] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill, "IPv6 [4] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill, "IPv6
Scoped Address Architecture", RFC 4007, Mar 2005. Scoped Address Architecture", RFC 4007, March 2005.
[5] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC [5] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC
4291, Feb 2006. 4291, February 2006.
[6] S. Bradner, "Key words for use in RFCs to Indicate Requirement [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, Mar 1997. Levels", BCP 14, RFC 2119, March 1997.
11. Informative References 11. Informative References
[7] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode [7] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode
(PIM-SM): Protocol Specification", RFC 2362, June 1998 (now (PIM-SM): Protocol Specification", RFC 2362, June 1998 (now
obsolete). obsolete).
[8] D. Kim, D. Meyer, H. Kilmer, D. Farinacci, "Anycast Rendevous Point [8] D. Kim, D. Meyer, H. Kilmer, D. Farinacci, "Anycast Rendevous Point
(RP) mechanism using Protocol Independent Multicast (PIM) and (RP) mechanism using Protocol Independent Multicast (PIM) and
Multicast Source Discovery Protocol (MSDP)", RFC 3446, Jan 2003. Multicast Source Discovery Protocol (MSDP)", RFC 3446, January
2003.
[9] D. Farinacci, Y. Cai, "Anycast-RP using PIM", Internet Draft draft- [9] D. Farinacci, Y. Cai, "Anycast-RP Using Protocol Independent
ietf-pim-anycast-rp-07.txt Multicast (PIM)", RFC 4610, August 2006
[10] IANA, "Address Family Numbers", linked from [10] W. Atwood, S. Islam, "Security Issues in PIM-SM Link-local
Messages", Internet Draft draft-ietf-pim-sm-linklocal-00, Work in
Progress, October 2006.
[11] IANA, "Address Family Numbers", linked from
http://www.iana.org/numbers.html http://www.iana.org/numbers.html
Authors' Addresses Authors' Addresses
Nidhi Bhaskar Nidhi Bhaskar
Cisco Systems Arastra, Inc.
170 W. Tasman Drive P.O. Box 10905
San Jose, CA 95134 Palo Alto, CA 94303
USA USA
nbhaskar@cisco.com nidhi@arastra.com
Alexander Gall Alexander Gall
SWITCH SWITCH
Limmatquai 138 Limmatquai 138
P.O. Box P.O. Box
CH-8021 Zurich CH-8021 Zurich
Switzerland Switzerland
gall@switch.ch gall@switch.ch
James Lingard James Lingard
Arastra, Inc. Arastra, Inc.
P.O. Box 10905 P.O. Box 10905
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
jchl@arastra.com jchl@arastra.com
Stig Venaas Stig Venaas
UNINETT UNINETT
NO-7465 Trondheim NO-7465 Trondheim
Norway Norway
venaas@uninett.no venaas@uninett.no
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
 End of changes. 76 change blocks. 
165 lines changed or deleted 216 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/