RFC 3973
Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)
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.
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.
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.
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.
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.
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.
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.
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
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.
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.
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)
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.
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.
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.
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:
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
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
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.
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.
[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.
[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
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.