The Locator/ID Separation Protocol (LISP) for Multicast Environments
draft-ietf-lisp-rfc6831bis-12
| Document | Type | Active Internet-Draft (lisp WG) | |
|---|---|---|---|
| Authors | Dino Farinacci , Vengada Prasad Govindan , David Meyer , John Zwiebel , Stig Venaas | ||
| Last updated | 2026-10-11 | ||
| Replaces | draft-farinacci-lisp-rfc6831bis | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews |
INTDIR Telechat review
(of
-07)
by Dave Thaler
Ready w/issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Luigi Iannone | ||
| Shepherd write-up | Show Last changed 2026-06-30 | ||
| IESG | IESG state | IESG Evaluation::AD Followup | |
| Action Holder | |||
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved. |
||
| Responsible AD | Jim Guichard | ||
| Send notices to | ggx@gigix.net | ||
| IANA | IANA review state | Version Changed - Review Needed |
draft-ietf-lisp-rfc6831bis-12
Network Working Group D. Farinacci
Internet-Draft lispers.net
Obsoletes: 6831 (if approved) V. Govindan
Intended status: Standards Track D. Meyer
Expires: 14 April 2027 J. Zwiebel
S. Venaas
Cisco Systems
11 October 2026
The Locator/ID Separation Protocol (LISP) for Multicast Environments
draft-ietf-lisp-rfc6831bis-12
Abstract
This document specifies the design for inter-domain multicast
overlays using the Locator/ID Separation Protocol (LISP) architecture
and protocols. The document specifies how LISP multicast overlays
operate over multicast and unicast underlays. The mechanisms in this
specification indicate how a signal-based approach using the PIM
protocol can be used to program LISP encapsulators with a replication
list in a locator-set, where the replication list can be a mix of
multicast and unicast locators. This document when approved
obsoletes RFC6831
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Farinacci, et al. Expires 14 April 2027 [Page 1]
Internet-Draft LISP for Multicast Environments October 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8
5. Source Addresses versus Group Addresses . . . . . . . . . . . 11
6. Locator Reachability Implications on LISP-Multicast . . . . . 12
7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . 13
7.1. PIM Join Attributes for LISP . . . . . . . . . . . . . . 15
8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . 15
8.1. Forwarding Procedures common to multicast and unicast
underlay . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1.1. ITR Forwarding Procedure . . . . . . . . . . . . . . 15
8.1.2. ETR Forwarding Procedure . . . . . . . . . . . . . . 15
8.2. Forwarding Procedures with multicast underlay . . . . . . 16
8.2.1. ITR Forwarding Procedure . . . . . . . . . . . . . . 16
8.2.2. ETR Forwarding Procedure . . . . . . . . . . . . . . 17
8.2.3. Replication Locations . . . . . . . . . . . . . . . . 17
8.3. Forwarding Procedures with unicast underlay . . . . . . . 18
8.3.1. ITR Forwarding Procedure . . . . . . . . . . . . . . 18
8.3.2. ETR Forwarding Procedure . . . . . . . . . . . . . . 18
9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 18
9.1. LISP and Non-LISP Mixed Sites . . . . . . . . . . . . . . 18
9.1.1. LISP Source Site to Non-LISP Receiver Sites . . . . . 19
9.1.2. Non-LISP Source Site to Non-LISP Receiver Sites . . . 21
9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 22
9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . 22
9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . 23
9.2. LISP Sites with Mixed Address Families . . . . . . . . . 23
10. Considerations When RP Addresses Are Embedded in Group
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
11. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 25
12. Operational Considerations . . . . . . . . . . . . . . . . . 26
12.1. Underlay related trade-Offs . . . . . . . . . . . . . . 26
12.2. Troubleshooting considerations . . . . . . . . . . . . . 26
13. Security Considerations . . . . . . . . . . . . . . . . . . . 26
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
Farinacci, et al. Expires 14 April 2027 [Page 2]
Internet-Draft LISP for Multicast Environments October 2026
16. Normative References . . . . . . . . . . . . . . . . . . . . 27
17. Informative References . . . . . . . . . . . . . . . . . . . 29
Appendix A. Changes since RFC6831 . . . . . . . . . . . . . . . 30
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 31
B.1. Changes to draft-ietf-lisp-rfc6831bis-03 . . . . . . . . 31
B.2. Changes to draft-ietf-lisp-rfc6831bis-03 . . . . . . . . 31
B.3. Changes to draft-ietf-lisp-rfc6831bis-02 . . . . . . . . 31
B.4. Changes to draft-ietf-lisp-rfc6831bis-01 . . . . . . . . 31
B.5. Changes to draft-ietf-lisp-rfc6831bis-00 . . . . . . . . 32
B.6. Changes to draft-farinacci-lisp-rfc6831bis-02 . . . . . . 32
B.7. Changes to draft-farinacci-lisp-rfc6831bis-01 . . . . . . 32
B.8. Changes to draft-farinacci-lisp-rfc6831bis-00 . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction
The Locator/ID Separation Protocol [RFC9300] architecture provides a
mechanism to separate out Identification and Location semantics from
the current definition of an IP address. By creating two namespaces,
an Endpoint ID (EID) namespace used by sites and a Routing Locator
(RLOC) namespace used by underlay routing, the underlay routing
infrastructure can scale by doing topological aggregation of routing
information.
Since LISP creates a new namespace, a mapping function must exist to
map a site's EID-Prefixes to its associated Locators. For unicast
packets, both the source address and destination address must be
mapped. For multicast packets, only the source address needs to be
mapped. The destination group address doesn't need to be mapped
because the semantics of an IPv4 or IPv6 group address are logical in
nature and not topology dependent. Therefore, this specification
focuses on mapping a source EID address of a multicast flow during
distribution tree setup and packet delivery.
This specification addresses the following scenarios:
1. How a multicast source host in a LISP site sends multicast
packets to receivers inside of its site as well as to receivers
in other sites that are LISP enabled.
Farinacci, et al. Expires 14 April 2027 [Page 3]
Internet-Draft LISP for Multicast Environments October 2026
2. How inter-domain (or between LISP sites) multicast distribution
trees are built and how forwarding of multicast packets leaving a
source site toward receivers sites is performed. While the
design principles of how such trees are built and maintained are
the same, there are some procedural differences based on whether
the underlay is unicast or multicast. The specifications of this
document are fully adherent to the recommendations outlined in
[RFC8815]. However, if a deployment choses to use PIM-ASM or
inter-domain multicast, the specification of this document allows
it.
3. What protocols are affected and what changes are required to such
multicast protocols.
4. How ASM-mode (Any Source Multicast) and SSM-mode (Single Source
Multicast) service models will operate.
5. How multicast packet flow will occur for multiple combinations of
LISP-enabled and non-LISP-enabled source and receiver sites. For
example:
a. How multicast packets from a source host in a LISP site are
sent to receivers in other sites when they are all non-LISP
sites.
b. How multicast packets from a source host in a LISP site are
sent to receivers in both LISP-enabled sites and non-LISP
sites.
c. How multicast packets from a source host in a non-LISP site
are sent to receivers in other sites when they are all LISP-
enabled sites.
d. How multicast packets from a source host in a non-LISP site
are sent to receivers in both LISP-enabled sites and non-LISP
sites.
This specification focuses on what changes are needed to the
multicast routing protocols to support LISP-Multicast as well as
other protocols used for inter-domain multicast, such as
Multiprotocol BGP (MP-BGP) [RFC4760]. The approach of this
specification requires no packet format changes to the protocols and
no operational procedural changes to the multicast infrastructure
inside of a site when all sources and receivers reside in that site,
even when the site is LISP enabled. That is, internal operation of
multicast is unchanged, regardless of whether or not the site is LISP
enabled or whether or not receivers exist in other sites that are
LISP enabled.
Farinacci, et al. Expires 14 April 2027 [Page 4]
Internet-Draft LISP for Multicast Environments October 2026
Therefore, there are only operational (and not protocol) changes for
PIM-ASM [RFC7761], Multicast Source Discovery Protocol (MSDP)
[RFC3618], Anycast-RP [RFC4610], and PIM-SSM [RFC4607]. BIDIR-PIM
[RFC5015], which typically does not run in an inter-domain
environment, is not addressed in this document.
The scope of this document does not cover multicast-based Traffic
Engineering (TE) relative to the TE-ITR (TE-based Ingress Tunnel
Router) and TE-ETR (TE-based Egress Tunnel Router) descriptions in
[RFC9300]. Similarly, specifying the detailed behavior for multicast
Proxy-ITRs (mPITRs) (Section 9.1.3), mtrace (Section 11), and locator
reachability (Section 6) is outside the scope of this document.
Deployment experiences of LISP Multicast over both unicast and
multicast underlays have been documented
[I-D.ietf-lisp-multicast-deploy].
This document obsoletes [RFC6831], please see Appendix A for changes.
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Definition of Terms
The terminology in this section is consistent with the definitions in
[RFC9300] but is extended specifically to deal with the application
of the terminology to multicast routing.
LISP-Multicast: a reference to the design in this specification.
That is, when any site that is participating in multicast
communication has been upgraded to be a LISP site, the operation
of control-plane and data-plane protocols is considered part of
the LISP-Multicast architecture.
Endpoint ID (EID): As defined in [RFC9300], a 32-bit (for IPv4) or
Farinacci, et al. Expires 14 April 2027 [Page 5]
Internet-Draft LISP for Multicast Environments October 2026
128-bit (for IPv6) value used in the source address field of the
first (most inner) LISP header of a multicast packet. The host
obtains a destination group address the same way it obtains one
today, as it would when it is a non-LISP site. The source EID is
obtained via existing mechanisms used to set a host's "local" IP
address. An EID is allocated to a host from an EID-Prefix block
associated with the site in which the host is located. An EID can
be used by a host to refer to another host, as when it joins an
SSM (S-EID,G) route using IGMP version 3 [RFC9776] or Multicast
Listener Discovery Version 2 [RFC9777] [RFC4604].
Routing Locator (RLOC): as defined in [RFC9300]
Ingress Tunnel Router (ITR): as defined in [RFC9300]. Additionally,
it is a router that accepts an IP multicast packet with a single
IP header (more precisely, an IP packet that does not contain a
LISP header). The router treats this "inner" IP destination
multicast address opaquely so it doesn't need to perform a map
lookup on the group address because it is topologically
insignificant. The router then prepends an "outer" IP header with
one of its globally routable RLOCs as the source address field.
This RLOC is known to other multicast receiver sites that have
used the mapping database to join a multicast tree for which the
ITR is the root. In general, an ITR receives IP packets from site
end-systems on one side and sends LISP-encapsulated multicast IP
packets out all external interfaces that have been joined.
An ITR would receive a multicast packet from a source inside of
its site when 1) it is on the path from the multicast source to
internally joined receivers, or 2) when it is on the path from the
multicast source to externally joined receivers.
Egress Tunnel Router (ETR): as defined in [RFC9300]. Additionally
it is a router that is on the path from a multicast source host in
another site to a multicast receiver in its own site. An ETR
accepts a PIM Join/Prune message from a site-internal PIM router
destined for the source's EID in the multicast source site. The
ETR maps the source EID in the Join/Prune message to an RLOC
address based on the EID-to-RLOC mapping. This sets up the ETR to
accept multicast encapsulated packets from the ITR in the source
multicast site. A multicast ETR decapsulates multicast
encapsulated packets and replicates them on interfaces leading to
internal receivers.
xTR: as defined in [RFC9300].
LISP Header: as defined in [RFC9300]. A LISP-encapsulated multicast
Farinacci, et al. Expires 14 April 2027 [Page 6]
Internet-Draft LISP for Multicast Environments October 2026
packet will have an "inner" header with the source EID in the
source field, an "outer" header with the source RLOC in the source
field, and the same globally unique group address in the
destination field of both the inner and outer header.
(S,G) State: the formal definition is in the PIM Sparse Mode
[RFC7761] specification. For this specification, the term is used
generally to refer to multicast state. Based on its topological
location, the (S,G) state that resides in routers can be either
(S-EID,G) state (at a location where the (S,G) state resides) or
(S-RLOC,G) state (in the Internet underlay).
(S-EID,G) State: refers to multicast state in multicast source and
receiver sites where S-EID is the IP address of the multicast
source host (its EID). An S-EID can appear in an IGMPv3 report,
an MSDP SA message or a PIM Join/Prune message that travels inside
of a site.
(S-RLOC,G) State: refers to multicast state in the underlay where S
is a source locator (the IP address of a multicast ITR) of a site
with a multicast source. The (S-RLOC,G) is mapped from the
(S-EID,G) entry by doing a mapping database lookup for the EID-
Prefix that S-EID maps to. An S-RLOC can appear in a PIM Join/
Prune message when it travels from an ETR to an ITR over the
Internet underlay.
uLISP Site: a unicast-only LISP site according to [RFC9300] that has
not deployed the procedures of this specification and, therefore,
for multicast purposes, follows the procedures from Section 9. A
uLISP site can be a traditional multicast site.
LISP Site: as defined in [RFC9300], a unicast LISP site (uLISP Site)
that is also multicast capable according to the procedures in this
specification.
mPETR: this is a multicast proxy-ETR that is responsible for
advertising a very coarse EID-Prefix to which non-LISP and uLISP
sites can target their (S-EID,G) PIM Join/Prune messages. mPETRs
are used so LISP source multicast sites can send multicast packets
using source addresses from the EID namespace. mPETRs act as
Proxy-ETRs for supporting multicast routing in a LISP
infrastructure. It is likely a unicast PITR [RFC6832] hereafter
referred to as uPITR in this document and an mPETR will be co-
located since the single device advertises a coarse EID-Prefix in
the underlying unicast routing system.
Mixed Locator-Sets: this is a Locator-Set for a LISP database
Farinacci, et al. Expires 14 April 2027 [Page 7]
Internet-Draft LISP for Multicast Environments October 2026
mapping entry where the RLOC addresses in the Locator-Set are in
both IPv4 and IPv6 format.
Unicast LISP Encapsulated PIM Join/Prune Message: this is a standard
PIM Join/Prune message (LISP-encapsulated with destination UDP
port 4341) that is sent by ETRs at multicast receiver sites to an
ITR at a multicast source site. This message is sent periodically
as long as there are interfaces in the OIF-list for the (S-EID,G)
entry for which the ETR is joining. A multicast ETR LISP
encapsulates PIM Join/Prune messages so PIM signalling is achieved
between the ETR and ITR.
OIF-list: this is [RFC7761] notation to describe the outgoing
interface list a multicast router stores per multicast routing
table entry so it knows on which interfaces to replicate multicast
packets.
RPF: Reverse Path Forwarding is a procedure used by multicast
routers as described in [RFC7761]. A router will accept a
multicast packet for forwarding if the packet was received on the
path that the router would use to forward unicast packets to the
multicast packet's source.
4. Theory of Operation
LISP, when used for unicast routing, increases the site's ability to
control ingress traffic flows. Egress traffic flows are controlled
by the IGP in the source site. For multicast, the IGP coupled with
PIM SHOULD decide which path multicast packets ingress. By using the
Traffic Engineering features of LISP [RFC9300], a multicast source
site MAY control the egress of its multicast traffic. By controlling
the priorities of Locators from a mapping database entry, a source
multicast site SHOULD control which way multicast receiver sites join
to the source site.
The fundamental multicast forwarding model MUST encapsulate a
multicast packet into another multicast packet or a unicast packet.
An ITR MUST encapsulate multicast packets received from sources that
it serves in a LISP-Multicast header. The destination group address
from the inner header MAY be copied to the destination address of the
outer header. Alternately, the destination address of the outer
header MAY be the RLOC of the ETR. The inner source address MUST be
the EID of the multicast source host and the outer source address
MUST be the RLOC of the encapsulating ITR.
The LISP-Multicast architecture will follow this high-level protocol
and operational sequence:
Farinacci, et al. Expires 14 April 2027 [Page 8]
Internet-Draft LISP for Multicast Environments October 2026
1. Receiver hosts in multicast sites will join multicast content
the way they do today -- they use IGMP/ MLD. When they use
IGMPv3/ MLDv2 where they specify source addresses, they use
source EIDs; that is, they join (S-EID,G). If the multicast
source is external to this receiver site, the PIM Join/Prune
message flows toward the ETRs.
2. The ETR MUST do a mapping database lookup for S-EID. If the
mapping is cached from a previous lookup (from either a previous
Join/Prune for the source multicast site or a unicast packet
that went to the site), it MUST use the RLOC information from
the mapping. The ETR MAY use the same priority and weighting
mechanism as for unicast. So, the source site can decide which
way multicast packets egress similar to the way unicast packets
flow.
3. All LISP sites should be provisioned with the underlay they must
use. Other methods of selecting the underlay are outside the
scope of this specificaiton.
4. When using a multicast underlay, the ETR MUST build two PIM
Join/Prune messages, one that contains an (S-EID,G) entry that
is unicast to the ITR that matches the RLOC the ETR selects, and
the other that contains an (S-RLOC,G) entry so the underlay
network can create multicast state from this ETR to the ITR.
5. When using a unicast underlay, the ETR MUST build one PIM Join/
Prune message, one that contains an (S-EID,G) entry that is
unicast to the ITR that matches the RLOC the ETR selects. This
PIM Join/ Prune message contains enough information to help the
ITR build ingress-replicated unicast trees.
6. When the ITR gets the unicast Join/Prune message (see Section 3
for formal definition), it will process (S-EID,G) entries in the
message and propagate them inside of the site where it has
explicit routing information for EIDs via the IGP.
7. When using the multicast underlay the ITR receives the
(S-RLOC,G) PIM Join/Prune message, it MUST process it like any
other join it would get in today's Internet. The S-RLOC address
is the IP address of this ITR.
8. When using the unicast underlay the ITR MAY create an explicitly
tracked list of unicast RLOC addresses that have joined the
tree. This information is used for ingress-replication.
Farinacci, et al. Expires 14 April 2027 [Page 9]
Internet-Draft LISP for Multicast Environments October 2026
9. The creation, refresh, timeout and removal of the receiver-ETR
RLOC entries tracked by the ITR follow the PIM Join/Prune state
rules of [RFC7761] as extended by the attributes in
[I-D.ietf-pim-rfc8059-9798bis]; this document specifies no
additional state machinery.
10. At this point, there is (S-EID,G) state from the joining host in
the receiver multicast site to the ETR of the receiver multicast
site. There is (S-RLOC,G) state across the underlay network
from the ETR of the multicast receiver site to the ITR in the
multicast source site and (S-EID,G) state in the source
multicast site. Note, the (S-EID,G) state is the same S-EID in
each multicast site. As other ETRs join the same multicast
tree, they can join through the same ITR (in which case the
packet replication is done in the underlay) or a different ITR
(in which case the packet replication is done at the source
site).
11. When a packet is originated by the multicast host in the source
site, the packet will flow to one or more ITRs that will prepend
a LISP header.
12. For the unicast underlay, the ITR MUST make individual copies
for every ETR, the outer destination MUST be set to the receiver
RLOC's ETR and the outer source address MUST be set to the
S-RLOC of the ITR.
13. For the multicast underlay, the ITR MAY copy the group address
to the outer destination address field, the ITR MUST insert its
own locator address in the outer source address field. The ITR
will look at its (S-RLOC,G) state, where S-RLOC is its own
locator address, and replicate the packet on each interface on
which an (S-RLOC,G) join was received. The underlay has
(S-RLOC,G) so where fan-out occurs to multiple sites, a underlay
router will do packet replication.
14. When either the source site or the underlay replicates the
packet, the ETR will receive a LISP packet with a destination
group address. It MUST decapsulate packets because it has
receivers for the group. Otherwise, it would not have received
the packets because it would not have joined. The ETR
decapsulates and does an (S-EID,G) lookup in its multicast
Forwarding Information Base (FIB) to forward packets out one or
more interfaces to forward the packet to internal receivers.
This architecture is consistent and scalable with the architecture
presented in [RFC9300] where multicast state in the underlay operates
on Locators, and multicast state at the sites operates on EIDs.
Farinacci, et al. Expires 14 April 2027 [Page 10]
Internet-Draft LISP for Multicast Environments October 2026
Alternatively, [RFC9300] also has a mechanism where (S-EID,G) state
can reside in the underlay through the use of RPF Vectors [RFC5496]
in PIM Join/Prune messages. However, few PIM implementations support
RPF Vectors, and LISP should avoid S-EID state in the underlay. See
Section 5 for details.
However, some observations can be made on the algorithm above. The
control plane can scale but at the expense of sending data to sites
that may have not joined the distribution tree where the encapsulated
data is being delivered. For example, one site joins (S-EID1,G), and
another site joins (S-EID2,G). Both EIDs are in the same multicast
source site. Both multicast receiver sites join to the same ITR with
state (S-RLOC,G) where S-RLOC is the RLOC for the ITR. The ITR joins
both (S-EID1,G) and (S-EID2,G) inside of the site. The ITR receives
(S-RLOC,G) joins and populates the OIF-list state for the (S-RLOC,G)
entry. Since both (S-EID1,G) and (S-EID2, G) map to the one
(S-RLOC,G), packets will be delivered by the underlay to both
multicast receiver sites even though each have joined a single
source-based distribution tree. This behavior is a consequence of
the many-to-one mapping between S-EIDs and a S-RLOC.
There is a possible solution to this problem that reduces the number
of many-to-one occurrences of (S-EID,G) entries aggregating into a
single (S-RLOC,G) entry. If a physical ITR can be assigned multiple
RLOC addresses and these addresses are advertised in mapping database
entries, then ETRs at receiver sites have more RLOC address options
and therefore can join different (RLOC,G) entries for each (S-EID,G)
entry joined at the receiver site. It would not scale to have a one-
to-one relationship between the number of S-EID sources at a source
site and the number of RLOCs assigned to all ITRs at the site, but
"n" can reduce to a smaller number in the "n-to-1" relationship. And
in turn, this reduces the opportunity for data packets to be
delivered to sites for groups not joined.
5. Source Addresses versus Group Addresses
Section 14 of [RFC9300] provides the background about multicast group
address act as both EID and RLOC
As for source addresses, as in the unicast LISP scenario, there is a
decoupling of identification from location. In a LISP site, packets
are originated from hosts using their allocated EIDs. EID addresses
MUST be used to identify the host as well as where in the site's
topology the host resides but not how and where it is attached to the
Internet.
Farinacci, et al. Expires 14 April 2027 [Page 11]
Internet-Draft LISP for Multicast Environments October 2026
Therefore, when multicast distribution tree state is created anywhere
in the network on the path from any multicast receiver to a multicast
source, EID state MUST be maintained at the source and receiver
multicast sites, and RLOC state MUST be maintained in the underlay.
When using a multicast underlay, a multicast distribution tree will
be represented as a 3-tuple of {(S-EID,G) (S-RLOC,G) (S-EID,G)},
where the first element of the 3-tuple is the state stored in routers
from the source to one or more ITRs in the source multicast site; the
second element of the 3-tuple is the state stored in routers
downstream of the ITR, in the underlay, to all LISP receiver
multicast sites; and the third element in the 3-tuple is the state
stored in the routers downstream of each ETR, in each receiver
multicast site, reaching each receiver. Note that (S-EID,G) is the
same in both the source and receiver multicast sites. The
concatenation/mapping from the first element to the second element of
the 3-tuples is done by the ITR, and from the second element to the
third element is done at the ETRs.
When using a unicast underlay, a multicast distribution tree MUST be
represented with {(S-EID, G)}.
6. Locator Reachability Implications on LISP-Multicast
Multicast state as it is stored in the underlay is either (S,G) state
for sources in non-LISP sites or (RLOC,G) state for sources in LISP
sites. The underlay routers cannot distinguish one from the other.
They don't need to because it is state that uses RPF against the
underlay routing tables in the RLOC namespace. The difference is
where the root of the distribution tree for a particular source is.
In the traditional multicast underlay, the source S is the source
host's IP address. For LISP-Multicast, the source S is a single ITR
of the multicast source site.
An ITR is selected based on the LISP EID-to-RLOC mapping used when an
ETR propagates a PIM Join/Prune message out of a receiver multicast
site. The selection is based on the same algorithm an ITR would use
to select an ETR when sending a unicast packet to the site. In the
unicast case, the ITR can change on a per-packet basis depending on
the reachability of the ETR. So, an ITR can change relatively easily
using local reachability state. However, in the multicast case, when
an ITR becomes unreachable, new distribution tree state must be built
because the encapsulating root has changed. This is more significant
than an RPF-change event, where any router would typically locally
change its RPF-interface for its existing tree state. But when an
encapsulating LISP-Multicast ITR goes unreachable, new distribution
state MUST be built and reflect the new encapsulator. Therefore,
when an ITR goes unreachable, all ETRs that are currently joined to
Farinacci, et al. Expires 14 April 2027 [Page 12]
Internet-Draft LISP for Multicast Environments October 2026
that ITR MUST trigger a new Join/Prune message for (S-RLOC,G) to the
new ITR and MUST send a unicast encapsulated Join/Prune message
telling the new ITR which (S-EID,G) is being joined.
This issue can be mitigated by using anycast addressing for the ITRs,
so the problem does reduce to an RPF change in the underlay, but
still requires a unicast encapsulated Join/Prune message to tell the
new ITR about (S-EID,G). The problem with this approach is that the
ETR really doesn't know when the ITR has changed, so the new anycast
ITR will get the (S-EID,G) state only when the ETR sends it the next
time during its periodic sending procedures.
7. Multicast Protocol Changes
A number of protocols are used today for inter-domain multicast
routing:
IGMPv3, MLDv2: These protocols [RFC9776] [RFC9777] [RFC4604] do not
require any changes for LISP-Multicast for two reasons. One is
that they are link-local and not used over site boundaries, and
the second is that they advertise group addresses that don't need
translation. Where source addresses are supplied in IGMPv3 and
Multicast Listener Discovery version 2 (MLDv2) messages, they are
semantically regarded as EIDs and don't need to be converted to
RLOCs until the multicast tree-building protocol, such as PIM, is
received by the ETR at the site boundary. Addresses used for IGMP
and MLD come out of the source site's allocated addresses, which
are therefore from the EID namespace.
MBGP: Even though the Multiprotocol Extensions for BGP-4 (MBGP)
[RFC4760] are not part of a multicast routing protocol, they are
used to find multicast sources when the unicast BGP peering
topology and the multicast MBGP peering topology are not
congruent. When MBGP is used in a LISP-Multicast environment, the
prefixes that are advertised are from the RLOC namespace. This
allows receiver multicast sites to find a path to the source
multicast site's ITRs. MBGP peering addresses will be from the
RLOC namespace. There are no MBGP changes required to support
LISP-Multicast.
MSDP: MSDP [RFC3618] is used to announce active multicast sources to
other routing domains (or LISP sites). The announcements come
from the PIM Rendezvous Points (RPs) from sites where there are
active multicast sources sending to various groups. In the
context of LISP-Multicast, the source addresses advertised in MSDP
will semantically be from the EID namespace since they describe
the identity of a source multicast host. It will be true that the
state stored in MSDP caches from underlay routers will be from the
Farinacci, et al. Expires 14 April 2027 [Page 13]
Internet-Draft LISP for Multicast Environments October 2026
EID namespace. An RP address inside of the site will be from the
EID namespace so it can be advertised and reached by an internal
unicast routing mechanism. However, for MSDP peer-RPF checking to
work properly across sites, the RP addresses must be converted or
mapped into a routable address that is advertised and maintained
in the BGP routing tables in the underlay. MSDP peering addresses
can come out of either the EID or a routable address namespace.
Also, the choice can be made unilaterally because the ITR at the
site will determine which namespace the destination peer address
is out of by looking in the mapping database service. There are
no MSDP changes required to support LISP-Multicast. Since MSDP
was never extended to IPv6 [RFC8815], the scope of MSDP
considerations outlined in this document are limited to IPv4
addresses only.
PIM-SSM: In the simplest form of distribution tree building, when
PIM operates in SSM mode [RFC4607], a source distribution tree is
built and maintained across site boundaries. In this case, there
is a small modification to how PIM Join/Prune messages are sent by
the LISP-Multicast component. No modifications to any message
format, but to support taking a Join/Prune message originated
inside of a LISP site with embedded addresses from the EID
namespace and converting them to addresses from the RLOC namespace
when the Join/Prune message crosses a site boundary. This is
similar to the requirements documented in [RFC5135].
PIM-ASM: The ASM mode of PIM [RFC7761], the most popular form of
PIM, is deployed in the Internet today by having shared trees
within a site and using source trees across sites. By the use of
MSDP and PIM-SSM techniques described above, multicast
connectivity can occur across LISP sites. Having said that, that
means there are no special actions required for processing (*,G)
or (S,G,R) Join/Prune messages since they all operate against the
shared tree that is site resident. Just like with ASM, there is
no (*,G) in the underlay when LISP-Multicast is in use. This is
also true for the RP-mapping mechanisms Auto-RP and Bootstrap
Router (BSR) [RFC5059].
Based on the protocol description above, the conclusion is that there
are no protocol message format changes, just a translation function
performed at the control plane. This will make for an easier and
faster transition for LISP since fewer components in the network have
to change.
It should also be stated just like it is in [RFC9300] that no host
changes, whatsoever, are required to have a multicast source host
send multicast packets and for a multicast receiver host to receive
multicast packets.
Farinacci, et al. Expires 14 April 2027 [Page 14]
Internet-Draft LISP for Multicast Environments October 2026
7.1. PIM Join Attributes for LISP
The PIM Join/Prune attributes used to build multicast distribution
trees with either a multicast or a unicast underlay, including the
attribute by which a receiver site selects between them, are
specified in [I-D.ietf-pim-rfc8059-9798bis].
8. LISP-Multicast Data-Plane Architecture
The LISP-Multicast data-plane operation conforms to the operation and
packet formats specified in [RFC9300].
There is no Data-Probe logic for ETRs as there can be in the unicast
forwarding case.
8.1. Forwarding Procedures common to multicast and unicast underlay
8.1.1. ITR Forwarding Procedure
1. A multicast data packet sent by a host in a LISP site will have
the source address equal to the host's EID and the destination
address equal to the address of the multicast group. It is
assumed the group information is obtained by current methods.
The same is true for a multicast receiver to obtain the source
and group address of a multicast flow.
2. When the ITR receives a multicast packet, it will have both S-EID
state and S-RLOC state stored. Since the packet was received on
a site-facing interface, the RPF lookup is based on the S-EID
state. If the RPF check succeeds, then the OIF-list contains
interfaces that are site facing and external facing. For the
site-facing interfaces, no LISP header is prepended. For the
external-facing interfaces a LISP header is prepended.
8.1.2. ETR Forwarding Procedure
The following procedure is used by an ETR, when it receives a
multicast packet from a source outside of its site:
1. In the decapsulation case, the ETR removes the outer header and
performs a multicast routing table lookup on the inner header
(S-EID,G) addresses. Then, the OIF-list for the (S-EID,G) entry
is used to replicate the packet on site-facing interfaces leading
to multicast receiver hosts.
2. Note that there are RPF checks that need to be performed when
using a multicast underlay as described in the specific section
below.
Farinacci, et al. Expires 14 April 2027 [Page 15]
Internet-Draft LISP for Multicast Environments October 2026
8.2. Forwarding Procedures with multicast underlay
8.2.1. ITR Forwarding Procedure
The following procedure is used by an ITR, when it receives a
multicast packet from a source inside of its site in addition to the
common procedures:
1. When the ITR prepends a LISP header, it uses its own RLOC address
as the source address and copies the group address supplied by
the IP header that the host built as the outer destination
address.
2. The process is simpler for multicast because there is no EID-to-
RLOC mapping lookup performed during packet forwarding.
8.2.1.1. Multiple RLOCs for an ITR
Typically, an ITR will have a single RLOC address, but in some cases
there could be multiple RLOC addresses assigned from either the same
or different service providers. In this case, when (S-RLOC,G) Join/
Prune messages are received for each RLOC, there is a OIF-list
merging action that must take place. Therefore, when a packet is
received from a site-facing interface that matches on an (S-EID,G)
entry, the interfaces of the OIF-list from all (S-RLOC,G-u) entries
joined to the ITR as well as the site-facing OIF-list joined for
(S-EID,G) must be included in packet replication. In addition to
replicating for all types of OIF-lists, each OIF-list entry must be
tagged with the RLOC address, so encapsulation uses the outer source
address for the RLOC joined.
8.2.1.2. Multiple ITRs for a LISP Source Site
Note that when ETRs from different multicast receiver sites receive
(S-EID,G) joins, they may select a different S-RLOC for a multicast
source site due to policy (the multicast ITR can return different
multicast priority and weight values per ETR Map-Request [RFC9301]).
In this case, the same (S-EID,G) is being realized by different
(S-RLOC,G) state in the underlay. This will not result in duplicate
packets because each ITR in the multicast source site will choose
their own RLOC for the source address for encapsulated multicast
traffic. The RLOC addresses are the ones joined by remote multicast
ETRs.
When different (S-EID,G) traffic is combined into a single (RLOC,G)
underlay distribution tree, this may cause traffic to go to a
receiver multicast site when it does not need to. This happens when
one receiver multicast site joins (S1-EID,Gi) through a underlay
Farinacci, et al. Expires 14 April 2027 [Page 16]
Internet-Draft LISP for Multicast Environments October 2026
distribution tree of (RLOC1,Gi) and another multicast receiver site
joins (S2-EID,Gi) through the same underlay distribution tree of
(RLOC1,Gi). When ETRs decapsulate such traffic, they should know
from their local (S-EID,G) state if the packet should be forwarded.
If there is no (S-EID,G) state that matches the inner packet header,
the packet is discarded.
8.2.2. ETR Forwarding Procedure
The following procedure is used by an ETR, when it receives a
multicast packet from a source outside of its site:
1. When a multicast data packet is received by an ETR on an
external-facing interface, it will do an RPF lookup on the S-RLOC
state it has stored. If the RPF check succeeds, the interfaces
from the OIF-list are used for replication to interfaces that are
site facing as well as interfaces that are external facing (this
ETR can also be a transit multicast router for receivers outside
of its site). When the packet is to be replicated for an
external-facing interface, the LISP encapsulation header is not
stripped. When the packet is replicated for a site-facing
interface, the encapsulation header is stripped.
8.2.3. Replication Locations
Multicast packet replication can happen in the following topological
locations:
* In an IGP multicast router inside a site that operates on S-EIDs.
* In a transit multicast router inside of the underlay that operates
on S-RLOCs.
* At one or more ETR routers depending on the path a Join/Prune
message exits a receiver multicast site.
* At one or more ITR routers in a source multicast site depending on
what priorities are returned in a Map-Reply [RFC9301] to receiver
multicast sites.
In the last case, the source multicast site can do replication rather
than having a single exit from the site. But this can occur only
when the priorities in the Map-Reply are modified for different
receiver multicast sites so that the PIM Join/Prune messages arrive
at different ITRs.
Farinacci, et al. Expires 14 April 2027 [Page 17]
Internet-Draft LISP for Multicast Environments October 2026
This policy technique, also used in [RFC6836] for unicast, is useful
for multicast to mitigate the problems of changing distribution tree
state as discussed in Section 6.
8.3. Forwarding Procedures with unicast underlay
8.3.1. ITR Forwarding Procedure
The following procedure is used by an ITR, when it receives a
multicast packet from a source inside of its site in addition to the
common procedures:
* When the ITR prepends a LISP header, it uses its own RLOC address
as the source address and makes one copy for each ETR that has
expressed interest in the (S-EID, G). The outer destination IP
address is set to that of the corresponding RLOC from which the
PIM join was received
8.3.2. ETR Forwarding Procedure
When using a unicast underlay, an ETR MUST accept a unicast LISP-
encapsulated multicast packet only where the outer destination
address is one of its own RLOCs. Additionally, it MUST check whether
the outer source address is the ITR RLOC it selected for the
(S-EID,G) in question. It MUST discard the packet if the outer
destination and/ or source address checks fail.
9. LISP-Multicast Interworking
This section describes the multicast corollary to [RFC6832] regarding
the interworking of multicast routing among LISP and non-LISP sites.
9.1. LISP and Non-LISP Mixed Sites
Since multicast communication can involve more than two entities to
communicate together, the combinations of interworking scenarios are
more involved. However, the state maintained for distribution trees
at the sites is the same, regardless of whether or not the site is
LISP enabled. So, most of the implications are in the underlay with
respect to storing routable EID-Prefixes from either PA or PI blocks.
Before enumerating the multicast interworking scenarios, let's define
three deployment states of a site:
* A non-LISP site that will run PIM-SSM or PIM-ASM with MSDP as it
does today. The addresses for the site are globally routable.
Farinacci, et al. Expires 14 April 2027 [Page 18]
Internet-Draft LISP for Multicast Environments October 2026
* A site that deploys LISP for unicast routing. The addresses for
the site are not globally routable. Let's define the name for
this type of site as a uLISP site.
* A site that deploys LISP for both unicast and multicast routing.
The addresses for the site are not globally routable. Let's
define the name for this type of site as a LISP-Multicast site.
A LISP site enabled for multicast purposes only will not be
considered in this document, but a uLISP site as documented in
[RFC6832] will be considered. In this section there is no discussion
of how a LISP site sends multicast packets when all receiver sites
are LISP-Multicast enabled; that has been discussed in previous
sections.
The following scenarios exist to make LISP-Multicast sites interwork
with non-LISP-Multicast sites:
1. A LISP site must be able to send multicast packets to receiver
sites that are a mix of non-LISP sites and uLISP sites.
2. A non-LISP site must be able to send multicast packets to
receiver sites that are a mix of non-LISP sites and uLISP sites.
3. A non-LISP site must be able to send multicast packets to
receiver sites that are a mix of LISP sites, uLISP sites, and
non-LISP sites.
4. A uLISP site must be able to send multicast packets to receiver
sites that are a mix of LISP sites, uLISP sites, and non-LISP
sites.
5. A LISP site must be able to send multicast packets to receiver
sites which are a mix of LISP sites, uLISP sites, and non-LISP
sites.
9.1.1. LISP Source Site to Non-LISP Receiver Sites
In the first scenario, a site is LISP enabled for both unicast and
multicast traffic and as such operates on EIDs. Therefore, there is
a possibility that the EID-Prefix block is not routable in the
underlay. For LISP receiver multicast sites, this isn't a problem,
but for non-LISP or uLISP receiver multicast sites, when a PIM Join/
Prune message is received by the edge router, it has no route to
propagate the Join/Prune message out of the site. This is no
different than the unicast case that LISP Network Address Translation
(LISP-NAT) in [RFC6832] solves.
Farinacci, et al. Expires 14 April 2027 [Page 19]
Internet-Draft LISP for Multicast Environments October 2026
LISP-NAT allows a unicast packet that exits a LISP site to get its
source address mapped to a globally routable address before the ITR
realizes that it should not encapsulate the packet destined to a non-
LISP site. For a multicast packet to leave a LISP site, distribution
tree state needs to be built so the ITR can know where to send the
packet. So, the receiver multicast sites need to know about the
multicast source host by its routable address and not its EID
address. When this is the case, the routable address is the
(S-RLOC,G) state that is stored and maintained in the underlay
routers. It is important to note that the routable address for the
host cannot be the same as an RLOC for the site because it is
desirable for ITRs to process a PIM Join/Prune message that is
received from an external-facing interface. If the message will be
propagated inside of the site, the site-part of the distribution tree
is built.
Using a globally routable source address allows non-LISP and uLISP
multicast receivers to join, create, and maintain a multicast
distribution tree. However, the LISP-Multicast receiver site will
want to perform an EID-to-RLOC mapping table lookup when a PIM Join/
Prune message is received on a site-facing interface. It does this
because it wants to find an (S-RLOC,G) entry to Join in the underlay.
So, there is a conflict of behavior between the two types of sites.
The solution to this problem is the same as when an ITR wants to send
a unicast packet to a destination site but needs to determine if the
site is LISP enabled or not. When it is not LISP enabled, the ITR
does not encapsulate the packet. So, for the multicast case, when
the ETR receives a PIM Join/Prune message for (S-EID,G) state, it
will do a mapping table lookup on S-EID. In this case, S-EID is not
in the mapping database because the source multicast site is using a
routable address and not an EID-Prefix address. So, the ETR knows to
propagate the PIM Join/Prune message to an external-facing interface
without converting the (S-EID,G) because it is an (S,G), where S is
routable and reachable via underlay routing tables.
Now that the multicast distribution tree is built and maintained from
any non-LISP or uLISP receiver multicast site, the way the packet
forwarding model is used can be explained.
Since the ITR in the source multicast site has never received a
unicast encapsulated PIM Join/Prune message from any ETR in a
receiver multicast site, it knows there are no LISP-Multicast
receiver sites. Therefore, there is no need for the ITR to
encapsulate data. Since it will know a priori (via configuration)
that its site's EIDs are not routable (and not registered to the
mapping database system), it assumes that the multicast packets from
the source host are sent by a routable address. That is, it is the
Farinacci, et al. Expires 14 April 2027 [Page 20]
Internet-Draft LISP for Multicast Environments October 2026
responsibility of the multicast source host's system administrator to
ensure that the source host sends multicast traffic using a routable
source address. When this happens, the ITR acts as a router and
forwards the multicast packet like an ordinary multicast router.
There is an alternative to using a LISP-NAT scheme just as there is
an alternative to using unicast [RFC6832] forwarding by employing
Proxy Tunnel Routers (PxTRs). This can work the same way for
multicast routing as well, but the difference is that non-LISP and
uLISP sites will send PIM Join/Prune messages for (S-EID,G) that make
their way in the underlay to multicast PxTRs. Let's call this use of
a PxTR as a "Multicast Proxy-ETR" (or mPETR). Since the mPETRs
advertise very coarse EID-Prefixes, they draw the PIM Join/Prune
control traffic making them the target of the distribution tree. To
get multicast packets from the LISP source multicast sites, the tree
needs to be built on the path from the mPETR to the LISP source
multicast site. To make this happen, the mPETR acts as a "Proxy-ETR"
(where in unicast it acts as a "Proxy-ITR", or an uPITR [RFC6832]).
The existence of mPETRs in the underlay allows source multicast site
ITRs to encapsulate multicast packets according to (S-RLOC,G) state.
The (S-RLOC,G) state is built from the mPETRs to the multicast ITRs.
The encapsulated multicast packets are decapsulated by mPETRs and
then forwarded according to (S-EID,G) state. The (S-EID,G) state is
built from the non-LISP and uLISP receiver multicast sites to the
mPETRs.
9.1.2. Non-LISP Source Site to Non-LISP Receiver Sites
Clearly non-LISP-Multicast sites can send multicast packets to non-
LISP receiver multicast sites. That is what they do today. However,
discussion is required to show how non-LISP-Multicast sites send
multicast packets to uLISP receiver multicast sites.
Since uLISP receiver multicast sites are not targets of any (S,G)
state, they send (S,G) PIM Join/Prune messages toward the non-LISP
source multicast site. Since the source multicast site in this case
has not been upgraded to LISP, all multicast source host addresses
are routable. So, this case is simplified to where a uLISP receiver
multicast site appears to the source multicast site to be a non-LISP
receiver multicast site.
Farinacci, et al. Expires 14 April 2027 [Page 21]
Internet-Draft LISP for Multicast Environments October 2026
9.1.3. Non-LISP Source Site to Any Receiver Site
When a non-LISP source multicast site has receivers in either a non-
LISP/uLISP site or a LISP site, one needs to decide how the LISP
receiver multicast site will attach to the distribution tree. It is
known from Section 9.1.2 that non-LISP and uLISP receiver multicast
sites can join the distribution tree, but a LISP receiver multicast
site ETR will need to know if the source address of the multicast
source host is routable or not. It has been shown in Section 9.1.1
that an ETR, before it sends a PIM Join/Prune message on an external-
facing interface, does an EID-to-RLOC mapping lookup to determine if
it should convert the (S,G) state from a PIM Join/Prune message
received on a site-facing interface to an (S-RLOC,G). If the lookup
fails, or it receives a Negative Map-Reply, the ETR can conclude the
source multicast site is a non-LISP site, so it forwards the Join/
Prune message. (It also doesn't need to send a unicast encapsulated
Join/Prune message because there is no ITR in a non-LISP site and
there is namespace continuity between the ETR and source.)
9.1.4. Unicast LISP Source Site to Any Receiver Sites
In the last section, it was explained how an ETR in a multicast
receiver site can determine if a source multicast site is LISP
enabled by looking into the mapping database. When the source
multicast site is a uLISP site, it is LISP enabled, but the ITR, by
definition, is not capable of doing multicast encapsulation. So, for
the purposes of multicast routing, the uLISP source multicast site is
treated as a non-LISP source multicast site.
Non-LISP receiver multicast sites can join distribution trees to a
uLISP source multicast site since the source site behaves, from a
forwarding perspective, as a non-LISP source site. This is also the
case for a uLISP receiver multicast site since the ETR does not have
multicast functionality built-in or enabled.
Special considerations are required for LISP receiver multicast
sites; since they think the source multicast site is LISP enabled,
the ETR cannot know if the ITR is LISP-Multicast enabled. To solve
this problem, each mapping database entry will have a multicast
2-tuple (M Priority, M Weight) per RLOC [RFC9301]. The definition
and usage of the 2-tuple MUST be done in accordance to the procedure
defined in Sec 5.4 of [RFC9301] When the M Priority is set to 255,
the site is considered not multicast capable. So, an ETR in a LISP
receiver multicast site can distinguish whether a LISP source
multicast site is a LISP-Multicast site or a uLISP site.
Farinacci, et al. Expires 14 April 2027 [Page 22]
Internet-Draft LISP for Multicast Environments October 2026
9.1.5. LISP Source Site to Any Receiver Sites
When a LISP source multicast site has receivers in LISP, non-LISP,
and uLISP receiver multicast sites, it has a conflict about how it
sends multicast packets. The ITR can either encapsulate or natively
forward multicast packets. Since the receiver multicast sites are
heterogeneous in their behavior, one packet-forwarding mechanism
cannot satisfy both. However, if a LISP receiver multicast site acts
like a uLISP site, then it could receive packets like a non-LISP
receiver multicast site, thereby making all receiver multicast sites
have homogeneous behavior. However, this poses the following issues:
* LISP-NAT techniques with routable addresses would be required in
all cases.
* Or, alternatively, mPETR deployment would be required, thus
forcing coarse EID-Prefix advertisement in the underlay.
* But, what is most disturbing is that when all sites that
participate are LISP-Multicast sites but a non-LISP or uLISP site
joins the distribution tree, then the existing joined LISP
receiver multicast sites would have to change their behavior.
This would create too much dynamic tree-building churn to be a
viable alternative.
* In this case the LISP ITR in the source multicast site MUST send
two packets, one that is encapsulated with (S-RLOC,G) to reach
LISP receiver multicast sites and another that is not encapsulated
with (S-EID,G) to reach non-LISP and uLISP receiver multicast
sites.
9.2. LISP Sites with Mixed Address Families
A LISP database mapping entry that describes the Locator-Set, M
Priority, and M Weight per locator address (RLOC), for an EID-Prefix
associated with a site could have RLOC addresses in either IPv4 or
IPv6 format. When a mapping entry has a mix of RLOC-formatted
addresses, it is an implicit advertisement by the site that it is a
dual-stack site. That is, the site can receive IPv4 or IPv6 unicast
packets.
To determine whether a site can receive dual-stack multicast packets
in addition to dual-stack unicast packets, the M Priority value is
configured relative to an IPv4 or IPv6 RLOC (see [RFC9301] for packet
format details).
Farinacci, et al. Expires 14 April 2027 [Page 23]
Internet-Draft LISP for Multicast Environments October 2026
If one considers the combinations of LISP, non-LISP, and uLISP sites
sharing the same distribution tree and considering the capabilities
of supporting IPv4, IPv6, or dual-stack, the number of total
combinations grows significantly.
Some of the combinations that can occur are listed below:
1. LISP-Multicast IPv4 Site
2. LISP-Multicast IPv6 Site
3. LISP-Multicast Dual-Stack Site
4. uLISP IPv4 Site
5. uLISP IPv6 Site
6. uLISP Dual-Stack Site
7. non-LISP IPv4 Site
8. non-LISP IPv6 Site
9. non-LISP Dual-Stack Site
The above combinatorial gets even worse when one considers a site
using one address family inside of the site and the xTRs using the
other address family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6
EIDs with IPv4 RLOCs).
To rationalize this combinatorial expansion, there are some
guidelines that need to be put in place:
* Each distribution tree shared between sites will either be an IPv4
distribution tree or an IPv6 distribution tree. Therefore, head-
end replication can be avoided by building and sending packets on
each address-family-based distribution tree. Even though there
might be an urge to do multicast packet translation from one
address family format to the other, it is a non-viable over-
complicated urge. Multicast ITRs will only encapsulate packets
where the inner and outer headers are from the same address
family. Delivery of IPv4 multicast services to IPv4 clients over
an IPv6-only core network [RFC8114] is outside the scope of this
document.
* All LISP sites on a multicast distribution tree MUST share a
common address family that is determined by the source site's
Locator-Set in its LISP database mapping entry. All receiver
Farinacci, et al. Expires 14 April 2027 [Page 24]
Internet-Draft LISP for Multicast Environments October 2026
multicast sites will use the best RLOC priority controlled by the
source multicast site. This is true when the source site is
either LISP-Multicast or uLISP enabled. This means that priority-
based policy modification is prohibited. When a receiver
multicast site ETR receives an (S-EID,G) join, it must select a
S-RLOC for the same address family as S-EID.
* When a multicast Locator-Set has more than one locator, only
locators from the same address family MUST be set to the same best
priority value. A mixed Locator-Set can exist (for unicast use),
but the multicast priorities MUST be the set for the same address
family locators.
* When the source site is not LISP enabled, determining the address
family for the flow is up to how receivers find the source and
group information for a multicast flow.
10. Considerations When RP Addresses Are Embedded in Group Addresses
When ASM is used in an IPv6 inter-domain environment, a technique
exists to embed the unicast address of an RP in an IPv6 group address
[RFC3956]. When routers in end sites process a PIM Join/Prune
message that contains an Embedded-RP group address, they extract the
RP address from the group address and treat it from the EID
namespace. However, underlay routers do not have state for the EID
namespace and need to extract an RP address from the RLOC namespace.
Therefore, it is the responsibility of ETRs in multicast receiver
sites to map the group address into a group address where the
Embedded-RP address is from the RLOC namespace. The mapped RP
address is obtained from an EID-to-RLOC mapping database lookup. The
ETR will also send a unicast (*,G) Join/Prune message to the ITR so
the branch of the distribution tree from the source site resident RP
to the ITR is created.
This technique is no different than the techniques described in this
specification for translating (S,G) state and propagating Join/Prune
messages into the underlay. The only difference is that the (*,G)
state in Join/Prune messages are mapped because they contain unicast
addresses encoded in an Embedded-RP group address.
11. Mtrace Considerations
Mtrace version 2 [RFC8487] does not currently define behaviour for
LISP-Multicast environments. Defining it is left to future work.
Farinacci, et al. Expires 14 April 2027 [Page 25]
Internet-Draft LISP for Multicast Environments October 2026
12. Operational Considerations
This section provides operational and manageability considerations
for deploying LISP-Multicast in accordance with the recommendations
of [I-D.ietf.opsawg-rfc5706bis].
12.1. Underlay related trade-Offs
All LISP sites should be provisioned with the underlay they need to
use.
* When using a multicast underlay, packet replication occurs in the
core underlay routers using (S-RLOC,G) state. This minimizes
replication overhead at the ITR site. However, since multiple
(S-EID,G) entries can map to a single (S-RLOC,G) entry, data
packets may be delivered to receiver sites for groups they have
not joined. The ETR must use its local (S-EID,G) state to filter
and discard these unwanted packets.
* When using a unicast underlay, packet replication moves entirely
to the ITR. The ITR must maintain an explicitly tracked list of
unicast RLOC addresses and make individual encapsulated copies for
every interested ETR. This keeps the underlay core free of
multicast state but significantly increases CPU and memory
consumption on the ITR.
12.2. Troubleshooting considerations
Implementations should provide separate counters for native site-
facing packets, LISP-encapsulated data packets, and unicast
encapsulated PIM signaling messages.
13. Security Considerations
The security concerns for LISP-Multicast are mainly the same as for
the base LISP specification [RFC9300]. LISP-multicast security
concerns are the same as those for PIM [RFC7761].
There is a security concern with respect to unicast PIM messages,
when multiple receiver sites are joining an (S-EID1,G) distribution
tree that maps to a (RLOC1,G) underlay distribution tree, and a
malicious receiver site joins an (S-EID2,G) distribution tree that
also maps to the (RLOC1,G) underlay distribution tree, the legitimate
sites will receive data from S-EID2 when they did not ask for it.
Farinacci, et al. Expires 14 April 2027 [Page 26]
Internet-Draft LISP for Multicast Environments October 2026
Implementations SHOULD provide Non-cryptographic Authentication
Mechanisms deployed PIM [RFC7761] to mitigate risks of malicious
receivers causing unwanted multicast traffic sent to sites without
actual receivers.
Authentication of PIM messages can also be done using mechanisms
described in [RFC7761] to prevent denial-of-service attacks.
14. IANA Considerations
No requests are made to IANA
15. Acknowledgments
The authors would like to gratefully acknowledge the following
individuals for their contributions, discussions, ideas, commentary,
and expert reviews during the development of this document: Alia
Atlas, Dave Oran, Darren Dukes, Dimitri Papadimitriou, Eric Vyncke,
Greg Shepherd, Gorry Fairhurst, Gunter Van de Velde, IJsbrand
Wijnands, Jari Arkko, Jesus Arango, Ketan Talaulikar, Lenny Guardino,
Liming Wei, Luigi Iannone, Mahesh Jethanandani, Marshall Eubanks,
Mike McBride, Ron Bonica, Scott Brim, Steve Casner, Toerless Eckert,
Tom Pusateri, and Yiqun Cai.
The authors also thank the MBONED working group for their
constructive verbal feedback, and the Routing Research Group (RRG) of
the IRTF where this work originated.
16. Normative References
[I-D.ietf-pim-rfc8059-9798bis]
Govindan, V. P. and S. Venaas, "PIM Join Attributes for
Locator/ID Separation Protocol (LISP) Environments", Work
in Progress, Internet-Draft, draft-ietf-pim-
rfc8059-9798bis, 14 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-pim-
rfc8059-9798bis>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, DOI 10.17487/RFC3956, November 2004,
<https://www.rfc-editor.org/info/rfc3956>.
Farinacci, et al. Expires 14 April 2027 [Page 27]
Internet-Draft LISP for Multicast Environments October 2026
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
August 2006, <https://www.rfc-editor.org/info/rfc4604>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>.
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
Independent Multicast (PIM)", RFC 4610,
DOI 10.17487/RFC4610, August 2006,
<https://www.rfc-editor.org/info/rfc4610>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a
Network Address Translator (NAT) and a Network Address
Port Translator (NAPT)", BCP 135, RFC 5135,
DOI 10.17487/RFC5135, February 2008,
<https://www.rfc-editor.org/info/rfc5135>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2:
Traceroute Facility for IP Multicast", RFC 8487,
DOI 10.17487/RFC8487, October 2018,
<https://www.rfc-editor.org/info/rfc8487>.
[RFC8815] Iannone, L., Salgueiro, G., and R. Kevler, "Deprecating
Anycast Any-Source Multicast (ASM) for IPv4", BCP 233,
RFC 8815, DOI 10.17487/RFC8815, January 2021,
<https://www.rfc-editor.org/info/rfc8815>.
Farinacci, et al. Expires 14 April 2027 [Page 28]
Internet-Draft LISP for Multicast Environments October 2026
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>.
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
Ed., "Locator/ID Separation Protocol (LISP) Control
Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/info/rfc9301>.
[RFC9776] Haberman, B., Ed., "Internet Group Management Protocol,
Version 3", STD 100, RFC 9776, DOI 10.17487/RFC9776, March
2025, <https://www.rfc-editor.org/info/rfc9776>.
[RFC9777] Haberman, B., Ed., "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", STD 101, RFC 9777,
DOI 10.17487/RFC9777, March 2025,
<https://www.rfc-editor.org/info/rfc9777>.
17. Informative References
[I-D.ietf-lisp-multicast-deploy]
Govindan, V., "LISP Multicast Deployment Experience", Work
in Progress, Internet-Draft, draft-ietf-lisp-multicast-
deploy-00, 7 May 2026, <https://ietf.org>.
[I-D.ietf.opsawg-rfc5706bis]
Claise, B., Clarke, J., Farrel, A., Barguil, S.,
Pignataro, C., and R. Chen, "Guidelines for Considering
Operations and Management in IETF Specifications", Work in
Progress, Internet-Draft, draft-ietf-opsawg-rfc5706bis-09,
6 October 2026, <https://ietf.org>.
[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
Discovery Protocol (MSDP)", RFC 3618,
DOI 10.17487/RFC3618, October 2003,
<https://www.rfc-editor.org/info/rfc3618>.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<https://www.rfc-editor.org/info/rfc5015>.
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
"Bootstrap Router (BSR) Mechanism for Protocol Independent
Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January
2008, <https://www.rfc-editor.org/info/rfc5059>.
Farinacci, et al. Expires 14 April 2027 [Page 29]
Internet-Draft LISP for Multicast Environments October 2026
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496,
DOI 10.17487/RFC5496, March 2009,
<https://www.rfc-editor.org/info/rfc5496>.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, DOI 10.17487/RFC6831, January
2013, <https://www.rfc-editor.org/info/rfc6831>.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832,
DOI 10.17487/RFC6832, January 2013,
<https://www.rfc-editor.org/info/rfc6832>.
[RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Topology
(LISP+ALT)", RFC 6836, January 2013,
<https://www.rfc-editor.org/rfc/rfc6836>.
[RFC8114] Boucadair, M., Jacquenet, C., and R. Asati, "Delivery of
IPv4 Multicast Services to IPv4 Clients over an IPv6-Only
Access Network", RFC 8114, March 2017,
<https://www.rfc-editor.org/rfc/rfc8114>.
Appendix A. Changes since RFC6831
The major change since [RFC6831] is the inclusion of the Unicast
underlay. This has been specified in a manner that allows co-
existence with the multicast underlay specified in [RFC6831]. Other
important changes include:
1. Terminology modernization to maintain consistency with the
Standards track LISP RFCs
2. Narrowed scope to include only fully specified multicast modes
(PIM-ASM and SSM)
3. Referenced the latest PIM RFCs
4. Deferred MTRACE related specifications
5. Deferred mPITR related specifications
6. Formalized the specification of M Priority and M Weight
Farinacci, et al. Expires 14 April 2027 [Page 30]
Internet-Draft LISP for Multicast Environments October 2026
Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-rfc6831bis-03
* Posted Nov 2025.
* Address one missing comment from Dino
B.2. Changes to draft-ietf-lisp-rfc6831bis-03
* Posted Nov 2025.
* Update document for comments from Luigi as prep for wGLC.
B.3. Changes to draft-ietf-lisp-rfc6831bis-02
* Posted July 2025.
* Update document timer and references.
* Update Dave Meyer's email address.
B.4. Changes to draft-ietf-lisp-rfc6831bis-01
* Posted January 2025 (Mike McBride).
* Changed all instances of "core" to "underlay".
* Changed "we see" to "there are".
* Changed "RFC" to "document".
* Updated the Requirements Notation.
* Added a reference to RFC 7761 for the RPF definition.
* Removed part of a sentence "...the exit is chosen according to
routing policies..."
* Rephrased sentence to: "Multicast state as it is stored in the
core is either (S,G) state for sources in non-LISP sites or
(RLOC,G) state for sources in LISP sites."
* Added "...or it receives a Negative Map-Reply".
* Added a reference to RFC8487 for MTRACE.
Farinacci, et al. Expires 14 April 2027 [Page 31]
Internet-Draft LISP for Multicast Environments October 2026
* Moved a few downrefs that needed to be moved to the Informative
section.
* Added Mike and Stig to acknowledgements
B.5. Changes to draft-ietf-lisp-rfc6831bis-00
* Posted August 2024.
* Make draft-farinacci-lisp-rfc6831bis-02 working group document
draft-ietf-lisp-rfc6831bis-00.
B.6. Changes to draft-farinacci-lisp-rfc6831bis-02
* Posted May 2024 (Vengada Prasad Govindan).
* Added reference to RFC8059
B.7. Changes to draft-farinacci-lisp-rfc6831bis-01
* Posted May 2024 (Vengada Prasad Govindan).
* Add support for unicast underlay in signal-based approach
(RFC6831)
B.8. Changes to draft-farinacci-lisp-rfc6831bis-00
* Posted May 2024.
* Starting with [RFC6831] to move it to a bis document for standards
track.
* Changed references to standards track RFCs.
* Address comments from Prasad Govindan.
Authors' Addresses
Dino Farinacci
lispers.net
Email: farinacci@gmail.com
Vengada Prasad Govindan
Cisco Systems
Email: venggovi@cisco.com
Farinacci, et al. Expires 14 April 2027 [Page 32]
Internet-Draft LISP for Multicast Environments October 2026
Dave Meyer
Cisco Systems
Tasman Drive
San Jose, CA
United States of America
Email: dmm613@gmail.com
John Zwiebel
Cisco Systems
Tasman Drive
San Jose, CA
United States of America
Email: jzwiebel@cruzio.com
Stig Venaas
Cisco Systems
Tasman Drive
San Jose, CA
United States of America
Email: stig@cisco.com
Farinacci, et al. Expires 14 April 2027 [Page 33]