Anycast-RP Using Protocol Independent Multicast (PIM)
Extracted elements (20)
Anycast-RP has traditionally required MSDP for source discovery across RPs. This specification extends the PIM Register mechanism to replicate Register messages among Anycast-RP set members, eliminating the MSDP dependency for intra-domain Anycast-RP.
Physical RP failover is as fast as unicast routing convergence because DRs and receivers always send to the Anycast-RP address, which routes to the nearest surviving RP. This retains the core convergence benefit of traditional Anycast-RP.
Rate-limiting of Register and Register-Stop messages is performed end-to-end (DR→RP1→{RP2,RP3}); no additional rate-limiting logic between the RPs is required because the existing per-hop rate limiting in RFC 4601 is sufficient.
The number of RPs in the Anycast-RP set should remain small to keep the amount of non-native (unicast-encapsulated) Register replication to a minimum, since each source registration is replicated to all set members.
A source is considered internal to a domain when discovered by an Anycast-RP through a received Register message, regardless of whether that Register was sent by a DR, another Anycast-RP, or the router itself.
An RP that does not support this specification can coexist with supporting RPs, but it must not receive registrations from DRs (i.e., should not be a closest-RP for any DR). Receivers may still join to it, and it will receive Register copies from supporting RPs.
When Anycast-PIM is used as a stub domain, MSDP peering may still be needed for advertising internal sources externally and learning external sources. Multiple Anycast-RPs may originate Source-Active (SA) messages for the same internal source; configuration can limit which RPs perform external MSDP peering.
Within a routing domain, mixing Anycast-RP set membership with MSDP peering among those same members is not recommended, as it may obscure which sources are local versus external and complicate MSDP SA advertisement.
An implementation MAY suppress sending Register-Stop messages in response to a Register received from another RP in the Anycast-RP set. Register-Stop processing is otherwise unchanged from RFC 4601.
An RP MUST NOT forward a copy of a Register to other RPs if the Register was received from an IP address that is in the Anycast-RP list (i.e., it originated from another RP, not a DR), preventing forwarding loops.
An RP MUST safeguard against inconsistently configured Anycast-RP sets by copying the TTL from a received Register message into the Register copies it forwards to other RPs in the set.
An RP that receives a Register from a DR MUST create (S,G) state. It MAY join back to the source-tree by triggering an (S,G) Join toward the source, but state creation is mandatory regardless.
If the received Register message is not addressed to the Anycast-RP address, an error has occurred and it SHOULD be rate-limited logged.
Null Registers (Registers with an IP header and no IP payload) MUST be replicated to all RPs in the Anycast-RP set so that source state remains alive for active sources.
The Anycast-RP set is configured with a shared unicast RP address (RPA) injected into the unicast routing system, plus a separate per-router IP address used exclusively for inter-RP Register forwarding. Each RP in the set must be configured with the addresses of all other RPs in the set.
When an RP receives a PIM Register message from a DR (i.e., from an address not in the Anycast-RP list), it decapsulates the packet, forwards it down its shared-tree, and sends a copy of the Register to every other RP in the Anycast-RP set using its own unicast IP address as the source.
An attacker may forge a Register message using an address from the Anycast-RP list to: (1) overwhelm the target RP in a DoS attack, (2) inject unauthorized data to receivers, or (3) inject bogus SA entries into external MSDP domains if the RP has external MSDP peerings.
An attacker may forge a Register-Stop message using an Anycast-RP address; impact beyond DoS is limited because RPs typically ignore Register-Stop messages. The DoS attack via forged Register or Register-Stop cannot be fully prevented, but the RP can rate-limit incoming messages or refuse to process Register-Stops.
An RP can be configured with a unique SA and SPI per Anycast-RP peer, but this creates a key management burden. For domains under single administrative control, it is preferable to use the same authentication algorithm parameters (including the key) for all registered packets domain-wide.
Unauthorized data injection and bogus Register messages can be prevented using the IPsec authentication method described in RFC 4601 section 6.3.2. When RP1 forwards a Register copy to RP2, RP1 acts as the DR and RP2 acts as the RP for purposes of that authentication.