Internet Engineering Task Force                                   PIM WG
INTERNET-DRAFT                                       Nidhi Bhaskar/Cisco
draft-ietf-pim-sm-bsr-04.txt
draft-ietf-pim-sm-bsr-05.txt                       Alexander Gall/SWITCH
                                           James Lingard/Data Connection
                                                     Stig Venaas/UNINETT
                                                        18 July 2004 February 2005
                                                    Expires: January August 2005

                Bootstrap Router (BSR) Mechanism for PIM

Status of this Document

By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or will be
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than a "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

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@catarina.usc.edu. pim@ietf.org.

Copyright Notice

Copyright (C) The Internet Society (2004). (2005). All Rights Reserved.

                                Abstract

     This document specifies the Bootstrap Router (BSR) mechanism
     for the class of multicast routing protocols in the PIM
     (Protocol Independent Multicast protocol) Multicast) family that use the concept
     of a Rendezvous Point as a means for receivers to discover the
     sources that send to a particular multicast group.  BSR is one
     way that a multicast router can learn the set of group-to-RP
     mappings required in order to function.  The mechanism is
     dynamic, largely self-configuring, and robust to router
     failure.

                           Table of Contents

     1. Introduction. . . . . . . . . . . . . . . . . . . . . .   4
      1.1. General Overview and Background. . . . . . Background . . . . .   4
      1.2. Overview of Bootstrap and RP Discovery for
      Global Scope. . . . . . . . . . . . . . . . .   4
      1.2. Protocol Overview. . . . . . .   7
      1.3. Administratively Scoped Multicast and BSR. . . . . .   8
      1.4. Bi-directional PIM . . . . . .   6
      1.3. Administrative Scoping and BSR . . . . . . . . . . .   9   7
     2. BSR State and Timers. . . . . . . . . . . . . . . . . .   9
     3. Bootstrap Router Election and RP-Set
     Distribution
        Distribution. . . . . . . . . . . . . . . . . . . . . .   9
      3.1. Bootstrap Router Election. . . . . . . . . . . . . .   9
       3.1.1. Per-Scope-Zone Candidate-BSR State
              Machine . . . . . . . . . . . . . . . . . . . . .  10
      3.1. Sending Candidate-RP-Advertisements.
       3.1.2. Per-Scope-Zone State Machine for Non-
              Candidate-BSR Routers . . . . . . . . . . . . . .  12
       3.1.3. Bootstrap Message Processing Checks . . . . . . .  14
       3.1.4. State Machine Transition Events . . . . . . . . .  14
       3.1.5. State Machine Actions . . . . . . . . . . .  19 . . .  15
      3.2. Sending Candidate-RP-Advertisement Messages. . . . .  16
      3.3. Creating the RP-Set at the BSR . . . . . . . . . . .  20
      3.3.  18
      3.4. Forwarding Bootstrap Messages. . . . . . . . . . . .  20
      3.5. Unicasting Bootstrap Messages to New and
           Rebooting Routers. . . . . . . . . . . . . . . . . .  21
      3.4.
      3.6. Receiving and Using the RP-Set . . . . . . . . . . .  22  21
     4. Message Formats . . . . . . . . . . . . . . . . . . . .  22  21
      4.1. Bootstrap Message Format . . . . . . . . . . . . . .  25  24
       4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . .  28  27
      4.2. Candidate-RP-Advertisement Message Format. . . . . . . . . .  30  29
     5. Default Values for Timers and Timer Values . . . . . . . . . . . . . . .  31 .  30
     6. Security Considerations . . . . . . . . . . . . . . . .  32  33
      6.1. Possible Threats . . . . . . . . . . . . . . . . . .  32  33
      6.2. Limiting Third-Party DoS Attacks . . . . . . . . . .  33
      6.3. BS Bootstrap Message Security. Security . . . . . . . . . . . . .  34
       6.3.1. Rejecting Unicast Bootstrap Messages. . . .  33
      6.4. C-RP-Advertisement Security. . . .  34
       6.3.2. Rejecting Bootstrap Messages from Invalid
              Neighbors . . . . . . . . .  35
      6.5. Denial of Service using IPsec. . . . . . . . . . . .  36
     7. Contributors.  35
      6.4. Candidate-RP-Advertisement Message Security. . . . .  35
       6.4.1. Non-Cryptographic Security of C-RP-Adv
              Messages. . . . . . . . . . . . . . . . . .  36
     8. Acknowledgments . . .  35
       6.4.2. Cryptographic Security of C-RP-Adv
              Messages. . . . . . . . . . . . . . . . . .  36
     9. IANA Considerations . . .  36
      6.5. Denial of Service using IPsec. . . . . . . . . . . .  36
     7. Contributors. . . . .  37
     10. Normative References . . . . . . . . . . . . . . . . .  37
     11. Informative References
     8. Acknowledgments . . . . . . . . . . . . . . . .  37
     12. Authors' Addresses . . . . . . . . .  37
     9. IANA Considerations . . . . . . . . .  37

                            List of Figures

     Figure 1. Per-Scope-Zone State-machine for a candi-
     date BSR . . . . . . . . .  37
     10. Normative References . . . . . . . . . . . . . . . .  11
     Figure 2. Per-Scope-Zone State-machine for a router
     not configured as C-BSR. .  37
     11. Informative References . . . . . . . . . . . . . . . .  13  38

1.  Introduction

This document assumes some familiarity with the workings concepts of Rendezvous Point-
based multicast routing protocols in the PIM protocol family, in
particular with Protocol
Independent Multicast - Sparse Mode (PIM-SM), as defined in [1], and Bi-directional Bi-
directional Protocol Independent Multicast (BIDIR-PIM), as defined in [3],
[2], as well as with Administratively Scoped IP Multicast, as described
in [2].

Throughout the document, any reference to the PIM protocol family is
restricted to [3], and the subset of RP-based protocols unless stated otherwise. IPv6 Scoped Address Architecture, described in [4].

For correct operation, every multicast router within a PIM domain must
be able to map a particular multicast group address to the same RP.  If
Rendezvous Point (RP).  The PIM specifications do not mandate the use of
a single mechanism to provide routers with the information to perform
this group-to-RP mapping.

This document describes the PIM Bootstrap Router (BSR) mechanism.  BSR
is not one way that a multicast router can learn the case then black holes may appear, where some receivers information required to
perform the group-to-RP mapping.  The mechanism is dynamic, largely
self-configuring, and robust to router failure.

BSR was first defined in RFC 2362 [7], which has since been obsoleted.
This document provides an updated specification of the BSR mechanism
from RFC 2362, and also extends it to cope with administratively scoped
region boundaries and different flavours of routing protocols.

Throughout the document, any reference to the domain cannot receive some groups.  A PIM domain protocol family is
restricted to the subset of RP-based protocols, namely PIM-SM and BIDIR-
PIM, unless stated otherwise.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this context
document are to be interpreted as described in RFC 2119 [6].

1.1.  Background

A PIM domain is a contiguous set of routers that all implement the multicast routing
protocol PIM and
are configured to operate within a common boundary defined by PIM
Multicast Border Routers (PMBRs).  PMBRs connect each PIM domain to the
rest of the internet.

A

Every PIM domain may also be broken up into multiple administrative scope
regions - these are regions where a border has been configured so that a
range of multicast groups will not be forwarded across that border.  For
more information on Administratively Scoped IP Multicast, see RFC 2365
[2]. The modified criteria for admin-scoped regions are that the region
is convex with respect to forwarding based on the MRIB, and that all PIM
routers within the same scope region map a particular scoped group to
the same RP within that region.

The PIM specifications do not mandate the use of a single mechanism to
provide routers with the information to perform the group-to-RP mapping.
This document describes the Bootstrap Router (BSR) mechanism.  BSR was
first defined in RFC 2362 [5], which has since been obsoleted.  This
document provides an updated specification of the BSR mechanism from RFC
2362, and also extends it to cope with administratively scoped region
boundaries and different flavours of routing protocols.

1.1.  General Overview and Background

Every PIM multicast group needs to multicast group needs to be associated with the IP address of
a Rendezvous Point (RP).  This address is used to build as the root of a group-specific group-
specific distribution tree rooted at that address whose branches extend to all nodes in the
domain that want to receive traffic sent to the group.  Senders inject
packets into the tree in such a manner that they reach all connected
receivers.  How this is done and how the packets are forwarded along the
distribution tree depends on the particular routing protocol.

For all senders to reach all receivers, it is crucial that there exists
a single distribution tree.  This can only be achieved when all routers
in the domain use the same mappings of group addresses to RP addresses.

There

An exception to the above is where a PIM domain has been broken up into
multiple administrative scope regions.  These are regions where a number border
has been configured so that a set of ways how such group-to-RP mappings can multicast groups will not be
established.  The simplest solution is for
forwarded across that border.  In this case, all the PIM routers in within the domain
same scope region must map a particular scoped group to be statically configured with the same information.  However, static
configuration generally doesn't scale well, and also does not
dynamically adapt to route around router or link failures.  The
mechanism specified in this document is known as RP
within that region.

In order to determine the PIM BootStrap
Router mechanism, or BSR RP for short, and provides a dynamic, adaptive
mechanism to distribute group-to-RP mapping information rapidly
throughout multicast group, a domain. PIM router
maintains a collection of group-to-RP mappings, called the RP-Set.  A
group-to-RP mapping contains the following elements.

o Multicast group range, expressed as an address and prefix length

o RP Priority

o <<<<<<< bsr.nrf IP address of RP. priority

o RP Holdtime ======= IP address of RP

o RP Holdtime >>>>>>> 1.49

o Hash mask length

The collection of all group-to-RP mappings known to a router at any
point in time is called the RP-set.  The router that assumes the role of
the BSR maintains a logically distinct RP-set called the C-RP-set, from
which it constructs the actual RP-set as explained below.

o SM / BIDIR flag

In general, the group ranges of these mapping entries group-to-RP mappings may overlap
in arbitrary ways; hence a particular multicast group may be covered by
multiple mapping entries. group-to-RP mappings.  When this is the case, the router
chooses only one of the entries RPs by applying a deterministic algorithm so
that all routers in the domain make the same choice and hence apply the same group-to-RP mapping. choice.  It is important to
note that this algorithm is part of the specification of the individual
routing protocols (and may differ among them), not of the BSR
specification.

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
to be statically configured with the same information.  However, static
configuration generally doesn't scale well, and, except when used in
conjunction with Anycast-RP (see [8] and [9]), does not dynamically
adapt to route around router or link failures.

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
domain.  It is adaptive, in that if an RP becomes unreachable, this will
be detected and the mapping tables RP-Sets will be modified so that the unreachable RP
is no longer used, used.

1.2.  Protocol Overview

In this section we give an informal and non-definitive overview of the new tables will be rapidly distributed throughout
the domain.
BSR mechanism.  The definitive specification begins in section 2.

The general idea behind the BSR-mechanism BSR mechanism is that some of the PIM
routers within a PIM domain are configured to be potential RPs for the
domain.  These are known as candidate-RPs Candidate-RPs (C-RPs).  A subset of the C-
RPs will eventually be used as the actual RPs for the domain.  In
addition, some of the PIM routers in the domain are configured as to be
candidate bootstrap routers routers, or Candidate-BSRs (C-BSRs).  One of these
C-BSRs will be elected to serve as be the bootstrap router (BSR) for the domain,
and all the PIM routers in the domain will learn the result of this
election through Bootstrap messages.  The C-RPs will then report their
candidacy to the elected BSR, which stores the group-to-C-RP mappings in its C-RP-
set.  It will chose chooses a subset of these mappings as the actual RP-set C-RPs and
distribute it
distributes corresponding group-to-RP mappings to all the routers in the
domain through Bootstrap messages.

The mechanism is complicated slightly by

In more detail, the presence of
administratively-scoped multicast regions within the PIM domain.  An
admin-scope region is a convex connected set of PIM routers surrounded
by an admin-scope boundary.  The boundary specifies a range of multicast
addresses that will not be forwarded into or out of the scoped region.
This complicates BSR because we do not want a PIM router within the
scoped region to use an RP outside the scoped region (or vice-versa).
Thus we need to modify the basic mechanism to ensure that this doesn't
happen - this is done by electing a BSR for every admin-scope region
within a PIM domain, and also a global BSR for the whole PIM domain.  C-
RPs typically register multiple times; once to the BSR of every admin
scope zone the C-RP is in.  For the remainder of this overview we will
ignore admin-scope regions, and concentrate on the global BSR and its
role.  Within each scope zone, the BSR for that zone acts in a similar
manner to how the global BSR acts for the whole domain. works as follows.  There are four
basic phases to the BSR mechanism (although in practice all phases may be occurring
simultaneously):

1.   BSR election. Election.  Each Candidate-BSR originates bootstrap Bootstrap messages
     (BSMs).  Every BSM contains a BSR priority Priority field.  Routers within
     the domain flood the BSMs throughout the domain.  A C-BSR that
     hears about a higher-priority C-BSR than itself then suppresses its
     sending of further BSMs for some period of time.  The single
     remaining C-BSR becomes the elected BSR, and its BSMs inform all
     the other routers in the domain that it is the elected BSR.

2.   C-RP advertisement. Advertisement.  Each Candidate-RP within a domain sends
     periodic Candidate-RP-Advertisement (C-RP-Adv) messages to the
     elected BSR.  A C-RP-Adv message includes the priority of the
     advertising C-RP, as well as a list of group ranges for which the
     candidacy is advertised.  In this way, the BSR learns about
     possible RPs that are currently up and reachable.

3.   C-RP-Set   RP-Set Formation.  The BSR selects a subset of the C-RPs that it
     has received C-RP-Adv messages from to form the RP-Set.  In general
     it should do this in such a way that the RP-Set is neither too
     large to inform all the routers in the domain about, nor too small
     so that load is overly concentrated on some RPs.  It should also
     attempt to produce an RP-Set that does not change frequently.

4.   RP-Set Flooding.  In future bootstrap Bootstrap messages, the BSR includes
     the RP-Set information.  As bootstrap  Bootstrap messages are flooded rapidly through the
     domain, this which ensures that the RP-Set rapidly reaches all the
     routers in the domain.  BSMs are originated periodically to ensure
     consistency after failure restoration.

     When a PIM router receives a Bootstrap message, it adds the group-
     to-RP mappings contained therein to its pool of mappings obtained
     from other sources (e.g. static configuration).  It calculates the
     final mappings of group addresses to RP addresses from this pool
     according to rules specific to the particular routing protocol and
     uses that information to construct multicast distribution trees.

In

If a PIM domain becomes partitioned, each area separated from the following sections we discuss more details about old
BSR for global
scope will elect its own BSR, which will distribute an RP-Set containing
RPs that are reachable within that partition.  When the partition heals,
another election will occur automatically and for admin scoping, before specifying the protocol starting in
section 2.

1.2.  Overview of Bootstrap and RP Discovery for Global Scope

A small set of routers from a domain are configured as candidate
bootstrap routers (C-BSRs) and, through a simple election mechanism, a
single BSR is selected for that domain.  A set of routers within a
domain are also configured as candidate RPs (C-RPs); typically these
will be the same routers that are configured as C-BSRs.  Candidate RPs
periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to
the BSR of that domain, advertising their willingness to be an RP.  A C-
RP-Adv message includes the address of the advertising C-RP, as well as
an optional list of group addresses and mask length fields, indicating
the group prefix(es) for which the candidacy is advertised.  The BSR
then includes a set of these Candidate-RPs (the RP-Set), along with
their corresponding group prefixes, in Bootstrap messages it
periodically originates.  Bootstrap messages are distributed hop-by-hop
throughout the domain.

If a PIM domain becomes partitioned, each area separated from the old
BSR will elect its own BSR, which will distribute an RP-Set containing
RPs that are reachable within that partition.  When the partition heals,
another election will occur automatically and only one of only one of the BSRs will
continue to send out Bootstrap messages.  As is expected at the time of
a partition or healing, some disruption in packet delivery may occur.
This time will be on the order of the region's round-trip time and the
bootstrap router timeout
BS_Timeout value.

1.3.  Administratively Scoped Multicast  Administrative Scoping and BSR

Administratively Scoped IP Multicast, as defined

The mechanism described in RFC 2365 [2], the previous section does not work when the
PIM domain is divided into administratively scoped regions.  To handle
this situation, we use the protocol modifications described in this
section.

Administrative scoping permits a network provider PIM domain to configure scope boundaries at multicast
routers.  Such be divided into multiple
admin-scope regions.  Each admin-scope region is a scope boundary consists convex connected set
of PIM routers, and is associated with a range set of group addresses.  The
boundary of multicast
addresses (expressed as an address and mask) that the router will admin-scope region is formed by Zone Border Routers
(ZBRs).  ZBRs are configured not to forward across traffic for any of the
scoped group addresses into or out of the scoped region.  It is
important to note that a given scope boundary always creates at least
two scoped regions: one on either side of the boundary.

In IPv4, administratively scoped regions are associated with a set of
addresses given by an address and a prefix length.  In IPv6,
administratively scoped regions are associated with a set of addresses
given by a single scope ID value.  The set of addresses corresponding to
a given scope ID value is defined in [5].  For correct operation, such example, a scope ID of 5
maps to the 16 IPv6 address ranges ff[0-f]5::/16.

There are certain topological restrictions on admin-scope regions.
Firstly, the 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 does not pass through a configured scope border router, and that
the multicast capable path between any arbitrary pair of multicast
routers in the scope zone must remain in the zone.

For BSR to function correctly with admin scoping, there must be a BSR
and at least one C-RP within every admin scope region.  Admin scope zone
boundaries must be configured at the Zone Border Routers (ZBRs), as they
need to filter PIM Join messages that might inadvertently cross the
border due to error conditions.  In addition, at least a
boundary for one C-BSR within
the admin scope zone must be configured to always be a C-BSR boundary for the admin all smaller scopes,

where a smaller scope zone's address range.

A separate BSR election will then take place (using bootstrap messages) for every admin scope range (plus IPv4 is one for the global range).  Admin
scope ranges are identified in the bootstrap message because the group whose address range is marked (using contained
within the "Admin Scope" bit, previously a "Reserved"
bit) to indicate that this is an administrative scope other address range, and not
just a range that a particular set of RPs are configured for IPv6 is one whose scope ID is
less than the other scope ID.

Administrative scoping complicates BSR because we do not want a PIM
router within the scoped region to use an RP outside the scoped region.
Thus we need to modify the basic mechanism to ensure that this doesn't
happen.

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
PIM domain.  Thus a separate BSR election takes place for each admin-
scope region, a C-RP typically registers to the BSR of every admin scope
zone it is in, and every PIM router receives Bootstrap messages for
every scope zone it is in.  The Bootstrap messages sent by the BSR for a
particular scope zone contain information about the RPs that should be
used for the set of addresses associated with that scope zone.

Bootstrap messages are marked to handle. indicate which scope zone they belong
to.  Such admin scoped bootstrap message packets Bootstrap messages are flooded in the normal way,
but will not be forwarded by another a ZBR across the boundary for that scope zone (see Section 3.3 for
zone.

For the specifics of this).

We do not require that C-RPs BSR mechanism to function correctly with admin scoping, within the
each admin scope zone region there must be configured to know
about the scope zone, as they can learn of its existence from bootstrap
messages.  However, we recommend that router vendors implement
configuration options that allow a at least one C-BSR, and at least
one C-RP to be that is configured to be a C-RP for global scope only, for one the set of more admin scopes only, or for all
scopes, both global and admin scoped.  We also recommend that group addresses
associated with the
default be that a C-RP is a C-RP for all scopes, both global and admin
scoped.

Unless configured otherwise, C-RPs discover the existence of the admin
scope zone and its group range from receiving scoped region.

Even when administrative scoping is used, a bootstrap message from copy of the scope zone's elected BSR containing mechanism is
still used across the scope zone's group-range,
marked using entire PIM domain, in order to distribute RP
information for groups that are not administratively scoped.  We call
this copy of the "Admin Scope" bit.  A C-RP stores mechanism Non-Scoped BSR.  The copies of the mechanism
run for each elected BSR's
address admin-scope region are called Scoped BSR.

Only the C-BSRs and the admin scope range contained in its bootstrap message.
It separately unicasts Candidate-RP-Advertisement messages ZBRs need to be configured to know about the
existence of the
appropriate BSR for every admin scope range within which it is willing

to serve as an RP. zones.  Other routers, including the C-RPs, learn
of their existence from Bootstrap messages.

All PIM routers within a PIM bootstrap domain where admin scope ranges
are in use must be capable of receiving bootstrap Bootstrap messages and storing
the winning BSR and RP-set RP-Set for all admin scope zones that apply.  Thus
PIM routers that only implement RFC 2362 or Non-Scoped BSR (which only
allows one BSR per domain) cannot be used in PIM domains where admin scope zones are
configured.

1.4.  Bi-directional PIM

Routers doing Bi-directional PIM [3] need group-to-RP mappings similar
to PIM-SM.  Group ranges for use by Bi-directional PIM are identified in
bootstrap messages by a "Bi-dir" bit (previously within the admin-scope regions
of a "Reserved" bit).
Routers that don't support Bi-directional PIM MUST NOT ignore these
ranges.  They MUST NOT treat them as having the default mode, i.e. PIM-
SM. domain.

2.  BSR State and Timers

A PIM router implementing BSR holds the following state state.

     RP-Set

     Per Configured or Learned Scope Zone (Z):

          At all routers:

          List of Active Scope Zones

          Per Scope Zone:

               Bootstrap State:

                    o

               Current Bootstrap Router's IP Address

                    o

               Current Bootstrap Router's BSR Priority

                    o Bootstrap Timer (BST)

                    o

               Last BSM received from this current BSR

          RP-Set

               Bootstrap Timer (BST(Z))

               Per group-to-RP mapping (M):

                    Group-to-RP mapping Expiry Timer (GET(M,Z))

          At a Candidate BSR:

          Per Scope Zone:

               o Candidate-BSR for Z:

               My state: One of "Candidate-BSR", "Pending-BSR",
                    "Elected-BSR"

          At a router that is not a Candidate BSR:

          Per Scope Zone: Candidate-BSR for Z:

               My state: One of "Accept Any", "Accept Preferred"

               Scope-Zone Expiry Timer: SZT(Z)

Bootstrap state is described in section 3, and the RP-Set is described
in section 3.4.

The following timers are also required:

     At Timer (SZT(Z))

          At the current Bootstrap Router for Z only:

               Per Scope Zone (Z):

               Per group-to-C-RP mapping (M):

                    Group-to-C-RP mapping Expiry Timer: CGET(M,Z) Timer (CGET(M,Z))

     At the C-RPs a C-RP only:

          C-RP Advertisement Timer: CRPT

     At all routers:

          Per Scope Zone (Z):

               Per group-to-RP mapping (M):

                    Group-to-RP mapping Expiry Timer: GET(M,Z) Timer (CRPT)

3.  Bootstrap Router Election and RP-Set Distribution

3.1.  Bootstrap Router Election

For simplicity, bootstrap Bootstrap messages (BSMs) are used in both the BSR election and
the RP-Set distribution mechanisms.

Each Bootstrap message indicates the scope that it belongs to.  If the
Admin Scope Zone bit is set in the first group range in the Bootstrap
message, the message is called a scoped BSM.  If the Admin Scope Zone
bit is not set in the first group range in the Bootstrap message, the
message is called a non-scoped BSM.

In a scoped IPv4 BSM, the scope of the message is given by the first
group range in the message, which can be any sub-range of 224/4.  In a
scoped IPv6 BSM, the scope of the message is given by the scope ID of
the first group range in the message, which must have a mask length of
at least 16.  For example, a group range of ff05::/16 with the Admin
Scope Zone bit set indicates that the Bootstrap message is for the scope
with scope ID 5.  If the mask length of the first group range in a
scoped IPv6 BSM is less than 16, the message MUST be dropped and a
warning SHOULD is logged.

The state-machine state machine for bootstrap Bootstrap messages depends on whether or not a
router has been configured to be a Candidate-BSR for a particular scope
zone.  The per-scope-zone state-machine state machine for a C-BSR is given below,
followed by the state-machine state machine for a router that is not configured to be
a C-BSR.

3.1.1.  Per-Scope-Zone Candidate-BSR State Machine

Figure 1: Per-Scope-Zone State-machine for a candidate BSR in tabular form

+-----------------------------------------------------------------------+
|                         When in C-BSR state                           |
+------------+-------------------+-------------------+------------------+
+-----------+------------------+--------------------+-------------------+
| Event     |  Receive         |  BS Timer  Bootstrap         | Receive non- Non-      |
|           |  Preferred BSM   |  Timer Expires     | preferred BSM     |
|           |                  |                    | from Elected      |
|           |                  |                    | BSR               |
+------------+-------------------+-------------------+------------------+
+-----------+------------------+--------------------+-------------------+
|           |  -> C-BSR state  |  -> P-BSR state    | -> P-BSR state    |
|           |  Forward BSM;    |  Set BS Timer Bootstrap     | Set BS Timer Bootstrap     |
| Action    |  Store RP-Set;   |  Timer to          | Timer to          |
|           |  Set BS Timer Bootstrap   |  rand_override  BS_Rand_Override  |  rand_override BS_Rand_Override  |
|           |  Timer to BS Timeout        |                    |                   |
+------------+-------------------+-------------------+------------------+
|           |  BS_Timeout      |                    |                   |
+-----------+------------------+--------------------+-------------------+

+-----------------------------------------------------------------------+
|                         When in P-BSR state                           |
+-------------+-------------------+------------------+------------------+
+------------+-------------------+-------------------+------------------+
| Event      |  Receive          | BS Timer  Bootstrap        |  Receive Non-    |
|            |  Preferred BSM    |  Timer Expires    |  preferred BSM   |
+-------------+-------------------+------------------+------------------+
+------------+-------------------+-------------------+------------------+
|            |  -> C-BSR state   |  -> E-BSR state   |  -> P-BSR state  |
|            |  Forward BSM;     |  Originate BSM;   |                  |
| Action     |  Store RP-Set;    |  Set BS Timer Bootstrap    |                  |
|            |  Set BS Timer Bootstrap    |  Timer to BS Period         |                  |
|            |  Timer to BS Timeout         |  BS_Period        |                  |
+-------------+-------------------+------------------+------------------+

+-----------------------------------------------------------------------+
|               When            |  BS_Timeout       |                   |                  |
+------------+-------------------+-------------------+------------------+

+-----------------------------------------------------------------------+
|                         When in E-BSR state                           |
+-------------+-------------------+------------------+------------------+
+------------+-------------------+-------------------+------------------+
| Event      |  Receive          | BS Timer  Bootstrap        |  Receive Non-    |
|            |  Preferred BSM    |  Timer Expires    |  preferred BSM   |
+-------------+-------------------+------------------+------------------+
+------------+-------------------+-------------------+------------------+
|            |  -> C-BSR state   |  -> E-BSR state   |  -> E-BSR state  |
|            |  Forward BSM;     |  Originate BSM;   |  Originate BSM;  |
| Action     |  Store RP-Set;    |  Set BS Timer Bootstrap    |  Set BS Timer Bootstrap   |
|            |  Set BS Timer Bootstrap    |  Timer to BS Period         |  Timer to BS Period        |
|            |  Timer to BS Timeout         |  BS_Period        |  BS_Period       |
|            |  BS_Timeout       |
+-------------+-------------------+------------------+------------------+                   |                  |
+------------+-------------------+-------------------+------------------+

A candidate-BSR Candidate-BSR may be in one of three states for a particular scope
zone:

Candidate-BSR (C-BSR)
     The router is a candidate to be the BSR for the scope zone, but
     currently another router is the preferred BSR.

Pending-BSR (P-BSR)
     The router is a candidate to be the BSR for the scope zone.
     Currently no other router is the preferred BSR, but this router is
     not yet the BSR.  For comparisons with incoming BS messages, the
     router treats itself as the elected BSR.  This is a temporary state that prevents
     rapid thrashing of the choice of BSR during BSR election.

Elected-BSR (E-BSR)
     The router is the elected bootstrap router BSR for the scope zone and it must
     perform all the BSR functions.

On startup, the initial state for this configured scope zone is
"Pending-BSR"; the BS Timer is initialized to the BS Timeout value.

In addition to the three states, there is one timer:

o The bootstrap timer (BS Timer) Bootstrap Timer (BST) - that is used to time out old bootstrap router
  information, and used in the election process to terminate P-BSR
  state.

On startup, the initial state for this configured scope zone is
"Pending-BSR"; the Bootstrap Timer is initialized to the BS_Timeout
value.

3.1.2.  Per-Scope-Zone State-machine State Machine for Non-Candidate-BSR Routers

Figure 2: Per-Scope-Zone State-machine for a router not configured as C-
                          BSR in tabular form

+-----------------------------------------------------------------------+
|                        When in NoInfo state                           |
+--------------------+--------------------------------------------------+
+---------------------+-------------------------------------------------+
|     Event           |        Receive BSM for unknown Admin Scope                              |
+--------------------+--------------------------------------------------+
+---------------------+-------------------------------------------------+
|                     |        -> AP State state                              |
|     Action          |        Forward BSM; Store RP-Set;               |
|                     |        Set BS Bootstrap Timer to BS Timeout; BS_Timeout;       |
|                     |        Set SZ Timer SZT to SZ Timeout SZ_Timeout                    |
+--------------------+--------------------------------------------------+
+---------------------+-------------------------------------------------+

+-----------------------------------------------------------------------+
|                       When in Accept Any state                        |
+---------------+-----------------------------+-------------------------+
+---------------+----------------------------+--------------------------+
|   Event       |    Receive BSM             |     SZ     Scope-Zone Expiry    |
|               |                            |     Timer Expires        |
+---------------+-----------------------------+-------------------------+
+---------------+----------------------------+--------------------------+
|               |    -> AP State state             |     -> NoInfo state      |
|               |    Forward BSM; Store      |     cancel     Cancel timers;       |
|   Action      |    RP-Set; Set BS             |     clear     Clear state          |
|   Action               |    Bootstrap Timer to BS      |                          |
|               |     Timeout;    BS_Timeout; Set SZ         |                          |
|               |     Timer    SZT to SZ             |                         |
|               |     Timeout SZ_Timeout       |                          |
+---------------+-----------------------------+-------------------------+
+---------------+----------------------------+--------------------------+

+-----------------------------------------------------------------------+
|                    When in Accept Preferred state                     |
+------------+--------------------+------------------+------------------+
+----------+-----------------------+------------------+-----------------+
| Event    | Receive Preferred     |   BS Timer  Bootstrap       |  Receive Non-   |
|          |  Preferred BSM                   |  Timer Expires   |  preferred BSM  |
+------------+--------------------+------------------+------------------+
+----------+-----------------------+------------------+-----------------+
|          | -> AP State state           |  -> AA State state     |  -> AP State state    |
|          | Forward BSM; Store    |  Refresh RP-     |                 |
| Action   |  Store RP-Set; Set           |   set;  Set; Remove     |                 |
| Action          |  Set BS Bootstrap Timer to    |  BSR state       |                 |
|          |  to BS Timeout;    |                  |                  |
|            | BS_Timeout; Set SZ Timer SZT   |                  |                 |
|          | to SZ Timeout SZ_Timeout         |                  |                 |
+------------+--------------------+------------------+------------------+
+----------+-----------------------+------------------+-----------------+
A router that is not a candidate-BSR Candidate-BSR may be in one of three states:

NoInfo
     The router has no information about this scope zone.  This state
     does not apply if the router is configured to know about this scope
     zone, or for the global scope zone.  When in this state, no state
     information is held and no timers run that refer to this scope
     zone.

Accept Any (AA)
     The router does not know of an active BSR, and will accept the
     first bootstrap Bootstrap message it sees as giving the new BSR's identity
     and the RP-Set.

Accept Preferred (AP)
     The router knows the identity of the current BSR, and is using the
     RP-Set provided by that BSR.  Only bootstrap Bootstrap messages from that BSR
     or from a C-BSR with higher weight than the current BSR will be
     accepted.

In addition to the three states, there are two timers:

o The Bootstrap Timer (BST) - used to time out old bootstrap router
  information.

o The Scope-Zone Expiry Timer (SZT) - used to time out the scope zone
  itself if Bootstrap messages specifying this scope zone stop arriving.

On startup, the initial state for this scope zone is "Accept Any" for
routers that know about this scope zone, either through configuration or
because the scope zone is the global scope which always exists; the SZ
Scope-Zone Expiry Timer is considered to be always running for such
scope zones.  For routers that do not know about a particular scope
zone, the initial state is NoInfo; no timers exist for the scope zone.

In addition to the three states, there are two timers:

o The bootstrap timer (BS Timer) - that is used to time out old
  bootstrap router information.

o The scope zone timer (SZ Timer) - that

3.1.3.  Bootstrap Message Processing Checks

When a Bootstrap message is used to time out the scope
  zone itself if BS messages specifying this scope zone stop arriving.

Bootstrap Message Processing Checks

When a bootstrap message is received, received, the following initial checks must
be performed:

if ( (DirectlyConnected(BSM.src_ip_address) ((DirectlyConnected(BSM.src_ip_address) == FALSE) OR
     (we have no Hello state for BSM.src_ip_address)) {
  drop the BS Bootstrap message silently
}

if (BSM.dst_ip_address == ALL-PIM-ROUTERS group) ALL-PIM-ROUTERS) {
  if ( BSM.src_ip_address (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address) ) RPF_neighbor(BSM.BSR_ip_address)) {
    drop the BS Bootstrap message silently
  }
} else if (BSM.dst_ip_address is one of my addresses) {
  if (Any ((any previous BSM for this scope has been accepted) OR
      (more than BS_Period has elapsed since startup)) {
    #the packet was unicast, but this wasn't
    #a quick refresh on startup
    drop the BS Bootstrap message silently
  }
} else {
  drop the BS Bootstrap message silently
}

if (the interface the message arrived on is an Admin Scope
    border for the BSM.first_group_address) {
  drop the BS Bootstrap message silently
}

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
ALL-PIM-ROUTERS group by the correct upstream router towards the BSR
that originated the BS Bootstrap message, or the router must have recently
restarted, have no BSR state for that admin scope (it just restarted) and have received the BS
Bootstrap message by unicast.  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 BS Bootstrap message.

BS State-machine

3.1.4.  State Machine Transition Events

If the bootstrap Bootstrap message passes the initial checks above without being
discarded, then it may cause a state transition event in one of the
above state-machines. state machines.  For both candidate and non-candidate BSRs, the
following transition events are defined:

     Receive Preferred BSM
          A bootstrap Bootstrap message is received from a BSR that has greater
          than higher or
          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.

          The weighting for weight of a BSR is defined to be the concatenation in fixed-
          precision
          fixed-precision unsigned arithmetic of the BSR priority Priority field
          from the bootstrap Bootstrap message and the IP address of the BSR from
          the
          bootstrap Bootstrap message (with the BSR priority Priority taking the most-
          significant bits and the IP address taking the least
          significant bits).

     Receive Non-preferred BSM
          A bootstrap Bootstrap message is received, regardless received from a BSR that has lower
          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.

     Receive Non-preferred BSM from Elected BSR weight.
          A non-candidate Bootstrap message is received from the elected BSR, but the
          BSR also Priority field in the received message has changed, so
          that now the following transition event defined: currently elected BSR has lower weight that the
          router itself.

     Receive BSM for unknown Admin Scope
          As "Receive BSM", except that
          A Bootstrap message is received, regardless of BSR weight.

In addition to state machine transitions caused by the admin scope zone indicated
          in receipt of
Bootstrap messages, a state machine transition takes place each time the BSM was not previously known at this router.

BS State-machine
Bootstrap Timer or Scope-Zone Expiry Timer expires.

3.1.5.  State Machine Actions

The state-machines state machines specify actions that include setting the BS timer Bootstrap
Timer and the Scope-Zone Expiry Timer to various values.  These values
are defined in Section 5.

In addition to setting and cancelling the timers, the following values:

     BS Period
          The periodic interval with which bootstrap messages are
          normally sent.  The default value is 60 seconds.

     BS Timeout
          The interval after which bootstrap router actions
may be triggered by state is timed out
          if no bootstrap message from that router has been heard.  The
          default value is 2 times the BS Period plus 10 seconds, which
          is 130 seconds.

     Randomized Override Interval
          The randomized interval during which a router avoids sending a
          bootstrap message while it waits to see if another router has
          a higher bootstrap weight.  This interval is to reduce control
          message overhead during BSR election.  The following
          pseudocode is proposed as an efficient implementation of this
          "randomized" value:

          Delay = 5 + 2 * log_2(1 + bestPriority - myPriority)
                  + AddrDelay

          where myPriority is the Candidate-BSR's configured priority,
          and bestPriority equals:

          bestPriority = Max(storedPriority, myPriority)

          and AddrDelay is given by the following for IPv4:

          if ( bestPriority == myPriority) {
              AddrDelay = log_2(storedAddr - myAddr) / 16
          } else {
              AddrDelay = 2 - (myAddr / 2^31)
          }

          and AddrDelay is given by the following for IPv6:

          if ( bestPriority == myPriority) {
              AddrDelay = log_2(storedAddr - myAddr) / 64
          } else {
              AddrDelay = 2 - (myAddr / 2^127)
          }

          where myAddr is the Candidate-BSR's address, storedAddr is the
          stored BSR's address, and storedPriority is the stored BSR's
          priority.

     SZ Timeout
          The interval after which a router will time out an Admin Scope
          zone that it has dynamically learned.  The interval MUST be
          larger than the BS Timeout.  The default value is ten times
          the BS Timeout, which is 1300 seconds.

In addition to setting the timers, the following actions may be
triggered by state-changes in the state-machines:

     Forward BSM
          A bootstrap changes in the state machines:

     Forward BSM
          A Bootstrap message that passes the Bootstrap Message
          Processing Checks is forwarded out of all interfaces with PIM
          neighbors (including the interface it is received on), except
          where this would cause the BSM to cross an admin-scope
          boundary for the scope zone indicated in the message.  For
          details, see section 3.3. 3.4.

     Originate BSM
          A new bootstrap Bootstrap message is constructed by the BSR, giving the
          BSR's address and BSR priority, and containing the BSR's
          chosen RP-Set.  The message is forwarded out of all multicast-
          capable interfaces, except where this would cause the BSM to
          cross an admin-scope boundary for the scope zone indicated in
          the message.  The IP source address of the message is the
          originating router's IP address on the interface the message
          is being forwarded from, the destination address is ALL-PIM-
          ROUTERS, and the TTL of the message is set to 1.

     Store RP-Set
          The router uses the group-to-RP mappings contained in a BSM to
          update its local RP-set. RP-Set.

          If a mapping does not yet exist, it is created and the
          associated group-to-RP Group-to-RP mapping expiry timer Expiry Timer (GET) is
          initialized with the holdtime from the BSM.

          If a mapping already exists, its GET is set to the holdtime
          from the BSM.  If the holdtime is zero, the mapping is removed
          immediately.

          In addition, the entire BSM

          All RP mappings associated with the scope zone of the BSM are
          updated with the new hash mask length from the received BSM.
          This includes any RP mappings learned from the current BSR but
          not contained in the received BSM, as well as any RP mappings
          learned from any previous BSR for the scope zone.

          In addition, the entire BSM is stored for use in the action
          Refresh RP-Set and to prime a new PIM neighbor as described
          below.

     Refresh RP-Set
          When the BS Bootstrap Timer expires, the router uses the copy of
          the last BSM that it has received to refresh its RP-set RP-Set
          according to the action Store RP-Set as if it had just
          received it.  This will increase the chance that the group-to-RP group-to-
          RP mappings will not expire during the election of the new
          BSR.

     Remove BSR state
          When the BS Bootstrap Timer expires, all state associated with
          the current BSR is removed (see section 2).  Note that this
          does not include any group-to-RP mappings.

In addition to the above state-machine actions, a DR also unicasts a
stored copy of the Bootstrap message to each new PIM neighbor, i.e.,
after the DR receives the neighbor's first Hello message, and sends a
Hello message in response.  It does so even if the new neighbor becomes
the DR.

3.1.

3.2.  Sending Candidate-RP-Advertisements Candidate-RP-Advertisement Messages

Every C-RP periodically unicasts a C-RP-Adv message to the BSR for that each
scope zone for which it has state, to inform the BSR of the C-RP's
willingness to function as an RP.
Unless configured otherwise, it does this for every Admin Scope zone for
which it has state, and for the global scope zone.  If the same router
is the BSR for more than one scope zone, the C-RP-Adv for these scope
zones MAY be combined into a single message.

If the C-RP is a ZBR for an admin scope zone, then the Admin Scope bit
MUST be set in the C-RP-Adv  These messages it sends for that scope zone;
otherwise this bit MUST NOT be set.  This information is currently only
used for logging purposes by the BSR, but might allow for future
extensions of the protocol.

The are sent with an
interval for sending these messages is subject to local
configuration at the C-RP, but must be smaller than the HoldTime in the
C-RP-Adv. of C_RP_Adv_Period.

[NOTE: possible optimization: prime the CRPT with a small random value
when a new BSR is elected.  This will allow the newly elected BSR to
learn group mappings fast.]

A Candidate-RP-Advertisement carries a list of group address and group
mask field pairs.  This enables

[NOTE: what happens if the C-RP router message becomes too large to restrict fit in a single
packet?  With the
advertisement per-mapping timers, it's not a problem to certain prefixes or scopes of groups.  If the C-RP
becomes an RP, it may enforce this scope acceptance when receiving
Registers or Join/Prune messages. send several
advertisements.  We need to say something about this.]

The C-RP priority Priority field determines which C-RPs get selected in these messages is used by the BSR to be select which
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
possible priority.  C-RPs should by default send C-RP-Adv messages with
the
`Priority' Priority field set to 192.

When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv
message to the BSR for each scope zone for which it is currently serving
as an RP; the
HoldTime Holdtime in this C-RP-Adv message should be zero.  The BSR
will then immediately time out the C-RP and generate a new BSR Bootstrap
message removing the shut down RP from the RP-set. RP-Set.

[NOTE: Should a new BSM be sent immediately when a C-RP-Adv message with HoldTime
Holdtime of 0 is received?  Need to clarify.]

[NOTE: what happens if the

A C-RP-Adv message becomes too large to fit in carries a single
packet?  With list of group address and group mask field
pairs.  This enables the per-mapping timers, it's not a problem C-RP to send several
advertisements.  We need specify the group prefixes for which it
is willing to say something about this.]

3.2.  Creating be the RP-Set at RP.  If the BSR

Upon C-RP becomes an RP, it may enforce this
scope acceptance when receiving a C-RP-Adv, if the router Register or Join/Prune messages.

A C-RP is not the elected BSR, configured with a list of group ranges for which it
silently ignores the message.

If should
advertise itself as the router is C-RP.  A C-RP uses the BSR, it creates following algorithm to
determine which ranges to send to a group-to-C-RP mapping for every given BSR.

For each group range R in the C-RP-Adv.  These mappings have identical values for list, the C-RP address, C-RP priority and holdtime.  The hash mask length is a
global property of advertises that range to
the scoped BSR and is therefore the same for all mappings
managed by the BSR.

[NOTE: This is substantially different from version 03, where state was
kept per C-RP.  The behaviour smallest scope that "contains" R.  For IPv6, the
containing scope is determined by matching the same if a C-RP always sends all
advertisements in a single message.  However, there seems to be no
requirement for this (and scope identifier of the case where all advertisements don't fit in

a single message seems not to be covered).  Keeping state per group
mapping allows a C-RP to send C-RP-Advs in chunks and even allows for
different holdtimes for different
group ranges (which may or may not be
useful) while being compatible range with the old version.]

Every mapping that is not part scope of the C-RP-set BSR.  For IPv4, it is added to the C-RP-set
and longest-
prefix match for R, amongst the associated group-to-C-RP mapping expiry timer (CGET) known admin-scope ranges.  If no scope
is
initialized found to contain the holdtime.

If a mapping already exists (i.e. group range the C-RP-set contains a mapping with
identical group-range and C-RP-address), C-RP includes it is updated with the
information from in the BSM and its associated CGET is reset C-RP-Adv
sent to the
holdtime from the BSM. non-scoped BSR.  If the holdtime is zero, the mapping is
immediately removed from the C-RP-set.

When a CGET expires, non-scoped BSR is not known, the corresponding group-to-C-RP mapping range
is removed
from not included in any C-RP-Adv.

In addition, for each IPv4 group range R in the C-RP-set.

The list, for each scoped
BSR constructs the RP-set from whose scope range is strictly contained within R, the C-RP-set.  It may apply a local
policy C-RP SHOULD by
default advertise that BSR's scope range to limit the number of Candidate RPs included that BSR.  And for each IPv6
group range R in the RP-set.  The
BSR may override the list with prefix indicated in a C-RP-Adv unless the
`Priority' field from the C-RP-Adv is less than 128.

For inclusion in a BSM, length < 16, the RP-set is subdivided into sets of {group-
prefix, RP-Count, RP-addresses}.  For C-RP SHOULD by
default advertise each RP-address, the corresponding
HoldTime is included in the "RP-HoldTime" field.  The format sub-range of the
Bootstrap message allows `semantic fragmentation', if the prefix length of the
original Bootstrap message exceeds the packet maximum boundaries.
However, we recommend against configuring a large number of routers as
C-RPs, 16 to reduce the semantic fragmentation required.

When an elected scoped BSR is being shut down, it should immediately originate
a Bootstrap message listing its current RP-Set, but
with the BSR
priority field set corresponding scope ID.  An implementation MAY supply a
configuration option to prevent the lowest priority value possible.  This will
cause behavior described in this

paragraph, but such an option SHOULD be disabled by default.

For IPv6, the election mask length of all group ranges included in the C-RP-Adv
message sent to a new scoped BSR to happen more quickly.

3.3.  Forwarding Bootstrap Messages

Bootstrap messages originate at the BSR, and are hop-by-hop forwarded by
intermediate routers if they pass MUST be >= 16.

If the Bootstrap Message Processing
Check.  Bootstrap messages above algorithm determines that there are multicast no group ranges to
advertise to the `ALL-PIM-ROUTERS' group.
When BSR for a particular scope zone, a BS C-RP-Adv message
MUST NOT be sent to that BSR.  A C-RP MUST NOT send a C-RP-Adv message
with no group ranges in it.

If the same router is forwarded, it is forwarded out of every multicast-
capable interface which has PIM neighbors (including the BSR for more than one over which scope zone, the message was received).  The exception to this is if C-RP-Adv
messages for these scope zones MAY be combined into a single message.

If the interface C-RP is
an administrative scope boundary a ZBR for the an admin scope zone indicated in zone, then the first group address Admin Scope Zone
bit MUST be set in the BS message packet.  The IP source address
on the bootstrap message should C-RP-Adv messages it sends for that scope zone;
otherwise this bit MUST NOT be set to set.  This information is currently only
used for logging purposes by the forwarding router's IP

address on BSR, but might allow for future
extensions of the interface protocol.

3.3.  Creating the message is being forwarded from.  Bootstrap
messages are always originated or forwarded with an IP TTL value of 1.

As an optimization, RP-Set at the BSR

Upon receiving a C-RP-Adv message, the router MAY choose needs to decide whether or
not to forward a BSM out accept each of the
interface group ranges included in the message was received on message.  For
each group range in the message, the router checks to see if that interface it is a point-to-
point interface.  On interfaces with multiple PIM neighbors, a router
SHOULD forward an accepted BSM onto the interface
elected BSR for any scope zone that BSM was received
on, but if contains the number of PIM neighbors on that interface is large, group range, or if it
MAY delay forwarding a BSM onto that interface by a small randomized
interval to prevent message implosion. A configuration option MAY be
provided to disable forwarding onto
is elected as the interface a message was received
on, but we recommend that non-scoped BSR.  If so, the default behavior group range is to forward onto that
interface.

Rationale: A BSM needs to be forwarded onto the interface the message
was received on (in addition to the other interfaces) because accepted;
if not, the
routers on a LAN may not have consistent routing information. group range is ignored.

If three
routers on the group range is accepted, a LAN are A, B, and C, and at router B RPF(BSR)==A group-to-C-RP mapping is created for
this group range and at
router C RPF(BSR)==B, then router A originally forwards the BSM onto the
LAN, but router C will only accept it when router B re-forwards the
message onto RP Address from the LAN. C-RP-Adv message.

If the underlying routing protocol configuration
guarantees that mapping is not already part of the routers have consistent routing information, then
forwarding onto C-RP-Set, it is added to the incoming interface may safely be disabled.

3.4.  Receiving
C-RP-Set and Using the RP-Set

[NOTE: what should go into this section?  It doesn't make sense to
repeat what associated Group-to-C-RP mapping Expiry Timer (CGET) is said in
initialized to the "Store RP-set" action.]

The RP-set maintained by BSR is used by RP-based multicast routing
protocols like PIM-SM and Bi-directional PIM.  These protocols may
obtain RP-sets holdtime from other sources as well.  How the final group-to-RP
mappings are obtained C-RP-Adv message.  Its priority is
set to the Priority from these RP-sets the C-RP-Adv message.

If the mapping is not already part of the BSR
specification.  In general, C-RP-Set, it is updated with the routing protocols need to re-calculate
Priority from the mappings when any of their RP-sets change.  How such a change C-RP-Adv message and its associated CGET is
signalled reset to
the routing protocol holdtime from the C-RP-Adv message.  If the holdtime is also not part of zero, the present
specification.

4.  Message Formats

BSR messages are PIM messages, as defined in [1].
mapping is immediately removed from the C-RP-Set.

The values hash mask length is a global property of the PIM
message Type field for BSR messages are:

4    Bootstrap Message

8    Candidate-RP-Advertisement

In this section we use the following terms defined in and is therefore
the PIM-SM [1]:

o    Encoded-Unicast format

o    Encoded-Group format

We repeat these here to aid readability.

Encoded-Unicast address

An Encoded-Unicast address takes same for all mappings managed by the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Addr Family  | Encoding Type |     Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

Addr Family BSR.

[NOTE: This is substantially different from version 03, where state was
kept per C-RP.  The PIM address family of the `Unicast Address' field of this
     address.

     Values of 0-127 are as assigned by behaviour is the IANA for Internet Address
     Families same if a C-RP always sends all
advertisements in [7]. Values 128-250 are reserved a single message.  However, there seems to be assigned by the
     IANA for PIM-specific Address Families.  Values 251 though 255 are
     designated for private use.  As there is no assignment authority
requirement for this space, collisions should (and the case where all advertisements don't fit in

a single message seems not to be expected.

Encoding Type
     The type of encoding used within covered).  Keeping state per group
mapping allows a specific Address Family.  The
     value `0' is reserved for this field, C-RP to send C-RP-Adv messages in chunks and represents the native
     encoding of the Address Family.

Unicast Address
     The unicast address as represented by the given Address Family and
     Encoding Type.

Encoded-Group address

Encoded-Group addresses take the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Addr Family  | Encoding Type |B| Reserved  |Z|  Mask Len     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

Addr Family
     described above.

Encoding Type
     described above.

[B]IDIR bit
     When set, all BIDIR capable PIM routers will operate the protocol
     described in [3] even
allows for the specified group range.

Reserved
     Transmitted as zero. Ignored upon receipt.

Admin Scope [Z]one
     When set, this bit indicates that this different holdtimes for different group address range is an
     administratively scoped range.

Mask Len
     The Mask length field is 8 bits. The value is ranges (which may or
may not be useful) while being compatible with the number old version.]

For compatibility with the previous version of
     contiguous one bits left justified used as the BSR specification, a mask which, combined
C-RP-Adv message with no group ranges SHOULD be treated as though it
contained the single group address, describes a range of groups. It is less
     than ff00::/8 or equal 224/4.  Therefore,
according to the address length in bits for the given Address
     Family rule above, this group range will be accepted if and Encoding Type. If
only if the message router is sent for elected as the non-scoped BSR.

When a single group
     then CGET expires, the Mask length must equal corresponding group-to-C-RP mapping is removed
from the address length C-RP-Set.

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 bits for the
     given Address Family and Encoding Type.  (e.g. 32 for IPv4 native
     encoding and 128 for IPv6 native encoding).

Group multicast Address
     Contains RP-Set.  The
BSR may override the group address.

4.1.  Bootstrap Message Format

A bootstrap prefix indicated in a C-RP-Adv message unless the
`Priority' field from the C-RP-Adv message is divided up less than 128.

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
Holdtime is included in the "RP-Holdtime" field.  The format of the
Bootstrap message allows `semantic fragments' fragmentation', if the length of the
original Bootstrap message exceeds the maximum packet size maximum boundaries.  Basically,
However, we recommend against configuring a single bootstrap message can be sent as multiple packets (semantic
fragments), so long large number of routers as
C-RPs, to reduce the fragment tags of all semantic fragmentation required.

A BSR originates separate scoped BSMs for each scope zone for which it
is the packets comprising elected BSR, as well as originating non-scoped BSMs if it is the message
elected non-scoped BSR.

Each group-to-C-RP mapping is included in precisely one of these BSM,
namely the same.

If scoped BSM for the bootstrap message contains information about more than one admin
scope zone, each different narrowest scope zone containing the group range
of the mapping, if any, or the non-scoped BSM otherwise.

A scoped BSM MUST occupy have at least one group range, and the first group
range in a different semantic
fragment. scoped BSM MUST have the "Admin Scope Zone" bit set.  This allows Zone Border Routers for an admin
group range identifies the scope of the BSM.  In a scoped IPv4 BSM, the
first group range is the range corresponding to the scope of the BSM.
In a scoped IPv6 BSM, the first group range may be any group range
subject to the general condition that all the group ranges in such a BSM
MUST have a mask length of at least 16 and MUST have the same scope ID
as the scope of the BSM.

RP mappings may be included in the first group range of a BSM, just as
for any other group range.  After this group range, other group ranges
for which there are RP mappings appear in any order.

The "Admin Scope Zone" bit of all group ranges other than the first
SHOULD be set to 0 on origination, and MUST be ignored on receipt.

When an elected BSR is being shut down, it should immediately originate
a Bootstrap message listing its current RP-Set, but with the BSR
Priority field set to the lowest priority value possible.  This will
cause the election of a new BSR to happen more quickly.

3.4.  Forwarding Bootstrap Messages

Bootstrap messages originate at the BSR, and are hop-by-hop forwarded by
intermediate routers if they pass the Bootstrap Message Processing
Checks.  When a Bootstrap message is forwarded, it is forwarded out of
every multicast-capable interface which has PIM neighbors (including the
one over which the message was received).  The exception to this is if
the interface is an administrative scope boundary for the admin scope
zone indicated in the first group address in the Bootstrap message
packet.

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-
point interface.  On interfaces with multiple PIM neighbors, a router
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
MAY delay forwarding a BSM onto that interface by a small randomized
interval to prevent message implosion.  A configuration option MAY be
provided to disable forwarding onto the interface a message was received
on, but we recommend that the default behavior is to forward onto that
interface.

Rationale: A BSM needs to be forwarded onto the interface the message
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 are A, B, and C, and at router B RPF(BSR)==A and at
router C RPF(BSR)==B, then router A originally forwards the BSM onto the
LAN, but router C will only accept it when router B re-forwards the
message onto the LAN.  If the underlying routing protocol configuration
guarantees that the routers have consistent routing information, then
forwarding onto the incoming interface may safely be disabled.

A ZBR constrains all BSMs which are of equal or smaller scope than the
configured boundary.  That is, the BSMs are not accepted from,
originated or forwarded on the interfaces on which the boundary is
configured.  For IPv6 the check is a comparison between the scope of the
first range in the scoped BSM and the scope of the configured boundary.
For IPv4, the first range in the scoped BSM is checked to see if it is
contained in or is the same as the range of the configured boundary.

3.5.  Unicasting Bootstrap Messages to New and Rebooting Routers

To allow new or rebooting routers to learn the RP-Set quickly, when a
Hello message is received from a new neighbor, or a Hello message with a
new GenID is received from an existing neighbor, one router on the LAN
unicasts a stored copy of the Bootstrap message for each admin scope
zone to the new or rebooting router.

The router that does this is the Designated Router (DR) on the LAN, or,
if the new or rebooting router is the DR, the router that would be the
DR if the new or rebooting router were excluded from the DR election
process.

Before unicasting a Bootstrap message in this manner, the DR must wait
until it has sent a triggered Hello message on this interface;
otherwise, the new neighbor will discard the Bootstrap message.

3.6.  Receiving and Using the RP-Set

The RP-Set maintained by BSR is used by RP-based multicast routing
protocols like PIM-SM and BIDIR-PIM.  These protocols may obtain RP-Sets
from other sources as well.  How the final group-to-RP mappings are
obtained from these RP-Sets is not part of the BSR specification.  In
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
routing protocol is also not part of the present specification.

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.  Routers that only support one of these protocols MUST NOT ignore
ranges indicated as being for the other protocol.  They MUST NOT treat
them as being for the protocol they support.

4.  Message Formats

BSR messages are PIM messages, as defined in [1].  The values of the PIM
Message Type field for BSR messages are:

4    Bootstrap

8    Candidate-RP-Advertisement

As with all other PIM control messages, BSR messages have IP protocol
number 103.

Candidate-RP-Advertisement messages are unicast to a BSR.  Usually,
Bootstrap messages are multicast with TTL 1 to the ALL-PIM-ROUTERS
group, but in some circumstances (described in section 3.5) Bootstrap

messages are unicast to a specific PIM neighbor.

The IP source address used for Candidate-RP-Advertisement messages is a
domain-wide reachable address.  The IP source address used for Bootstrap
messages (regardless of whether they are being originated or forwarded)
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
Hello messages it sends out that interface).

All Bootstrap and Candidate-RP-Advertisement messages SHOULD carry the
Router Alert IP option.  See section 6 for information about the way in
which the Router Alert option is checked by receving routers.

The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13.  The IPv6 ALL-PIM-ROUTERS
group is ff02::d.

In this section we use the following terms defined in the PIM-SM
specification [1]:

o    Encoded-Unicast format

o    Encoded-Group format

We repeat these here to aid readability.

Encoded-Unicast address

An Encoded-Unicast address takes the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Addr Family  | Encoding Type |     Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

Addr Family
     The PIM address family of the `Unicast Address' field of this
     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
     the IANA for PIM-specific Address Families.  Values 251 though 255
     are designated for private use.  As there is no assignment
     authority for this space, collisions should be expected.

Encoding Type
     The type of encoding used within a specific Address Family.  The
     value `0' is reserved for this field, and represents the native
     encoding of the Address Family.

Unicast Address
     The unicast address as represented by the given Address Family and
     Encoding Type.

Encoded-Group address

Encoded-Group addresses take the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Addr Family  | Encoding Type |B| Reserved  |Z|  Mask Len     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

Addr Family
     described above.

Encoding Type
     described above.

[B]IDIR bit
     When set, all BIDIR capable PIM routers will operate the protocol
     described in [2] for the specified group range.

Reserved
     Transmitted as zero.  Ignored upon receipt.

Admin Scope [Z]one
     When set, this bit indicates that this group address range is an
     administratively scoped range.

Mask Len
     The Mask length field is 8 bits.  The value is the number of
     contiguous one bits left justified used as a mask which, combined
     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
     Family and Encoding Type.  If the message is sent for a single
     group then the Mask length must equal the address length in bits
     for the given Address Family and Encoding Type.  (e.g. 32 for IPv4
     native encoding and 128 for IPv6 native encoding).

Group multicast Address
     Contains the group address.

4.1.  Bootstrap Message Format

A Bootstrap message is divided up into `semantic fragments' if the
original message exceeds the maximum packet size boundaries.  Basically,
a single Bootstrap message can be sent as multiple packets (semantic
fragments), so long as the fragment tags of all the packets comprising
the message is the same.

If the Bootstrap message contains information about more than one admin
scope zone, each different scope zone MUST occupy a different semantic
fragment.  This allows Zone Border Routers for an admin scope zone to
not forward only those fragments that should not traverse the admin
scope boundary.

The format of a single `fragment' is given below:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |   Reserved    |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Fragment Tag          | Hash Mask len Len | BSR-priority BSR Priority  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             BSR Address (Encoded-Unicast format)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Group Address 1 (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Count 1    | Frag RP Cnt 1 |         Reserved              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RP Address 1 (Encoded-Unicast format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          RP1 Holdtime         | RP1 Priority  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RP Address 2 (Encoded-Unicast format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          RP2 Holdtime         | RP2 Priority  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RP Address m (Encoded-Unicast format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          RPm Holdtime         | RPm Priority  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Group Address 2 (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Group Address n (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Count n    | Frag RP Cnt n |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RP Address 1 (Encoded-Unicast format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          RP1 Holdtime         | RP1 Priority  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RP Address 2 (Encoded-Unicast format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          RP2 Holdtime         | RP2 Priority  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|             RP Address m (Encoded-Unicast format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          RPm Holdtime         | RPm Priority  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Version, Reserved, Checksum
     Described in [1].

Type
     PIM Message Type.  Value is 4 for a Bootstrap Message. message.

Fragment Tag
     A randomly generated number, acts to distinguish the fragments
     belonging to different Bootstrap messages; fragments belonging to
     same Bootstrap message carry the same `Fragment Tag'.

Hash Mask len same `Fragment Tag'.

Hash Mask Len
     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
     126.  This field SHOULD be the same for all fragments belonging to
     the same Bootstrap message.

BSR Priority
     Contains the BSR priority value of the included BSR.  This field is
     considered as a high order byte when comparing BSR addresses.  Note
     that for historical reasons, the highest BSR priority is 255 (the
     higher the better), whereas the highest RP Priority (see below) is
     0 (the lower the better).

BSR Address
     The address of the bootstrap router for the domain.  The format for
     this address is given in the Encoded-Unicast address in [1].

Group Address 1..n
     The group prefix (address and mask) with which the Candidate-RPs
     are associated.  Format described in [1].  In an fragment
     containing admin scope ranges, the first group address in the
     fragment MUST 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 range; for IPv6 the Mask Len MUST be at least 16
     and have the scope ID of the admin scope 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 RP-Set are specified
     later in the fragment along with their RPs.

RP Count 1..n
     The length (in bits) number of the mask to use Candidate-RP addresses included in the hash function. For
     IPv4 we recommend whole
     Bootstrap message for the corresponding group prefix.  A router
     does not replace its old RP-Set for a value given group prefix
     until/unless it receives `RP-Count' addresses for that prefix; the
     addresses could be carried over several fragments.  If only part of 30. For IPv6 we recommend
     the RP-Set for a value of
     126.

BSR priority
     Contains given group prefix was received, the BSR priority value router
     discards it, without updating that specific group prefix's RP-Set.

Frag RP Cnt 1..m
     The number of the Candidate-RP addresses included BSR.  This in this fragment of
     the Bootstrap message, for the corresponding group prefix.  The
     `Frag RP Cnt' field is
     considered as facilitates parsing of the RP-Set for a high order byte given
     group prefix, when comparing BSR addresses.  Note
     that carried over more than one fragment.

RP address 1..m
     The address of the Candidate-RPs, for historical reasons, the highest BSR priority corresponding group
     prefix.  The format for these addresses is 255 (the
     higher given in the better), whereas Encoded-
     Unicast address in [1].

RP1..m Holdtime
     The Holdtime (in seconds) for the highest corresponding RP.  This field is
     copied from the `Holdtime' field of the associated RP stored at the
     BSR.

RP1..m Priority (see below)
     The `Priority' of the corresponding RP and Encoded-Group Address.
     This field is
     0 (the copied from the `Priority' field stored at the BSR
     when receiving a C-RP-Adv message.  The highest priority is `0'
     (i.e. unlike BSR priority, the lower the better).

BSR Address
     The address value of the bootstrap router for `Priority'
     field, the domain.  The format for
     this address better).  Note that the priority is given in per RP per Group
     Address.

Within a Bootstrap message, the BSR Address, all the Encoded-Unicast address in [1]. Group Address 1..n
     The group prefix (address Addresses and mask) with which
all the Candidate RPs
     are associated.  Format described in [1]. RP Addresses MUST be of the same address family.  In a fragment containing
     admin scope ranges, addition,
the first group address family of the fields in the fragment message MUST be the group range for same as the entire admin scope range,
IP source and this MUST
     have destination addresses of the Admin Scope bit set. packet.  This permits maximum
implementation flexibility for dual-stack IPv4/IPv6 routers.

4.1.1.  Semantic Fragmentation of BSMs

Bootstrap messages may be split over several PIM Bootstrap Message
Fragment (BSMF) packets; this is the case even if there known as semantic fragmentation.  There
are
     no RPs in the RP-Set two reasons for semantic fragmentation:

o    The BSM would exceed the entire link MTU the packet will be forwarded
     over.

o    The BSM includes information about more than one admin scope range - in this
     case zone.

Let us initially consider only the sub-ranges for former case; the RP-Set are specified later in packet would be too
large because the
     fragment along with their RPs.

RP Count 1..n
     The number set of Candidate RP addresses included in the whole
     Bootstrap message for the corresponding group prefix. A router does
     not replace its old RP-Set prefixes and the RPs for a given each group
prefix until/unless it
     receives `RP-Count' addresses for that prefix; are too long to fit in one packet.  The BSR will then split the addresses could
     be carried over
BSM across several fragments.  If only part BSMF packets; each of the RP-Set for these must be a given group prefix was received, well-formed
BSMF packet in its own right.

If the router discards it, without
     updating BSR can split up the BSM so that specific different group prefix's RP-Set.

Frag RP Cnt 1..m
     The number of Candidate prefixes (and
their RP addresses included information) can fit in this fragment different fragments, then it should do
so.  If one of these BSMF packets is then lost, the Bootstrap message, state from the
previous BSM for the corresponding group prefix. The
     `Frag RP Cnt' field facilitates parsing of group-prefix from the RP-Set missing packet will be
retained.  Each fragment that does arrive will update the RP information
for a given
     group prefix, when carried over more than one fragment. the group-prefixes contained in that fragment, and the new group-to-
RP address 1..m mapping for those can be used immediately.  The address of information from the Candidate RPs, for
missing fragment will be obtained when the corresponding group
     prefix.  The format for these addresses BSM is given in next transmitted.  In
this case, whilst the Encoded-
     Unicast address in [1].

RP1..m Holdtime
     The Holdtime Fragment Tag must be set to the same value for all
BSMFs comprising a single BSM, the corresponding RP.  This field tag is copied from not actually used by routers
receiving the `Holdtime' field of BSM.

If the associated RP stored at list of RPs for a single group-prefix is too long to fit in a
single BSMF packet, then that information must be split across multiple
BSMF packets.  In this case, all the BSR.

RP1..m Priority
     The `Priority' of BSMF packets comprising the corresponding
information for that group-prefix must be received before the group-to-
RP and Encoded-Group Address. mapping in use can be modified.  This field is copied from the `Priority' field stored at purpose of the BSR
     when receiving RP Count
field - a Candidate-RP-Advertisement.  The highest priority
     is `0' (i.e. unlike BSR priority, the lower router receiving BSMF packets from the value of same BSM (ie that have
the
     `Priority' field, same fragment tag) must wait until the better).  Note BSMFs providing RP Count RPs
for that group-prefix have been received before the priority is per RP
     per Group Address.

4.1.1.  Semantic Fragmentation of BSMs

Bootstrap messages may new group-to-RP
mapping can be split over several PIM Bootstrap Message
Fragment (BSMF) packets; this is known as semantic fragmentation.  There
are two reasons used for semantic fragmentation:

o    The BSM would exceed the link MTU the packet that group-prefix.  If a single BSMF from such a
large group-prefix is lost, then that entire group-prefix will be forwarded
     over.

o    The have to
wait until the next BSM includes information about more than one admin scope zone.

Let us initially is originated.

Next we need to consider only the former case; the packet how a BSR would be too
large because remove group-prefixes from the
BSM.  A router receiving a set of group prefixes BSMFs cannot tell if a group-prefix is
missing.  If it has seen a group-prefix before, it must assume that that
group-prefix still exists, and the RPs for each group
prefix are too long to fit in one packet.  The BSR will then split the
BSM across several that the BSMF packets; each of these must be describing it has been
lost.  It should retain this information for BS_Timeout.  Thus for a well-formed
BSMF packet in its own right.

If the BSR can split up
to remove a group-prefix from the BSM so BSR, it should include that different group prefixes (and
their group-
prefix, but with a RP information) can fit in different fragments, then Count of zero, and it should do
so.  If one of these BSMF packets is then lost, the state from the
previous resend this
information in each BSM for BS_Timeout.

Finally, we come to the group-prefix from case of fragments for the missing packet will be
retained.  Each fragment that does arrive will update purpose of conveying
admin scope group-prefixes.  In general, the RP information for each admin
scope range is independent of information about other admin scope
ranges.  As no BSMF is allowed to convey information for more than one
admin scope range, then the group-prefixes contained in procedure above also applies to BSMs that fragment,
are fragmented due to admin scoping.  However, to time out all the state
for an entire admin scope zone requires waiting SZ_Timeout rather than
BS_Timeout, as admin scope zones are not expected to come and go
frequently.

4.2.  Candidate-RP-Advertisement Message Format

Candidate-RP-Advertisement messages are periodically unicast from the new group-to- C-
RPs to the BSR.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |   Reserved    |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Count  |   Priority    |           Holdtime            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RP mapping for those can be used immediately.  The information from the
missing fragment will be obtained when the BSM Address (Encoded-Unicast format)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Group Address 1 (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Group Address n (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Version, Reserved, Checksum
     Described in [1].

Type
     PIM Message Type.  Value is next transmitted.  In
this case, whilst the Fragment Tag must be set to the same value 8 for all
BSMFs comprising a single BSM, the tag is not actually used by routers
receiving the BSM.

If the list Candidate-RP-Advertisement
     message.

Prefix Count
     The number of RPs for a single group-prefix is too long to fit encoded group addresses included in a
single BSMF packet, then that information must be split across multiple
BSMF packets.  In this case, all the BSMF packets comprising message;
     indicating the
information group prefixes for that group-prefix must be received before which the group-to-
RP mapping in use can be modified.  This C-RP is the purpose of the RP Count
field - advertising.
     C-RPs MUST NOT send C-RP-Adv messages with a router receiving BSMF packets from the same BSM (ie that have
the same fragment tag) must wait until the BSMFs providing RP Prefix Count RPs
for that group-prefix have been received before of `0'.

Priority
     The `Priority' of the new group-to-RP
mapping can be used included RP, for that group-prefix.  If a single BSMF from such a
large group-prefix is lost, then that entire group-prefix will have to
wait until the next BSM corresponding Encoded-
     Group Address (if any).  The highest priority is `0' (i.e. the
     lower the value of the `Priority' field, the higher the priority).
     This field is originated.

Next we need to consider how a stored at the BSR would remove group-prefixes from upon receipt along with the
BSM.  A router receiving a RP
     address and corresponding Encoded-Group Address.

Holdtime
     The amount of time (in seconds) the advertisement is valid.  This
     field allows advertisements to be aged out.  This field should be
     set to 2.5 times C_RP_Adv_Period.

RP Address
     The address of BSMFs cannot tell if the interface to advertise as a group-prefix Candidate RP.  The
     format for this address is
missing.  If it has seen a group-prefix before, it must assume that that
group-prefix still exists, and that given in the BSMF describing it has been
lost.  It should retain this information for BS Timeout seconds.  Thus Encoded-Unicast address in
     [1].

Group Address-1..n
     The group prefixes for a BSR to remove a group-prefix from which the BSR, it should include that
group-prefix, but with C-RP is advertising.  Format
     described in Encoded-Group-Address in [1].

Within a Candidate-RP-Advertisement message, the RP Count of zero, Address and it should resend this
information in each BSM for BS Timeout seconds.

Finally, we come to all the case
Group Addresses MUST be of fragments for the purpose of conveying
admin scope group-prefixes. same address family.  In general, addition, the information for each admin
scope range is independent
address family of information about other admin scope
ranges.  As no BSMF is allowed to convey information for more than one
admin scope range, then the procedure above also applies to BSMs that
are fragmented due to admin scoping.  However, to time out all the state
for an entire admin scope zone requires waiting SZ Timeout rather than
BS Timeout, fields in the message MUST be the same as admin scope zones are not expected to come and go
frequently.

4.2.  Candidate-RP-Advertisement Format

Candidate-RP-Advertisements are periodically unicast from the C-RPs to IP
source and destination addresses of the BSR.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type packet.  This permits maximum
implementation flexibility for dual-stack IPv4/IPv6 routers.

5.  Timers and Timer Values

Timer Name: Bootstrap Timer (BST(Z))

+---------------------+--------------------------+----------------------+
|   Reserved Value Name          |           Checksum  Value                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Explanation        | Prefix Count
+---------------------+--------------------------+----------------------+
|   Priority BS_Period           |           Holdtime  Default: 60 seconds     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Periodic interval  |             RP Address (Encoded-Unicast format)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     |            Group Address 1 (Encoded-Group format)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   with which BSMs    |                               .
|                     |                               .                          |   are normally       |                               .
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     |            Group Address n (Encoded-Group format)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Version, Reserved, Checksum
     Described in [1].

Type PIM Message Type.  Value is 8 for   originated         |
+---------------------+--------------------------+----------------------+
| BS_Timeout          |  Default: 130 seconds    |   Interval after     |
|                     |                          |   which a Candidate-RP-Advertisement
     Message.

Prefix Count
     The number of encoded group addresses included in BSR is     |
|                     |                          |   timed out if no    |
|                     |                          |   BSM is received    |
|                     |                          |   from that BSR      |
+---------------------+--------------------------+----------------------+
| BS_Rand_Override    |  see below               |   Randomized         |
|                     |                          |   interval used to   |
|                     |                          |   reduce control     |
|                     |                          |   message overhead   |
|                     |                          |   during BSR         |
|                     |                          |   election           |
+---------------------+--------------------------+----------------------+

Note that BS_Timeout MUST be larger than BS_Period, even if their values
are changed from the message;
     indicating defaults.  We recommend that BS_Timeout is set to 2
times BS_Period plus 10 seconds.

BS_Rand_Override is calculated using the group prefixes for following pseudocode, in which the C-RP is advertising. A
     Prefix Count of `0' implies
all multicast groups, e.g. for IPv4 a
     prefix values are in units of 224.0.0.0 with mask length seconds.  The values of 4.  If the C-RP is not
     configured BS_Rand_Override
generated by this pseudocode are between 5 and 23 seconds, with Group-prefix information, smaller
values generated if the C-RP puts C-BSR has a default
     value of `0' in this field.

Priority
     The `Priority' of the included RP, for high bootstrap weight, and larger
values generated if the corresponding Encoded-
     Group Address (if any).  highest priority C-BSR has a low bootstrap weight.

     BS_Rand_Override = 5 + priorityDelay + addrDelay

where priorityDelay is `0' (i.e. the lower
     the value of the `Priority' field, the higher the priority). This
     field given by:

     priorityDelay = 2 * log_2(1 + bestPriority - myPriority)

and addrDelay is stored at given by the BSR upon receipt along with following for IPv4:

     if (bestPriority == myPriority) {
         addrDelay = log_2(1 + bestAddr - myAddr) / 16
     } else {
         addrDelay = 2 - (myAddr / 2^31)
     }

and addrDelay is given by the RP address following for IPv6:

     if (bestPriority == myPriority) {
         addrDelay = log_2(1 + bestAddr - myAddr) / 64
     } else {
         addrDelay = 2 - (myAddr / 2^127)
     }

and corresponding Encoded-Group Address.

Holdtime
     The amount of time bestPriority is given by:

     bestPriority = max(storedPriority, myPriority)

and bestAddr is given by:

     bestAddr = max(storedAddr, myAddr)

and where myAddr is the advertisement Candidate-BSR's address, storedAddr is valid. This field allows
     advertisements to be aged out.

RP Address
     The address of the interface to advertise as a Candidate RP.  The
     format for this address
stored BSR's address, myPriority is given in the Encoded-Unicast address in
     [1].

Group Address-1..n
     The group prefixes for which the C-RP Candidate-BSR's configured
priority, and storedPriority is advertising.  Format
     described in Encoded-Group-Address in [1].

5.  Default Values for Timers the stored BSR's priority.

Timer Name: Bootstrap Scope Zone Expiry Timer (BST)

+-------------------+--------------------------+------------------------+ (SZT(Z))

+----------------+-----------------------------+------------------------+
|  Value Name    |   Value                     |   Explanation          |
+-------------------+--------------------------+------------------------+
+----------------+-----------------------------+------------------------+
|  BS Period  SZ_Timeout    |   Default: 60 secs       |   Period between       |
|                   |                          |   originating          |
|                   |                          |   bootstrap messages   |
+-------------------+--------------------------+------------------------+
|  BS Timeout       |   2 * BS_Period + 10 1300 seconds     |   Period   Interval after last       |
|                |   seconds                             |   BS message before   which a scope zone   |
|                |                             |   BSR   is timed out if no   |
|                |                             |   and election         |
|                   |   BSM is received      |   begins
|
+-------------------+--------------------------+------------------------+                |  rand_override                             |   rand(0, 5.0 secs)   for that scope       |   Suppression period
|                |                             |   zone                 |   in BSR election
+----------------+-----------------------------+------------------------+

Note that SZ_Timeout MUST be larger than BS_Timeout, even if their
values are changed from the defaults.  We recommend that SZ_Timeout is
set to   |
|                   |                          |   prevent thrashing    |
+-------------------+--------------------------+------------------------+ 10 times BS_Timeout.

Timer Name: Group-to-C-RP apping mapping Expiry Timer (CGET(M,Z))

+----------------------+--------------+---------------------------------+
|Value

+--------------------------+--------------------+-----------------------+
|  Value Name            |Value              |    Value           |    Explanation        |
+----------------------+--------------+---------------------------------+
|C-RP
+--------------------------+--------------------+-----------------------+
|  C-RP Mapping Timeout  |from message    | Hold time    from C-RP-Adv message    |
+----------------------+--------------+---------------------------------+

C-RP Advertisement messages are sent periodically with period C-RP-Adv-
Period.  C-RP-Adv-Period defaults to 60 seconds.  The holdtime to be

specified in a C-RP-Adv    Holdtime from C-   |
|                          |                    |    RP-Adv message should be set to (2.5 * C-RP-Adv-Period
).  This timer is used for group-to-C-RP mappings in the C-RP-set at the
BSR.     |
+--------------------------+--------------------+-----------------------+

Timer Name: Group-to-RP mapping Expiry Timer (GET(M,Z))

+------------------------+--------------------+-------------------------+

+-------------------------+--------------------+------------------------+
|  Value Name             |   Value            |    Explanation         |
+------------------------+--------------------+-------------------------+
+-------------------------+--------------------+------------------------+
|  RP Mapping Timeout     |   from message     |    Hold time    Holdtime from BSM   |
+------------------------+--------------------+-------------------------+

This timer is identical to CGET, except that it applies to the mappings
in the RP-set rather than the C-RP-set.
+-------------------------+--------------------+------------------------+

Timer Name: C-RP Advertisement Timer (CRPT)

+--------------------+--------------------------+-----------------------+

+---------------------+-------------------------+-----------------------+
|  Value Name         |  Value                  |   Explanation         |
+--------------------+--------------------------+-----------------------+
+---------------------+-------------------------+-----------------------+
| C-RP-Adv-Period  C_RP_Adv_Period    |  Default: 60 seconds    |  Period with which    |
|                    |                          |  periodic C-RP        |
|                    |                          |  Advertisements are   |
|                    |                          |  sent to BSR          |
+--------------------+--------------------------+-----------------------+

Timer Name: Scope Zone Expiry Timer (SZT(Z))

+------------------------------------+--------------+--------------------+
|Value Name      Value   Explanation |              |                    |
+------------------------------------+--------------+--------------------+
|SZ Timeout                          | 1300 seconds | Interval after   Periodic interval   |
|                     |                         |   with which a scope zone |
|                                    |              | will be timed out C-RP-    |
|                     |                         | if the state is   Adv messages are    |
|                     |                         | not refreshed   sent to a BSR       |
+------------------------------------+--------------+--------------------+
+---------------------+-------------------------+-----------------------+

6.  Security Considerations

6.1.  Possible Threats

Threats affecting the PIM BSR mechanism are primarily of two forms:
denial of service attacks, and traffic diversion attacks.  An attacker
that subverts the BSR mechanism can prevent multicast traffic from
reaching the intended recipients, can divert multicast traffic to a
place where they can monitor it, and can potentially flood third parties
with traffic.

Traffic can be prevented from reaching the intended recipients by one of
two mechanisms:

o    Subverting a BSM, and specifying RPs that won't actually forward
     traffic.

o    Registering with the BSR as a C-RP, and then not forwarding
     traffic.

Traffic can be diverted to a place where it can be monitored by both of
the above mechanisms; in this case the RPs would forward the traffic,
but are located so as to aid monitoring or man-in-the-middle attacks on
the multicast traffic.

A third party can be flooded by either of the above two mechanisms by
specifying the third party as the RP, and register-encapsulated traffic
will then be forwarded to them.

6.2.  Limiting Third-Party DoS Attacks

The third party DoS attack above can be greatly reduced if PIM routers
acting as DR do not continue to forward Register traffic to the RP in
the presence of ICMP Protocol Unreachable or ICMP Host Unreachable
responses.  If a PIM router sending Register packets to an RP receives
one of these responses to a data packet it has sent, it should rate-
limit the transmission of future Register packets to that RP for a short
period of time.

As this does not affect interoperability, the precise details are left
to the implementor to decide.  However we note that a router
implementing such rate limiting must only do so if the ICMP packet
correctly echoes part of a Register packet that was sent to the RP.  If
this check were not made, then simply sending ICMP Unreachable packets
to the DR with the source address of the RP spoofed would be sufficient
to cause a denial-of-service attack on the multicast traffic originating
from that DR.

6.3.  BS  Bootstrap Message Security

If a legitimate PIM router is compromised, there is little any security
mechanism can do to prevent that router subverting PIM traffic in that
domain.  However we recommend that implementors provide a mechanism
whereby a PIM router using the BSR mechanisms can be configured with the
IP addresses of valid BSR routers, and that any BS Message Bootstrap message from
any other BSR should then be dropped and logged as a security issue.  We
also recommend that this not be enabled by default, as it makes the
initial configuration of a PIM domain problematic - it is the sort of
feature that might be enabled once the configuration of a domain has
stabilized.

The primary security requirement for BSR (as for PIM) is that it is
possible to prevent hosts that are not legitimate PIM routers, either
within or outside the domain, from subverting the BSR mechanism.

The Bootstrap Message Processing Checks prevent a router from accepting
a BS Bootstrap message from outside of the PIM Domain, as the source
address on BS
Messages Bootstrap messages must be an immediate PIM neighbor.  There
is however a small window of time after a reboot where a PIM router will
accept a bad BS
Message Bootstrap message unicast from an immediate neighbor, and
it might be possible to unicast a BS Message Bootstrap message to a router during
this interval from outside the domain, using the spoofed source address
of a neighbor.  This can be prevented if PMBRs perform source-address
filtering to prevent packets entering the PIM domain with IP source
addresses that are infrastructure addresses in the PIM domain.

The principal threat to BS Message Bootstrap message security comes from hosts
within the PIM domain that attempt to subvert the BSR mechanism.  They
may be able to do this by sending PIM messages to their local router, or
by unicasting a BS Bootstrap message to another PIM router during the brief
interval after it has restarted.

All BS

6.3.1.  Rejecting Unicast Bootstrap Messages

All Bootstrap messages SHOULD carry the Router Alert IP option.  If a
PIM router receives a BS Message Bootstrap message that does not carry the router alert Router
Alert option, it SHOULD drop it (a configuration option should also be
provided to disable this check on a per-interface basic for backward
compatibility with older PIM routers).  The Router Alert option allows a
PIM router to perform checks on unicast packets it would otherwise
blindly forward.  All PIM routers should check that packets with Router
Alert that are not destined for the router itself are not PIM Bootstrap
messages.  Any such packets should be dropped and logged as a possible
security issue - it is never acceptable for a PIM BS Bootstrap message to
travel multiple IP hops.

6.3.2.  Rejecting Bootstrap Messages from Invalid Neighbors

Most hosts that are likely to attempt to subvert PIM BSR are likely to
be located on leaf subnets.  We recommend that implementors provide a
configuration option that specifies an interface is a leaf subnet, and
that no PIM packets are accepted on such interfaces.

On multi-access subnets with multiple PIM routers and hosts that are not
trusted, we recommend that IPsec AH is used to protect communication
between PIM routers, and that such routers are configured to drop and
log communication attempts from any host that do not pass the
authentication check.  When all the PIM routers are under the same
administrative control, this authentication may use a configured shared
secret.  The securing of interactions between PIM neighbors is discussed
in more detail in the Security Considerations section of [1], and so we
do not discuss the details further here.  The same security mechanisms
that can be used to secure PIM Join, Prune and Assert messages should
also be used to secure BS Bootstrap messages.

6.4.  C-RP-Advertisement  Candidate-RP-Advertisement Message Security

Even if it is not possible to subvert BS Messages, Bootstrap messages, an attacker
might be able to perform most of the same attacks by simply sending C-RP-Adv C-
RP-Adv messages to the BSR specifying the attacker's choice of RPs.
Thus it is necessary to control the sending of C-RP-Adv messages in
essentially the same ways that we control BS Messages. Bootstrap messages.  However,
C-RP-Adv messages are unicast and normally travel multiple hops, so
controlling them is a
little harder. more difficult.

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
option, and that the BSR SHOULD by default drop and log C-RP-Adv
messages that do not carry this option.  Setting Router Alert on these
packets is practical because the rate of C-RP-Adv messages should be
very low, so the extra load on routers forwarding these packets will be
insignificant.  All  PIM routers forwarding such a packet are may then be capable
of checking whether the packet came from a valid PIM neighbor, although
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
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
NOT drop C-RP-Adv messages that do not come from a valid PIM neighbor.

If the unicast and multicast topologies are known to be congruent, the
following checks should be made.  On interfaces that are configured to
be leaf subnets, all C-RP-Adv messages should be dropped.  On multi-access multi-
access subnets with multiple PIM routers and hosts that are not trusted,

the router can at least check that the source MAC address is that of a
valid PIM neighbor.  PMBRs should ensure that no C-RP-Adv messages enter
the domain from an external neighbor.

6.4.2.  Cryptographic Security of C-RP-Adv Messages

For true security, we recommend that all C-RPs are configured to use
IPsec authentication.  The authentication process for a C-RP-Adv message
between a C-RP and the BSR is identical to the authentication process
for PIM Register messages between a DR and the relevant RP, except that
there will normally be fewer C-RPs in a domain than there are DRs, so
key management is a little simpler.  We do not describe the details of
this process further here, but refer to the Security Considerations
section of [1].  Note that the use of cryptographic security for C-RP-
Advs
Adv messages does not remove the need for the non-cryptographic
mechanisms, as explained below.

6.5.  Denial of Service using IPsec

An additional concern is that of Denial-of-Service attacks caused by
sending high volumes of BS Messages Bootstrap messages or C-RP-Adv messages with
invalid IPsec authentication information.  It is possible that these
messages could overwhelm the CPU resources of the recipient.

The non-cryptographic security mechanisms above prevent unicast BS
Bootstrap messages from traveling multiple hops, and constrain who can
originate such messages.  However, it is obviously important that PIM Messages
messages that are required to have Router Alert checked are checked for
this option before the IPsec AH is checked.  Thus the remaining
vulnerability primarily exists for hosts on multi-access subnets
containing more than one PIM router.  A PIM router receiving PIM packets
with Router Alert set from such a subnet should already be checking that
the source MAC address is that of a valid PIM neighbor, but this is
hardly strong security.  In addition, we recommend that rate-limiting
mechanisms can be configured, to be applied to the forwarding of unicast
PIM packets containing Router Alert options.  The rate-limiter MUST
independently rate-limit different types of PIM packets - for example a
flood of C-RP-
Adv C-RP-Adv messages MUST NOT cause a rate limiter to drop low-rate BS Messages. low-
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,
but in practice this is more likely to constrain bad PIM Messages messages close
to their origin.  In addition, the rate limiter will prevent attacks on
PIM from affecting other activity on the destination router, such as
unicast routing.

7.  Contributors

Bill Fenner, Mark Handley, Roger Kermode and David Thaler have
contributed greatly to this draft.  They were authors of this draft up
to version 03.  Most of the current text is identical to 03.

8.  Acknowledgments

PIM-SM was designed over many years by a large group of people,
including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve
Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri,
Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern,
Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish
Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas and Hugh
Holbrook.  This BSR specification draws heavily on text from RFC 2362.

Many members of the PIM Working Group have contributed comments and
corrections for this document, including Christopher Thomas Brown, Ardas
Cilingiroglu, Murthy Esakonu, Venugopal Hemige, Prashant Jhingran,
Rishabh Parekh and Katta Sambasivarao.

9.  IANA Considerations

This document has no actions for IANA.

10.  Normative References

[1] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
     Independent Multicast - Sparse Mode (PIM-SM): Protocol
     Specification (Revised)", Internet Draft draft-ietf-pim-sm-
     v2-new-09.ps
     v2-new-11.txt

[2] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, Jul
     1998.

[3] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional
     Protocol Independent Multicast (BIDIR-PIM)", Internet Draft draft-
     ietf-pim-bidir-06.txt

11.  Informative References
     ietf-pim-bidir-07.txt

[3] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, Jul
     1998.

[4] S. Deering , W. Fenner , Deering, B. Haberman, "Multicast Listener Discovery
     (MLD) T. Jinmei, E. Nordmark, B. Zill, "IPv6
     Scoped Address Architecture", Internet Draft draft-ietf-
     ipv6-scoping-arch-02.txt

[5] R. Hinden, S. Deering, "Internet Protocol Version 6 (IPv6)
     Addressing Architecture", RFC 3513, Apr 2003.

[6] S. Bradner, "Key words for IPv6", use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2710, Oct 1999.

[5] 2119, Mar 1997.

11.  Informative References

[7] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode
     (PIM-SM): Protocol Specification", RFC 2362, June 1998 (now
     obsolete).

[6] W. Fenner, "Internet Group Management Protocol, Version 2",

[8] D. Kim, D. Meyer, H. Kilmer, D. Farinacci, "Anycast Rendevous Point
     (RP) mechanism using Protocol Independent Multicast (PIM) and
     Multicast Source Discovery Protocol (MSDP)", RFC
     2236, Nov 1997.

[7] 3446, Jan 2003.

[9] D. Farinacci, Y. Cai, "Anycast-RP using PIM", Internet Draft draft-
     ietf-pim-anycast-rp-02.txt

[10] IANA, "Address Family Numbers", linked from
     http://www.iana.org/numbers.html

12.

Authors' Addresses

     Nidhi Bhaskar
     Cisco Systems
     170 W. Tasman Drive
     San Jose, CA 95134
     USA
     nbhaskar@cisco.com

     Alexander Gall
     SWITCH
     Limmatquai 138
     P.O. Box
     CH-8021 Zurich
     Switzerland
     gall@switch.ch

     James Lingard
     Data Connection Ltd
     100 Church Street
     Enfield
     EN2 6BQ
     United Kingdom
     james.lingard@dataconnection.com
     Stig Venaas
     UNINETT
     NO-7465 Trondheim
     Norway
     venaas@uninett.no

Copyright Statement

Copyright (C) The Internet Society (2004). (2005).  This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.