Explicit Reverse Path Forwarding (RPF) Vector
Extracted elements (17)
The Explicit RPF Vector was created because RFC 5496 loose RPF Vectors still depend on unicast reachability, which may route two PIM trees over the same transit router. For PIM Live-Live resiliency (two spatially diverse trees carrying the same broadcast video), network administrators need strictly path-diverse trees that do not share any transit router, necessitating explicit hop-by-hop path control.
When an Explicit RPF Vector router finds no PIM neighbor matching the next-hop vector, it does NOT fall back to loose routing; instead it may store the RPF Vector list so the Join can be sent as soon as the neighbor appears. This strict behavior is intentional to guarantee path diversity rather than silently rerouting.
Explicit RPF Vectors and loose RPF Vectors (RFC 5496) can be mixed in the same PIM Join Attribute list, allowing part of a multicast tree to follow an explicit path while other parts are loosely routed. RPF Vectors are processed in the order they appear.
For PIM Asserts, the route metric included in the Assert should be the route metric of the first Explicit RPF Vector address in the list. Because the first Explicit Vector should always be directly connected, the metric is likely zero and will typically not act as a tie breaker in Assert selection.
Routers that do not understand the Explicit RPF Vector TLV (F bit clear) will discard it and continue processing the Join per RFC 5384 Section 3.3.2. Administrators should compute explicit paths that include only routers supporting the Explicit Vector and verify state creation using tools like mtrace.
For Join Suppression, the suppression procedure (per RFC 5496 Section 3.3.4) MUST match against all Explicit RPF Vectors in the PIM Join before a PIM Join can be suppressed.
It is RECOMMENDED that a router performing conflict resolution log a message to aid operators in diagnosing path inconsistencies.
The F bit MUST be set to 0 in all Explicit RPF Vectors to ensure that upstream routers which do not support the TLV will discard it rather than forwarding it, preventing loops that could result from unsupported routers being listed as hops in the explicit path.
The F (Transitive Attribute) bit MUST be set to 0 in the Explicit RPF Vector TLV. Setting it to 1 could cause routing loops because routers that do not understand the attribute would propagate it upstream rather than discarding it.
The Value field of the Explicit RPF Vector Attribute SHOULD be a valid IPv4 or IPv6 address of an upstream router.
When a PIM Join with a Join Attribute list is received from a downstream neighbor, the router MUST verify that the order in which RPF Vector types appear matches what is stored for reaching the source or RP. Once the types match, the content MUST be compared per RFC 5384 Section 3.3.3.
When there is a conflict between RPF Vector types or RPF Vector content from multiple downstream neighbors, the router MUST use the RPF Vector stack from the PIM adjacency with the numerically smallest IP address (link-local for IPv6). When two neighbors share the same IP address, the interface index MUST be used as a tie breaker.
The Explicit RPF Vector Attribute is a new PIM Join Attribute TLV (type 4) that encodes an explicit list of directly connected PIM neighbors as hop-by-hop RPF path, bypassing unicast route lookup entirely. Unlike the loose RPF Vector of RFC 5496, if no matching PIM neighbor exists for an Explicit RPF Vector, the router does not fall back to loose routing.
IANA assigned value 4 to the Explicit RPF Vector Attribute in the 'PIM Join Attribute Types' registry.
A malicious downstream node can launch a denial-of-service attack by sending PIM Join packets with invalid addresses in the RPF Vector stack, stopping propagation of Joins to the correct upstream node, or by targeting all Joins to a specific node to overload its forwarding capacity.
Security of the Explicit RPF Vector Attribute relies entirely on the security of the PIM packet itself (per PIM-SM RFC 7761). To minimize denial-of-service risk from forged PIM Joins with Explicit RPF Vector stacks, the feature should be used only within a single trusted management domain.
The Explicit RPF Vector Attribute TLV has a 1-byte field containing F bit (transitive, MUST be 0), E bit (end of attributes), and 6-bit Type (value 4); followed by a 1-byte Length and a variable-length Value carrying an Encoded-Unicast address (IPv4 or IPv6).