tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3973

 
 
 

Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)

Part 3 of 3, p. 38 to 61
Prev RFC Part

 


prevText      Top      Up      ToC       Page 38 
4.7.  PIM Packet Formats

   All PIM-DM packets use the same format as PIM-SM packets.  In the
   event of a discrepancy, PIM-SM [4] should be considered the
   definitive specification.  All PIM control messages have IP protocol
   number 103.  All PIM-DM messages MUST be sent with a TTL of 1.  All
   PIM-DM messages except Graft and Graft Ack messages MUST be sent to
   the ALL-PIM-ROUTERS group.  Graft messages SHOULD be unicast to the
   RPF'(S).  Graft Ack messages MUST be unicast to the sender of the
   Graft.

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

4.7.1.  PIM Header

   All PIM control messages have the following header:

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PIM Ver PIM version number is 2.

Top      Up      ToC       Page 39 
   Type
     Types for specific PIM messages.  Available types are as follows:
     0 = Hello
     1 = Register (PIM-SM only)
     2 = Register Stop (PIM-SM only)
     3 = Join/Prune
     4 = Bootstrap (PIM-SM only)
     5 = Assert
     6 = Graft
     7 = Graft Ack
     8 = Candidate RP Advertisement (PIM-SM only)
     9 = State Refresh

   Reserved
     Set to zero on transmission.  Ignored upon receipt.

   Checksum
     The checksum is the standard IP checksum; i.e., the 16 bit one's
     complement of the one's complement sum of the entire PIM message.
     For computing checksum, the checksum field is zeroed.

     For IPv6, the checksum also includes the IPv6 "pseudo-header", as
     specified in RFC 2460, Section 8.1 [5].

4.7.2.  Encoded Unicast Address

   An Encoded Unicast Address has 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 0 - 127 are as assigned by the IANA for Internet
     Address Families in [9].  Values 128 - 250 are reserved to be
     assigned by the IANA for PIM specific Address Families.  Values 251
     - 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 with a specific Address Family.  The
     value '0' is reserved for this field and represents the native
     encoding of the Address Family.

Top      Up      ToC       Page 40 
   Unicast Address
     The unicast address as represented by the given Address Family and
     Encoding Type.

4.7.3.  Encoded Group Address

   An Encoded Group address has 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
     As described above.

   Encoding Type
     As described above.

   B
     Indicates that the group range should use Bidirectional PIM [16].
     Transmitted as zero; ignored upon receipt.

   Reserved
     Transmitted as zero.  Ignored upon receipt.

   Z
     Indicates that the group range is an admin scope zone.  This is
     used in the Bootstrap Router Mechanism [18] only.  For all other
     purposes, this bit is set to zero and ignored on receipt.

   Mask Len
     The mask length field is 8 bits.  The value is the number of
     contiguous left justified one bits used as a mask, which, combined
     with the address, describes a range of addresses.  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 address
     then the mask length MUST equal the address length.  PIM-DM routers
     MUST only send for a single address.

   Group Multicast Address
     The address of the multicast group.

Top      Up      ToC       Page 41 
4.7.4.  Encoded Source Address

   An Encoded Source address has 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 |  Rsrvd  |S|W|R|  Mask Len     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Source Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   Addr Family
     As described above.

   Encoding Type
     As described above.

   Rsrvd
     Reserved.  Transmitted as zero.  Ignored upon receipt.

   S
     The Sparse Bit.  Set to 0 for PIM-DM.  Ignored upon receipt.

   W
     The Wild Card Bit.  Set to 0 for PIM-DM.  Ignored upon receipt.

   R
     The Rendezvous Point Tree bit.  Set to 0 for PIM-DM.  Ignored upon
     receipt.

   Mask Len
     As described above.  PIM-DM routers MUST only send for a single
     source address.

   Source Address
     The source address.

Top      Up      ToC       Page 42 
4.7.5.  Hello Message Format

   The PIM Hello message, as defined by PIM-SM [4], has 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Option Type          |         Option Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Option Value                          |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Option Type          |         Option Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Option Value                          |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PIM Ver, Type, Reserved, Checksum
     Described above.

   Option Type
     The type of option given in the Option Value field.  Available
     types are as follows:

       0              Reserved
       1              Hello Hold Time
       2              LAN Prune Delay
       3 - 16         Reserved
       17             To be assigned by IANA
       18             Deprecated and SHOULD NOT be used
       19             DR Priority (PIM-SM Only)
       20             Generation ID
       21             State Refresh Capable
       22             Bidir Capable
       23 - 65000     To be assigned by IANA
       65001 - 65535  Reserved for Private Use [9]

     Unknown options SHOULD be ignored.

Top      Up      ToC       Page 43 
4.7.5.1.  Hello Hold Time Option

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type = 1           |           Length = 2          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Hold Time          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Hold Time is the number of seconds a receiver MUST keep the neighbor
   reachable.  If the Hold Time is set to '0xffff', the receiver of this
   message never times out the neighbor.  This may be used with dial-
   on-demand links to avoid keeping the link up with periodic Hello
   messages.  Furthermore, if the Holdtime is set to '0', the
   information is timed out immediately.  The Hello Hold Time option
   MUST be used by PIM-DM routers.

4.7.5.2.  LAN Prune Delay Option

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type = 2           |           Length = 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T|       LAN Prune Delay       |       Override Interval       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LAN_Prune_Delay option is used to tune the prune propagation
   delay on multi-access LANs.  The T bit is used by PIM-SM and SHOULD
   be set to 0 by PIM-DM routers and ignored upon receipt.  The LAN
   Delay and Override Interval fields are time intervals in units of
   milliseconds and are used to tune the value of the J/P Override
   Interval and its derived timer values.  Section 4.3.5 describes how
   these values affect the behavior of a router.  The LAN Prune Delay
   SHOULD be used by PIM-DM routers.

Top      Up      ToC       Page 44 
4.7.5.3.  Generation ID Option

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type = 20           |           Length = 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Generation ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Generation ID is a random value for the interface on which the Hello
   message is sent.  The Generation ID is regenerated whenever PIM
   forwarding is started or restarted on the interface.  The Generation
   ID option MAY be used by PIM-DM routers.

4.7.5.4.  State Refresh Capable Option

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type = 21           |           Length = 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Version = 1  |   Interval    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Interval field is the router's configured State Refresh Interval
   in seconds.  The Reserved field is set to zero and ignored upon
   receipt.  The State Refresh Capable option MUST be used by State
   Refresh capable PIM-DM routers.

Top      Up      ToC       Page 45 
4.7.6.  Join/Prune Message Format

   PIM Join/Prune messages, as defined in PIM-SM [4], have 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Upstream Neighbor Address (Encoded Unicast Format)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |  Num Groups   |          Hold Time            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Multicast Group Address 1 (Encoded Group Format)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Number of Joined Sources    |   Number of Pruned Sources    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Joined Source Address 1 (Encoded Source Format)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Joined Source Address n (Encoded Source Format)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Pruned Source Address 1 (Encoded Source Format)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Pruned Source Address n (Encoded Source Format)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Multicast Group Address m (Encoded Group Format)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Number of Joined Sources    |   Number of Pruned Sources    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Joined Source Address 1 (Encoded Source Format)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 46 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Joined Source Address n (Encoded Source Format)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Pruned Source Address 1 (Encoded Source Format)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Pruned Source Address n (Encoded Source Format)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PIM Ver, Type, Reserved, Checksum
     Described above.

   Upstream Neighbor Address
     The address of the upstream neighbor.  The format for this address
     is given in the Encoded Unicast address in Section 4.7.2.  PIM-DM
     routers MUST set this field to the RPF next hop.

   Reserved
     Transmitted as zero.  Ignored upon receipt.

   Hold Time
     The number of seconds a receiving PIM-DM router MUST keep a Prune
     state alive, unless removed by a Join or Graft message.  If the
     Hold Time is '0xffff', the receiver MUST NOT remove the Prune state
     unless a corresponding Join or Graft message is received.  The Hold
     Time is ignored in Join messages.

   Number of Groups
     Number of multicast group sets contained in the message.

   Multicast Group Address
     The multicast group address in the Encoded Multicast address format
     given in Section 4.7.3.

   Number of Joined Sources
     Number of Join source addresses listed for a given group.

   Number of Pruned Sources
     Number of Prune source addresses listed for a given group.

Top      Up      ToC       Page 47 
   Join Source Address 1..n
     This list contains the sources from which the sending router wishes
     to continue to receive multicast messages for the given group on
     this interface.  The addresses use the Encoded Source address
     format given in Section 4.7.4.

   Prune Source Address 1..n
     This list contains the sources from which the sending router does
     not wish to receive multicast messages for the given group on this
     interface.  The addresses use the Encoded Source address format
     given in Section 4.7.4.

4.7.7.  Assert Message Format

   PIM Assert Messages, as defined in PIM-SM [4], have 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Multicast Group Address (Encoded Group Format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Source Address (Encoded Unicast Format)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|                     Metric Preference                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Metric                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PIM Ver, Type, Reserved, Checksum
     Described above.

   Multicast Group Address
     The multicast group address in the Encoded Multicast address format
     given in Section 4.7.3.

   Source Address
     The source address in the Encoded Unicast address format given in
     Section 4.7.2.

   R
     The Rendezvous Point Tree bit.  Set to 0 for PIM-DM.  Ignored upon
     receipt.

Top      Up      ToC       Page 48 
   Metric Preference
     The preference value assigned to the unicast routing protocol that
     provided the route to the source.

   Metric
     The cost metric of the unicast route to the source.  The metric is
     in units applicable to the unicast routing protocol used.

4.7.8.  Graft Message Format

   PIM Graft messages use the same format as Join/Prune messages, except
   that the Type field is set to 6.  The source address MUST be in the
   Join section of the message.  The Hold Time field SHOULD be zero and
   SHOULD be ignored when a Graft is received.

4.7.9.  Graft Ack Message Format

   PIM Graft Ack messages are identical in format to the received Graft
   message, except that the Type field is set to 7.  The Upstream
   Neighbor Address field SHOULD be set to the sender of the Graft
   message and SHOULD be ignored upon receipt.

4.7.10.  State Refresh Message Format

   PIM State Refresh Messages have 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Multicast Group Address (Encoded Group Format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Source Address (Encoded Unicast Format)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Originator Address (Encoded Unicast Format)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|                     Metric Preference                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Metric                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Masklen    |    TTL        |P|N|O|Reserved |   Interval    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PIM Ver, Type, Reserved, Checksum
     Described above.

Top      Up      ToC       Page 49 
   Multicast Group Address
     The multicast group address in the Encoded Multicast address format
     given in Section 4.7.3.

   Source Address
     The address of the data source in the Encoded Unicast address
     format given in Section 4.7.2.

   Originator Address
     The address of the first hop router in the Encoded Unicast address
     format given in Section 4.7.2.

   R
     The Rendezvous Point Tree bit.  Set to 0 for PIM-DM.  Ignored upon
     receipt.

   Metric Preference
     The preference value assigned to the unicast routing protocol that
     provided the route to the source.

   Metric
     The cost metric of the unicast route to the source.  The metric is
     in units applicable to the unicast routing protocol used.

   Masklen
     The length of the address mask of the unicast route to the source.

   TTL
     Time To Live of the State Refresh message.  Decremented each time
     the message is forwarded.  Note that this is different from the IP
     Header TTL, which is always set to 1.

   P
     Prune indicator flag.  This MUST be set to 1 if the State Refresh
     is to be sent on a Pruned interface.  Otherwise, it MUST be set to
     0.

   N
     Prune Now flag.  This SHOULD be set to 1 by the State Refresh
     originator on every third State Refresh message and SHOULD be
     ignored upon receipt.  This is for compatibility with earlier
     versions of state refresh.

   O
     Assert Override flag.  This SHOULD be set to 1 by upstream routers
     on a LAN if the Assert Timer (AT(S,G)) is not running and SHOULD be
     ignored upon receipt.  This is for compatibility with earlier
     versions of state refresh.

Top      Up      ToC       Page 50 
   Reserved
     Set to zero and ignored upon receipt.

   Interval
     Set by the originating router to the interval (in seconds) between
     consecutive State Refresh messages for this (S,G) pair.

4.8.  PIM-DM Timers

   PIM-DM maintains the following timers.  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 downward
   towards zero.

   Global Timers
     Hello Timer: HT

     Per interface (I):
       Per neighbor (N):
         Neighbor Liveness Timer: NLT(N,I)

       Per (S,G) Pair:
         (S,G) Assert Timer: AT(S,G,I)
         (S,G) Prune Timer: PT(S,G,I)
         (S,G) PrunePending Timer: PPT(S,G,I)

       Per (S,G) Pair:
         (S,G) Graft Retry Timer: GRT(S,G)
         (S,G) Upstream Override Timer: OT(S,G)
         (S,G) Prune Limit Timer: PLT(S,G)
         (S,G) Source Active Timer: SAT(S,G)
         (S,G) State Refresh Timer: SRT(S,G)

Top      Up      ToC       Page 51 
   When timer values are started or restarted, they are set to default
   values.  The following tables summarize those default values.

Timer Name: Hello Timer (HT)
+----------------------+--------+--------------------------------------+
| Value Name           | Value  | Explanation                          |
+----------------------+--------+--------------------------------------+
|Hello_Period          | 30 sec | Periodic interval for hello messages |
+----------------------+--------+--------------------------------------+
|Triggered_Hello_Delay | 5 sec  | Random interval for initial Hello    |
|                      |        | message on bootup or triggered Hello |
|                      |        | message to a rebooting neighbor      |
+----------------------+--------+--------------------------------------+

   Hello messages are sent on every active interface once every
   Hello_Period seconds.  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                    |
+-------------------+-----------------+--------------------------------+
| Hello Holdtime    | From message    | Hold Time from Hello Message   |
+-------------------+-----------------+--------------------------------+

Timer Name: PrunePending Timer (PPT(S,G,I))
+-----------------------+---------------+------------------------------+
| Value Name            | Value         | Explanation                  |
+-----------------------+---------------+------------------------------+
| J/P_Override_Interval | OI(I) + PD(I) | Short time after a Prune to  |
|                       |               | allow other routers on the   |
|                       |               | LAN to send a Join           |
+-----------------------+---------------+------------------------------+

   The J/P_Override_Interval is the sum of the interface's
   Override_Interval (OI(I)) and Propagation_Delay (PD(I)).  If all
   routers on a LAN are using the LAN Prune Delay option, both
   parameters MUST be set to the largest value on the LAN.  Otherwise,
   the Override_Interval (OI(I)) MUST be set to 2.5 seconds, and the
   Propagation_Delay (PD(I)) MUST be set to 0.5 seconds.

Top      Up      ToC       Page 52 
Timer Name: Prune Timer (PT(S,G,I))
+----------------+----------------+------------------------------------+
| Value Name     | Value          | Explanation                        |
+----------------+----------------+------------------------------------+
| Prune Holdtime | From message   | Hold Time read from Prune Message  |
+----------------+----------------+------------------------------------+

Timer Name: Assert Timer (AT(S,G,I))
+--------------------------+---------+---------------------------------+
| Value Name               | Value   | Explanation                     |
+--------------------------+---------+---------------------------------+
| Assert Time              | 180 sec | 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.  If all members of a LAN are state refresh
   enabled, the Assert Time will be three times the received
   RefreshInterval(S,G).

Timer Name: Graft Retry Timer (GRT(S,G))
+--------------------+-------+-----------------------------------------+
| Value Name         | Value | Explanation                             |
+--------------------+-------+-----------------------------------------+
| Graft_Retry_Period | 3 sec | In the absence of receipt of a GraftAck |
|                    |       | message, the time before retransmission |
|                    |       | of a Graft message                      |
+--------------------+-------+-----------------------------------------+

Timer Name: Upstream Override Timer (OT(S,G))
+------------+----------------+----------------------------------------+
| Value Name | Value          | Explanation                            |
+------------+----------------+----------------------------------------|
| t_override | rand(0, OI(I)) | Randomized delay to prevent response   |
|            |                | implosion when sending a join message  |
|            |                | to override someone else's prune       |
+------------+----------------+----------------------------------------+

   t_override is a random value between 0 and the interface's
   Override_Interval (OI(I)).  If all routers on a LAN are using the LAN
   Prune Delay option, the Override_Interval (OI(I)) MUST be set to the
   largest value on the LAN.  Otherwise, the Override_Interval (OI(I))
   MUST be set to 2.5 seconds.

Top      Up      ToC       Page 53 
Timer Name: Prune Limit Timer (PLT(S,G))
+------------+--------------------+------------------------------------+
| Value Name | Value              | Explanation                        |
+------------+--------------------+------------------------------------|
| t_limit    | Default: 210 secs  | Used to prevent Prune storms on a  |
|            |                    | LAN                                |
+------------+--------------------+------------------------------------+

Timer Name: Source Active Timer (SAT(S,G))
+----------------+-------------------+---------------------------------+
| Value Name     | Value             | Explanation                     |
+----------------+-------------------+---------------------------------+
| SourceLifetime | Default: 210 secs | Period of time after receiving  |
|                |                   | a multicast message a directly  |
|                |                   | attached router will continue   |
|                |                   | to send State Refresh messages  |
+----------------+-------------------+---------------------------------+

Timer Name: State Refresh Timer (SRT(S,G))
+-----------------+------------------+---------------------------------+
| Value Name      | Value            | Explanation                     |
+-----------------+------------------+---------------------------------+
| RefreshInterval | Default: 60 secs | Interval between successive     |
|                 |                  | state refresh messages          |
+-----------------+------------------+---------------------------------+

5.  Protocol Interaction Considerations

   PIM-DM is designed to be independent of underlying unicast routing
   protocols and will interact only to the extent needed to perform RPF
   checks.  It is generally assumed that multicast area and autonomous
   system boundaries will correspond to the same boundaries for unicast
   routing, though a deployment that does not follow this assumption is
   not precluded by this specification.

   In general, PIM-DM interactions with other multicast routing
   protocols should be in compliance with RFC 2715 [7].  Other specific
   interactions are noted below.

5.1.  PIM-SM Interactions

   PIM-DM is not intended to interact directly with PIM-SM, even though
   they share a common packet format.  It is particularly important to
   note that a router cannot differentiate between a PIM-DM neighbor and
   a PIM-SM neighbor based on Hello messages.

Top      Up      ToC       Page 54 
   In the event that a PIM-DM router becomes a neighbor of a PIM-SM
   router, the two will effectively form a simplex link, with the PIM-DM
   router sending all multicast messages to the PIM-SM router while the
   PIM-SM router sends no multicast messages to the PIM-DM router.

   The common packet format permits a hybrid PIM-SM/DM implementation
   that would use PIM-SM when a rendezvous point is known and PIM-DM
   when one is not.  Such an implementation is outside the scope of this
   document.

5.2.  IGMP Interactions

   PIM-DM will forward received multicast data packets to neighboring
   host group members in all cases except when the PIM-DM router is in
   an Assert Loser state on that interface.  Note that a PIM Prune
   message is not permitted to prevent the delivery of messages to a
   network with group members.

   A PIM-DM Router MAY use the DR Priority option described in PIM-SM
   [14] to elect an IGMP v1 querier.

5.3.  Source Specific Multicast (SSM) Interactions

   PIM-DM makes no special considerations for SSM [15].  All Prunes and
   Grafts within the protocol are for a specific source, so no
   additional checks have to be made.

5.4.  Multicast Group Scope Boundary Interactions

   Although multicast group scope boundaries are generally identical to
   routing area boundaries, it is conceivable that a routing area might
   be partitioned for a particular multicast group.  PIM-DM routers MUST
   NOT send any messages concerning a particular group across that
   group's scope boundary.

6.  IANA Considerations

6.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.  When the
   PIM packet format was designed, only 15 values were assigned for
   Address Families, and large numbers of new Address Families were not
   envisioned; 8 bits seemed large enough.  However, the IANA assigns
   Address Families in a 16 bit value.  Therefore, the PIM Address
   Family is allocated as follows:

Top      Up      ToC       Page 55 
   Values 0 - 127 are designated to have the same meaning as IANA
   assigned Address Family Numbers [9].

   Values 128 - 250 are designated to be assigned by the IANA based on
   IESG approval, as defined in [8].

   Values 251 - 255 are designated for Private Use, as defined in [8].

6.2.  PIM Hello Options

   Values 17 - 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
   [8].  Assignments are valid for one year and may be renewed.
   Permanent assignments require a specification, as defined in [8].

7.  Security Considerations

   The IPsec authentication header [10] MAY be used to provide data
   integrity protection and groupwise data origin authentication of PIM
   protocol messages.  Authentication of PIM messages can protect
   against unwanted behaviors caused by unauthorized or altered PIM
   messages.  In any case, a PIM router SHOULD NOT accept and process
   PIM messages from neighbors unless a valid Hello message has been
   received from that neighbor.

   Note that PIM-DM has no rendezvous point, and therefore no single
   point of failure that may be vulnerable.  Because PIM-DM uses unicast
   routes provided by an unknown routing protocol, it may suffer
   collateral effects if the unicast routing protocol is attacked.

7.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. A forged PIM-DM message is link local and 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 Hello message can cause multicast traffic to be delivered
      to links where there are no legitimate requestors, potentially
      wasting bandwidth on that link.  On a multi-access LAN, the
      effects are limited without the capability to forge a Join
      message, as other routers will Prune the link if the traffic is
      not desired.

   2. A forged Join/Prune message can cause multicast traffic to be
      delivered to links where there are no legitimate requestors,
      potentially wasting bandwidth on that link.  A forged Prune

Top      Up      ToC       Page 56 
      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 Prune with a Join before the upstream router
      stops forwarding data to the LAN.

   3. A forged Graft message can cause multicast traffic to be delivered
      to links where there are no legitimate requestors, potentially
      wasting bandwidth on that link.  In principle, Graft messages
      could be sent multiple hops because they are unicast to the
      upstream router.  This should not be a problem, as the remote
      forger should have no way to get a Hello message to the target of
      the attack.  Without a valid Hello message, the receiving router
      SHOULD NOT accept the Graft.

   4. A forged GraftAck message has no impact, as it will be ignored
      unless the router has recently sent a Graft to its upstream
      router.

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

   6. A forged State Refresh message on a multi-access LAN would have
      the same impact as a forged Assert message, having the same
      general functions.  In addition, forged State Refresh messages
      would be propagated downstream and might be used in a denial of
      service attack.  Therefore, a PIM-DM router SHOULD rate limit
      State Refresh messages propagated.

7.2.  Non-cryptographic Authentication Mechanisms

   A PIM-DM router SHOULD provide an option to limit the set of
   neighbors from which it will accept PIM-DM messages.  Either static
   configuration of IP addresses or an IPSec security association may be
   used.  All options that restrict the range of addresses from which
   packets are accepted MUST default to allowing all packets.

   Furthermore, a PIM router SHOULD NOT accept protocol messages from a
   router from which it has not yet received a valid Hello message.

7.3.  Authentication Using IPsec

   The IPSec [10] transport mode using the Authentication Header (AH) is
   the recommended method to prevent the above attacks in PIM.  The
   specific AH authentication algorithm and parameters, including the
   choice of authentication algorithm and the choice of key, are
   configured by the network administrator.  The Encapsulating Security

Top      Up      ToC       Page 57 
   Payload (ESP) MAY also be used to provide both encryption and
   authentication of PIM protocol messages.  When IPsec authentication
   is used, a PIM router SHOULD reject (drop without processing) any
   unauthorized PIM protocol messages.

   To use IPSec, the administrator of a PIM network configures each PIM
   router with one or more Security Associations and associated Security
   Parameters Indices that are used by senders to authenticate PIM
   protocol messages and are used by receivers to authenticate received
   PIM protocol messages.  This document does not describe protocols for
   establishing Security Associations.  It assumes that manual
   configuration of Security Associations is performed, but it does not
   preclude the use of some future negotiation protocol such as GDOI
   [17] to establish Security Associations.

   The network administrator defines a Security Association (SA) and
   Security Parameters Index (SPI) to be used to authenticate all PIM-DM
   protocol messages from each router on each link in a PIM-DM domain.

   In order to avoid the problem of allocating individual keys for each
   neighbor on a link to each individual router, it is acceptable to
   establish only one authentication key for all PIM-DM routers on a
   link.  This will not specifically authenticate the individual router
   sending the message, but will ensure that the sender is a PIM-DM
   router on that link.  If this method is used, the receiver of the
   message MUST ignore the received sequence number, thus disabling
   anti-replay mechanisms.  The effects of disabling anti-replay
   mechanisms are essentially the same as the effects of forged
   messages, described in Section 7.1, with the additional protection
   that the forger can only reuse legitimate messages.

   The Security Policy Database at a PIM-DM router should be configured
   to ensure that all incoming and outgoing PIM-DM packets use the SA
   associated with the interface to which the packet is sent.  Note
   that, according to [10], there is nominally a different Security
   Association Database (SAD) for each router interface.  Thus, the
   selected Security Association for an inbound PIM-DM packet can vary
   depending on the interface on which the packet arrived.  This fact
   allows the network administrator to use different authentication
   methods for each link, even though the destination address is the
   same for most PIM-DM packets, regardless of interface.

Top      Up      ToC       Page 58 
7.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 data traffic.  Authenticating PIM protocol
   traffic prevents some, but not all, of these attacks.  The possible
   attacks include the following:

   * Sending packets to many different group addresses quickly can
     amount to a denial of service attack in and of itself.  These
     messages will initially be flooded throughout the network before
     they are pruned back.  The maintenance of state machines and State
     Refresh messages will be a continual drain on network resources.

   * Forged State Refresh messages sent quickly could be propagated by
     downstream routers, creating a potential denial of service attack.
     Therefore, a PIM-DM router SHOULD limit the rate of State Refresh
     messages propagated.

8.  Acknowledgments

   The major features of PIM-DM were originally designed by Stephen
   Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed Helmy,
   David Meyer, and Liming Wei.  Additional features for state refresh
   were designed by Dino Farinacci, Isidor Kouvelas, and Kurt Windisch.
   This revision was undertaken to incorporate some of the lessons
   learned during the evolution of the PIM-SM specification and early
   deployments of PIM-DM.

   Thanks the PIM Working Group for their comments.

9.  References

9.1.  Normative References

   [1]  Deering, S., "Host extensions for IP multicasting", STD 5, RFC
        1112, August 1989.

   [2]  Fenner, W., "Internet Group Management Protocol, Version 2", RFC
        2236, November 1997.

   [3]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
        Thyagarajan, "Internet Group Management Protocol, Version 3",
        RFC 3376, October 2002.

Top      Up      ToC       Page 59 
   [4]  Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
        Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei,
        "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
        Specification", RFC 2362, June 1998.

   [5]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

   [6]  Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
        Discovery (MLD) for IPv6", RFC 2710, October 1999.

   [7]  Thaler, D., "Interoperability Rules for Multicast Routing
        Protocols", RFC 2715, October 1999.

   [8]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

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

   [10] Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

   [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [12] Deering, S.E., "Multicast Routing in a Datagram Internetwork",
        Ph.D. Thesis, Electrical Engineering Dept., Stanford University,
        December 1991.

   [13] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector
        Multicast Routing Protocol", RFC 1075, November 1988.

   [14] Fenner,  W., Handley, M., Holbrook, H., and I. Kouvelas,
        "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
        Specification (Revised)", Work in Progress.

   [15] Holbrook, H. and B. Cain, "Source Specific Multicast for IP",
        Work in Progress.

   [16] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bi-
        directional Protocol Independent Multicast", Work in Progress.

   [17] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
        Domain of Interpretation", RFC 3547, July 2003.

Top      Up      ToC       Page 60 
   [18] Fenner, W., Handley, M., Kermode, R., and D. Thaler, "Bootstrap
        Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress.

Authors' Addresses

   Andrew Adams
   NextHop Technologies
   825 Victors Way, Suite 100
   Ann Arbor, MI 48108-2738

   EMail: ala@nexthop.com


   Jonathan Nicholas
   ITT Industries
   Aerospace/Communications Division
   100 Kingsland Rd
   Clifton, NJ  07014

   EMail: jonathan.nicholas@itt.com


   William Siadak
   NextHop Technologies
   825 Victors Way, Suite 100
   Ann Arbor, MI 48108-2738

   EMail: wfs@nexthop.com

Top      Up      ToC       Page 61 
Full Copyright Statement

   Copyright (C) The Internet Society (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.

   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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.