PIM Message Type Space Extension and Reserved Bits
obsoletes
- rfc-8736 — PIM Message Type Space Extension and Reserved Bits
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)
Flag bits are defined on a per-message-type basis rather than globally because different message types have distinct operational needs. Bit 7 is the most significant (immediately after the Type field) and bit 0 is the least significant (immediately before the Checksum), providing a well-defined numbering convention for future specifications.
The type space extension uses types 13, 14, and 15 with a 4-bit subtype in the upper flag bits to expand PIM message types from 16 to 64 (48 new extended types) without changing the common header size. No relationship is expected or implied between extended type messages sharing a common Type field value.
This document obsoletes RFC 8736 and updates RFCs 7761, 3973, 5015, 5059, 6754, and 8364 by formally defining per-message-type flag bit usage. IANA has updated references in the PIM Message Types registry from RFC 8736 to this document (RFC 9436).
Assignments to the PIM Message Types registry MUST define any non-default usage of the flag bits in addition to the type itself.
The specification of a new PIM type MUST indicate whether the flag bits should be treated differently from the default (zero on send, ignore on receive).
Unless otherwise specified, all flag bits for each PIM message type are Unassigned and MUST be set to zero on transmission, and they MUST be ignored upon receipt.
Extended type 15.15 is Reserved for future extensions; all four of its flag bits (0-3) are also Reserved. New extended message types should be assigned consecutively starting with 13.0, then 13.1, etc.
PIM message type 10 (DF Election) uses the four most significant flag bits (bits 4-7) as a subtype field per RFC 5015. The remaining flag bits 0-3 are Unassigned.
PIM message type 12 (PIM Flooding Mechanism) defines flag bit 7 as 'No-Forward' per RFC 8364. The remaining flag bits 0-6 are Unassigned.
PIM message type 4 (Bootstrap) defines flag bit 7 as 'No-Forward' per RFC 5059. The remaining flag bits 0-6 are Unassigned.
Types 13, 14, and 15 are each extended into 16 subtypes via the Subtype field (bits 4-7), producing 48 available extended types (13.0 through 15.15). Each extended type has 4 remaining flag bits (bits 0-3) defined per extended type.
This document updates the IANA 'PIM Message Types' registry to document which flag bits are defined or Unassigned for each of the 16 base message types (0-15) plus extended types 13.0-15.15. Extended type 15.15 is Reserved. Registration policy remains IETF Review.
This document clarifies use of flag bits in the PIM common header and extends the type space, but introduces no new security impact or changes to the security considerations established in RFC 7761 and RFC 3973.
For extended types 13, 14, and 15, the Flag Bits field is split into a 4-bit Subtype field (bits 4-7) and a 4-bit FB (flag bits, bits 0-3) field. The extended type is referenced using 'type.subtype' notation, yielding 48 new types total.
The PIM common header is a 32-bit structure with four fields: PIM Ver (4 bits), Type (4 bits), Flag Bits (8 bits, formerly Reserved), and Checksum (16 bits). This document renames the Reserved field to 'Flag Bits field' and defines its per-message-type usage.