



Network Working Group                                          V. Moreno
Internet-Draft                                                Google LLC
Intended status: Experimental                               D. Farinacci
Expires: 7 November 2026                                     lispers.net
                                                              6 May 2026


                  LISP Virtual Private Networks (VPNs)
                         draft-ietf-lisp-vpn-14

Abstract

   This document describes the use of the Locator/ID Separation Protocol
   (LISP) to create Virtual Private Networks (VPNs).  LISP is used to
   provide segmentation in both the LISP data plane and control plane.
   These VPNs can be created over the top of the Internet or over
   private transport networks, and can be implemented by Enterprises or
   Service Providers.  The goal of these VPNs is to leverage the
   characteristics of LISP - routing scalability, simply expressed
   Ingress site TE Policy, IP Address Family traversal, and mobility, in
   ways that provide value to network operators.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


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 7 November 2026.






Moreno & Farinacci       Expires 7 November 2026                [Page 1]

Internet-Draft                  LISP VPN                        May 2026


Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
   3.  LISP Virtual Private Networks (VPNs)  . . . . . . . . . . . .   4
     3.1.  The LISP IID in the Control Plane . . . . . . . . . . . .   6
     3.2.  The LISP IID in the Data Plane  . . . . . . . . . . . . .   7
     3.3.  Locator Network Segmentation  . . . . . . . . . . . . . .   7
     3.4.  Multicast in LISP VPN environments  . . . . . . . . . . .   8
   4.  LISP VPN Extranet . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  LISP Extranet VPN Control Plane . . . . . . . . . . . . .   9
       4.1.1.  LISP Extranet VPN Map Register Procedures . . . . . .  10
       4.1.2.  LISP Extranet VPN Map Lookup Procedures . . . . . . .  10
       4.1.3.  LISP Extranet Publish/Subscribe Procedures  . . . . .  11
       4.1.4.  LISP Extranet VPN Home-IID encoding . . . . . . . . .  11
     4.2.  LISP Extranet VPN Data Plane  . . . . . . . . . . . . . .  12
     4.3.  LISP Extranet VPN Multicast Considerations  . . . . . . .  12
       4.3.1.  LISP Extranet VPN Multicast Control Plane . . . . . .  13
       4.3.2.  LISP Extranet VPN Multicast Data Plane  . . . . . . .  13
     4.4.  LISP Extranet SMR Considerations  . . . . . . . . . . . .  14
       4.4.1.  Home-IID inclusion in SMR messages  . . . . . . . . .  14
     4.5.  LISP Extranet RLOC Probing Considerations . . . . . . . .  14
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     5.1.  LISP VPNs and LISP Crypto . . . . . . . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17







Moreno & Farinacci       Expires 7 November 2026                [Page 2]

Internet-Draft                  LISP VPN                        May 2026


1.  Introduction

   Network virtualization creates multiple, logically separated
   topologies across one common physical infrastructure.  These
   logically separated topologies are known as Virtual Private Networks
   (VPNs) and are generally used to create closed groups of end-points.
   Network reachability within a VPN is restricted to the addresses of
   the end-points that are members of the VPN.  This level of
   segmentation is useful in providing fault isolation, enforcing
   access-control restrictions, enabling the use of a single network by
   multiple tenants and scoping network policy per VPN.

   LISP creates two namespaces: The End-point Identifier (EID) namespace
   and the Routing Locator (RLOC) namespace.  The LISP Mapping System
   maps EIDs to RLOCs.  Either the EID space, the RLOC space or both may
   be segmented.  The LISP Mapping System can be used to map a segmented
   EID address space to the RLOC space.  When the EID namespace is
   segmented, a LISP Instance-ID (IID) is encoded in both the data plane
   and the control plane to provide segmentation and to disambiguate
   overlapping EID Prefixes.  This allows multiple VRFs to 'share' a
   common Routing Locator network while maintaining EID prefix
   segmentation.

   LISP VPNs must support Multicast traffic in the EID space and must
   also support the ability to provide controlled reachability across
   VPNs which is commonly known as extranet functionality.  When data
   path security is needed, LISP virtualization can be combined with
   LISP Crypto to provide data path confidentiality, integrity, origin
   authentication and anti-replay protection.

2.  Definition of Terms

   LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel
   Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map-
   Resolver (MR) are defined in the LISP specification [RFC9300].

   Terms defining interactions with the LISP Mapping System are defined
   in [RFC9301].

   Terms related to the procedures for signal free multicast are defined
   in [RFC8378].

   The following terms are here defined to facilitate the descriptions
   and discussions within this particular document.







Moreno & Farinacci       Expires 7 November 2026                [Page 3]

Internet-Draft                  LISP VPN                        May 2026


   Forwarding Context - Logical segment of a device's forwarding table
   and its associated interfaces.  This is usually in the form of a VRF
   for IP forwarding, may also be in the form of a Bridge Domain or VLAN
   for MAC forwarding.

   Home-IID - In the context of cross VPN connectivity, a particular EID
   will be registered with multiple Instance-IDs, the Home-IID
   identifies the Instance-ID associated to the Forwarding Context (VRF)
   to which an EID is actually connected.

   Extranet-VPN - In the context of cross VPN connectivity, a VPN that
   is reachable by all Extranet-Subscriber-VPNs and can reach all
   Extranet-Subscriber-VPNs.

   Extranet-Subscriber-VPN - The VPNs that can reach the Extranet-VPN,
   but cannot reach each other.

   Extranet Policy - The definition of which VPNs share reachability
   information with each other in the context of cross VPN connectivity.
   May be structured as a group of Extranet-Subscriber-VPNs that
   subscribe to an Extranet-VPN.

3.  LISP Virtual Private Networks (VPNs)

   A LISP VPN is a collection of LISP Sites building an Overlay Network.
   These sites share a common control plane, the LISP Mapping System.
   The members of this VPN also share common RLOC connectivity, whether
   it be the Internet or a private IP network.

   Multiple LISP VPNs may run over a common RLOC space and many LISP
   VPNs may share one or more locations, requiring XTRs to service
   multiple VPNs simultaneously.

   VPNs must be allowed to have overlapping address space.  It is
   necessary to disambiguate the EID namespace in both the control and
   data plane as well as maintain forwarding segmentation within the
   XTRs.  The LISP Instance ID (IID) is used to provide a VPN wide
   unique identifier that can be used both in the control and data
   planes.

   The LISP Instance ID is a 32 bit unstructured namespace that
   identifies a LISP VPN.  The tuple of EID Prefix and IID is referred
   to as an Extended EID (XEID) [RFC8111].  The LISP IID is used in the
   data plane of the LISP header [RFC9300], as well as in the LISP
   control plane [RFC8060].

   An implementation should default to an Instance ID value equal to
   zero when LISP VPNs are not in use.



Moreno & Farinacci       Expires 7 November 2026                [Page 4]

Internet-Draft                  LISP VPN                        May 2026


   The operation of a LISP VPN is consistent with the operation of LISP
   in a non-VPN environment as defined in [RFC9300] and [RFC9301].  The
   operation of a LISP VPN is here described at a high level in terms of
   EID registrations, EID lookups and traffic forwarding:

   EID registration: In a LISP VPN, XTRs that are members of the VPN
   should be configured with a forwarding context (e.g. VRF) and the
   associated IID for the VPN.  Based on this configuration, the ETRs
   must register the EIDs within the forwarding context as Extended EIDs
   (IID+EID).  The LISP mapping system consolidates the registrations
   from all the ETRs in the VPN and builds a mapping database for the
   VPN.

   EID Lookup: ITRs that are members of the VPN will do forwarding
   lookups in the forwarding context where traffic was received.  Upon a
   cache miss within the forwarding context, the ITR must issue a Map-
   Request for the destination EID and include the VPN's IID.  This
   information must be encoded as an Extended EID (IID+EID) in the Map-
   Request issued.  The IID to associate with the EID in this Map-
   request is derived from the configuration of the VPN's forwarding
   context (in which the traffic was received).  The Mapping System
   should reply to the Map Request with a Mapping for the Extended EID
   (IID+EID), the IID of the Extended EID should be used to identify the
   forwarding context in which the Mapping received should be cached.

   Traffic Forwarding: Once a Mapping has been cached in the VPN's
   forwarding context, the ITR will encapsulate the traffic towards the
   RLOC in the mapping.  The IID corresponding to the VPN's forwarding
   context must be included in the Instance-ID field of the data plane
   header.  When the encapsulated traffic is received at the ETR the
   encapsulation header is removed and the IID received in the header is
   used to identify the forwarding context to use to do a forwarding
   lookup for the decapsulated traffic.

   A more formal description of the Control and Data Plane procedures
   for a LISP VPN is documented in the following sections.

   In order to create VPNs, the following segmentation functions must be
   provided:












Moreno & Farinacci       Expires 7 November 2026                [Page 5]

Internet-Draft                  LISP VPN                        May 2026


   *  Device Segmentation.  The forwarding tables of the devices must be
      segmented so that independent forwarding decisions can be made for
      each virtual network.  Virtual Routing and Forwarding (VRF)
      contexts may be used to create multiple instances of Layer 3
      routing tables virtualization (segmentation) at the device level.
      If the EID space is in a Layer 2 address family (e.g. MAC
      addresses), then Layer 2 contexts such as VLANs or bridge domains
      may be used to segment the device.  We generalize the concept of
      separate forwarding tables as forwarding contexts.

   *  Data Plane Segmentation.  Data Plane Forwarding separation is
      necessary for the devices to maintain virtual network semantics at
      forwarding time.  Data plane separation can be maintained across
      network paths using either single-hop path segmentation (hop-by-
      hop) or multi-hop path segmentation.  Single-hop path segmentation
      mechanisms include constructs such as 802.1q VLAN trunks, multi-
      hop mechanisms include MPLS, LISP, VXLAN and GRE tunnels.

   *  Control Plane Segmentation.  In order to correctly populate the
      multiple forwarding tables in the segmented network devices, the
      control plane needs to be segmented so that the different updates
      that are conveyed by the control plane contain the necessary
      virtual network semantics to discriminate between information
      relevant to one segment vs another.  Control plane segmentation is
      key to allowing sites to use overlapping network prefixes in these
      logically separate topologies.  BGP/MPLS VPNs (ref RFC 4364) are
      an example of this control plane segmentation.

3.1.  The LISP IID in the Control Plane

   In a LISP Mapping System supporting VPNs, EID Prefixes should be
   registered as Extended EID tuples of information that include the EID
   prefix as well as its corresponding Instance ID (IID) information.

   In a segmented LISP network, whenever an EID is present in a LISP
   message, the EID must be encoded as an extended EID using the
   Instance ID LCAF type defined in [RFC8060].  This includes all LISP
   messages pertinent to the EIDs in the segmented space, including, but
   not limited to, Map-Register, Map-Request, Map-Reply, Map-Notify,
   SMRs, etc.

   On EID registration by an ETR, the Map-Register message sent by the
   ETR must contain the corresponding IID encoded as part of the EID
   using the Instance ID LCAF type.

   On EID lookup, when an ITR issues a Map-Request, both the Map-Request
   message and the resulting Map-Reply must contain the IID for the EID
   encoded using the IID LCAF type.  The IID to use for a Map-Request



Moreno & Farinacci       Expires 7 November 2026                [Page 6]

Internet-Draft                  LISP VPN                        May 2026


   may be derived from the configuration of the ITR Ingress VRF.  The
   mappings received by an ITR in a Map-Reply should be cached in the
   VRF corresponding (by configuration) to the IID included in the Map-
   Reply message.

   The Mapping System must maintain the IID information that corresponds
   to any EIDs actively registered with the Mapping System.

3.2.  The LISP IID in the Data Plane

   A LISP xTR will map, by configuration, a LISP Instance ID to a given
   forwarding context in its EID namespace.  The Instance-ID must be
   included in the data plane header to allow an xTR to identify which
   VPN the packet belongs to when encapsulating or decapsulating LISP
   packets.  The LISP header [RFC9300] as well as the VXLAN header
   [RFC7348] reserve a 24 bit field for the purposes of encoding the
   Instance-ID (referred to as VNID in the VXLAN specification).

   LISP ITRs may receive non-encapsulated traffic on an interface that
   is associated with the forwarding context for a VPN (e.g. VRF).  A
   LISP ITR should do Map-cache lookups for the destination EID within
   the forwarding context in which it received the traffic.  The LISP
   ITR must encapsulate the traffic to the destination RLOC found in the
   map-cache and must include, in the header of the encapsulated packet,
   the IID associated with the forwarding context for the VPN.  In the
   event of a map-cache miss, the LISP ITR must issue a Map-request with
   the IID associated with the ITR Ingress VRF as described in
   Section 3.1.

   On receipt of an encapsulated LISP packet, a LISP ETR will deliver
   the decapsulated packets to the VRF associated with the IID received
   in the LISP header.  Standard routing lookups will then take place
   within the context of the VRF for the forwarding of the decapsulated
   packet towards its destination.

   The use of multiple IIDs on a single site xTR, each mapped to a
   different EID VRF allows for multiplexing of VPNs over a Locator
   network.

3.3.  Locator Network Segmentation

   This document has so far discussed virtualizing the LISP EID
   namespace, and communication between xTRs and the LISP Mapping
   System.  Implicit in this communication requirement is a network
   between these devices.  LISP VPNs do not require this underlay
   network connectivity to be in the "default" VRF, just that a a given
   LISP Site and its Mapping System be interconnected via a common VRF.




Moreno & Farinacci       Expires 7 November 2026                [Page 7]

Internet-Draft                  LISP VPN                        May 2026


   LISP xTRs may have connectivity to each other via multiple distinct
   VRFs, as in the case where the LISP VPN is being used to create an
   Overlay with multiple MPLS-VPN Service Providers being used as the
   transport.  In other words, the RLOC space may also be segmented, the
   segmentation of the RLOC space is not done by LISP, but the
   segmentation of the RLOC space is delivered by the routing protocols
   and data plane used by the RLOC space.  When the RLOC space is
   segmented, different EID segments may use different RLOC segments.
   An RLOC segment may service one or many EID segments, allowing a VPN
   in the RLOC space to service a subset of the VPNs created in the EID
   space.

3.4.  Multicast in LISP VPN environments

   Both Signaled and Signal Free Multicast within a VPN will operate
   without modification in VPN environments provided that all LISP
   control plane messages include the Instance ID for their VPN as
   specified in Section 3.  Multicast Source (S) state as well as
   multicast Group (G) state are both scoped within a VPN and therefore
   the values for S and G may be reused in other VPNs.

4.  LISP VPN Extranet

   In a multi-tenant network the communication between a shared VPN and
   a multitude of otherwise isolated VPNs is generally known as extranet
   communication.  Reachability is established between an shared
   Extranet-VPN and a multitude of Extranet-Subscriber-VPNs without
   enabling reachability between the different Extranet-Subscriber-VPNs.
   This section specifies the procedures and protocol encodings
   necessary to provide extranet functionality in a multi-instance LISP
   network.  The mechanisms described require cross VPN lookups and
   therefore assume that the EID space across all VPNs involved does not
   overlap or has been translated to a normalized space that resolves
   any overlaps.

   The operation of a LISP VPN Extranet is consistent with the operation
   of LISP VPNs as defined in Section 3.  The operation of a LISP VPN
   Extranet is here described at a high level in terms of EID
   registrations, EID lookups and traffic forwarding:

   EID Registration: EIDs in the Extranet-VPN should be registered in
   their Home-IID as well as in all other IIDs that are part of the
   Extranet scope.  EIDs in the Extranet-Subscriber-VPNs should be
   registered in their Home-IID and the Extranet-VPN's IID.  This makes
   the EIDs available for lookups in VPNs other than their Home-VPN.
   When an EID is registered in an IID that it does not belong to, the
   mapping should include a parameter containing the Home-IID for the
   EID.  As a result any EID that should be reachable based on the



Moreno & Farinacci       Expires 7 November 2026                [Page 8]

Internet-Draft                  LISP VPN                        May 2026


   Extranet configuration will be registered in every relevant VPN, if
   the EID is not native to that VPN, the mapping will have a parameter
   with the Home-IID for the EID.

   EID Lookup: Map-requests will be issued within the IID of the
   requesting VPN as specified in Section 3.  If the destination is
   across VPNs, the mapping for the destination EID should contain the
   EID's Home-IID as a parameter.  The mapping, including the Home-IID
   parameter is returned in a Map-Reply and cached by the ITR in the
   Forwarding Context of the requesting VPN.  The cache will include the
   destination's Home-IID as a parameter of the mapping.

   Traffic Forwarding: An ITR will encapsulate traffic to a cross VPN
   destination using the destination's Home-IID in the data plane
   header.  Upon decapsulation at the ETR, traffic is handed directly to
   the destination VPN's forwarding context based on the IID used in the
   header.

   A more formal description of the Control and Data Plane procedures
   for a LISP VPN Extranet is documented in the following sections.

4.1.  LISP Extranet VPN Control Plane

   In order to achieve reachability across VPNs, EID mapping entries in
   the Extranet-VPN must be accessible for lookups initiated from an
   Extranet-Subscriber-VPN and vice-versa.

   The definition of which VPNs share reachability information is
   governed by configurable Extranet Policy.  The Extranet Policy will
   simply state which VPNs are extranet-subscribers to a particular
   extranet-VPN.  There may be multiple Extranet-VPNs in a LISP network
   and a VPN may subscribe to multiple Extranet-VPNs.  An Extranet-
   subscriber-VPN may act as an Extranet-VPN to provide reachability
   across Extranet-subscriber-VPNs, this effectively merges the
   Extranet-subscriber-VPNs together, a scenario that is usually better
   achieved by creating a single Extranet-subscriber-VPN.

   The Instance-ID (IID) for the VPN to which an EID is connected is
   referred to as the Home-IID of the EID.  As cross VPN registrations
   and lookups take place, the Home-IID for an EID must be preserved and
   communicated in any pertinent LISP messages.










Moreno & Farinacci       Expires 7 November 2026                [Page 9]

Internet-Draft                  LISP VPN                        May 2026


4.1.1.  LISP Extranet VPN Map Register Procedures

   An ETR may register EIDs in their Home-IID as well as in the other
   IIDs within the scope of the Extranet Policy.  For example, an EID
   connected to the Extranet-VPN may be registered by its ETR in its
   Home-IID and also in all the IIDs corresponding to the Extranet-
   Subscriber-VPNs defined in the Extranet Policy.  When Map-Register
   messages for an EID are issued in IIDs other than the EID's Home-IID,
   the Home-IID for the EID must be included in the Map-Register.  The
   Home-IID must be encoded as described in Section 4.1.4.

   When registering an EID in multiple IIDs, it is advisable to pack the
   multiple registrations in a single Map-Register message containing
   the multiple XEID records.

   A Map-Server may be configured with the Extranet Policy.  This may
   suffice for the Map-Server to be able to satisfy cross VPN lookups.
   In such implementations, ETRs may not be required to register an EID
   across the entire scope of IIDs defined in the Extranet Policy, but
   may only require the registration of the EID in its Home-IID.

   Which method of cross VPN mapping registration is used (initiated by
   the ETR or initiated by the Map-Server) should be a configurable
   option on the XTRs and Map-Server.

4.1.2.  LISP Extranet VPN Map Lookup Procedures

   Map-Request messages issued by an ITR, their structure and use do not
   change when a destination EID is outside of the Home-IID for the
   source EID.

   When a Map-Request message is forwarded from the Map-Resolver to an
   authoritative Map-Server (either directly or by DDT delegation), the
   IID of the requesting EID must be preserved so that the Map-Reply is
   sent in the correct context.

   Map-Reply messages must use the IID of the requesting EID and must
   also include the Home-IID of the destination EID.  The Home-IID is a
   parameter of the destination EID, part of the mapping and must be
   encoded as described in Section 4.1.4.  The mapping obtained in the
   Map-Reply must be cached in the forwarding context of the requesting
   EID, which is identified by the IID for the requesting EID.  The
   mappings cached will contain the Home-IID of the destination EID
   whenever this destination EID is cached outside of its Home-IID.

   Since each IID at the Map Server has a complete set of EIDs in the
   scope of the extranet policy, the deterination of a covering prefix
   in the case of a non-LISP or external destination is straightforward



Moreno & Farinacci       Expires 7 November 2026               [Page 10]

Internet-Draft                  LISP VPN                        May 2026


   and follows the proceedures delineated in the procedures for a
   negative map reply in [RFC9300].When the Map Server determines that
   the requested destination EID is either not an EID or not registered
   it must calculate the covering prefix for the requested EID and reply
   in one of two ways:

   - With a Negative Map Reply per the procedures outlined in [RFC9300].
   If using a PeTR, the Home-IID for the PeTR must be configured at the
   requesting ITR.

   - WIth a Map Reply mapping the calculated EID covering prefix to the
   RLOCs of a configured or registered PeTR.  The Map Reply must contain
   the Home-IID of the registered PeTR.

4.1.3.  LISP Extranet Publish/Subscribe Procedures

   When LISP Extranet VPNs are implemented together with LISP Publish/
   Subscribe functionality [RFC9437], the following considerations
   apply.

   Subscriptions initiated across VPNs MUST maintain a record of the IID
   from which the subscription was requested.  An ITR that issues a Map-
   Request with the N-bit set from an Extranet-Subscriber-VPN will use
   the IID of the Extranet-Subscriber-VPN as the IID for the XEID it
   subscribes to.  The Map-Request is routed to the Extranet-VPN (Home-
   VPN) where the EID is registered, as defined in Section 4.1.2.  The
   subscription is maintained in the Home-VPN and will include a record
   of the IID of the Extranet-Subscriber-VPN from which the subscription
   was initiated.

   Any changes in the RLOC set for the EID will be published using a
   Map-Notify message.  The Map-Notify message will include the
   Extranet-Subscriber-VPN IID in the XEID and it will also include the
   IID of the Home-VPN (Home-IID) encoded as specified in Section 4.1.4.

4.1.4.  LISP Extranet VPN Home-IID encoding

   The Home-IID is an attribute of the EID-RLOC mapping.  The Home-IID
   must be encoded as an additional RLOC within the record carried in
   Map-Reply messages as defined in [RFC9300].  The Home-IID should also
   be included in Map-Notify messages when LISP Extranet VPNs are
   implemented together with LISP Publish/Subscribe functionality
   [RFC9437].

   The additional RLOC containing the Home-IID should use AFI = 16387
   (LCAF) with a List type as described in Section 4.1.4.1.





Moreno & Farinacci       Expires 7 November 2026               [Page 11]

Internet-Draft                  LISP VPN                        May 2026


4.1.4.1.  Home-IID encoded in LCAF List type

   The Home-IID may be encoded as LCAF AFI of type Instance ID (Type 2).
   The IID LCAF AFI entry should be nested within a List Type LCAF (Type
   1).  The list type is used to include a distinguished name type (as
   documented in [RFC9735] that would provide the semantical information
   that identifies this field as a Home-IID to be used for the purposes
   of Extranet VPNs.  Map-Servers and XTRs receiving the encoded
   messages would leverage the semantical information to parse the
   control plane message properly.  The different LCAF types are
   documented in [RFC8060].  The logical structure of the nested LCAF
   structure is depicted below:

   AFI = LCAF(16387)
     Type = LIST(1)
       ITEM1
         AFI = Distinguished Name
         Value = "Home-IID"
       ITEM2
         AFI = LCAF(16387)
         Type = IID(2)
         Value = <Home-IID.value>

4.1.4.2.  Home-IID encoded in dedicated LCAF Type

   Alternatively, a new dedicated LCAF type could be used in order to
   include application semantics to the encoding of the IID in a
   purposely structured type.  In the future, this document may be
   updated to provide details of the definition of structure and
   semantics for a dedicated LCAF type to be used in this application.

4.2.  LISP Extranet VPN Data Plane

   Traffic will be forwarded according to the procedures outlined in
   [RFC9300].  The map-cache will include the Home-IID for the
   destination EID as part of the mapping for the destination EID.  In
   an ITR, unicast traffic will be encapsulated using the Home-IID for
   the destination EID as the Instance-ID in the encapsulation header.
   On de-capsulation, the Instance-ID in the header points to the
   destination VPN already so no further procedures are required.

4.3.  LISP Extranet VPN Multicast Considerations

   When Multicast traffic needs to be forwarded across VPNs, there are
   special considerations that are closely tied to the definition of the
   Extranet functionality.  This specification will focus on the use of
   Signal Free Multicast [RFC8378] for the delivery of a cross VPN
   multicast service.



Moreno & Farinacci       Expires 7 November 2026               [Page 12]

Internet-Draft                  LISP VPN                        May 2026


4.3.1.  LISP Extranet VPN Multicast Control Plane

   The Receiver-site Registration procedures described in [RFC8378] are
   expanded to allow the formation of a replication-list inclusive of
   Receivers detected in the different VPNs within the scope of the
   Extranet Policy.

   Once the Receiver-ETRs detect the presence of Receivers at the
   Receiver-site, the Receiver-ETRs will issue Map-Register messages to
   include the Receiver-ETR RLOCs in the replication-list for the
   multicast-entry the Receivers joined.

   The encodings for Map-Register messages and the EIDs and RLOCs within
   follow the guidelines defined in [RFC8378].

   For VPNs within the scope of the Extranet Policy the multicast
   receiver registrations will be used to build a common replication
   list across all VPNs in the Extranet Policy scope.  This replication
   list is maintained within the scope of the VPN where the multicast
   source resides.  When Receivers are in the Extranet-Subscriber-VPN,
   Multicast sources are assumed to be in the Extranet-VPN and
   viceversa.

   The Instance-ID used to Register the Receiver-ETR RLOCs in the
   replication-list is the Instance-ID of the Extranet-VPN, i.e. the VPN
   where the Multicast Source resides.  When listeners are detected in
   the Extranet-VPN, then multiple Registrations must be sent with the
   Instance-IDs of the Extranet-Subscriber-VPNs under the assumption
   that the Multicast sources could be in one or more of the Extranet-
   Subscriber-VPNs.

   Source-ITRs will complete lookups for the replication-list of a
   particular multicast group destination as well as the forwarding of
   traffic to this multicast group following the procedures defined in
   [RFC8378] without any change.

4.3.2.  LISP Extranet VPN Multicast Data Plane

   It is desirable to send a single copy of the Multicast traffic over
   the transit network and have the Receiver-ETRs locally replicate the
   traffic to all Receiver-VPNs necessary.  This replication is governed
   by the Extranet Policy configured at the ETR.  Thus, ITRs will
   encapsulate the traffic with the Instance-ID for the VPN where the
   Multicast Source resides.  ETRs will receive traffic in the source
   IID and replicate it to the Receiver VPNs per the Extranet Policy.






Moreno & Farinacci       Expires 7 November 2026               [Page 13]

Internet-Draft                  LISP VPN                        May 2026


4.4.  LISP Extranet SMR Considerations

   Data driven SMRs MUST carry the IID for the VPNs of the receivers of
   traffic.  Data driven SMRs MAY carry the IID for the VPNs of senders
   of traffic if the sender VPN IIDs are known by the ETR generating the
   SMR.  If the sender VPN's Instance-ID is not known, the ETR SHOULD
   send the SMR to the RLOC of the sending ITR without the sender VPN's
   IID.

   The SMR MUST be replicated to all extranet VPNs that are defined in
   the Extranet Policy and instantiated at the sending ITR.

   When the IID of the sender VPN is known at the ETR, the ETR MAY
   include the sender VPN's IID in the SMR and issue a separate SMR for
   each sender VPN IID known to the ETR.  Multicast optimizations could
   be used to minimize the amount of traffic replicated when sending
   these SMRs and potentially replicate only at the ITR.

   When the IID of the sender VPN is not known at the ETR, the ETR
   SHOULD issue a single SMR to each of the sending ITRs.  The SMR will
   then be replicated at the ITR to all extranet VPNs that are defined
   in the Extranet Policy and instantiated at the sending ITR.

4.4.1.  Home-IID inclusion in SMR messages

   The Instance IDs relevant to the SMR signaling will be encoded in the
   SMR Map-request message fields as follows:

   Source-EID field: If known by the ETR, this field SHOULD carry the
   instance-ID of the traffic source VPN at the ITR with the obsolete
   map-cache.  This is the IID of the senders of the traffic.
   Otherwise, the Instance-ID in this field MUST be the same as the
   Instance-ID of the destination VPN at the ETR generating the SMR.

   EID-Prefix field: This field carries the Instance-ID of the
   destination VPN at the ETR sending the SMR.  This is the IID of the
   receivers of the traffic.  This field must always be set with the IID
   of the receivers.

4.5.  LISP Extranet RLOC Probing Considerations

   RLOC Probes must be sent with the IID of the VPN originating the
   probe.  The XTR receiving the probe must identify the VPN for the
   target EID.  The XTR receiving the probe should run all verifications
   as specified in [RFC9300] within the forwarding context corresponding
   to the VPN where the target EID is connected.  Once verifications are
   completed, the reply to the probe should be sent in the IID of the
   VPN that originated the probe.



Moreno & Farinacci       Expires 7 November 2026               [Page 14]

Internet-Draft                  LISP VPN                        May 2026


5.  Security Considerations

   LISP [RFC9300] and [RFC9301] incorporates many security mechanisms as
   part of the mapping database service when using control-plane
   procedures for obtaining EID-to-RLOC mappings.  In general, data
   plane mechanisms are not of primary concern for general Internet use-
   case.  However, when LISP VPNs are deployed, several additional
   security mechanisms and considerations must be addressed.

   Data plane traffic uses the LISP instance-id (IID) header field for
   segmentation. in-flight modifications of this IID value could result
   in violations to the tenant segmentation provided by the IID.
   Protection against this attack can be achieved by using the integrity
   protection mechanisms afforded by LISP Crypto, with or without
   encryption depending on users' confidentiality requirements (see
   below).

5.1.  LISP VPNs and LISP Crypto

   The procedures for data plane confidentiality in LISP are documented
   in [RFC8061] and are primarily aimed at negotiating secret shared
   keys between ITR and ETR in map-request and map-reply messages.
   These secret shared keys are negotiated on a per RLOC basis and
   without regard for any VPN segmentation done in the EID space.  Thus,
   multiple VPNs using a shared RLOC may also share a common secret key
   to encrypt communications of the multiple VPNs.

   It is possible to negotiate secret shared keys on a per EID basis by
   applying the procedures described in [RFC8061] to RLOC probes.  In a
   VPN environment, RLOC probes would be aimed at Extended EIDs that
   contain Instance-ID semantics, therefore resulting in the calculation
   of different secret shared keys for different XEID.  Since the keys
   are calculated per XEID prefix rather than per VPN, there are scale
   considerations when implementing this level of key negotiation
   granularity.

6.  IANA Considerations

   This document has no IANA implications

7.  Acknowledgements

   The authors want to thank Marc Portoles, Vrushali Ashtaputre, Johnson
   Leong, Jesus Arango, Prakash Jain, Sanjay Hooda, Alberto Rodriguez-
   Natal, Darrel Lewis and Greg Schudel for their insightful
   contribution to shaping the ideas in this document.

8.  References



Moreno & Farinacci       Expires 7 November 2026               [Page 15]

Internet-Draft                  LISP VPN                        May 2026


8.1.  Normative References

   [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>.

   [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>.

8.2.  Informative References

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
              eXtensible Local Area Network (VXLAN): A Framework for
              Overlaying Virtualized Layer 2 Networks over Layer 3
              Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
              <https://www.rfc-editor.org/info/rfc7348>.

   [RFC8060]  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
              February 2017, <https://www.rfc-editor.org/info/rfc8060>.

   [RFC8061]  Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
              (LISP) Data-Plane Confidentiality", RFC 8061,
              DOI 10.17487/RFC8061, February 2017,
              <https://www.rfc-editor.org/info/rfc8061>.

   [RFC8111]  Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
              Smirnov, "Locator/ID Separation Protocol Delegated
              Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
              May 2017, <https://www.rfc-editor.org/info/rfc8111>.

   [RFC8378]  Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
              Separation Protocol (LISP) Multicast", RFC 8378,
              DOI 10.17487/RFC8378, May 2018,
              <https://www.rfc-editor.org/info/rfc8378>.







Moreno & Farinacci       Expires 7 November 2026               [Page 16]

Internet-Draft                  LISP VPN                        May 2026


   [RFC9437]  Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai,
              S., and M. Boucadair, "Publish/Subscribe Functionality for
              the Locator/ID Separation Protocol (LISP)", RFC 9437,
              DOI 10.17487/RFC9437, August 2023,
              <https://www.rfc-editor.org/info/rfc9437>.

   [RFC9735]  Farinacci, D. and L. Iannone, Ed., "Locator/ID Separation
              Protocol (LISP) Distinguished Name Encoding", RFC 9735,
              DOI 10.17487/RFC9735, February 2025,
              <https://www.rfc-editor.org/info/rfc9735>.

Authors' Addresses

   Victor Moreno
   Google LLC
   1600 Amphitheatre Pkwy
   Mountain View, CA 94043
   United States of America
   Email: vimoreno@google.com


   Dino Farinacci
   lispers.net
   San Jose, CA 95120
   United States of America
   Email: farinacci@gmail.com

























Moreno & Farinacci       Expires 7 November 2026               [Page 17]
