



Network Working Group                                        M. Portoles
Internet-Draft                                             V. Ashtaputre
Intended status: Experimental                                   F. Maino
Expires: 20 November 2026                                  Cisco Systems
                                                               V. Moreno
                                                              Google LLC
                                                            D. Farinacci
                                                             lispers.net
                                                             19 May 2026


         LISP L2/L3 EID Mobility Using a Unified Control Plane
                    draft-ietf-lisp-eid-mobility-18

Abstract

   The LISP control plane offers the flexibility to support multiple
   overlay flavors simultaneously.  This document specifies how LISP can
   be used to provide control-plane support to deploy a unified L2 and
   L3 overlay solution for End-point Identifier (EID) mobility, as well
   as analyzing possible deployment options and models.

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







Portoles, et al.        Expires 20 November 2026                [Page 1]

Internet-Draft             L2/L3 EID Mobility                   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.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   4
   3.  Definition of terms . . . . . . . . . . . . . . . . . . . . .   4
   4.  Reference System  . . . . . . . . . . . . . . . . . . . . . .   4
   5.  L3 Overlays and Mobility Support  . . . . . . . . . . . . . .   6
     5.1.  Reference Architecture and packet flows . . . . . . . . .   6
       5.1.1.  Routed Traffic Flow: L3 Overlay use . . . . . . . . .   6
       5.1.2.  L3 Mobility Flow  . . . . . . . . . . . . . . . . . .   7
         5.1.2.1.  L3 Mobility Flow using Data Driven SMRs . . . . .   7
         5.1.2.2.  L3 Mobility Flow using Publish/Subscribe
                 Mechanisms  . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Implementation Considerations . . . . . . . . . . . . . .   9
       5.2.1.  L3 Segmentation . . . . . . . . . . . . . . . . . . .   9
       5.2.2.  L3 Database-Mappings  . . . . . . . . . . . . . . . .   9
       5.2.3.  LISP Mapping System support . . . . . . . . . . . . .  10
       5.2.4.  Using SMRs to Track Moved-Away Hosts  . . . . . . . .  11
       5.2.5.  L3 multicast support  . . . . . . . . . . . . . . . .  11
       5.2.6.  Time-to-Live Handling in Data-Plane . . . . . . . . .  11
   6.  L2 Overlays and Mobility Support  . . . . . . . . . . . . . .  11
     6.1.  Reference Architecture and packet flows . . . . . . . . .  11
       6.1.1.  Bridged Traffic Flow: L2 Overlay use  . . . . . . . .  12
       6.1.2.  L2 Mobility Flow  . . . . . . . . . . . . . . . . . .  13
         6.1.2.1.  L2 Mobility Flow using Data Driven SMRs . . . . .  13
         6.1.2.2.  L2 Mobility Flow using Publish/Subscribe
                 mechanisms  . . . . . . . . . . . . . . . . . . . .  14
     6.2.  Implementation Considerations . . . . . . . . . . . . . .  14
       6.2.1.  L2 Segmentation . . . . . . . . . . . . . . . . . . .  15
       6.2.2.  L2 Database-Mappings  . . . . . . . . . . . . . . . .  15
       6.2.3.  Interface to the LISP Mapping System  . . . . . . . .  16
       6.2.4.  SMR support to track L2 hosts that moved away . . . .  16
       6.2.5.  L2 Broadcast and Multicast traffic  . . . . . . . . .  17
       6.2.6.  L2 Unknown Unicast Support  . . . . . . . . . . . . .  17



Portoles, et al.        Expires 20 November 2026                [Page 2]

Internet-Draft             L2/L3 EID Mobility                   May 2026


       6.2.7.  Time-to-Live Handling in Data-Plane . . . . . . . . .  18
     6.3.  Multihoming Support . . . . . . . . . . . . . . . . . . .  18
       6.3.1.  Identification of L2 multihomed sites . . . . . . . .  19
       6.3.2.  Discovery of peer xTRs in multihomed sites  . . . . .  19
       6.3.3.  Designated Forwarder Selection  . . . . . . . . . . .  20
       6.3.4.  Split Horizon filtering . . . . . . . . . . . . . . .  21
       6.3.5.  Multihoming operation . . . . . . . . . . . . . . . .  21
     6.4.  Support to ARP resolution through Mapping System  . . . .  22
       6.4.1.  Map-Server support to ARP resolution: Packet Flow . .  22
       6.4.2.  ARP registrations: MAC as a locator record  . . . . .  24
       6.4.3.  Implementation Considerations . . . . . . . . . . . .  26
   7.  Optional Deployment Models  . . . . . . . . . . . . . . . . .  26
     7.1.  IP Forwarding of Intra-subnet Traffic . . . . . . . . . .  27
     7.2.  Data-plane Encapsulation Options  . . . . . . . . . . . .  28
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  28
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  29
     10.2.  Informative References . . . . . . . . . . . . . . . . .  30
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30

1.  Introduction

   This document describes the architecture and design options required
   to offer a unified L2 and L3 overlay solution for End-point
   Identifier (EID) mobility using the LISP control-plane.

   The architecture takes advantage of the flexibility that LISP
   provides to simultaneously support different overlay types.  While
   the LISP specification defines both the data-plane and the control-
   plane, this document focuses on the use of the control-plane to
   provide L2 and L3 overlay services with EID mobility.  The control
   plane may be combined with a data-plane of choice, e.g., LISP, VXLAN-
   GPE, or VXLAN.

   The recommendation on whether a flow is sent over the L2 or the L3
   overlay is based on whether the traffic is bridged (intra-subnet or
   non-IP) or routed (inter-subnet), respectively.  This allows treating
   both overlays as separate segments, and enables L2-only and L3-only
   deployments (and combinations of them) without modifying the
   architecture.

   The unified solution for L2 and L3 overlays offers the possibility to
   extend subnets and routing domains (as required in state-of-art
   Datacenter and Enterprise architectures) with mobility support and
   traffic optimization.





Portoles, et al.        Expires 20 November 2026                [Page 3]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   An important use-case of the unified architecture is that, while most
   data centers are complete layer-3 routing domains, legacy
   applications either have not converted to IP or still use auto-
   discovery at layer-2 and assume all nodes in an application cluster
   belong to the same subnet.  For these applications, the L2-overlay
   limits the functionality to where the legacy app lives versus having
   to extend layer-2 into the underlay network.

   Broadcast, Unknown and Multicast traffic on the overlay are supported
   by either replicated unicast, or underlay (RLOC) multicast as
   specified in [RFC9301] and [RFC8378].

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 document uses the terms defined in Section 3 of documents
   [RFC9300] and [RFC9301], notably EID, RLOC, Map-Request, Map-Reply,
   Map-Notify, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR),
   xTR, Map-Server (MS) and Map-Resolver (MR).

4.  Reference System

   The following figure illustrates the reference system used to support
   the packet flow description throughout this document.  The system
   defines 4 sites.  Site A and Site D provide access to different
   subnets (non-extended), while Site B and Site C extend a common
   subnet.  The xTR in each one of the sites registers EIDs from the
   sites with the LISP Mapping System and provides support to
   encapsulate overlay (EID) traffic through the underlay (RLOC space).















Portoles, et al.        Expires 20 November 2026                [Page 4]

Internet-Draft             L2/L3 EID Mobility                   May 2026


                            ,-------------.
                           (Mapping System )
                            -+------------+
                           +--+--+   +-+---+
                           |MS/MR|   |MS/MR|
                           +-+---+   +-----+
              .-._..-._.--._..|._.,.-._.,|-._.-_._.-.._.-.
          .-.'                                            '.-.
         (                    L3 Underlay                     )
          (                   (RLOC Space)                    )
          '.-._.'.-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-._.-.'
            /              |                 |               \
    RLOC=IP_A          RLOC=IP_B         RLOC=IP_C         RLOC=IP_D
    +-+--+--+          +-+--+--+         +-+--+--+         +-+--+--+
   .| xTR A |.-.      .| xTR B |.-.     .| xTR C |.-.     .| xTR D |.-.
  ( +-+--+--+   )    ( +-+--+--+   )   ( +-+--+--+   )   ( +-+--+--+   )
 .'   Site A   )   .'   Site B    )   .'   Site C   )   .'   Site D   )
 ( 1.0.0.0/24 .    ( 3.0.0.0/24  .    ( 3.0.0.0/24 .   (  2.0.0.0/24 .
 '--'._.'.     )    '--'._.'.     )    '--'._.'.    )   '--'._.'.     )
        /  '--'            |  '--'          |   '--'             \ '--'
    '--------'          '--------'        '--------'        '--------'
    :  End   :          :  End   :        :  End   :        :  End   :
    :Device 1:          :Device 2:        :Device 3:        :Device 4:
    '--------'          '--------'        '--------'        '--------'
    IP: 1.0.0.1         IP: 3.0.0.2       IP: 3.0.0.3       IP: 2.0.0.4
                     MAC: 0:0:3:0:0:2   MAC: 0:0:3:0:0:3

     Figure 1: Reference System Architecture with unified L2 and L3
                                overlays

   The recommended selection between the use of L2 and L3 overlays is to
   map them to bridged (intra-subnet or non-IP) and routed (inter-
   subnet) traffic.  The rest of the document follows this
   recommendation to describe the packet flows.

   However, note that in a different selection approach, intra-subnet
   traffic MAY also be sent over the L3 overlay.  Section 7.1 specifies
   the changes needed to send all IP traffic using the L3 overlay and
   restricting the use of the L2 overlay to non-IP traffic.

   When required, the control plane makes use of two basic types of EID-
   to-RLOC mappings associated with end-hosts to support the unified
   architecture:

   *  EID = <IID, MAC> to RLOC=<IP>.  This is used to support the L2
      overlay.





Portoles, et al.        Expires 20 November 2026                [Page 5]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   *  EID = <IID, IP> to RLOC=<IP>.  This is the traditional mapping as
      defined in the original LISP specification and supports the L3
      overlay.

5.  L3 Overlays and Mobility Support

5.1.  Reference Architecture and packet flows

   In order to support the packet flow descriptions in this section we
   use Figure 1 as reference.  This section uses Sites A and D to
   describe the flows.


           /              |                 |               \
   RLOC=IP_A          RLOC=IP_B         RLOC=IP_C         RLOC=IP_D
   +-+--+--+          +-+--+--+         +-+--+--+         +-+--+--+
  .| xTR A |.-.      .| xTR B |.-.     .| xTR C |.-.     .| xTR D |.-.
 ( +-+--+--+   )    ( +-+--+--+   )   ( +-+--+--+   )   ( +-+--+--+   )
.'   Site A   )   .'   Site B    )   .'   Site C   )   .'   Site D   )
( 1.0.0.0/24 .    ( 3.0.0.0/24  .    ( 3.0.0.0/24 .   (  2.0.0.0/24 .
'--'._.'.     )    '--'._.'.     )    '--'._.'.    )   '--'._.'.     )
       /  '--'            |  '--'          |   '--'             \ '--'
   '--------'          '--------'        '--------'        '--------'
   :  End   :          :  End   :        :  End   :        :  End   :
   :Device 1:          :Device 2:        :Device 3:        :Device 4:
   '--------'          '--------'        '--------'        '--------'
 (IID1,1.0.0.1)      (IID1,3.0.0.2)     (IID1,3.0.0.3)    (IID1,2.0.0.4)
                  (IID2,0:0:3:0:0:2)   (IID2,0:0:3:0:0:3)

              Figure 2: Reference Mobility Architecture


5.1.1.  Routed Traffic Flow: L3 Overlay use

   Inter-subnet traffic is encapsulated using the L3 overlay.  The
   process to encapsulate this traffic is the same as described in
   [RFC9300] and [RFC9301].  We describe the packet flow here for
   completeness.

   The following is a sequence example of the unicast packet flow and
   the control plane operations when in the topology shown in Figure 1
   End-Device 1, in LISP site A, wants to communicate with End-Device 4
   in LISP site D.  Note that both end systems reside in different
   subnets.  We'll assume that End-Device 1 knows the EID IP address of
   End-Device 4 (e.g. it is learned using a DNS service).






Portoles, et al.        Expires 20 November 2026                [Page 6]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   *  End-Device 1 sends an IP packet frame with destination 2.0.0.4 and
      source 1.0.0.1.  As the destination address lies on a different
      subnet End-Device 1 sends the packet following its routing table
      to ITR A (e.g., it is its default gateway).

   *  ITR A does a L3 lookup in its local map-cache for the destination
      IP 2.0.0.4.  When the lookup of 2.0.0.4 is a miss, the ITR sends a
      Map-Request to the mapping database system looking up
      EID=<IID1,2.0.0.4>.

   *  The Mapping System forwards the Map-Request to ETR D, which has
      registered the EID-to-RLOC mapping of EID=<IID1,2.0.0.4>.

   *  ETR D sends a Map-Reply to ITR A that includes the EID-to-RLOC
      mapping: EID=<IID1,2.0.0.4> -> RLOC=IP_D, where IP_D is the
      locator of ETR D.

   *  ITR A populates the local map-cache with the EID to RLOC mapping,
      and encapsulates all subsequent packets with a destination IP
      2.0.0.4 using destination RLOC=IP_D.

5.1.2.  L3 Mobility Flow

   Support for L3 mobility covers the requirements to allow an end-host
   to move from a given site to another and maintain correspondence with
   the rest of end-hosts that are connected to the same L3 routing
   domain.  This support MUST ensure convergence of L3 forwarding (IPv4/
   IPv6 based) from the old location to the new one when the host
   completes its move.

   The update of the ITR map-caches when EIDs move MAY be achieved using
   Data Driven SMRs or the Publish/Subscribe mechanisms defined in
   [RFC9437].  The following two sections are sequence descriptions of
   the packet flow when End-Device 1 in the reference figure roams to
   site D.

5.1.2.1.  L3 Mobility Flow using Data Driven SMRs

   The following is a sequence description of the packet flow when End-
   Device 1 in the reference figure roams to site D.  This sequence uses
   Data Driven SMRs to trigger the updates of the ITR map-caches.

   *  When End-Device 1 is attached or detected in site D, ETR D sets up
      the database mapping corresponding to EID=<IID1, 1.0.0.1>.  ETR D
      sends a Map-Register to the mapping system registering RLOC=IP_D
      as locator for EID=<IID1, 1.0.0.1>.  Now the mapping system is
      updated with the new EID-to-RLOC mapping (location) for End-Device
      1.



Portoles, et al.        Expires 20 November 2026                [Page 7]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   *  The Mapping System, after receiving the new registration for
      EID=<IID1, 1.0.0.1> sends a Map-Notify to the departure ETR(s)
      (ETR A) to inform it of the move.  Then, ETR A removes its local
      database mapping information and stops registering EID=<IID1,
      1.0.0.1>.

   *  Any ITR or PiTR participating in the L3 overlay (corresponding to
      IID1) that were sending traffic to 1.0.0.1 before the migration
      keep sending traffic to ETR A.

   *  Once ETR A is notified by the Mapping system, when it receives
      traffic from an ITR with destination 1.0.0.1, it generates a
      Solicit-Map-Request (SMR) back to the ITR (or PiTR) for EID=<IID1,
      1.0.0.1>.

   *  Upon receiving the SMR the ITR invalidates its local map- cache
      entry for EID=<IID1, 1.0.0.1> and sends a new Map-Request for that
      EID.  The Map-Reply includes the new EID-to-RLOC mapping for End-
      Device 1 with RLOC=IP_D.

   *  Similarly, once the local database mapping is removed from ITR A,
      non-encapsulated packets arriving at ITR A from a local End-Device
      and destined to End-Device 1 result in a cache miss, which
      triggers sending a Map-Request for EID=<IID1, 1.0.0.1> to populate
      the map-cache of ITR A.

5.1.2.2.  L3 Mobility Flow using Publish/Subscribe Mechanisms

   When Publish/Subscribe ([RFC9437]) mechanisms are used, the flow of
   signaling to achieve EID mobility is modified.  In this case, when a
   local end-device connected via an ITR establishes communication with
   a remote mobile end-device (connected to a remote ETR), the ITR will
   issue a Map-Request for the mobile end-device.  Following the Mapping
   Request Subscribe Procedures defined in [RFC9437], the Map-request
   will be issued with the N-bit set on the EID-Record so that the ITR
   is notified of any RLOC-set changes for the mobile EID-prefix.

   The following is a sequence description of the packet flow when End-
   Device 1 in the reference figure roams to site D.  This sequence
   leverages Publish/Subscribe mechanisms to update the ITR map-caches.

   *  When an end-device connected via an ITR establishes communication
      with a mobile end-device (e.g. end-device 1), the ITR will issue a
      Map-Request for the mobile end-device.  Following the Mapping
      Request Subscribe Procedures defined in [RFC9437], the Map-Request
      will be issued with the N-bit set on the EID-Record so that the
      ITR is notified of any RLOC-set changes for the mobile EID-prefix.




Portoles, et al.        Expires 20 November 2026                [Page 8]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   *  When the mobile end-device (End-Device 1) is attached or detected
      in a new site (e.g. site D), the ETR at the new site (e.g. ETR D)
      sets up the database mapping corresponding to the EID of the
      mobile end-device (e.g. EID=<IID1, 1.0.0.1>).  The ETR at the new
      site (e.g. ETR D) sends a Map-Register to the mapping system
      registering its RLOCs (e.g. RLOC=IP_D) as locator for the EID of
      the mobile end-device (e.g.  EID=<IID1, 1.0.0.1>).  Now the
      mapping system is updated with the new EID-to-RLOC mapping
      (location) for the mobile end-device (e.g. End-Device 1).

   *  The Mapping System, after receiving the new registration for the
      EID of the mobile end-device (EID=<IID1, 1.0.0.1>) sends a Map-
      Notify to the departure site (ETR A) to inform it of the move.
      Then, the ETR at the departure site (ETR A) removes its local
      database mapping information and stops registering the EID for the
      mobile end-device (EID=<IID1, 1.0.0.1>).

   *  Any ITR or PiTR participating in the L3 overlay (corresponding to
      IID1) that were sending traffic to the mobile end-device (1.0.0.1)
      would have subscribed to receive notifications of any changes in
      the RLOC-set for the EID of the mobile end-device (1.0.0.1).  The
      Mapping System publishes the updated RLOC-set to the subscribed
      ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping
      Notification Publish Procedures defined in [RFC9437].

   *  Upon receiving the Map-Notify message, the ITR updates the RLOC-
      set in its local map-cache entry for the EID of the mobile end-
      device (EID=<IID1, 1.0.0.1>).  Once the map-cache is updated,
      traffic is tunneled by the ITR to the new location.


5.2.  Implementation Considerations

5.2.1.  L3 Segmentation

   LISP support of segmentation and multi-tenancy is structured around
   the propagation and use of Instance-IDs (IID), and handled as part of
   the EID in control plane operations.  The encoding is described in
   [RFC8060] and its use in [RFC8111].

   Instance-IDs can be used to support L3 overlay segmentation, such as
   in extended VRFs or multi-VPN overlays ([I-D.ietf-lisp-vpn]).

5.2.2.  L3 Database-Mappings

   When an end-host is attached or detected in an ETR that provides
   L3-overlay services and mobility, a database mapping is registered to
   the mapping system with the following structure:



Portoles, et al.        Expires 20 November 2026                [Page 9]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   *  The EID 2-tuple (IID, IP) with its binding to a corresponding ETR
      locator set (IP RLOC)

   The registration of these EIDs MUST follow the LCAF format as defined
   in [RFC8060] and the specific EID record to be used is illustrated in
   the following figure:

   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record TTL                           |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   E   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   I   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   D   | Rsvd  |  Map-Version Number   |         AFI = 16387           |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |    Rsvd1     |     Flags      |   Type = 2    | IID mask-len  |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |             4 + n             |        Instance-ID...         |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |       ...Instance-ID          |        EID-AFI = 1 or 2       |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                    EID-Prefix (IPv4 or IPv6)                  |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The L3 EID record follows the structure as described in [RFC9301].

5.2.3.  LISP Mapping System support

   The interface between the xTRs and the Mapping System is described in
   [RFC9301] and this document follows the specification as described
   there.  When available, the registrations MAY be implemented over a
   reliable transport as described in
   [I-D.ietf-lisp-map-server-reliable-transport].

   In order to support system convergence after mobility, when the Map-
   Server receives a new registration for a specific EID, it MUST send a
   Map-Notify to the entire RLOC set in the site that last registered
   this same EID.  This Map-Notify is used to track moved-away state of
   L3 EIDs as described in Section 5.2.4.







Portoles, et al.        Expires 20 November 2026               [Page 10]

Internet-Draft             L2/L3 EID Mobility                   May 2026


5.2.4.  Using SMRs to Track Moved-Away Hosts

   One of the key elements to support end-host mobility using the LISP
   architecture is the Solicit-Map-Request (SMR).  This is a special
   message by means of which an ETR can request an ITR to send a new
   Map-Request for a particular EID record.  In essence the SMR message
   is used as a signal to indicate a change in mapping information and
   it is described in [RFC9301].

   In order to support mobility, an ETR SHALL maintain a list of EID
   records for which it has to generate a SMR message whenever it
   receives traffic with that EID as destination.

   The particular strategy to maintain an Away Table is implementation
   specific and it will be typically based on the strategy to detect the
   presence of hosts and the use of Map-Notify messages received from
   the Map-Server.  In essence the table SHOULD provide support to the
   following:

   *  Keep track of end-hosts that were once connected to an ETR and
      have moved away.

   *  Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR
      message SHOULD be generated.

5.2.5.  L3 multicast support

   L3 Multicast traffic on the overlay MAY be supported by either
   replicated unicast, or underlay (RLOC) multicast.  Specific solutions
   to support L3 multicast over LISP controlled overlays are specified
   in [RFC9301], and [RFC8378].

5.2.6.  Time-to-Live Handling in Data-Plane

   The LISP specification ([RFC9300]) describes how to handle Time-to-
   Live values of the inner and outer headers during encapsulation and
   decapsulation of packets when using the L3 overlay.

6.  L2 Overlays and Mobility Support

6.1.  Reference Architecture and packet flows

   In order to support L2 packet flow descriptions in this section we
   use Figure 1 as reference.  This section uses Sites B and C to
   describe the flows.






Portoles, et al.        Expires 20 November 2026               [Page 11]

Internet-Draft             L2/L3 EID Mobility                   May 2026


           /              |                 |               \
   RLOC=IP_A          RLOC=IP_B         RLOC=IP_C         RLOC=IP_D
   +-+--+--+          +-+--+--+         +-+--+--+         +-+--+--+
  .| xTR A |.-.      .| xTR B |.-.     .| xTR C |.-.     .| xTR D |.-.
 ( +-+--+--+   )    ( +-+--+--+   )   ( +-+--+--+   )   ( +-+--+--+   )
.'   Site A   )   .'   Site B    )   .'   Site C   )   .'   Site D   )
( 1.0.0.0/24 .    ( 3.0.0.0/24  .    ( 3.0.0.0/24 .   (  2.0.0.0/24 .
'--'._.'.     )    '--'._.'.     )    '--'._.'.    )   '--'._.'.     )
       /  '--'            |  '--'          |   '--'             \ '--'
   '--------'          '--------'        '--------'        '--------'
   :  End   :          :  End   :        :  End   :        :  End   :
   :Device 1:          :Device 2:        :Device 3:        :Device 4:
   '--------'          '--------'        '--------'        '--------'
 (IID1,1.0.0.1)      (IID1,3.0.0.2)     (IID1,3.0.0.3)    (IID1,2.0.0.4)
                  (IID2,0:0:3:0:0:2)   (IID2,0:0:3:0:0:3)

              Figure 3: Reference Mobility Architecture


6.1.1.  Bridged Traffic Flow: L2 Overlay use

   Bridged traffic is encapsulated using the L2 overlay.  This section
   provides an example of the unicast packet flow and the control plane
   operations when End-Device 2 in site B communicates with End-Device 3
   in site C.  In this case we assume that End Device 2 knows the MAC
   address of End-Device 3 (e.g., learned through ARP).

   *  End-Device 2 sends an Ethernet/IEEE 802 MAC frame with destination
      0:0:3:0:0:3 and source 0:0:3:0:0:2.

   *  ITR B does a L2 lookup in its local map-cache for the destination
      MAC 0:0:3:0:0:3.  When the lookup of 0:0:3:0:0:3 is a miss, the
      ITR sends a Map-Request to the mapping database system looking up
      for EID=<IID2,0:0:3:0:0:3>.

   *  The mapping systems forwards the Map-Request to ETR C, which has
      registered the EID-to-RLOC mapping for EID=<IID2,0:0:3:0:0:3>.
      Alternatively, depending on the mapping system configuration, a
      Map-Server which is part of the mapping database system MAY send a
      Map-Reply directly to ITR B.

   *  ETR C sends a Map-Reply to ITR B that includes the EID-to-RLOC
      mapping: EID=<IID2, 0:0:3:0:0:3> -> RLOC=IP_C, where IP_C is the
      locator of ETR C.

   *  ITR B populates the local map-cache with the EID to RLOC mapping,
      and encapsulates all subsequent packets with a destination MAC
      0:0:3:0:0:3 using destination RLOC=IP_C.



Portoles, et al.        Expires 20 November 2026               [Page 12]

Internet-Draft             L2/L3 EID Mobility                   May 2026


6.1.2.  L2 Mobility Flow

   Support for L2 mobility covers the requirements to allow an end-host
   to move from a given site to another and maintain correspondence with
   the rest of the end-hosts that are connected to the same L2 domain
   (e.g. extended VLAN).  This support MUST ensure convergence of L2
   forwarding (MAC based) from the old location to the new one, when the
   host completes its move.

   The update of the ITR map-caches when EIDs move SHOULD be achieved
   using Data Driven SMRs or the Publish/Subscribe mechanisms defined in
   [RFC9437].  The following two sections are sequence descriptions of
   the packet flow when End-Device 2 in the reference figure roams to
   site C, which is extending its own subnet network.

6.1.2.1.  L2 Mobility Flow using Data Driven SMRs

   The following is a sequence description of the packet flow when End-
   Device 2 in the reference figure roams to site C.  This sequence uses
   Data Driven SMRs to trigger the updates of the ITR map-caches.

   *  When End-Device 2 is attached or detected in site C, ETR C sets up
      the database mapping corresponding to EID=<IID2, 0:0:3:0:0:2>.
      ETR C sends a Map-Register to the mapping system registering
      RLOC=IP_C as locator for EID=<IID2, 0:0:3:0:0:2>.

   *  The Mapping System, after receiving the new registration for
      EID=<IID2, 0:0:3:0:0:2> sends a Map-Notify to ETR B with the new
      locator set (IP_C).  ETR B the removes its local database mapping
      and stops registering <IID2, 0:0:3:0:0:2>.

   *  Any PiTR or ITR participating in the same L2-overlay
      (corresponding to IID2) that was encapsulating traffic to
      0:0:3:0:0:2 before the migration continues encapsulating this
      traffic to ETR B.

   *  Once ETR B is notified by the Mapping system, when it receives
      traffic from an ITR which is destined to 0:0:3:0:0:2, it will
      generate a Solicit-Map-Request (SMR) message that is sent to the
      ITR for (IID2,0:0:3:0:0:2).

   *  Upon receiving the SMR, the ITR sends a new Map-Request for the
      EID=<IID2,0:0:3:0:0:2>.  As a response ETR C sends a Map-Reply
      that includes the new EID-to-RLOC mapping for <IID2,0:0:3:0:0:2>
      with RLOC=IP_C.  This entry is cached in the L2 table of the ITR,
      replacing the previous one, and traffic is then forwarded to the
      new location.




Portoles, et al.        Expires 20 November 2026               [Page 13]

Internet-Draft             L2/L3 EID Mobility                   May 2026


6.1.2.2.  L2 Mobility Flow using Publish/Subscribe mechanisms


   When Publish/Subscribe ([RFC9437]) mechanisms are used, the flow of
   signaling to achieve EID mobility is modified.  In this case, when an
   End-Device connected via an ITR establishes communication with a
   mobile EID-prefix, the ITR will issue a Map-Request for the mobile
   End-device.  Following the Mapping Request Subscribe Procedures
   defined in [RFC9437], the Map-Request will be issued with the N-bit
   set on the EID-Record so that the ITR is notified of any RLOC-set
   changes for the mobile EID-prefix.

   The following is a sequence description of the packet flow when End-
   Device 2 in the reference figure roams to site C.  This sequence
   leverages Publish/Subscribe mechanisms to update the ITR map-caches.

   *  When End-Device 2 is attached or detected in site C, ETR C sets up
      the database mapping corresponding to EID=<IID2, 0:0:3:0:0:2>.
      ETR C sends a Map-Register to the mapping system registering
      RLOC=IP_C as locator for EID=<IID2, 0:0:3:0:0:2>.

   *  The Mapping System, after receiving the new registration for
      EID=<IID2, 0:0:3:0:0:2> sends a Map-Notify to the departure site
      (ETR B) with the new locator set (IP_C).  ETR B removes then its
      local database mapping and stops registering <IID2, 0:0:3:0:0:2>.

   *  Any ITR or PiTR participating in the same L2-overlay
      (corresponding to IID2) that was encapsulating traffic to
      0:0:3:0:0:2 before the migration would have subscribed to receive
      notifications of any changes in the RLOC-set for 0:0:3:0:0:2.  The
      Mapping System publishes the updated RLOC-set to the subscribed
      ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping
      Notification Publish Procedures defined in [RFC9437].

   *  Upon receiving the Map-Notify message, the ITR updates the RLOC-
      set in its local map-cache entry for EID=<IID2, 0:0:3:0:0:2>.
      Once the map-cache is updated, traffic is tunneled by the ITR to
      the new location.

6.2.  Implementation Considerations











Portoles, et al.        Expires 20 November 2026               [Page 14]

Internet-Draft             L2/L3 EID Mobility                   May 2026


6.2.1.  L2 Segmentation

   As with L3 overlays, LISP support of L2 segmentation is structured
   around the propagation and use of Instance-IDs, and handled as part
   of the EID in control plane operations.  The encoding is described in
   [RFC8060] and its use in [RFC8111].  Instance-IDs are unique to a
   Mapping System and MAY be used to identify the overlay type (e.g., L2
   or L3 overlay).

   An Instance-ID can be used for L2 overlay segmentation.  An important
   aspect of L2 segmentation is the mapping of VLANs to IIDs.  In this
   case a Bridge Domain (which is the L2 equivalent to a VRF as a
   forwarding context) maps to an IID, a VLAN-ID may map 1:1 to a bridge
   domain or different VLAN-IDs on different ports may map to a common
   Bridge Domain, which in turn maps to an IID in the L2 overlay.  When
   Ethernet traffic is double tagged, usually the outer 802.1Q tag will
   be mapped to a bridge domain on a per port basis, and the inner
   802.1Q tag will remain part of the payload to be handled by the
   overlay.  The IID should therefore be able to carry Ethernet traffic
   with or without an 802.1Q header.  A port may also be configured as a
   trunk and we may choose to take the encapsulated traffic and map it
   to a single IID in order to multiplex traffic from multiple VLANs on
   a single IID.  These are all examples of local operations that could
   be applied to VLANs in order to map them to IIDs, they are provided
   as examples and are not exhaustive.

6.2.2.  L2 Database-Mappings

   When an end-host is attached or detected in an ETR that provides
   L2-overlay services, a database mapping is registered to the mapping
   system with the following structure:

   *  The EID 2-tuple (IID, MAC) with its binding to a locator set (IP
      RLOC)

   The registration of these EIDs MUST follow the LCAF format as defined
   in [RFC8060] and as illustrated in the following figure:














Portoles, et al.        Expires 20 November 2026               [Page 15]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record TTL                           |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   E   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   I   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   D   | Rsvd  |  Map-Version Number   |         AFI = 16387           |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |    Rsvd1     |     Flags      |   Type = 2    | IID mask-len  |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |             4 + n             |        Instance-ID...         |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |       ...Instance-ID          |        EID-AFI = 6            |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                   Layer-2 MAC Address  ...                    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /| ... Layer-2 MAC Address       |    Priority   |    Weight     |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |  M Priority   |   M Weight    |        Unused Flags     |L|p|R|
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | | |           Loc-AFI             |     Locator....               |
   | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|       ...   Locator
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The L2 EID record follows the structure as described in [RFC9301].

6.2.3.  Interface to the LISP Mapping System

   The interface between the xTRs and the Mapping System is described in
   [RFC9301] and this document follows the specification as described
   there.  When available, the registrations MAY be implemented over a
   reliable transport.

   In order to support system convergence after mobility, when the Map-
   Server receives a new registration for a specific EID, it MUST send a
   Map-Notify to the entire RLOC set in the site that last registered
   this same EID.  This Map-Notify is used to track moved-away state of
   L2 EIDs as described in Section 6.2.4.

6.2.4.  SMR support to track L2 hosts that moved away

   In order to support mobility, an ETR SHALL maintain a list of EID
   records for which it has to generate a SMR message whenever it
   receives traffic with that EID as destination.

   The particular strategy to maintain a SMR table is implementation
   specific.  In essence the table SHOULD provide support for the
   following:



Portoles, et al.        Expires 20 November 2026               [Page 16]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   *  Keep track of end-hosts that were once connected to an ETR and
      have moved away.

   *  Support for L2 EID records, the 2-tuple (IID, MAC), for which a
      SMR message SHOULD be generated.

6.2.5.  L2 Broadcast and Multicast traffic

   Broadcast and Multicast traffic on the L2-overlay is supported by
   either replicated unicast, or underlay (RLOC) multicast.

   xTRs that offer L2 overlay services and are part of the same
   Instance-ID join a common Multicast Group.  When required, this group
   allows ITRs to send traffic that needs to be replicated (flooded) to
   all ETRs participating in the L2-overlay (e.g., broadcast traffic
   within a subnet).  When the core network (RLOC space) supports native
   multicast, ETRs participating in the L2-overlay join a (*,G) group
   associated with the Instance-ID.

   When multicast is not available in the core network, each xTR that is
   part of the same instance-ID SHOULD register a (S,G) entry to the
   mapping system using the procedures described in [RFC8378], where S
   is 0000-0000-0000/0 and G is ffff-ffff-ffff/48.  This strategy allows
   an ITR to know which ETRs are part of the L2 overlay and it can head-
   end replicate traffic to.

   Following the same case, when multicast is not available in the core
   network, the procedures in [RFC8378] can be used to ensure proper
   distribution of multicast traffic locally between xTRs participating
   in the L2 overlay.  In such a case, the xTRs SHOULD join (S,G)
   entries with S being 0000-0000-0000/0 and where G is
   0100-5e00-0000/25 and 3333-0000-0000/16.

6.2.6.  L2 Unknown Unicast Support

   An ITR attempts to resolve MAC destination misses through the Mapping
   System.  When the destination host remains undiscovered the
   destination is considered an Unknown Unicast.

   A Map-Server SHOULD respond to a Map-Request for an undiscovered host
   with a Negative Map-Reply with action "Natively-Forward".
   Alternatively the action "Drop" may be used in order to suppress
   Unknown Unicast forwarding.

   An ITR that receives a Negative Map-Reply with Action "Natively-
   Forward" will handle traffic for the undiscovered host as L2
   Broadcast traffic and will be unicast replicated or flooded using
   underlay multicast to the rest of ETRs in the Layer-2 overlay.



Portoles, et al.        Expires 20 November 2026               [Page 17]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   Upon discovery of a previously unknown unicast MAC EID, a data
   triggered SMR for the discovered EID should be sent by the discovery
   ETR back to the ITRs that are flooding the unknown unicast traffic.
   This would allow ITRs to refresh their caches and stop flooding
   unknown unicast traffic as necessary.

6.2.7.  Time-to-Live Handling in Data-Plane

   When using a L2 overlay and the encapsulated traffic is IP traffic,
   the Time-to-Live value of the inner IP header MUST remain unmodified
   during encapsulation and decapsulation.  Network hops traversed as
   part of the L2 overlay SHOULD be hidden to tools like traceroute and
   applications that require direct L2 connectivity.

6.3.  Multihoming Support

   L2 multihoming support requires additional mechanisms to those
   specified in [RFC9300] and [RFC9301] to provide LISP multihoming.

   In order to support packet flow descriptions related to L2
   multihoming, this section uses Figure 4 as a reference.  The figure
   expands site B in the previous figures to become a multihomed site
   with identifier site-ID "b".


                             /                 \
                         RLOC=IP_B1        RLOC=IP_B2
                         +-+--+--+         +-+--+--+
                        .| xTR B1|.-.--.-.| xTR B2 |.-.
                       ( +-+--+--+         +-+--+--+   )
                     .'            Site B               )
                     (           (site-ID b)          .'
                      '--'._.'.    .'._.'--'._.'.    )
                               '--'    |         '--'
                                  '--------'
                                  :  End   :
                                  :Device 2:
                                  '--------'
                                (IID1,3.0.0.2)
                              (IID2,0:0:3:0:0:2)

                    Figure 4: Reference Multihomed Site









Portoles, et al.        Expires 20 November 2026               [Page 18]

Internet-Draft             L2/L3 EID Mobility                   May 2026


6.3.1.  Identification of L2 multihomed sites

   The site-ID, as defined in [RFC9301], is used as the identifier that
   enables logical grouping of multiple xTRs that provide multihomed
   access to a L2 domain.

   All EID-to-RLOC mappings from ETRs in a L2 multihomed site MUST be
   registered with the site-ID, by setting bit I in the Map-Register
   message.

6.3.2.  Discovery of peer xTRs in multihomed sites

   Providing L2 multihomed access support for L2 domains requires that
   participating xTRs discover each other and implement procedures like
   designated forwarder selection or split-horizon filtering.

   To this end, the discovery and grouping of multihomed xTRs is
   supported through registration, by all participating xTRs, of a
   common EID that carries the site-ID of the site that they are
   providing multihoming access to.  The Mapping System merges these
   registrations and notifies all participating xTRs about the
   aggregated list.

   Specifically, multihomed xTRs use an EID of the Distinguished Name
   type [RFC9735] with name "L2-xTRs-<site-ID>" to support the
   multihomed site-ID registration.  The site-ID part of the EID MUST be
   encoded using the string representation of the hexadecimal value of
   the site-ID.

   This EID is registered by each xTR with their corresponding locator
   set in the RLOC record. xTRs MUST set the merge-request bit (a bit)
   in the registration. xTRs MUST also set the want-map-notify bit (M
   bit) so that they can learn about all participating xTRs when they
   register.

   In its turn the Mapping System, when receiving every multihomed site-
   ID registration, MUST aggregate the locator-set received from each
   xTR and send a Map-Notify to all participating xTRs with the
   resulting locator set list.

   Note that the xTRs and Mapping System use a dedicated IID to carry
   and hold these registrations.  The specific name used is predefined
   as specified in this document and only used within the dedicated IID.

   Using the reference figure above, the process of xTR discovery in a
   L2 multihomed group works as follows:





Portoles, et al.        Expires 20 November 2026               [Page 19]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   *  xTR B1 registers EID with name "L2-xTRs-b" and IP_B1 as its
      corresponding locator-set

   *  The Map-Server creates a registration entry with the mapping
      EID="L2-xTRs-b" -> RLOC=IP_B1.  It also sends a Map-Notify to xTR
      B1 with the mapping

   *  xTR B2, registers EID with name "L2-xTRs-b" and IP_B2 as its
      corresponding locator-set.

   *  The Map-Server merges the new registration with the existing one
      obtaining a mapping with EID="L2-xTRs-b" -> RLOC=<IP_B1, IP_B2>.
      It also sends a Map-Notify to xTR B1 and xTR B2 with the
      aggregated mapping.

   After the Map-Server notifies xTRs with the merged list of locators,
   all xTRs have an up-to-date list of participating xTRs.  Whenever a
   xTR joins or leaves the multihoming group, the Map-Server MUST send
   an updated Map-Notify to all the remaining participants.

6.3.3.  Designated Forwarder Selection

   When multiple xTRs are providing multihomed access to a L2 site, a
   Designated Forwarder must be selected to forward L2 broadcast,
   unknown unicast and multicast traffic to and from other sites.

   LISP sites use the M-priority field in the RLOC record of mappings to
   rank which xTR is the selected forwarder for a site.  When the
   M-priority is the same, the xTRs use RLOC addresses to break the tie.

   Using the reference figure, the following sequence illustrates how
   the forwarder is selected and notified to all of the xTRs:

   *  xTR B1, registers the mapping EID="L2-xTRs-b" -> RLOC=IP_B1 with
      the Mapping System and sets the M-priority value of the RLOC to 1

   *  xTR B2, registers the mapping EID="L2-xTRs-b" -> RLOC=IP_B2 with
      the Mapping System and sets the M-priority value of the RLOC to 2

   *  The Map-Server merges the registrations and sends a Map-Notify to
      both xTR B1 and xTR B2, with the merged locator-set and respecting
      the M-priority of each RLOC

   *  On receiving the Map-Notify xTR B1 finds its own RLOC as having
      the best M-priority and starts acting as the broadcast Forwarder






Portoles, et al.        Expires 20 November 2026               [Page 20]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   *  On receiving the Map-Notify xTR B2 discovers that xTR B1 has a
      better M-priority, sets itself as backup forwarder. xTR B2 SHOULD
      start monitoring xTR B1 to take an active forwarder role if xTR B1
      becomes unavailable.

   In case multihomed xTRs register the multihomed site-ID EID with the
   same M-priority, the xTRs will use RLOC address sorting to break the
   tie. xTRs MUST use the numerical IP ascending order defined in
   [RFC9301] to sort the RLOCs and break the tie.

   Note that multihomed xTRs can register multiple site-IDs with
   different M-priorities and select a different Designated Forwarder
   for each site.  When different L2 segments want to use a different
   forwarder they are assigned to the corresponding site according to
   the preference.

6.3.4.  Split Horizon filtering

   A xTR that discovers that it is part of a L2 multihoming group,
   SHOULD implement procedures to ensure that packets forwarded from the
   L2 multihomed site are not looped back into the site.  The list of
   RLOCs learned through the L2 multihoming site-ID registration SHOULD
   be used to apply the necessary filtering to encapsulated packets
   received by the xTR from peer xTRs.  Filtering is done using source
   RLOCs of the received packets.

6.3.5.  Multihoming operation

   When providing multihomed access to a L2 site, any xTR can be used to
   forward traffic to and from remote sites.  Unicast traffic is
   typically load split between the multiple xTRs.  The Designated
   Forwarder MAY be the only one joining the multicast group or
   replication list (following Section 6.2.5).

   If a non-Designated Forwarder decides to join the multicast group, it
   MUST implement split horizon filtering as well as ensure that remote
   traffic is not forwarded to the local site, to avoid duplication.

   Specifically, xTRs that are providing active multihoming access to a
   site MUST support the following:

   *  All active xTRs register site L2 mappings with the Mapping System.
      The registration must have the I bit set and carry both the site-
      ID and the corresponding xTR-ID.  The Map-Register MUST also have
      the merge-request bit (a bit) set and the want-map-notify bit (M)
      set, so that they can learn when L2 xTR peers also discover the
      same Mapping.




Portoles, et al.        Expires 20 November 2026               [Page 21]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   *  A Map-Server only merges RLOCs from mappings with the same site-
      ID, and MUST send a Map-Notify message after receiving Map-
      Register messages following the procedures in Section 6.1.2 and
      also honoring the want-map-notify bit (M), following [RFC9301].

   *  The selected Designated Forwarder joins the L2 multicast group or
      replication list as specified in Section 6.2.5

   *  The selected Designated Forwarder is the only one that can forward
      broadcast traffic to and from remote sites.

   *  xTRs that are not Designated Forwarder are recommended not to join
      the L2 broadcast group.  When a non-Designated Forwarder joins the
      broadcast group it MUST implement split horizon and broadcast
      suppression mechanisms to avoid traffic duplication and loops in
      the site.

   Note that in multihomed environments the Map-Server resolves the
   possible ambiguity between multihoming registrations and endpoint
   roaming when it only merges RLOCs from registrations with the same
   site-ID.  This allows xTRs to continue differentiating a move from a
   multihoming aggregation by verifying the presence of their own RLOC
   in the locator-set of a Map-Notify packet.

6.4.  Support to ARP resolution through Mapping System

6.4.1.  Map-Server support to ARP resolution: Packet Flow

   A large majority of applications are IP based and, as a consequence,
   end systems are typically provisioned with IP addresses as well as
   MAC addresses.

   In this case, to limit the flooding of ARP traffic and reduce the use
   of multicast in the RLOC network, the LISP mapping system MAY be used
   to support ARP resolution at the ITR.

   In order to provide this support, ETRs handle and register an
   additional EID-to-RLOC mapping as follows,

   *  EID-record contents = <IID, IP>, RLOC-record contents = <MAC>.











Portoles, et al.        Expires 20 November 2026               [Page 22]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   There is a dedicated IID used for the registration of the ARP/ND
   related mappings.  Thus, a system with L2 and L3 overlays as well as
   ARP/ND mappings would have three IIDs at play.  In the spirit of
   providing clarity, we will refer to those IIDs as L2-IID, L3-IID and
   ARP-IID respectively.  By using these definitions, we do not intend
   to coin new terminology, nor is there anything special about those
   IIDs that would make them differ from the generic definition of an
   IID.  The types of mappings expected in such a system are summarized
   below:

   *  EID = <IID1, IP> to RLOC = <IP-RLOC> (L3-overlay)

   *  EID = <IID2, MAC> to RLOC = <IP-RLOC> (L2-overlay)

   *  EID = <IID3, IP> to RLOC = <MAC-RLOC> (ARP/ND mapping)

   The following packet flow sequence describes the use of the LISP
   Mapping System to support ARP resolution for hosts residing in a
   subnet that is extended to multiple sites.  Using Figure 1, End-
   Device 2 tries to find the MAC address of End-Device 3.  Note that
   both have IP addresses within the same subnet:

   *  End-Device 2 sends a broadcast ARP message to discover the MAC
      address of End-Device 3.  The ARP request targets IP 3.0.0.3.

   *  ITR B receives the ARP message, but rather than flooding it on the
      overlay network sends a Map-Request to the mapping database system
      for EID = <IID3,3.0.0.3>.

   *  When receiving the Map-Request, the Map-Server sends a Proxy-Map-
      Reply back to ITR B with the mapping EID = <IID3,3.0.0.3> -> MAC
      0:0:3:0:0:3.

   *  Using this Map-Reply, ITR B sends an ARP-Reply back to End-Device
      2 with the tuple IP 3.0.0.3, MAC 0:0:3:0:0:3.

   *  End-Device 2 learns MAC 0:0:3:0:0:3 from the ARP message and can
      now send L2 traffic to End-Device 3.  When this traffic reaches
      ITR B is sent over the L2-overlay as described above in
      Section 6.1.1.

   This example shows how LISP, by replacing dynamic data plane learning
   (such as Flood-and-Learn) can reduce the use of multicast in the
   underlay network.







Portoles, et al.        Expires 20 November 2026               [Page 23]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   Note that ARP resolution using the Mapping System is a stateful
   operation on the ITR.  The source IP,MAC tuple coming from the ARP
   request has to be stored to generate the ARP-reply when the Map-Reply
   is received.

   Note that the ITR SHOULD cache the ARP entry.  In that case future
   ARP-requests can be handled without sending additional Map-Requests.

6.4.2.  ARP registrations: MAC as a locator record

   When an end-host is attached or detected in an ETR that provides
   L2-overlay services and also supports ARP resolution using the LISP
   control-plane, an additional mapping entry is registered to the
   mapping system:

   *  The EID 2-tuple (IID, IP) and its binding to a corresponding host
      MAC address.

   In this case both the xTRs and the Mapping System MUST support an
   EID-to-RLOC mapping where the MAC address is set as a locator record.
   Since this locator is not used for forwarding, it MUST be registered
   with priority 255.

   In order to guarantee compatibility with current implementations of
   xTRs, the MAC locator record SHALL be encoded following the AFI-List
   LCAF Type defined in [RFC8060].  This option would also allow adding
   additional attributes to the locator record, while maintaining
   compatibility with legacy devices.

   This mapping is registered with the Mapping System using the
   following EID record structure,




















Portoles, et al.        Expires 20 November 2026               [Page 24]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record TTL                           |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   E   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   I   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   D   | Rsvd  |  Map-Version Number   |         AFI = 16387           |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |    Rsvd1     |     Flags      |   Type = 2    | IID mask-len  |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   |             4 + n             |        Instance-ID...         |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |       ...Instance-ID          |        EID-AFI = 1 or 2       |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                    EID-Prefix (IPv4 or IPv6)                  |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | M |        Unused Flags     |L|p|R|        AFI = 16387            |
   | A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | C |    Rsvd1     |     Flags      |   Type = 1    |     Rsvd2     |
   | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | | |             2 + 6             |             AFI = 6           |
   | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | | |                    Layer-2 MAC Address  ...                   |
   | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \| ... Layer-2 MAC Address       |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.

   An EID record with a locator record that carries a MAC address
   follows the same structure as described in [RFC9301].  However, some
   fields of the EID record and the locator record require special
   consideration:

   Locator Count:  This value SHOULD be set to 1.

   Instance-ID:  This is the IID used to provide segmentation of the
      L2-overlays, L3 overlays and ARP tables.

   Priority and Weight:  IP to MAC bindings are one-to-one bindings.  An
      ETR SHOULD NOT register more than one MAC address in the locator
      record together with an IP based EID.  The Priority of the MAC
      address record is set to 255.  The Weight value SHOULD be ignored
      and the recommendation is to set it to 0.

   L bit:  This bit of the locator record SHOULD only be set to 1 when
      an ETR is registering its own IP to MAC binding.

   p bit:  This bit of the locator record SHOULD be set to 0.



Portoles, et al.        Expires 20 November 2026               [Page 25]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   R bit:  This bit of the locator record SHOULD be set to 0.

   Note that an IP EID record that carries a MAC address in the locator
   record SHALL be registered with the Proxy Map-Reply bit set.

6.4.3.  Implementation Considerations

   While ARP support through the LISP Mapping System fits the LISP
   control plane there are a series of considerations to take into
   account when providing this feature:

   *  As indicated, when an end-host is attached the ETR maintains and
      registers a mapping with the binding EID = <IID, IP> -> RLOC =
      <MAC>.

   *  ARP support through the LISP Mapping System is OPTIONAL and the
      xTRs should allow the possibility to enable or disable the
      feature.

   *  When the ARP entry has not been registered, a Map Server SHOULD
      send a Negative Map-Reply with action "No-Action" as a response to
      an ARP based Map Request.

   *  In case the ITR receives a Negative Map-Reply for an ARP request
      it should fall back to flooding the ARP packet as any other L2
      Broadcast packet (as described in Section 6.2.5).

   *  When receiving a positive Map-Reply for an ARP based Map-Request,
      the ITR/xTR MUST recreate the actual ARP Reply, impersonating the
      real host.  As a consequence, ARP support is a stateful operation
      where the ITR needs to store enough information about the host
      that generates an ARP request in order to recreate the ARP Reply.

   *  ARP replies learned from the Mapping System SHOULD be cached and
      the information used to reply to subsequent ARP requests to the
      same hosts.

7.  Optional Deployment Models

   The support of an integrated L2 and L3 overlay solution allows
   multiple architectural design options, that depend on the specific
   requirements of the deployment environment.  While the previous
   sections describe specific packet flows and solutions based on the
   recommended solution, this section documents OPTIONAL design
   considerations that differ from the recommended one but that MAY be
   required on alternative deployment environments.





Portoles, et al.        Expires 20 November 2026               [Page 26]

Internet-Draft             L2/L3 EID Mobility                   May 2026


7.1.  IP Forwarding of Intra-subnet Traffic

   As pointed out at the beginning the recommended selection of the L2
   and L3 overlays is not the only one possible.  In fact, providing L2
   extension to some cloud platforms is not always possible and subnets
   need to be extended using the L3 overlay.

   In order to send all IP traffic (intra- and inter-subnet) through the
   L3 overlay the solution MUST change the ARP resolution process
   described in Section 6.4.1 to the following one (we follow again
   Figure 1 to drive the example.  End-Device 2 queries for End-Device
   3):

   *  End-Device 2 sends a broadcast ARP message to discover the MAC
      address of 3.0.0.3.

   *  ITR B receives the ARP message and sends a Map-Request to the
      Mapping System for EID = <IID1,3.0.0.3>.

   *  In this case, the Map-Request is routed by the Mapping system
      infrastructure to ETR C, that will send a Map-Reply back to ITR B
      containing the mapping EID = <IID1,3.0.0.3> -> RLOC=IP_C.

   *  ITR B populates its local cache with the received entry on the L3
      forwarding table.  Then, using the cache information it sends a
      Proxy ARP-reply with its own MAC (MAC_xTR_B) address to End-Device
      2.

   *  End-Device 2 learns MAC_ITR_B from the proxy ARP-reply and sends
      traffic with destination address 3.0.0.3 and destination MAC,
      MAC_xTR_B.

   *  As the destination MAC address is the one from xTR B, when xTR B
      receives this traffic it is forwarded using the L3-overlay.

   *  Note that when implementing this solution, when a host that is
      local to an ETR moves away, the ETR SHOULD locally send a
      Gratuitous ARP with its own MAC address and the IP of the moved
      away host, to refresh the ARP tables of local hosts and guarantee
      the use of the L3 overlay when connecting to the remote host.

   It is also important to note that using this strategy to extend
   subnets through the L3 overlay but still keeping the L2 overlay for
   the rest of the traffic MAY lead to flow asymmetries.  This MAY be
   the case in deployments that filter Gratuitous ARPs, or when moved
   hosts continue using actual L2 information collected before a
   migration.




Portoles, et al.        Expires 20 November 2026               [Page 27]

Internet-Draft             L2/L3 EID Mobility                   May 2026


7.2.  Data-plane Encapsulation Options

   The LISP control-plane offers independence from the data-plane
   encapsulation.  Any encapsulation format that can carry a 24-bit
   instance-ID can be used to provide the unified overlay.

   Common encapsulation formats that can be used are VXLAN-GPE, LISP and
   VXLAN:

   *  VXLAN-GPE encap: This encapsulation format is defined in
      [RFC9305].  It allows encapsulation of both L2 and L3 packets and
      the VNI field directly maps to the Instance-ID used in the control
      plane.  Note that when using this encapsulation for a unified
      solution the P-bit is set and the Next-Protocol field is used
      (typically with values 0x1 (IPv4) or 0x2 (IPv6) in L3-overlays,
      and value 0x3 in L2-overlays).

   *  LISP encap: This is the encapsulation format defined in the LISP
      specification [RFC9300].  The encapsulation allows encapsulating
      both L2 and L3 packets.  The Instance-ID used in the EIDs directly
      maps to the Instance-ID that the LISP header carries.  At the ETR,
      after decapsulation, the IID MAY be used to decide between L2
      processing or L3 processing.

   *  VXLAN encap: This is a L2 encapsulation format defined in
      [RFC7348].  While being a L2 encapsulation it can be used for both
      L2 and L3 overlays.  The Instance-ID used in LISP signaling maps
      to the VNI field of the VXLAN header.  Providing L3 overlays using
      VXLAN generally requires using the ETR MAC address as destination
      MAC address of the inner Ethernet header.  The process to learn or
      derive this ETR MAC address is not included as part of this
      document.

8.  IANA Considerations

   This memo includes no request to IANA.

9.  Acknowledgements

   This draft builds on top of two expired drafts that introduced the
   concept of LISP L2/L3 overlays (draft-maino-nvo3-lisp-cp and draft-
   hertoghs-nvo3-lisp-controlplane-unified).  Many thanks to the
   combined authors of those drafts, that SHOULD be considered main
   contributors of this draft as well: Vina Ermagan, Dino Farinacci,
   Yves Hertoghs, Luigi Iannone, Fabio Maino, Victor Moreno, and Michael
   Smith.

10.  References



Portoles, et al.        Expires 20 November 2026               [Page 28]

Internet-Draft             L2/L3 EID Mobility                   May 2026


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

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

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

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

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

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

   [RFC9305]  Maino, F., Ed., Lemon, J., Agarwal, P., Lewis, D., and M.
              Smith, "Locator/ID Separation Protocol (LISP) Generic
              Protocol Extension", RFC 9305, DOI 10.17487/RFC9305,
              October 2022, <https://www.rfc-editor.org/info/rfc9305>.





Portoles, et al.        Expires 20 November 2026               [Page 29]

Internet-Draft             L2/L3 EID Mobility                   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>.

10.2.  Informative References

   [I-D.ietf-lisp-map-server-reliable-transport]
              Venkatachalapathy, B., Portoles-Comeras, M., Lewis, D.,
              Kouvelas, I., and C. Cassar, "LISP Map Server Reliable
              Transport", Work in Progress, Internet-Draft, draft-ietf-
              lisp-map-server-reliable-transport-08, 5 April 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
              map-server-reliable-transport-08>.

   [I-D.ietf-lisp-vpn]
              Moreno, V. and D. Farinacci, "LISP Virtual Private
              Networks (VPNs)", Work in Progress, Internet-Draft, draft-
              ietf-lisp-vpn-14, 6 May 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
              vpn-14>.

Authors' Addresses

   Marc Portoles Comeras
   Cisco Systems
   170 Tasman Drive
   San Jose, CA 95134
   United States of America
   Email: mportole@cisco.com


   Vrushali Ashtaputre
   Cisco Systems
   170 Tasman Drive
   San Jose, CA 95134
   United States of America
   Email: vrushali@cisco.com







Portoles, et al.        Expires 20 November 2026               [Page 30]

Internet-Draft             L2/L3 EID Mobility                   May 2026


   Fabio Maino
   Cisco Systems
   170 Tasman Drive
   San Jose, CA 95134
   United States of America
   Email: fmaino@cisco.com


   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
   United States of America
   Email: farinacci@gmail.com






























Portoles, et al.        Expires 20 November 2026               [Page 31]
