| Internet-Draft | LISP Silent Host Discovery using the Map | September 2026 |
| Nehru & Portoles | Expires 7 March 2027 | [Page] |
The on-demand discovery model of the Locator/ID Separation Protocol (LISP) is ineffective for "silent hosts", endpoints that do not initiate traffic. This is a common challenge in environments like manufacturing and IoT environments, where low-power devices frequently go silent to conserve energy. This document proposes a mechanism to discover these hosts by using the LISP mapping system itself. xTRs that are able to probe a given EID prefix register that capability with the Map-Server. When a Map-Request for an unknown destination arrives at the Map-Server, it is forwarded and replicated to all xTRs that have registered the covering EID prefix, initiating a controlled, on-demand discovery process for that specific host. This approach provides a scalable alternative to network flooding for locating silent endpoints.¶
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 March 2027.¶
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.¶
The Locator/ID Separation Protocol (LISP) architecture relies on a pull-based model in which EID-to-RLOC mappings are learned on demand. This model operates efficiently under the assumption that endpoints actively register their presence with the LISP Mapping System. However, this assumption fails for "silent hosts", endpoints that do not initiate traffic that can be used to discovery their presence, therefore not leading to Database-Mapping creation and a Map-Register. As a result, these hosts remain undiscovered and unreachable within the LISP domain.¶
This document specifies a mechanism to discover such silent hosts by leveraging the existing LISP control plane. The core principle is to use the Map-Request for an Endpoint ID (EID) with no registration on Mapping System as a trigger. When a xTR queries the mapping system for a silent host, the Map-Server forwards and replicates that Map-Request to the xTRs that have registered to probe the covering EID prefix, initiating a controlled, on-demand discovery process targeted at that specific EID space.¶
This approach offers several key advantages over traditional discovery methods:¶
Eliminates Network Flooding: It provides a direct discovery mechanism, removing the need for network-wide broadcast or multicast flooding, which is often enabled solely for the purpose of locating silent hosts.¶
Address-Family Agnostic: The solution is applicable to IP (IPv4/IPv6) and MAC EIDs, and can be used for both Layer 2 and Layer 3 LISP deployments independent of IP version.¶
Scalable and Rate-Controlled: Because the Map-Server forwards and replicates map-requests to trigger discovery, it can enforce rate limits to protect the network from excessive probes that target non-existent or malicious EIDs.¶
Extensible Framework: The mechanism can be extended to support administrative functions, such as proactively inventorying silent hosts within a given EID prefix, without requiring new protocol machinery.¶
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].¶
For purposes of this document, terminology is used as defined in [RFC9300] and [RFC9301].¶
The silent host discovery mechanism follows a registration and forwarding model in which probing xTRs register the capability to discover endpoints with the Mapping System and the Mapping Sytem acts as the forwarding and replication point to trigger discovery. This structure decouples capability registration from the on-demand discovery trigger and is fundamental to providing a scalable solution. The high-level process is as follows:¶
Silent Host Discovery Registration: An xTR that is capable of performing silent host discovery within a locally attached EID prefix range (such as a subnet or VLAN) send a Map-Register with the Mapping System advertising the capability, the EID prefix and its RLOC(s).¶
Silent Host Discovery Table: The Mapping System maintains a registration database (the "Silent Host Discovery Table"), where the Mappings associate EID prefixes with the set of xTRs that have registered the capability to discover silent hosts within them.¶
Map-Request Replication and Forwarding: When any ITR sends a Map-Request for a destination EID that has no active registration, but that falls within an EID prefix with silent host registrations, the Mapping System replicates and forwards the Map-Request to all xTRs that have registered the ability to discover within that prefix range.¶
Local Probing and Discovery: The xTRs that have registered silent host discovery capability and receive a Map-Request for an endpoint within the range, can trigger local probing to awaken the endpoint.¶
If one of the xTRs successfully discovers the endpoint, it originates a standard Map-Register message with the Mapping System, completing the discovery cycle and allowing subsequent regular EID resolution [RFC9301] and forwarding [RFC9300].¶
Figure 1 illustrates a typical network topology where the silent host discovery mechanism is applied. The numbered steps in the description correspond to the full lifecycle, from capability registration to on-demand replication and forwarding, which unfolds when Host2 attempts to communicate with the undiscovered Host1.¶
+--------------------------+
| MS/MR |
| (Silent Host Discovery |
| Table) |
+--------------------------+
^ ^ |
(1)| (3)| | (5)
| | v
+--------------------------------------------------------------------+
| Underlay Network (RLOC Space) |
| |
| +------------+ +------------+
+-------| xTR-1 |----------------------------------| xTR-2 |----(2)--+
+------------+ +------------+ |
| EID Space
(6)| |
v +-----------+
+--------------+ | Host2 |
| Host1 | +-----------+
| (Silent Host)|
+--------------+
The discovery flow is as follows:¶
xTR-1 has the ability to discover silent hosts in the EID prefix range that covers Host1. It sends a Map-Register for the EID prefix indicating the Silent Host Discovery capability, with its own RLOC as part of the RLOC record and the merge-bit set.¶
When the Map-Server (MS/MR) receives this Map-Register adds the Mapping to the registration database indicating that this EID prefix is meant to be used for silent host discovery. RLOCs from all such registrations are merged when added to the registration database.¶
When, at a later time, Host2 sends a packet destined for Host1. The local router, xTR-2, intercepts the packet and sends a Map-Request to the Mapping System, since it has not cached any entry for the EID.¶
The MS/MR receives the Map-Request. The lookup finds the entry for the EID prefix with the silent host flag. This entry lists xTR-1 as a xTR that can discover the endpoint.¶
Note that the Mapping System MUST generate a regular negative Map-Reply towards xTR-2 as specified in [RFC9301], ignoring the presence of the silent host registration.¶
The MS/MR forwards the Map-Request to xTR-1. The Map-Request would be replicated and forwarded to any other RLOC that is part of the silent host EID record.¶
Upon receiving the forwarded Map-Request, xTR-1 triggers a local discovery. It would typically generate a local probe (such as an ARP or ND request) to the ports that provide access to the EID space that Host1 is connected to.¶
If Host1 shows signs of life, xTR-1 may follow the procedures of [I-D.ietf-lisp-eid-mobility] to on-board and track the host within the LISP network.¶
This section details the specific LISP protocol extensions and procedures required to implement silent host discovery. This specification reuses most of existing LISP interfaces as defined in [RFC9301]. As an extension it defines a new LCAF following format specified in [I-D.ietf-lisp-rfc8060bis], to indicate that an EID prefix defines a silent host discovery range in Map-Register messages.¶
A xTR that is able to trigger local silent host discovery in a specific EID prefix range, sends a Map-Register to the Mapping System indicating that. This Map-Register carries the EID prefix encapsulated using a new silent host discovery LCAF (SHD LCAF). The RLOCs in the Mapping Record correspond to the RLOCs of the xTR. The Map-Register MUST set the merge-request bit (a bit).¶
The Map-Server MUST be able to store this EID prefix with some indication that its purpose is to drive Silent Host Discovery procedures through the Mapping System. The registration record MUST aggregate (merge) the list of RLOCs corresponding to the xTRs that support Silent Host Discovery.¶
This document specifies a new LISP Canonical Address Format (LCAF) Type, the Silent Host Discovery (SHD) LCAF. It is used to encode the EID in the Mapping Record of the registration.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHD Subtype =TBD | EID AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Prefix (variable, per AFI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: to be determined when the document is adopted.¶
SHD Subtype: for now this is set to 0, but it is reserved in case silent host discovery for this prefix needs special handling.¶
The prefix length associated to the EID prefix, used to define the discovery range is carried normally, as part of the EID record in the Map-Register, as specified in [RFC9301].¶
The discovery process is triggered when the Mapping System receives a Map-Request for an EID that without a registration in the database. When the Map-Server lookup for the destination EID finds a SHD registration, the Map-Request is replicated and forwarded to all the xTRs that have registered the SHD Mapping.¶
xTRs that received the forwarded request, use this Map-Request as a trigger to attempt a local discovery of the endpoint on the local access interfaces associated to the EID prefix range.¶
To protect network resources from excessive probing, particularly from sweeping tools or denial-of-service attacks, the Map-Server MUST implement rate-limiting mechanisms. The "Silent Host Discovery Table" can serve as a state-tracking tool to control the frequency of discovery triggers.¶
Throttling can be applied at a granular level, such as for an individual host EID, or more broadly at the EID prefix level. Implementations SHOULD allow tuning of rate-limiting parameters to adapt to every specific deployment.¶
An xTR participating in silent host discovery, as specified in this document, MUST implement the following mechanisms:¶
Originate Map-Register messages containing the SHD LCAF type to advertise the capability to drive the discovery service for specific EID prefixes.¶
Process incoming forwarded Map-Request messages as a trigger for silent host discovery, when the destination EID cannot be found in local database, but it is covered by the SHD EID prefix.¶
Upon receipt, the xTR MUST initiate a local discovery (e.g. local probe) to awake the silent host on candidate interfaces.¶
A Map-Server supporting silent host discovery, as specified in this document, MUST implement the following mechanisms:¶
Process Map-Register messages containing the SHD LCAF and store these registrations with a special indication that identifies their purpose.¶
When a Map-Request matches a SHD registration, replicate and forward the Map-Request to all RLOCs in the (merged) registration.¶
Implement and apply rate-limiting policies to prevent excessive discovery triggers for any given EID or prefix.¶
The authors would like to thank Raja Janardanan(Cisco Systems), Sanjay Hooda(Cisco Systems), Balaji Pitta Venkatachalapathy(Cisco Systems) for their contributions to this document.¶