4.10.  PIM Timers

   PIM-SM maintains the following timers, as discussed in Section 4.11.
   All timers are countdown timers; they are set to a value and count
   down to zero, at which point they typically trigger an action.  Of
   course, they can just as easily be implemented as count-up timers,
   where the absolute expiry time is stored and compared against a
   real-time clock, but the language in this specification assumes that
   they count downwards to zero.

   Global Timers

   Per interface (I):

        Hello Timer: HT(I)

        Per neighbor (N):

             Neighbor Liveness Timer: NLT(N,I)

        Per Group (G):

             (*,G) Join Expiry Timer: ET(*,G,I)

             (*,G) Prune-Pending Timer: PPT(*,G,I)

             (*,G) Assert Timer: AT(*,G,I)

             Per Source (S):

                  (S,G) Join Expiry Timer: ET(S,G,I)

                  (S,G) Prune-Pending Timer: PPT(S,G,I)

                  (S,G) Assert Timer: AT(S,G,I)

                  (S,G,rpt) Prune Expiry Timer: ET(S,G,rpt,I)

                  (S,G,rpt) Prune-Pending Timer: PPT(S,G,rpt,I)

   Per Group (G):

        (*,G) Upstream Join Timer: JT(*,G)

        Per Source (S):

             (S,G) Upstream Join Timer: JT(S,G)

             (S,G) Keepalive Timer: KAT(S,G)

             (S,G,rpt) Upstream Override Timer: OT(S,G,rpt)

   At the DRs or relevant Assert Winners only:

        Per Source,Group pair (S,G):

             Register-Stop Timer: RST(S,G)

4.11.  Timer Values

   When timers are started or restarted, they are set to default values.
   This section summarizes those default values.

   Note that protocol events or configuration may change the default
   value of a timer on a specific interface.  When timers are
   initialized in this document, the value specific to the interface in
   context must be used.

   Some of the timers listed below (Prune-Pending, Upstream Join,
   Upstream Override) can be set to values that depend on the settings
   of the Propagation_Delay and Override_Interval of the corresponding
   interface.  The default values for these are given below.

   Variable Name: Propagation_Delay(I)

+-------------------------------+--------------+----------------------+
|  Value Name                   |  Value       |  Explanation         |
+-------------------------------+--------------+----------------------+
|  Propagation_delay_default    |  0.5 secs    |  Expected            |
|                               |              |  propagation delay   |
|                               |              |  over the local      |
|                               |              |  link.               |
+-------------------------------+--------------+----------------------+

   The default value of the Propagation_delay_default is chosen to be
   relatively large to provide compatibility with older PIM
   implementations.

   Variable Name: Override_Interval(I)

+--------------------------+-----------------+-------------------------+
|  Value Name              |    Value        |    Explanation          |
+--------------------------+-----------------+-------------------------+
|  t_override_default      |    2.5 secs     |    Default delay        |
|                          |                 |    interval over        |
|                          |                 |    which to randomize   |
|                          |                 |    when scheduling a    |
|                          |                 |    delayed Join         |
|                          |                 |    message.             |
+--------------------------+-----------------+-------------------------+

   Timer Name: Hello Timer (HT(I))

+---------------------+--------+---------------------------------------+
|Value Name           | Value  | Explanation                           |
+---------------------+--------+---------------------------------------+
|Hello_Period         | 30 secs| Periodic interval for Hello messages. |
+---------------------+--------+---------------------------------------+
|Triggered_Hello_Delay| 5 secs | Randomized interval for initial Hello |
|                     |        | message on bootup or triggered Hello  |
|                     |        | message to a rebooting neighbor.      |
+---------------------+--------+---------------------------------------+

   At system power-up, the timer is initialized to
   rand(0, Triggered_Hello_Delay) to prevent synchronization.  When a
   new or rebooting neighbor is detected, a responding Hello is sent
   within rand(0, Triggered_Hello_Delay).

   Timer Name: Neighbor Liveness Timer (NLT(N,I))

+--------------------------+----------------------+--------------------+
| Value Name               |  Value               |  Explanation       |
+--------------------------+----------------------+--------------------+
| Default_Hello_Holdtime   |  3.5 * Hello_Period  |  Default holdtime  |
|                          |                      |  to keep neighbor  |
|                          |                      |  state alive       |
+--------------------------+----------------------+--------------------+
| Hello_Holdtime           |  from message        |  Holdtime from     |
|                          |                      |  Hello message     |
|                          |                      |  Holdtime option.  |
+--------------------------+----------------------+--------------------+

   The Holdtime in a Hello message should be set to
   (3.5 * Hello_Period), giving a default value of 105 seconds.

   Timer Names: Expiry Timer (ET(*,G,I), ET(S,G,I), ET(S,G,rpt,I))

+----------------+----------------+------------------------------------+
| Value Name     |  Value         |  Explanation                       |
+----------------+----------------+------------------------------------+
| J/P_HoldTime   |  from message  |  Holdtime from Join/Prune message  |
+----------------+----------------+------------------------------------+

   The value of J/P Holdtime that is included in Join/Prune messages is
   specified below, in the description of "Upstream Join Timer (JT(*,G),
   JT(S,G))".

   Timer Names: Prune-Pending Timer (PPT(*,G,I), PPT(S,G,I),
   PPT(S,G,rpt,I))

+--------------------------+---------------------+---------------------+
|Value Name                | Value               | Explanation         |
+--------------------------+---------------------+---------------------+
|J/P_Override_Interval(I)  | Default:            | Short period after  |
|                          | Effective_          | a join or prune to  |
|                          | Propagation_        | allow other         |
|                          | Delay(I) +          | routers on the LAN  |
|                          | Effective_Override_ | to override the     |
|                          | Interval(I)         | join or prune       |
+--------------------------+---------------------+---------------------+

   Note that both Effective_Propagation_Delay(I) and
   Effective_Override_Interval(I) are interface-specific values that may
   change when Hello messages are received (see Section 4.3.3).

   Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I))

+---------------------------+---------------------+--------------------+
| Value Name                | Value               | Explanation        |
+---------------------------+---------------------+--------------------+
| Assert_Override_Interval  | Default: 3 secs     | Short interval     |
|                           |                     | before an assert   |
|                           |                     | times out where    |
|                           |                     | the assert winner  |
|                           |                     | resends an Assert  |
|                           |                     | message            |
+---------------------------+---------------------+--------------------+
| Assert_Time               | Default: 180 secs   | Period after last  |
|                           |                     | assert before      |
|                           |                     | assert state is    |
|                           |                     | timed out          |
+---------------------------+---------------------+--------------------+

   Note that for historical reasons, the Assert message lacks a Holdtime
   field.  Thus, changing the Assert Time from the default value is not
   recommended.

   Timer Names: Upstream Join Timer (JT(*,G), JT(S,G))

+-------------+--------------------+-----------------------------------+
|Value Name   | Value              | Explanation                       |
+-------------+--------------------+-----------------------------------+
|t_periodic   | Default: 60 secs   | Period between Join/Prune messages|
+-------------+--------------------+-----------------------------------+
|t_suppressed | rand(1.1 *         | Suppression period when someone   |
|             | t_periodic, 1.4 *  | else sends a J/P message so we    |
|             | t_periodic) when   | don't need to do so.              |
|             | Suppression_       |                                   |
|             | Enabled(I) is      |                                   |
|             | true, 0 otherwise  |                                   |
+-------------+--------------------+-----------------------------------+
|t_override   | rand(0, Effective_ | Randomized delay to prevent       |
|             | Override_          | response implosion when sending a |
|             | Interval(I))       | Join message to override someone  |
|             |                    | else's Prune message.             |
+-------------+--------------------+-----------------------------------+

   t_periodic may be set to take into account such things as the
   configured bandwidth and expected average number of multicast route
   entries for the attached network or link (e.g., the period would be
   longer for lower-speed links, or for routers in the center of the
   network that expect to have a larger number of entries).  If the
   Join/Prune-Period is modified during operation, these changes should
   be made relatively infrequently, and the router should continue to
   refresh at its previous Join/Prune-Period for at least
   Join/Prune-Holdtime, in order to allow the upstream router to adapt.

   The Holdtime specified in a Join/Prune message should be set to
   (3.5 * t_periodic).

   t_override depends on the Effective Override Interval of the upstream
   interface, which may change when Hello messages are received.

   t_suppressed depends on the Suppression State of the upstream
   interface (Section 4.3.3) and becomes zero when suppression is
   disabled.

   Timer Name: Upstream Override Timer (OT(S,G,rpt))

+---------------+--------------------------+---------------------------+
| Value Name    | Value                    |  Explanation              |
+---------------+--------------------------+---------------------------+
| t_override    | see Upstream Join Timer  |  see Upstream Join Timer  |
+---------------+--------------------------+---------------------------+

   The Upstream Override Timer is only ever set to the t_override value;
   this value is defined earlier in this section, under "Timer Names:
   Upstream Join Timer (JT(*,G), JT(S,G))".

   Timer Name: Keepalive Timer (KAT(S,G))

+-----------------------+-----------------------+----------------------+
| Value Name            |  Value                |  Explanation         |
+-----------------------+-----------------------+----------------------+
| Keepalive_Period      |  Default: 210 secs    |  Period after last   |
|                       |                       |  (S,G) data packet   |
|                       |                       |  during which (S,G)  |
|                       |                       |  Join state will be  |
|                       |                       |  maintained even in  |
|                       |                       |  the absence of      |
|                       |                       |  (S,G) Join          |
|                       |                       |  messages.           |
+-----------------------+-----------------------+----------------------+
| RP_Keepalive_Period   |  ( 3 * Register_      |  As                  |
|                       |  Suppression_Time )   |  Keepalive_Period,   |
|                       |  + Register_          |  but at the RP when  |
|                       |  Probe_Time           |  a Register-Stop is  |
|                       |                       |  sent.               |
+-----------------------+-----------------------+----------------------+

   The normal keepalive period for the KAT(S,G) defaults to 210 seconds.
   However, at the RP, the keepalive period must be at least the
   Register_Suppression_Time, or the RP may time out the (S,G) state
   before the next Null-Register arrives.  Thus, the KAT(S,G) is set to
   max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop
   is sent.

   Timer Name: Register-Stop Timer (RST(S,G))

+---------------------------+--------------------+---------------------+
|Value Name                 | Value              | Explanation         |
+---------------------------+--------------------+---------------------+
|Register_Suppression_Time  | Default: 60 secs   | Period during       |
|                           |                    | which a DR stops    |
|                           |                    | sending Register-   |
|                           |                    | encapsulated data   |
|                           |                    | to the RP after     |
|                           |                    | receiving a         |
|                           |                    | Register-Stop       |
|                           |                    | message.            |
+---------------------------+--------------------+---------------------+
|Register_Probe_Time        | Default: 5 secs    | Time before RST     |
|                           |                    | expires when a DR   |
|                           |                    | may send a Null-    |
|                           |                    | Register to the RP  |
|                           |                    | to cause it to      |
|                           |                    | resend a Register-  |
|                           |                    | Stop message.       |
+---------------------------+--------------------+---------------------+

   If the Register_Suppression_Time or the Register_Probe_Time is
   configured to values other than the defaults, it MUST be ensured that
   the value of the Register_Probe_Time is less than half the value of
   the Register_Suppression_Time to prevent a possible negative value in
   the setting of the Register-Stop Timer.

5.  IANA Considerations

5.1.  PIM Address Family

   The PIM Address Family field was chosen to be 8 bits as a tradeoff
   between packet format and use of the IANA-assigned numbers.  Because
   when the PIM packet format was designed only 15 values were assigned
   for Address Families, and large numbers of new Address Family values
   were not envisioned, 8 bits seemed large enough.  However, the IANA
   assigns Address Families in a 16-bit field.  Therefore, the PIM
   Address Family is allocated as follows:

      Values 0 through 127 are designated to have the same meaning as
      IANA-assigned Address Family Numbers [7].

      Values 128 through 250 are designated to be assigned for PIM by
      the IANA based upon IESG Approval, as defined in [9].

      Values 251 through 255 are designated for Private Use, as defined
      in [9].

5.2.  PIM Hello Options

   Values 17 through 65000 are to be assigned by the IANA.  Since the
   space is large, they may be assigned as First Come First Served, as
   defined in [9].  Such assignments are valid for one year and may be
   renewed.  Permanent assignments require a specification (see
   "Specification Required" in [9]).

6.  Security Considerations

   This section describes various possible security concerns related to
   the PIM-SM protocol.  The reader is referred to [8], [14], and [15]
   for further discussion of PIM-SM and multicast security.

   Note that PIM relies upon an MRIB populated outside of PIM;
   therefore, securing the sources of change to the MRIB is RECOMMENDED.

6.1.  Attacks Based on Forged Messages

   The extent of possible damage depends on the type of counterfeit
   messages accepted.  We next consider the impact of possible
   forgeries, including forged link-local (Join/Prune, Hello, and
   Assert) and forged unicast (Register and Register-Stop) messages.

6.1.1.  Forged Link-Local Messages

   Join/Prune, Hello, and Assert messages are all sent to the link-local
   ALL-PIM-ROUTERS multicast address and thus are not forwarded by a
   compliant router.  A forged message of this type can only reach a LAN
   if it was sent by a local host or if it was allowed onto the LAN by a
   compromised or non-compliant router.

   1.  A forged Join/Prune message can cause multicast traffic to be
       delivered to links where there are no legitimate requesters,
       potentially wasting bandwidth on that link.  A forged leave
       message on a multi-access LAN is generally not a significant
       attack in PIM, because any legitimately joined router on the LAN
       would override the leave with a join before the upstream router
       stops forwarding data to the LAN.

   2.  By forging a Hello message, an unauthorized router can cause
       itself to be elected as the Designated Router on a LAN.  The
       Designated Router on a LAN is (in the absence of asserts)
       responsible for forwarding traffic to that LAN on behalf of any
       local members.  The Designated Router is also responsible for
       register-encapsulating to the RP any packets that are originated
       by hosts on the LAN.  Thus, the ability of local hosts to send
       and receive multicast traffic may be compromised by a forged
       Hello message.

   3.  By forging an Assert message on a multi-access LAN, an attacker
       could cause the legitimate designated forwarder to stop
       forwarding traffic to the LAN.  Such a forgery would prevent any
       hosts downstream of that LAN from receiving traffic.

6.1.2.  Forged Unicast Messages

   Register messages and Register-Stop messages are forwarded by
   intermediate routers to their destination using normal IP forwarding.
   Without data origin authentication, an attacker who is located
   anywhere in the network may be able to forge a Register or
   Register-Stop message.  We next consider the effect of a forgery of
   each of these messages.

   1.  By forging a Register message, an attacker can cause the RP to
       inject forged traffic onto the shared multicast tree.

   2.  By forging a Register-Stop message, an attacker can prevent a
       legitimate DR from registering packets to the RP.  This can
       prevent local hosts on that LAN from sending multicast packets.

   The above two PIM messages are not changed by intermediate routers
   and need only be examined by the intended receiver.  Thus, these
   messages can be authenticated end-to-end.  Attacks on Register and
   Register-Stop messages do not apply to a PIM-SSM-only implementation,
   as these messages are not required for PIM-SSM.

6.2.  Non-cryptographic Authentication Mechanisms

   A PIM router SHOULD provide an option to limit the set of neighbors
   from which it will accept Join/Prune, Assert, and Hello messages.
   Either static configuration of IP addresses or an IPsec security
   association MAY be used.  Furthermore, a PIM router SHOULD NOT accept
   protocol messages from a router from which it has not yet received a
   valid Hello message.

   A Designated Router MUST NOT register-encapsulate a packet and send
   it to the RP unless the source address of the packet is a legal
   address for the subnet on which the packet was received.  Similarly,
   a Designated Router SHOULD NOT accept a Register-Stop packet whose IP
   source address is not a valid RP address for the local domain.

   An implementation SHOULD provide a mechanism to allow an RP to
   restrict the range of source addresses from which it accepts
   Register-encapsulated packets.

   All options that restrict the range of addresses from which packets
   are accepted MUST default to allowing all packets.

6.3.  Authentication

   This document refers to RFC 5796 [8], which specifies mechanisms to
   authenticate PIM-SM link-local messages using the IPsec Encapsulating
   Security Payload (ESP) or (optionally) the Authentication Header
   (AH).  It also points out that non-link-local PIM-SM messages (i.e.,
   Register and Register-Stop messages) can be secured by a normal
   unicast IPsec Security Association (SA) between two communicants.

6.4.  Denial-of-Service Attacks

   There are a number of possible denial-of-service attacks against PIM
   that can be caused by generating false PIM protocol messages or even
   by generating false traffic.  Authenticating PIM protocol traffic
   prevents some, but not all, of these attacks.  Two of the possible
   attacks include the following:

   o  Sending packets to many different group addresses quickly can be a
      denial-of-service attack in and of itself.  This will cause many
      register-encapsulated packets, loading the DR, the RP, and the
      routers between the DR and the RP.

   o  Forging Join messages can cause a multicast tree to get set up.
      A large number of forged joins can consume router resources and
      result in denial of service.

7.  References

7.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
        <http://www.rfc-editor.org/info/rfc2119>.

   [2]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
        Thyagarajan, "Internet Group Management Protocol, Version 3",
        RFC 3376, DOI 10.17487/RFC3376, October 2002,
        <http://www.rfc-editor.org/info/rfc3376>.

   [3]  Deering, S., "Host extensions for IP multicasting", STD 5,
        RFC 1112, DOI 10.17487/RFC1112, August 1989,
        <http://www.rfc-editor.org/info/rfc1112>.

   [4]  Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
        Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710,
        October 1999, <http://www.rfc-editor.org/info/rfc2710>.

   [5]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998,
        <http://www.rfc-editor.org/info/rfc2460>.

   [6]  Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
        RFC 4607, DOI 10.17487/RFC4607, August 2006,
        <http://www.rfc-editor.org/info/rfc4607>.

   [7]  IANA, "Address Family Numbers",
        <http://www.iana.org/assignments/address-family-numbers>.

   [8]  Atwood, W., Islam, S., and M. Siami, "Authentication and
        Confidentiality in Protocol Independent Multicast Sparse Mode
        (PIM-SM) Link-Local Messages", RFC 5796, DOI 10.17487/RFC5796,
        March 2010, <http://www.rfc-editor.org/info/rfc5796>.

   [9]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 5226,
        DOI 10.17487/RFC5226, May 2008,
        <http://www.rfc-editor.org/info/rfc5226>.

7.2.  Informative References

   [10] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol
        Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760,
        January 2007, <http://www.rfc-editor.org/info/rfc4760>.

   [11] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap
        Router (BSR) Mechanism for Protocol Independent Multicast
        (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008,
        <http://www.rfc-editor.org/info/rfc5059>.

   [12] Black, D., "Differentiated Services and Tunnels", RFC 2983,
        DOI 10.17487/RFC2983, October 2000,
        <http://www.rfc-editor.org/info/rfc2983>.

   [13] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
        "Bidirectional Protocol Independent Multicast (BIDIR-PIM)",
        RFC 5015, DOI 10.17487/RFC5015, October 2007,
        <http://www.rfc-editor.org/info/rfc5015>.

   [14] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent
        Multicast - Sparse Mode (PIM-SM) Multicast Routing Security
        Issues and Enhancements", RFC 4609, DOI 10.17487/RFC4609,
        October 2006, <http://www.rfc-editor.org/info/rfc4609>.

   [15] Savola, P. and J. Lingard, "Host Threats to Protocol Independent
        Multicast (PIM)", RFC 5294, DOI 10.17487/RFC5294, August 2008,
        <http://www.rfc-editor.org/info/rfc5294>.

   [16] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP)
        Address in an IPv6 Multicast Address", RFC 3956,
        DOI 10.17487/RFC3956, November 2004,
        <http://www.rfc-editor.org/info/rfc3956>.

   [17] Zheng, L., Zhang, J., and R. Parekh, "Survey Report on Protocol
        Independent Multicast - Sparse Mode (PIM-SM) Implementations and
        Deployments", RFC 7063, DOI 10.17487/RFC7063, December 2013,
        <http://www.rfc-editor.org/info/rfc7063>.

Appendix A.  Functionality Removed from RFC 4601

   Based on a survey of PIM implementations and deployments [17]
   conducted by the IETF PIM working group, the following functionality
   of RFC 4601 has been removed due to lack of sufficient implementation
   and deployment experience:

   o  (*,*,RP) State

   o  PIM Multicast Border Router (PMBR)

   o  Authentication using IPsec

Acknowledgements

   PIM-SM was designed over many years by a large group of people,
   including ideas, comments, and corrections from Deborah Estrin, Dino
   Farinacci, Ahmed Helmy, David Thaler, 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, Brian
   Haberman, Hal Sandick, Mike Mroz, Garry Kump, Pavlin Radoslavov, Mike
   Davison, James Huang, Christopher Thomas Brown, and James Lingard.

   Thanks are due to the American Licorice Company, for its obscure but
   possibly essential role in the creation of this document.

Authors' Addresses

   Bill Fenner
   Arista Networks

   Email: fenner@arista.com


   Mark Handley
   Department of Computer Science
   University College London
   Gower Street
   London WC1E 6BT
   United Kingdom

   Email: M.Handley@cs.ucl.ac.uk

   Hugh Holbrook
   Arista Networks
   5453 Great America Parkway
   Santa Clara, CA  95054

   Email: holbrook@arista.com


   Isidor Kouvelas
   Arista Networks
   5453 Great America Parkway
   Santa Clara, CA  95054

   Email: kouvelas@arista.com


   Rishabh Parekh
   Cisco Systems, Inc.
   170 W. Tasman Drive
   San Jose, CA  95134

   Email: riparekh@cisco.com


   Zhaohui Zhang
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886

   Email: zzhang@juniper.net


   Lianshu Zheng
   Huawei Technologies Co., Ltd
   Huawei Campus, 156 Beiqing Road, Hai-dian District
   Beijing  100089
   China

   Email: vero.zheng@huawei.com