Summary

  • RFC 9798 permits a receiver ETR to put a multicast address in the Receiver RLOC field only when the LISP core underlay supports multicast; the ETR's group choice is local and outside the RFC's allocation scope.
  • The root ITR creates one outgoing-interface-list entry for every unique underlay mapping. If it needs an ETR list, it uses the Join/Prune source address, which must be an ETR RLOC—not the multicast group value.
  • Authentication can help validate a join request, but group authority, underlay capability, receiver presence, forwarding and delivery still require their own evidence.

The group answers the wrong counting question

Suppose a root ITR receives a LISP-carried PIM Join/Prune with Transport set to multicast and a multicast Receiver RLOC. How many receivers has it learned?

The tempting answer is the number of members implied by the group. The protocol answer is none. The field names an underlay group on which the receiver ETR wishes to receive the encapsulated flow. It is a delivery request, not an inventory. RFC 9798 says that, when the ITR needs to track ETRs that sent joins, it must use the source IP address of the incoming Join/Prune; that source must itself be an ETR RLOC.

That distinction matters because one group can aggregate several overlay flows, and one overlay flow can be realised by several underlay groups. Counting groups does not count ETRs. Counting Join messages without stable source identity does not count active receiver sites. Counting OIF entries does not count delivered packets.

RFC 9798 is an Experimental RFC published in June 2025. It updates RFC 8059, but only for the case where the existing Transport Attribute equals zero, meaning multicast. It changes neither that attribute's syntax nor its semantics. Instead, it broadens the Receiver RLOC definition: a unicast address remains the destination for unicast encapsulation; a multicast address can be used for multicast encapsulation, and only when the LISP core underlay supports IP multicast transport.

The last condition is a protocol requirement, not a remote attestation system. The RFC does not define how a root proves the receiver's claim about underlay support. It assigns the next decision locally: the ETR chooses an underlay multicast group it can join, identifies the upstream LISP site where the tree must be rooted, and constructs the Join/Prune as RFC 8059 specifies. A deployment therefore needs to retain the local policy, capability observation or configuration that justified “can join”; the group value alone cannot carry it.

Mapping cardinality moves cost

RFC 6831 supplies the underlying architecture. Multicast state inside LISP sites is expressed with EIDs; the core can use RLOC-rooted state. The ITR encapsulates site traffic, and core multicast can perform fan-out before receiver ETRs decapsulate and consult their inner (S-EID,G) state.

RFC 9798 makes the overlay-to-underlay group choice explicit with three cardinalities:

  1. many (root-EID,G) flows may share one (root-RLOC,G-u) underlay flow;
  2. one overlay flow may use two or more underlay flows for different downstream xTR requirements;
  3. one overlay flow may have one unique underlay flow.

None is free. Many-to-one economises on core multicast state, but RFC 6831 explains the leakage mechanism: when different source flows share one core tree, a receiver site can receive encapsulated traffic for a source it did not join and discard it only after decapsulation. One-to-many can respect different downstream group ranges but moves work toward the root. One-to-one sharpens isolation while consuming more mapping and forwarding state.

RFC 9798 assigns the root-side accounting unit cleanly. For every unique underlay multicast mapping in a received Join/Prune, the ITR allocates a new outgoing-interface-list entry. It may apply local policy to rate-limit the number of copies it needs to make. That policy is also outside the RFC. The evidence needed for cost and service analysis is therefore the mapping identifier, OIF entry, requested copy count, admitted count and rate decision—not a generic claim that “multicast saved bandwidth”.

Range constraints make this operational rather than academic. Different subsets of xTRs consuming the same overlay stream may need distinct underlay multicast ranges. At a PxTR boundary, site-facing trees and the external LISP core may deliberately use different group ranges. Hardware limits may narrow the multicast addresses a platform can support. A useful control record binds each chosen group to the applicable range policy, boundary, platform capability and change epoch.

Attribute carriage is not capability discovery

RFC 5384 defines the generic PIM Join Attribute envelope. It warns that tree-affecting attributes are useful only in a cooperating scope where routers are known in advance to understand the encoding and the attributes. Its ordinary PIM mechanism uses a Hello option to avoid sending the special source encoding to an incapable neighbour.

The LISP case has a sharper seam. RFC 8059 says xTRs do not exchange PIM Hellos, defines no Hello negotiation for its attributes, and assumes systems supporting unicast head-end replication understand them. The Transport and Receiver RLOC attributes are non-transitive. RFC 9798 extends their use to multicast underlay without adding a capability-discovery protocol or a global group allocator.

This is consistent with a minimal initial specification: standardise the interoperable signal and leave genuinely local future decisions local. It also prevents the standard from being used as evidence it never promised. A parser accepting a type-6 attribute proves representation handling. A configured range proves operator intent. An OIF entry proves control state. A counter proves a running path saw packets. A receiver trace proves an outcome. Those layers should be linked, not collapsed.

Authentication narrows one uncertainty

RFC 8059 says Join Attributes inherit the security of the PIM packet and add no authenticity themselves. RFC 9798 identifies a concrete pressure point: numerous joins with different or overlapping groups can interfere with legitimate traffic or exhaust resources through replication. It says PIM authentication from RFC 5796 could validate requests, and suggests implementation tracking or configurable per-ETR-RLOC group ceilings.

“Could” is important. RFC 9798 does not mandate a new authorization system. RFC 5796 specifies IPsec-based protection for PIM-SM link-local messages and the keying and peer-authentication machinery around them. Where deployed correctly, that evidence can support a statement about message origin and integrity under a named security association. It cannot prove that the group was allocated to the sender, that every hop supports it, that receivers joined, or that data arrived.

A defensible receipt for each mapping therefore carries: exact Join/Prune bytes; parsed Transport and Receiver RLOC; authentication result and security-association identity, if any; packet source ETR RLOC; receiver-side group-selection policy; root site; mapping cardinality; OIF state; rate-limit result; core counters; decapsulation evidence; and receiver outcome. Each transition gets a time and correlation identifier. “Valid join” is too coarse.

Sources