draft-ietf-pim-sm-bsr-06.txt   draft-ietf-pim-sm-bsr-07.txt 
Internet Engineering Task Force PIM WG Internet Engineering Task Force PIM WG
INTERNET-DRAFT Nidhi Bhaskar/Cisco INTERNET-DRAFT Nidhi Bhaskar/Cisco
draft-ietf-pim-sm-bsr-06.txt Alexander Gall/SWITCH draft-ietf-pim-sm-bsr-07.txt Alexander Gall/SWITCH
James Lingard James Lingard
Stig Venaas/UNINETT Stig Venaas/UNINETT
23 October 2005 3 March 2006
Expires: April 2006 Expires: September 2006
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 1, line 39 skipping to change at page 1, line 39
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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 pim@ietf.org. addressed to the authors, or the WG's mailing list at pim@ietf.org.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies the Bootstrap Router (BSR) mechanism This document specifies the Bootstrap Router (BSR) mechanism
for the class of multicast routing protocols in the PIM for the class of multicast routing protocols in the PIM
(Protocol Independent Multicast) family that use the concept (Protocol Independent Multicast) family that use the concept
of a Rendezvous Point as a means for receivers to discover the of a Rendezvous Point as a means for receivers to discover the
sources that send to a particular multicast group. BSR is one sources that send to a particular multicast group. BSR is one
way that a multicast router can learn the set of group-to-RP way that a multicast router can learn the set of group-to-RP
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. . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . 5 1.1. Background . . . . . . . . . . . . . . . . . . . . . 4
1.2. Protocol Overview. . . . . . . . . . . . . . . . . . 7 1.2. Protocol Overview. . . . . . . . . . . . . . . . . . 6
1.3. Administrative Scoping and BSR . . . . . . . . . . . 8 1.3. Administrative Scoping and BSR . . . . . . . . . . . 7
2. BSR State and Timers. . . . . . . . . . . . . . . . . . 10 2. BSR State and Timers. . . . . . . . . . . . . . . . . . 9
3. Bootstrap Router Election and RP-Set 3. Bootstrap Router Election and RP-Set
Distribution. . . . . . . . . . . . . . . . . . . . . . 10 Distribution. . . . . . . . . . . . . . . . . . . . . . 9
3.1. Bootstrap Router Election. . . . . . . . . . . . . . 10 3.1. Bootstrap Router Election. . . . . . . . . . . . . . 9
3.1.1. Per-Scope-Zone Candidate-BSR State 3.1.1. Per-Scope-Zone Candidate-BSR State
Machine . . . . . . . . . . . . . . . . . . . . . 11 Machine . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . 12
3.1.3. Bootstrap Message Processing Checks . . . . . . . 15 3.1.3. Bootstrap Message Processing Checks . . . . . . . 14
3.1.4. State Machine Transition Events . . . . . . . . . 15 3.1.4. State Machine Transition Events . . . . . . . . . 14
3.1.5. State Machine Actions . . . . . . . . . . . . . . 16 3.1.5. State Machine Actions . . . . . . . . . . . . . . 15
3.2. Sending Candidate-RP-Advertisement Messages. . . . . 18 3.2. Sending Candidate-RP-Advertisement Messages. . . . . 17
3.3. Creating the RP-Set at the BSR . . . . . . . . . . . 19 3.3. Creating the RP-Set at the BSR . . . . . . . . . . . 18
3.4. Forwarding Bootstrap Messages. . . . . . . . . . . . 22 3.4. Forwarding Bootstrap Messages. . . . . . . . . . . . 20
3.5. Unicasting Bootstrap Messages to New and 3.5. Unicasting Bootstrap Messages to New and
Rebooting Routers. . . . . . . . . . . . . . . . . . 22 Rebooting Routers. . . . . . . . . . . . . . . . . . 21
3.6. Receiving and Using the RP-Set . . . . . . . . . . . 23 3.6. Receiving and Using the RP-Set . . . . . . . . . . . 22
4. Message Formats . . . . . . . . . . . . . . . . . . . . 23 4. Message Formats . . . . . . . . . . . . . . . . . . . . 22
4.1. Bootstrap Message Format . . . . . . . . . . . . . . 25 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 24
4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 29 4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 28
4.2. Candidate-RP-Advertisement Message Format. . . . . . 30 4.2. Candidate-RP-Advertisement Message Format. . . . . . 29
5. Timers and Timer Values . . . . . . . . . . . . . . . . 32 5. Timers and Timer Values . . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . 34
6.1. Possible Threats . . . . . . . . . . . . . . . . . . 35 6.1. Possible Threats . . . . . . . . . . . . . . . . . . 34
6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 35 6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 34
6.3. Bootstrap Message Security . . . . . . . . . . . . . 36 6.3. Bootstrap Message Security . . . . . . . . . . . . . 35
6.3.1. Rejecting Unicast Bootstrap Messages. . . . . . . 36 6.3.1. Rejecting Unicast Bootstrap Messages. . . . . . . 35
6.3.2. Rejecting Bootstrap Messages from Invalid 6.3.2. Rejecting Bootstrap Messages from Invalid
Neighbors . . . . . . . . . . . . . . . . . . . . 37 Neighbors . . . . . . . . . . . . . . . . . . . . 36
6.4. Candidate-RP-Advertisement Message Security. . . . . 37 6.4. Candidate-RP-Advertisement Message Security. . . . . 36
6.4.1. Non-Cryptographic Security of C-RP-Adv 6.4.1. Non-Cryptographic Security of C-RP-Adv
Messages. . . . . . . . . . . . . . . . . . . . . 37 Messages. . . . . . . . . . . . . . . . . . . . . 36
6.4.2. Cryptographic Security of C-RP-Adv 6.4.2. Cryptographic Security of C-RP-Adv
Messages. . . . . . . . . . . . . . . . . . . . . 38 Messages. . . . . . . . . . . . . . . . . . . . . 37
6.5. Denial of Service using IPsec. . . . . . . . . . . . 38 6.5. Denial of Service using IPsec. . . . . . . . . . . . 37
7. Contributors. . . . . . . . . . . . . . . . . . . . . . 39 7. Contributors. . . . . . . . . . . . . . . . . . . . . . 38
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 39 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 38
9. IANA Considerations . . . . . . . . . . . . . . . . . . 39 9. IANA Considerations . . . . . . . . . . . . . . . . . . 38
10. Normative References . . . . . . . . . . . . . . . . . 39 10. Normative References . . . . . . . . . . . . . . . . . 38
11. Informative References . . . . . . . . . . . . . . . . 40 11. Informative References . . . . . . . . . . . . . . . . 39
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 [9], which has since been obsoleted.
This document provides an updated specification of the BSR mechanism This document provides an updated specification of the BSR mechanism
from RFC 2362, and also extends it to cope with administratively scoped from RFC 2362, and also extends it to cope with administratively scoped
region boundaries and different flavours of routing protocols. 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 5, line 36 skipping to change at page 5, line 36
o SM / BIDIR flag o SM / BIDIR flag
In general, the group ranges of these group-to-RP mappings may overlap In general, the group ranges of these group-to-RP mappings may overlap
in arbitrary ways; hence a particular multicast group may be covered by in arbitrary ways; hence a particular multicast group may be covered by
multiple group-to-RP mappings. When this is the case, the router multiple group-to-RP mappings. When this is the case, the router
chooses only one of the RPs by applying a deterministic algorithm so chooses only one of the RPs by applying a deterministic algorithm so
that all routers in the domain make the same choice. It is important to that all routers in the domain make the same choice. It is important to
note that this algorithm is part of the specification of the individual note that this algorithm is part of the specification of the individual
routing protocols (and may differ among them), not of the BSR routing protocols (and may differ among them), not of the BSR
specification. specification. E.g. PIM-SM [1] defines one such algorithm. It makes
use of a hash function for the case where a group range has multiple RPs
with the same priority. The hash mask length is used by this function.
There are a number of ways in which such group-to-RP mappings can be There are a number of ways in which such group-to-RP mappings can be
established. The simplest solution is for all the routers in the domain established. The simplest solution is for all the routers in the domain
to be statically configured with the same information. However, static to be statically configured with the same information. However, static
configuration generally doesn't scale well, and, except when used in configuration generally doesn't scale well, and, except when used in
conjunction with Anycast-RP (see [8] and [9]), does not dynamically conjunction with Anycast-RP (see [10] and [11]), does not dynamically
adapt to route around router or link failures. adapt to route around router or link failures.
The BSR mechanism provides a way in which viable group-to-RP mappings The BSR mechanism provides a way in which viable group-to-RP mappings
can be created and rapidly distributed to all the PIM routers in a can be created and rapidly distributed to all the PIM routers in a
domain. It is adaptive, in that if an RP becomes unreachable, this will domain. It is adaptive, in that if an RP becomes unreachable, this will
be detected and the RP-Sets will be modified so that the unreachable RP be detected and the RP-Sets will be modified so that the unreachable RP
is no longer used. is no longer used.
1.2. Protocol Overview 1.2. Protocol Overview
skipping to change at page 10, line 45 skipping to change at page 10, line 45
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in C-BSR state | | When in C-BSR state |
+-----------+------------------+--------------------+-------------------+ +-----------+------------------+--------------------+-------------------+
| Event | Receive | Bootstrap | Receive Non- | | Event | Receive | Bootstrap | Receive Non- |
| | Preferred BSM | Timer Expires | preferred BSM | | | Preferred BSM | Timer Expires | preferred BSM |
| | | | from Elected | | | | | from Elected |
| | | | BSR | | | | | BSR |
+-----------+------------------+--------------------+-------------------+ +-----------+------------------+--------------------+-------------------+
| | -> C-BSR state | -> P-BSR state | -> P-BSR state | | | -> C-BSR state | -> P-BSR state | -> P-BSR state |
| | Forward BSM; | Set Bootstrap | Set Bootstrap | | | Forward BSM; | Set Bootstrap | Forward BSM; |
| Action | Store RP-Set; | Timer to | Timer to | | Action | Store RP-Set; | Timer to | Set Bootstrap |
| | Set Bootstrap | BS_Rand_Override | BS_Rand_Override | | | Set Bootstrap | BS_Rand_Override | Timer to |
| | Timer to | | | | | Timer to | | BS_Rand_Override |
| | BS_Timeout | | | | | BS_Timeout | | |
+-----------+------------------+--------------------+-------------------+ +-----------+------------------+--------------------+-------------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in P-BSR state | | When in P-BSR state |
+------------+-------------------+-------------------+------------------+ +------------+-------------------+-------------------+------------------+
| Event | Receive | Bootstrap | Receive Non- | | Event | Receive | Bootstrap | Receive Non- |
| | Preferred BSM | Timer Expires | preferred BSM | | | Preferred BSM | Timer Expires | preferred BSM |
+------------+-------------------+-------------------+------------------+ +------------+-------------------+-------------------+------------------+
| | -> C-BSR state | -> E-BSR state | -> P-BSR state | | | -> C-BSR state | -> E-BSR state | -> P-BSR state |
| | Forward BSM; | Originate BSM; | | | | Forward BSM; | Originate BSM; | Forward BSM |
| Action | Store RP-Set; | Set Bootstrap | | | Action | Store RP-Set; | Set Bootstrap | |
| | Set Bootstrap | Timer to | | | | Set Bootstrap | Timer to | |
| | Timer to | BS_Period | | | | Timer to | BS_Period | |
| | BS_Timeout | | | | | BS_Timeout | | |
+------------+-------------------+-------------------+------------------+ +------------+-------------------+-------------------+------------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in E-BSR state | | When in E-BSR state |
+------------+-------------------+-------------------+------------------+ +------------+-------------------+-------------------+------------------+
| Event | Receive | Bootstrap | Receive Non- | | Event | Receive | Bootstrap | Receive Non- |
skipping to change at page 14, line 19 skipping to change at page 14, line 19
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
} }
if (BSM.dst_ip_address == ALL-PIM-ROUTERS) { if (BSM.dst_ip_address == ALL-PIM-ROUTERS) {
if (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address)) { if (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address)) {
drop the Bootstrap message silently drop the Bootstrap message silently
} }
} else if (BSM.dst_ip_address is one of my addresses) { } else if (BSM.dst_ip_address is my primary address on the interface) {
if ((any previous BSM for this scope has been accepted) OR if ((any previous BSM for this scope has been accepted) OR
(more than BS_Period has elapsed since startup)) { (more than BS_Period has elapsed since startup)) {
#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 Bootstrap message silently drop the Bootstrap message silently
} }
} else { } else {
drop the Bootstrap message silently drop the Bootstrap 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 Bootstrap message silently drop the Bootstrap message silently
} }
Basically, the packet must have come from a directly connected neighbor Basically, the packet must have come from a directly connected neighbor
for which we have active Hello state. It must have been sent to the for which we have active Hello state. It must have been sent to the
ALL-PIM-ROUTERS group by the correct upstream router towards the BSR ALL-PIM-ROUTERS group by the correct upstream router towards the BSR
that originated the Bootstrap message, or the router must have recently that originated the Bootstrap message, or the router must have recently
restarted, have no BSR state for that admin scope and have received the restarted, have no BSR state for that admin scope and have received the
Bootstrap message by unicast. In addition it must not have arrived on Bootstrap message by unicast. The destination address of a unicast
an interface that is a configured admin scope border for the first group Bootstrap message must be our primary address on the interface it was
address contained in the Bootstrap message. received, that is, the address we source PIM Hello messages from. In
addition it must not have arrived on an interface that is a configured
admin scope border for the first group address contained in the
Bootstrap message.
3.1.4. State Machine Transition Events 3.1.4. 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 higher or A Bootstrap message is received from a BSR that has higher or
equal weight than the current BSR. If a router is in P-BSR equal weight than the current BSR. If a router is in P-BSR
state, then it uses its own weight as that of the current BSR. state, then it uses its own weight as that of the current BSR.
A Bootstrap message is also preferred if it is from the A Bootstrap message is also preferred if it is from the
current BSR with a lower weight than the previous BSM it sent, current BSR with a lower weight than the previous BSM it sent,
provided that if the router is a Candidate BSR the current BSR provided that if the router is a Candidate BSR the current BSR
still has a weight higher or equal than the router itself. In still has a weight higher or equal than the router itself. In
this case, the "Current Bootstrap Router's BSR Priority" state this case, the "Current Bootstrap Router's BSR Priority" state
must be updated. (For lower weight, see Non-preferred BSM from must be updated. (For lower weight, see Non-preferred BSM
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 that has lower
skipping to change at page 16, line 43 skipping to change at page 16, line 47
priority must be updated if changed. priority must be updated if changed.
Mappings for a group range are also to be immediately removed Mappings for a group range are also to be immediately removed
if they are not present in the received group range. This if they are not present in the received group range. This
means that if there are any existing Group-to-RP mappings for means that if there are any existing Group-to-RP mappings for
a range where the respective RPs are not in the received a range where the respective RPs are not in the received
range, then those mappings must be removed. range, then those mappings must be removed.
All RP mappings associated with the scope zone of the BSM are All RP mappings associated with the scope zone of the BSM are
updated with the new hash mask length from the received BSM. updated with the new hash mask length from the received BSM.
This includes any RP mappings learned from the current BSR but This includes RP mappings for all group ranges learned for
not contained in the received BSM, as well as any RP mappings this zone, not just the ranges in this particular BSM.
learned from any previous BSR for the scope zone.
In addition, the entire BSM is stored for use in the action In addition, the entire BSM is stored for use in the action
Refresh RP-Set and to prime a new PIM neighbor as described Refresh RP-Set and to prime a new PIM neighbor as described
below. below.
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-
skipping to change at page 17, line 26 skipping to change at page 17, line 26
does not include any group-to-RP mappings. does not include any group-to-RP mappings.
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 SHOULD send one to three C-RP-Adv When a new BSR is elected, the C-RP MUST send one to three C-RP-Adv
messages, waiting a randomized amount of 0-3 seconds before sending each messages, waiting a randomized amount of 0-3 seconds before sending each
message. We recommend sending three messages because it is important message. We recommend sending three messages because it is important
that the BSR quickly learns which RPs are active, and some packet loss that the BSR quickly learns which RPs are active, and some packet loss
may occur when a new BSR is elected due to changes in the network. One may occur when a new BSR is elected due to changes in the network. One
way of implementing this is to set the CRPT to 0-3 seconds when the new way of implementing this is to set the CRPT to 0-3 seconds when the new
BSR is elected, as well as setting a counter to 2. Whenever the CRPT BSR is elected, as well as setting a counter to 2. Whenever the CRPT
expires, we first send a C-RP-Adv message as usual. Next, if the expires, we first send a C-RP-Adv message as usual. Next, if the
counter is non-zero, it is decremented and the CRPT is again set to 0-3 counter is non-zero, it is decremented and the CRPT is again set to 0-3
seconds instead of C_RP_Adv_Period. seconds instead of C_RP_Adv_Period.
[NOTE: Add a name for this timer and counter?]
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 removing the shut down RP from the RP-Set. message with the shut down RP holdtime set to 0.
[NOTE: Should a new BSM be sent immediately when a C-RP-Adv message with
Holdtime of 0 is received? Need to clarify.]
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 prefixes 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.
skipping to change at page 19, line 41 skipping to change at page 19, line 36
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 prefix 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.
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 corresponding prefix, RP-Count, RP-addresses}. For each RP-address, the "RP-Holdtime"
Holdtime is included in the "RP-Holdtime" field. The format of the field is set to the Holdtime from the C-RP-Set, subject to the
Bootstrap message allows `semantic fragmentation', if the length of the constraint that it MUST be larger than BS_Period and SHOULD be larger
original Bootstrap message exceeds the packet maximum boundaries. than 2.5 times BS_Period to allow for some Bootstrap messages getting
However, we recommend against configuring a large number of routers as lost.
C-RPs, to reduce the semantic fragmentation required.
The format of the Bootstrap message allows `semantic fragmentation', if
the length of the original Bootstrap message exceeds the packet maximum
boundaries. However, we recommend against configuring a large number of
routers as C-RPs, to reduce the semantic fragmentation required.
In general BSMs are originated at regular intervals according to the In general BSMs are originated at regular intervals according to the
BS_Period timer. We do recommend that a BSM is also originated whenever BS_Period timer. We do recommend that a BSM is also originated whenever
the RP-set to be announced in the BSMs changes. This will usually the RP-set to be announced in the BSMs changes. This will usually
happen when receiving C-RP advertisements from a new C-RP, or when a C- happen when receiving C-RP advertisements from a new C-RP, or when a C-
RP is shut down (C-RP advertisement with a holdtime of zero). There RP is shut down (C-RP advertisement with a holdtime of zero). There
MUST however be a minimum of 10 seconds between each time a BSM is sent. MUST however be a minimum of 10 seconds between each time a BSM is sent.
In particular, when a new BSR is elected, it will first send one BSM In particular, when a new BSR is elected, it will first send one BSM
(which is likely to be empty since it has not yet received any C-RP (which is likely to be empty since it has not yet received any C-RP
advertisements), and then wait at least 10 seconds before sending a new advertisements), and then wait at least 10 seconds before sending a new
one. During those 10 seconds, it is likely to have received C-RP one. During those 10 seconds, it is likely to have received C-RP
advertisements from all usable C-RPs (since we say that a C-RP should advertisements from all usable C-RPs (since we say that a C-RP should
send one or more advertisements with small random delays of 0-3 seconds send one or more advertisements with small random delays of 0-3 seconds
when a new BSR is elected). For this case in particular, where routers when a new BSR is elected). For this case in particular, where routers
may not have a usable RP-set, we recommend originating a BSM as soon as may not have a usable RP-set, we recommend originating a BSM as soon as
those 10 seconds have passed. We suggest though that a BSR can do this those 10 seconds have passed. We suggest though that a BSR can do this
in general. One way of implementing this, is to decrease the Bootstrap in general. One way of implementing this, is to decrease the Bootstrap
skipping to change at page 20, line 19 skipping to change at page 20, line 18
one. During those 10 seconds, it is likely to have received C-RP one. During those 10 seconds, it is likely to have received C-RP
advertisements from all usable C-RPs (since we say that a C-RP should advertisements from all usable C-RPs (since we say that a C-RP should
send one or more advertisements with small random delays of 0-3 seconds send one or more advertisements with small random delays of 0-3 seconds
when a new BSR is elected). For this case in particular, where routers when a new BSR is elected). For this case in particular, where routers
may not have a usable RP-set, we recommend originating a BSM as soon as may not have a usable RP-set, we recommend originating a BSM as soon as
those 10 seconds have passed. We suggest though that a BSR can do this those 10 seconds have passed. We suggest though that a BSR can do this
in general. One way of implementing this, is to decrease the Bootstrap in general. One way of implementing this, is to decrease the Bootstrap
Timer to 10 seconds whenever the RP-set changes, while not changing the Timer to 10 seconds whenever the RP-set changes, while not changing the
timer if it is less or equal to 10. timer if it is less or equal to 10.
[NOTE: Add a name for this 10s value as a function of the 0-3s random
delay?]
A BSR originates separate scoped BSMs for each scope zone for which it A BSR originates separate scoped BSMs for each scope zone for which it
is the elected BSR, as well as originating non-scoped BSMs if it is the is the elected BSR, as well as originating non-scoped BSMs if it is the
elected non-scoped BSR. elected non-scoped BSR.
Each group-to-C-RP mapping is included in precisely one of these BSM, Each group-to-C-RP mapping is included in precisely one of these BSM,
namely the scoped BSM for the narrowest scope containing the group range namely the scoped BSM for the narrowest scope containing the group range
of the mapping, if any, or the non-scoped BSM otherwise. of the mapping, if any, or the non-scoped BSM otherwise.
A scoped BSM MUST have at least one group range, and the first group A scoped BSM MUST have at least one group range, and the first group
range in a scoped BSM MUST have the "Admin Scope Zone" bit set. This range in a scoped BSM MUST have the "Admin Scope Zone" bit set. This
skipping to change at page 22, line 45 skipping to change at page 22, line 40
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
group, but in some circumstances (described in section 3.5) Bootstrap group, but in some circumstances (described in section 3.5) Bootstrap
messages are unicast to a specific PIM neighbor. messages are unicast to a specific PIM neighbor. Unicast Bootstrap
messages MUST be sent with TTL 1 to the source address of the neighbor's
PIM hello messages.
The IP source address used for Candidate-RP-Advertisement messages is a The IP source address used for Candidate-RP-Advertisement messages is a
domain-wide reachable address. The IP source address used for Bootstrap domain-wide reachable address. The IP source address used for Bootstrap
messages (regardless of whether they are being originated or forwarded) messages (regardless of whether they are being originated or forwarded)
is the link-local address of the interface on which the message is being is the link-local address of the interface on which the message is being
sent (that is, the same source address that the router uses for the sent (that is, the same source address that the router uses for the
Hello messages it sends out that interface). Hello messages it sends out that interface).
All Bootstrap and Candidate-RP-Advertisement messages SHOULD carry the All Bootstrap and Candidate-RP-Advertisement messages SHOULD carry the
Router Alert IP option. See section 6 for information about the way in Router Alert IP option [7] for IPv4, and the IPv6 Router Alert Option
which the Router Alert option is checked by receving routers.
[8] for IPv6. See section 6 for information about the way in which the
Router Alert option is checked by receiving routers.
The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS
group is ff02::d. group is ff02::d.
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
specification [1]: specification [1]:
o Encoded-Unicast format o Encoded-Unicast format
o Encoded-Group format o Encoded-Group format
skipping to change at page 23, line 36 skipping to change at page 23, line 35
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 [12]. 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 24, line 49 skipping to change at page 24, line 49
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
native encoding and 128 for IPv6 native encoding). native 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 may be divided up into 'semantic fragments' if the
original message exceeds the maximum packet size boundaries. Basically, resulting IP datagram would exceed the maximum packet size boundaries.
a single Bootstrap message can be sent as multiple packets (semantic Basically, a single Bootstrap message can be sent as multiple semantic
fragments), so long as the fragment tags of all the packets comprising fragments (each in a separate IP datagram), so long as the fragment tags
the message is the same. of all the semantic fragments comprising the message are the same. The
format of a single non-fragmented message is the same as the one used
for semantic fragments.
The format of a single `fragment' is given below: The format of a single `fragment' is given below:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Tag | Hash Mask Len | BSR Priority | | Fragment Tag | Hash Mask Len | BSR Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 27, line 29 skipping to change at page 27, line 29
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. This field SHOULD be the same for all fragments belonging to
the same Bootstrap message. 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. Note considered as a high order byte when comparing BSR addresses. BSRs
that for historical reasons, the highest BSR priority is 255 (the should by default set this field to 64. Note that for historical
higher the better), whereas the highest RP Priority (see below) is reasons, the highest BSR priority is 255 (the higher the better),
0 (the lower the better). whereas the highest RP Priority (see below) is 0 (the lower the
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 prefix (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 address 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
skipping to change at page 28, line 47 skipping to change at page 28, line 47
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
Fragment (BSMF) packets; this is known as semantic fragmentation. It is Fragments (BSMF); this is known as semantic fragmentation. Each of
needed when the BSM would exceed the MTU of the link the packet will be these must be according to the above format.
forwarded over.
The packet would be too large because the set of group prefixes and the This is useful if the BSM would otherwise exceed the MTU of the link the
RPs for each group prefix are too long to fit in one packet. The BSR message will be forwarded over. If one relies purely on IP
fragmentation, one would lose the entire message if one fragment is
will then split the BSM across several BSMF packets; each of these must lost. By use of semantic fragmentation, one lost IP fragment will only
be a well-formed BSMF packet in its own right. 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
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
group ranges the lost semantic fragment contains information for.
If the BSR can split up the BSM so that different group prefixes (and If the BSR can split up the BSM so that each group prefix (and all of
their RP information) can fit in different fragments, then it should do its RP information) can fit entirely inside one BSMF, then it should do
so. If one of these BSMF packets is then lost, the state from the so. If a BSMF is lost, the state from the previous BSM for the group-
previous BSM for the group-prefix from the missing packet will be prefixes from the missing BSMF will be retained. Each fragment that
retained. Each fragment that does arrive will update the RP information does arrive will update the RP information for the group-prefixes
for the group-prefixes contained in that fragment, and the new group-to- contained in that fragment, and the new group-to-RP mappings for those
RP mapping for those can be used immediately. The information from the can be used immediately. The information from the missing fragment will
missing fragment will be obtained when the BSM is next transmitted. In be obtained when the next BSM is transmitted.
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 If the list of RPs for a single group-prefix is long, one may split the
single BSMF packet, then that information must be split across multiple information across multiple BSMFs to avoid IP fragmentation. In this
BSMF packets. In this case, all the BSMF packets comprising the case, all the BSMFs comprising the information for that group-prefix
information for that group-prefix must be received before the group-to- must be received before the group-to-RP mapping in use can be modified.
RP mapping in use can be modified. This is the purpose of the RP Count This is the purpose of the RP Count field - a router receiving BSMFs
field - a router receiving BSMF packets from the same BSM (ie that have from the same BSM (i.e. that have the same fragment tag) must wait until
the same fragment tag) must wait until the BSMFs providing RP Count RPs BSMFs providing RP Count RPs for that group-prefix have been received
for that group-prefix have been received before the new group-to-RP before the new group-to-RP mapping can be used for that group-prefix.
mapping can be used for that group-prefix. If a single BSMF from such a If a single BSMF from such a large group-prefix is lost, then that
large group-prefix is lost, then that entire group-prefix will have to entire group-prefix will have to wait until the next BSM is originated.
wait until the next BSM is originated. Hence the benefit of using semantic fragmentation is in this case
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-prefixes from the
BSM. A router receiving a set of BSMFs cannot tell if a group-prefix is 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 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 group-prefix still exists, and that the BSMF describing it has been
lost. It should retain this information for BS_Timeout. Thus for a BSR lost. It should retain this information for BS_Timeout. Thus for a BSR
to remove a group-prefix from the BSR, it should include that group- 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 prefix, but with a RP Count of zero, and it should resend this
information in each BSM for BS_Timeout. information in each BSM for BS_Timeout.
skipping to change at page 35, line 41 skipping to change at page 35, line 41
addresses that are infrastructure addresses in the PIM domain. addresses that are infrastructure addresses in the PIM domain.
The principal threat to Bootstrap message security comes from hosts The principal threat to Bootstrap message security comes from hosts
within the PIM domain that attempt to subvert the BSR mechanism. They 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 may be able to do this by sending PIM messages to their local router, or
by unicasting a Bootstrap message to another PIM router during the brief by unicasting a Bootstrap message to another PIM router during the brief
interval after it has restarted. interval after it has restarted.
6.3.1. Rejecting Unicast Bootstrap Messages 6.3.1. Rejecting Unicast Bootstrap Messages
All Bootstrap messages SHOULD carry the Router Alert IP option. If a All Bootstrap messages SHOULD carry the Router Alert option, for IPv4
PIM router receives a Bootstrap message that does not carry the Router the Router Alert IP option [7], and for IPv6, the IPv6 Router Alert
Alert option, it SHOULD drop it (a configuration option should also be Option [8]. If a PIM router receives a Bootstrap message that does not
provided to disable this check on a per-interface basic for backward carry the Router Alert option, it SHOULD drop it (a configuration option
compatibility with older PIM routers). The Router Alert option allows a should also be provided to disable this check on a per-interface basic
PIM router to perform checks on unicast packets it would otherwise for backward compatibility with older PIM routers). The Router Alert
blindly forward. All PIM routers should check that packets with Router option allows a PIM router to perform checks on unicast packets it would
Alert that are not destined for the router itself are not PIM Bootstrap otherwise blindly forward. All PIM routers should check that packets
messages. Any such packets should be dropped and logged as a possible with Router Alert that are not destined for the router itself are not
security issue - it is never acceptable for a PIM Bootstrap message to PIM Bootstrap messages. Any such packets should be dropped and logged
travel multiple IP hops. as a possible security issue - it is never acceptable for a PIM
Bootstrap message to travel multiple IP hops.
6.3.2. Rejecting Bootstrap Messages from Invalid Neighbors 6.3.2. Rejecting Bootstrap Messages from Invalid Neighbors
Most hosts that are likely to attempt to subvert PIM BSR are likely to 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 be located on leaf subnets. We recommend that implementors 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
skipping to change at page 36, line 36 skipping to change at page 36, line 36
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.
6.4.1. Non-Cryptographic Security of C-RP-Adv Messages 6.4.1. Non-Cryptographic Security of C-RP-Adv Messages
We specify that C-RP-Adv messages SHOULD also carry the Router Alert IP We specify that C-RP-Adv messages SHOULD also carry the Router Alert
option, and that the BSR SHOULD by default drop and log C-RP-Adv 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 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 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 very low, so the extra load on routers forwarding these packets will be
insignificant. PIM routers forwarding such a packet may then be capable insignificant. PIM routers forwarding such a packet may then be capable
of checking whether the packet came from a valid PIM neighbor, although of checking whether the packet came from a valid PIM neighbor, although
note that such checks are only possible if the unicast and multicast note that such checks are only possible if the unicast and multicast
topologies in the network are congruent. If this is not the case, it is topologies in the network are congruent. If this is not the case, it is
legitimate to receive a C-RP-Adv message from a router which is not a legitimate to receive a C-RP-Adv message from a router which is not a
valid PIM neighbor, and therefore in this situation a PIM router MUST valid PIM neighbor, and therefore in this situation a PIM router MUST
skipping to change at page 37, line 18 skipping to change at page 37, line 18
6.4.2. Cryptographic Security of C-RP-Adv Messages 6.4.2. Cryptographic Security of C-RP-Adv Messages
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
Adv messages does not remove the need for the non-cryptographic messages does not remove the need for the non-cryptographic mechanisms,
mechanisms, as explained below. as explained below.
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 prevent unicast The non-cryptographic security mechanisms above prevent unicast
Bootstrap messages from traveling multiple hops, and constrain who can Bootstrap messages from traveling multiple hops, and constrain who can
skipping to change at page 38, line 28 skipping to change at page 38, line 28
Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas and Hugh Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas and Hugh
Holbrook. This BSR specification draws heavily on text from RFC 2362. Holbrook. This BSR specification draws heavily on text from RFC 2362.
Many members of the PIM Working Group have contributed comments and Many members of the PIM Working Group have contributed comments and
corrections for this document, including Christopher Thomas Brown, Ardas corrections for this document, including Christopher Thomas Brown, Ardas
Cilingiroglu, Murthy Esakonu, Venugopal Hemige, Prashant Jhingran, Cilingiroglu, Murthy Esakonu, Venugopal Hemige, Prashant Jhingran,
Rishabh Parekh and Katta Sambasivarao. Rishabh Parekh and Katta Sambasivarao.
9. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. IANA is requested to assign a value for the IPv6 Router Alert Option [8]
to be used for both Bootstrap and Candidate-RP-Advertisement messages.
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)", Internet Draft draft-ietf-pim-sm- Specification (Revised)", Internet Draft draft-ietf-pim-sm-
v2-new-11.txt v2-new-11.txt
[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-07.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, Jul
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, Mar 2005.
[5] R. Hinden, S. Deering, "Internet Protocol Version 6 (IPv6) [5] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC
Addressing Architecture", RFC 3513, Apr 2003. 4291, Feb 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, Mar 1997.
[7] D. Katz, "IP Router Alert Option", RFC 2113, Feb 2006.
[8] C. Partridge, A. Jackson, "IPv6 Router Alert Option", RFC 2711, Oct
1999.
11. Informative References 11. Informative References
[7] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode [9] 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 [10] 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, Jan 2003.
[9] D. Farinacci, Y. Cai, "Anycast-RP using PIM", Internet Draft draft- [11] D. Farinacci, Y. Cai, "Anycast-RP using PIM", Internet Draft draft-
ietf-pim-anycast-rp-04.txt ietf-pim-anycast-rp-07.txt
[10] IANA, "Address Family Numbers", linked from [12] 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 Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
nbhaskar@cisco.com nbhaskar@cisco.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
Data Connection Ltd
100 Church Street
Enfield
EN2 6BQ
United Kingdom
james@lingard.com james@lingard.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 Internet Society (2005). This document is subject to Copyright (C) The Internet Society (2006). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 52 change blocks. 
148 lines changed or deleted 159 lines changed or added

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