| Internet-Draft | lisp-delegated-mappings | October 2025 |
| Portoles, et al. | Expires 20 April 2026 | [Page] |
The LISP protocol with its inherent decoupling of control-plane and data-plane, offers the flexibility to support modern networking paradigms. This document specifies how to use the LISP protocol to enable centralized onboarding and management of EIDs within a network from an external controller or orchestration system.¶
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.¶
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 April 2026.¶
Copyright (c) 2025 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.¶
As new compute system environments emerge, routing networks have been adapting to serve their communication needs. In many of these cases, network controllers or orchestration engines are used to organize resources or enforce network policies in a centralized manner.¶
Examples of these types of systems range from wireless systems in enterprise environments, Software-Defined Networks (SDN) (e.g., in WAN, Datacenter, or Campus environments), and include public (or private) cloud networks.¶
In all these cases, it is common that a centralized controller or orchestrator drives how endpoints authenticate, join, leave, or move within the network. In many cases, this centralized controller is also the point of reference that determines the policies that need to be enforced.¶
Networks running the LISP protocol can exploit the vantage point of these controllers for early and faster onboarding and movement of endpoints at selected locations of the network. Controllers that deploy or authenticate sites and endpoints can interface directly with the Mapping System to distribute this information to selected locations (xTRs).¶
This document specifies Delegated Mappings, where a controller can use its interface to a LISP Mapping System to delegate ownership of specific EIDs to selected xTRs of the network. The document provides a detailed description of the mechanisms used to distribute this type of mappings in a network running the LISP protocol.¶
In particular, the specification describes:¶
How a controller may use the LISP Map-Register and Map-Notify interfaces to distribute Delegated Mappings to LISP sites that should take ownership of specific EIDs.¶
The procedures that an ETR follows to take ownership of a Delegated Mapping so that an EID can be resolved using LISP protocol procedures.¶
Finally, it also details how the controller can make use of specific LCAF encodings such as ELPs and multiple data-planes (see [RFC8060]), to convey EID access information to the corresponding ETR.¶
Note also that Delegated Mappings can be combined with the procedures specified in [I-D.ietf-lisp-eid-mobility] to support controller-based mobility in a network running the LISP protocol.¶
The document uses the terms defined in Section 3 of documents [RFC9300] and [RFC9301].¶
Additionally, this document introduces the following terms:¶
Figure 1 illustrates a reference system model used to support the discussion of Delegated Mappings through this section.¶
------------
| xTR |
| Controller |------------,
| | |
------------ |
+----+----+
| Map |
| Server |
+----+----+
_..-._.--._..._.,.-|._._.-._.-_._.-..
.-.' '.-.
( )
( )
'.-..-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-.'
| |
RLOC=IP_A RLOC=IP_B
+-+--+--+ +-+--+--+
.| xTR A |.-. .| xTR B |.-.
( +-+--+--+ ) ( +-+--+--+ )
.' Site A ) .' Site B )
( . ( .
'--'._.'. ) '--'._.'. )
| '--' | '--'
'--------' '--------'
: Host 1 : : Host 2 :
'--------' '--------'
IP: 10.0.0.1 IP: 10.1.1.2
A xTR-controller implements LISP control-plane interfaces so that it can interact with the LISP Mapping System, represented with a single Map-Server in the figure. The interconnection between the xTR-controller and the Map-Server is out of the scope of this specification, but the Map-Server MUST be able to handle Map Registration procedures through this connection.¶
The network running the LISP protocol has two sites (A and B) with the corresponding xTRs providing access to them. There is a local endpoint on each one of the sites (host 1 and 2)¶
For the purpose of this specification the xTR-Controller knows when endpoints are connected, authenticated or released from each one of the sites. The controller is also aware of the xTRs (and their corresponding RLOC addresses) that provide access to each one of the sites.¶
When a xTR-Controller attempts to use the process of Delegated Mappings to distribute EID Mappings to target LISP sites, it MUST know beforehand the RLOCs of the xTRs providing access to those sites. Using Figure 1 as reference, the xTR-controller knows that IP_A is the RLOC of xTR A, associated to site A.¶
Using this information, the xTR-controller uses Delegated Mappings to distribute information about Host 1 to Site A using the following procedures:¶
This operation repeats for every EID and for every site that the xTR-Controller wants to distribute information to.¶
The distribution of Delegated Mappings relies on the use of the D-bit (see Section 4) both in the Map-Register and Map-Notify messages.¶
The xTR-Controller sending a Delegated Mapping MUST NOT set the authoritative bit in the EID record. Only the site ETR, after accepting a Delegated Mapping can set this bit when registering the EID prefix.¶
Equally, a Map-Register carrying a Delegated Mapping MUST NOT have the Proxy Map-Reply bit (P-bit) or the security-capable (S-bit) set. Since the xTR-controller is not authoritative for the Mapping, it cannot set either of these bits. Only the authoritative ETR for the destination site can set these bits with its corresponding Map-Register, when accepting the Delegated Mapping.¶
A Delegated Mapping can also be removed. In that case the xTR-Controller MUST send the Map-Register with the D-bit and with a TTL with value 0 in the EID record. This removal MUST carry the RLOC record corresponding to the site that the Delegated Mapping is being removed from. The Map-Notify with the D-bit set is sent to all the RLOCs in the RLOC record with the same TTL of value 0.¶
A Map-Server that supports Delegated Mappings, SHOULD send a Map-Notify with the D-bit to all the RLOCs in the RLOC record of the Delegated Mapping.¶
A Map-Server MAY record in its registration table a Delegated Mapping, but it MUST NOT use a Delegated Mapping Record to send a proxy Map-Reply in response to a Map-Request for the EID in the Mapping. In such a case, the Map-Server MAY forward the Map-Request to one of the RLOCs in the record, following [RFC9301].¶
This restriction extends to the procedures described in [RFC9437]. A Map-Server MUST NOT send Map-Notify with a Delegated Mapping as a publication message for EID subscribers. Only the Map-Register from the authoritative ETR can be published following LISP Publish/Subscribe procedures.¶
In order to avoid periodic Map-Register and Map-Notification messages, Delegated Mappings MAY be distributed using a reliable transport as described in [I-D.ietf-lisp-map-server-reliable-transport].¶
When an ETR receives Map-Notify with a Delegated Mapping (D-bit set) that carries its own RLOC in the RLOC record it SHOULD verify the reachability of the EID in the site before accepting the mapping. The verification process is out of scope of this document.¶
Once the Mapping is accepted the ETR adds the EID in its local mapping database and it MUST send a Map-Register with the EID Record setting the authoritative bit (A-bit).¶
The ETR MUST be able to follow procedures described in [RFC9300] and [RFC9301] when handling EID records learned through the Delegated Mapping procedure.¶
When the ETR receives a Map-Notify with a Delegated Mapping with a TTL of value 0 it SHOULD remove the EID from the local mapping database.¶
When the ETR receives a Delegated Mapping that does not carry its own RLOC in the RLOC record it MUST follow the procedures described in [I-D.ietf-lisp-eid-mobility] and handle this as a mobility event.¶
This document proposes an extension of the Map-Register and Map-Notify messages to carry the notion that a Mapping is being distributed as a Delegated Mapping. This information is used by both Map-Server and ETRs to implement the procedures described in this specification.¶
The Map-Register header, as defined in [RFC9301] is extended with an additional field, the Delegated Mapping bit (D-bit).¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P|S|I|D| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
a¶
The Map-Notify header, as defined in [RFC9301], is extended with an additional field, the Delegated Mapping bit.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=4 |D| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
In many cases a controller using Delegated Mappings needs to convey EID access information to the ETRs that receive the EID record. This access information indicates what is the path that the ETR can take to reach the EID within the local site.¶
As a reference example, if we take site B in the reference system, Figure 2 illustrates the case when there is an intermediate router (r) between xTR B and Host 2. In this example xTR B must route traffic through the intermediate router to reach the endpoint:¶
|
RLOC=IP_B
+-+--+--+
| xTR B |
+-+--+--+
|
(IP_r)
+-+--+--+
| r |
+-+--+--+
|
'--------'
: Host 2 :
'--------'
IP: 10.1.1.2
A xTR-Controller MAY use ELPs (LCAF type 10 in [RFC8060]) in Delegated Mappings to convey information to the ETR about how to access the EID, when required. The ETR can use this information to program a forwarding path to the EID and also to verify reachability of the EID before accepting a Delegated Mapping.¶
The First locator in the ELP sequence MUST correspond to the RLOC of the ETR and the rest of locators MUST correspond to the sequence of hops that the ETR should follow to reach the EID.¶
It is worth noting also that local site reachability between the ETR and the endpoint may not require encapsulation or alternative encapsulations to the one used in the rest of the network. To solve this case each locator in the ELP is sent using the Multiple Data-Planes LCAF (Type 16 in [RFC8060]) and selecting the bit corresponding to the encapsulation type. When no encapsulation is needed Type 16 is also used but with all encapsulation bits set to 0.¶
In order to illustrate this, Figure 3 exemplifies the use of the ELP and Multiple Data-Plane LCAFs for the figure above. In this reference encoding, the ELP carries both the IP address of xTR B and the intermediate router r. The IP of the intermmediate router is disttribured indicating that no encapsulation is needed and xTR B can access Host 2 routing packets through IP_r.¶
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E | Locator Count | EID mask-len | ACT |A| Reserved | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D | Rsvd | Map-Version Number | EID-AFI = 1 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-Prefix (10.1.1.2) | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c /| Priority | Weight | M Priority | M Weight | o | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r R | Unused Flags |L|p|R| AFI = 16387 | d L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | O | Rsvd1 | Flags | Type = 10 | Rsvd2 | | C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Length | Rsvd3 |L|P|S| | R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E | AFI = 1 or 2 | IP_B ~ | C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | O ~ IP_B | | R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | D | Rsvd3 |L|P|S| AFI = 16387 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E | Rsvd1 | Flags | Type = 16 | Rsvd2 | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P | Length | 0 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 0 | AFI = 1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| IP_r | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Delegated Mappings can be used in environments running the LISP protocol that implement VPN based segmentation ([I-D.ietf-lisp-vpn]) and EID mobility ([I-D.ietf-lisp-eid-mobility]).¶
Delegated Mappings can be distributed using VPN segmentation procedures, following the procedures described in [I-D.ietf-lisp-vpn]. When the xTR-controller intents to distribute EIDs within specific VPN segments, it MUST use the same IID that is used in the target LISP site for that segment.¶
Following the same procedures, a Map-Register and Map-Notify with the D-bit set carry the XEID encoded using the Instance-id LCAF ([RFC8060]) in the EID record.¶
An ETR receiving a Map-Notify with the D-bit set and with an IID that is not known or used, SHOULD ignore the Map-Notify.¶
It is NOT RECOMMENDED to use Delegated Mappings with extranet encoding to distribute Mappings across IID boundaries. The Map-Server SHOULD prevent this distribution.¶
When Delegated Mappings are combined with the procedures of [I-D.ietf-lisp-eid-mobility], a controller can be used to drive the mobility of EIDs through the network.¶
A Map-Server that receives a Map-Register with the D-bit set, SHOULD generate a Map-Notify with the D-bit set to all ETRs that have an active registration of the Mapping.¶
When an ETR receives a Delegated Mapping with a RLOC record that does not have any local RLOC on the ETR, it must treat the Mapping as a mobility event and follow the procedures in [I-D.ietf-lisp-eid-mobility]¶
Delegated Mappings can be distributed using a reliable transport as described in [I-D.ietf-lisp-map-server-reliable-transport]. Since both Map-Register and Map-Notify encodings are reuse when sending Reliable Registrations and Reliable Notifications, the same D-bit is used in this case to indicate the distribution of a Delegated Mapping.¶
Map-Register and Map-Notify messages MUST be authenticated following the procedures specified in [RFC9301]. XTR-Controllers follow the same procedures.¶
Map-Notify messages carrying Delegated Mappings are handled by ETRs as unsolicited Map-Notify messages, following [RFC9301]. The Map-Server MUST use the pre-shared key associated to the target Site of the Delegated Mapping to authenticate the Map-Notify.¶
This memo includes no request to IANA.¶