PIM Message Type Space Extension and Reserved Bits
obsoleted by
- rfc-9436 — PIM Message Type Space Extension and Reserved Bits
obsoletes
- rfc-6166 — A Registry for PIM Message Types
updates
- rfc-3973 — Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)
- rfc-5015 — Bidirectional Protocol Independent Multicast (BIDIR-PIM)
- rfc-5059 — Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)
- rfc-6754 — Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect
- rfc-7761 — Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)
- rfc-8364 — PIM Flooding Mechanism (PFM) and Source Discovery (SD)
Extracted elements (15)
Previously, the eight reserved bits in the common PIM header were not formally assigned on a per-message-type basis. This document formalizes per-type flag bit assignment to allow different message types to use the bits independently without conflicting interpretations.
The PIM type space (0–15) was nearly exhausted. Rather than requiring an entirely new header version, types 13, 14, and 15 were repurposed to carry a 4-bit Subtype field in the flag bits, extending the effective type space by 48 values with minimal header change.
This document updates RFCs 7761 and 3973 by redefining the Reserved field as Flag Bits, and further updates RFCs 5015, 5059, 6754, and 8364 by specifying flag bit usage for their respective message types. It obsoletes RFC 6166.
Assignments into the 'PIM Message Types' registry MUST define any non-default usage of the flag bits in addition to defining the type itself.
The specification of a new PIM type MUST indicate whether the flag bits should be treated differently from the default Reserved behavior (zero on send, ignore on receive).
Unless otherwise specified, all flag bits for each PIM message type are Reserved: they MUST be set to zero on transmission and MUST be ignored upon receipt.
Flag bits are numbered such that bit 7 is the most significant (immediately following the Type field) and bit 0 is the least significant (immediately before the Checksum field).
PIM message type 10 (DF Election) uses flag bits 4–7 as a subtype field, as defined in RFC 5015; flag bits 0–3 are reserved.
PIM message type 12 (PIM Flooding Mechanism) uses flag bit 7 as 'No-Forward' as defined in RFC 8364; flag bits 0–6 are reserved.
PIM message type 4 (Bootstrap) uses flag bit 7 as 'No-Forward' as defined in RFC 5059; flag bits 0–6 are reserved.
Types 13, 14, and 15 each support 16 subtypes (via the Subtype field in bits 4–7), providing 48 total subtypes for future PIM extensions. The notation 'type.subtype' is used to reference them. The remaining four flag bits (0–3) are reserved for use by each extended type.
The 'PIM Message Types' registry (registration policy: IETF Review) is updated to record per-type flag bit definitions for all 16 existing types (0–12, plus 13.0–15.15 unassigned). New extended types should be assigned consecutively starting with 13.0.
This document only clarifies the use of flag bits in the common PIM header and extends the type space; there is no security impact and no changes to the security considerations of RFC 7761 or RFC 3973.
For extended message types 13, 14, and 15, the Flag Bits field is split into Subtype (bits 4–7, 4 bits) and FB (bits 0–3, 4 bits), yielding the layout: PIM Ver | Type | Subtype | FB | Checksum.
The PIM common header is redefined with the 8-bit Reserved field renamed to 'Flag Bits': PIM Ver (4 bits), Type (4 bits), Flag Bits (8 bits), Checksum (16 bits). All other fields remain unchanged from RFC 7761 Section 4.9.