The xTR subscribes for changes to a given EID-Prefix by sending a Map-Request to the Mapping System with the N-bit set on the EID-Record. The xTR builds a Map-Request according to Section 5.3
of RFC 9301
and also does the following:
The xTR MUST set the I-bit to 1 and append its xTR-ID and Site-ID to the Map-Request.
The xTR MUST set the N-bit to 1 for the EID-Record to which the xTR wants to subscribe.
If the xTR has a nonce associated with the EID-Prefix, it MUST use this nonce increased by one in the Map-Request. Otherwise, it generates a nonce as described in Section 5.2 of RFC 9301. It is RECOMMENDED that the xTR use persistent storage to keep nonce state. If the xTR does not have persistent storage and does not have a nonce associated with the EID-Prefix, it MUST reset the nonce by using the procedure described in Section 7.1 to successfully create a new security association with the Map-Server.
The Map-Request is forwarded to the appropriate Map-Server through the Mapping System. This document does not assume that a Map-Server is pre-assigned to handle the subscription state for a given xTR. The Map-Server that receives the Map-Request will be the Map-Server responsible for notifying that specific xTR about future mapping changes for the subscribed mapping records.
Upon receipt of the Map-Request, the Map-Server processes it as described in Section 8.3
of RFC 9301
. In addition, unless the xTR is using the procedure described in Section 7.1
to create a new security association, the Map-Server MUST
verify that the nonce in the Map-Request is greater than the stored nonce (if any) associated with the xTR-ID (and EID-Prefix, when applicable). Otherwise, the Map-Server MUST
silently drop the Map-Request message and SHOULD
log the event to record that a replay attack could have occurred. Furthermore, upon processing, for the EID-Record that has the N-bit set to 1, the Map-Server proceeds to add the xTR-ID contained in the Map-Request to the list of xTRs that have requested to be subscribed to that EID-Prefix.
If an xTR-ID is successfully added to the list of subscribers for an EID-Prefix, the Map-Server MUST
extract the nonce and ITR-RLOCs present in the Map-Request and store the association between the EID-Prefix, xTR-ID, ITR-RLOCs, and nonce. Any state that is already present regarding ITR-RLOCs and/or nonce for the same xTR-ID MUST
be overwritten. When the LISP deployment has a single Map-Server, the Map-Server can be configured to keep a single nonce per xTR-ID for all EID-Prefixes (when used, this option MUST
be enabled at the Map-Server and all xTRs).
If the xTR-ID is added to the list, the Map-Server MUST
send a Map-Notify message back to the xTR to acknowledge the successful subscription. The Map-Server builds the Map-Notify according to Sections 5.5
of [RFC 9301
] with the following considerations:
The Map-Server MUST use the nonce from the Map-Request as the nonce for the Map-Notify.
The Map-Server MUST use its security association with the xTR (Section 7.1) to sign the authentication data of the Map-Notify. The xTR MUST use the security association to verify the received authentication data.
The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs received in the Map-Request (which one is implementation specific).
As a reminder, the initial transmission and retransmission of Map-Notify messages by a Map-Server follow the procedure specified in Section 5.7
of RFC 9301
. Some state changes may trigger an overload that would impact, e.g., the outbound capacity of a Map-Server. A similar problem may be experienced when a large number of state entries are simultaneously updated. To prevent such phenomena, Map-Servers SHOULD
be configured with policies to control the maximum number of subscriptions and also the pace of Map-Notify messages. For example, the Map-Server may be instructed to limit the resources that are dedicated to unsolicited Map-Notify messages to a small fraction (e.g., less than 10%) of its overall processing and forwarding capacity. The exact details to characterize such policies are deployment and implementation specific. Likewise, this document does not specify which notifications take precedence when these policies are enforced.
When the xTR receives a Map-Notify with a nonce that matches one in the list of outstanding Map-Request messages sent with an N-bit set, it knows that the Map-Notify is to acknowledge a successful subscription. The xTR processes this Map-Notify, as described in Section 5.7
of RFC 9301
use the Map-Notify to populate its Map-Cache with the returned EID-Prefix and RLOC-set. As a reminder, following Section 5.7
of RFC 9301
, the xTR has to send a Map-Notify-Ack back to the Map-Server. If the Map-Server does not receive the Map-Notify-Ack after exhausting the Map-Notify retransmissions described in Section 5.7
of RFC 9301
, the Map-Server can remove the subscription state. If the Map-Server removes the subscription state, and absent explicit policy, it SHOULD
notify the xTR by sending a single Map-Notify with the same nonce but with Loc-Count = 0 (and Loc-AFI = 0) and ACT bits set to 5 "Drop/Auth-Failure". It is OPTIONAL
for the xTR to update its Map-Cache entry for the EID-Prefix (if any) based on this Map-Notify. This message is specifically useful for cases where Map-Notifies are successfully received by an xTR, but the corresponding Map-Notify-Acks are lost when forwarded to the Map-Server. xTR implementations can use this signal to try to reinstall their subscription state instead of maintaining stale mappings.
The subscription of an xTR-ID may fail for a number of reasons. For example, it fails because of local configuration policies (such as accept and drop lists of subscribers), because the Map-Server has exhausted the resources to dedicate to the subscription of that EID-Prefix (e.g., the number of subscribers excess the capacity of the Map-Server), or because the xTR was not successful tried but was not successful in establishing a new security association (Section 7.1
If the subscription request fails, the Map-Server sends a Map-Reply to the originator of the Map-Request, as described in Section 8.3
of RFC 9301
, with the following considerations:
If the subscription request fails due to policy (e.g., for explicitly configured subscriptions, as described later in this section), the Map-Server MUST respond to the Map-Request with a Negative Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT bits set to 4 "Drop/Policy-Denied".
If the subscription request fails due to authentication (e.g., when a new security association is being established, as described in Section 7.1), the Map-Server MUST respond to the Map-Request with a Negative Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT bits set to 5 "Drop/Auth-Failure".
If the subscription request fails due to any other reason, the Map-Server MUST follow Section 8.3 of RFC 9301 with no changes.
The xTR processes any Map-Reply or Negative Map-Reply as specified in Section 8.1
of RFC 9301
, with the following considerations: if the xTR receives a Negative Map-Reply with ACT bits set to 4 "Drop/Policy-Denied" or 5 "Drop/Auth-Failure" as a response to a subscription request, it is OPTIONAL
for the xTR to update its Map-Cache entry for the EID-Prefix (if any). If the subscription request fails (for whichever reason), it is up to the implementation of the xTR to try to subscribe again.
If the Map-Server receives a subscription request for an EID-Prefix not present in the mapping database, it SHOULD
follow the same logic described in Section 8.4
of RFC 9301
and create a temporary subscription state for the xTR-ID to the least specific prefix that both matches the original query and does not match any EID-Prefix known to exist in the LISP-capable infrastructure. Alternatively, the Map-Server can determine that such a subscription request fails and send a Negative Map-Reply following Section 8.3
of RFC 9301
. In both cases, the TTL of the temporary subscription state or the Negative Map-Reply SHOULD
be configurable, with a value of 15 minutes being RECOMMENDED
The subscription state can also be created explicitly by configuration at the Map-Server (possible when a pre-shared security association exists, see Section 7
) using a variety of means that are outside the scope of this document. If there is no nonce that can be used for the explicit subscription state at the time the explicit subscription is configured (e.g., from a different subscription already established with the same xTR when a single nonce is kept per xTR-ID), then both the xTR and Map-Server MUST
be configured with the initial nonce. RECOMMENDED
to have a configuration option to enable (or disable) the xTR to accept publication information for EID-Prefixes that the xTR did not explicitly subscribe to. By default, the xTR is allowed to modify explicitly configured subscription state following the procedures described in this section; however, this MAY
be disabled at the Map-Server via configuration. If the Map-Server is instructed to not allow xTRs to modify explicitly configured subscriptions, and an xTR tries to do so, this triggers a Negative Map-Reply with ACT bits set to 4 "Drop/Policy-Denied" as described earlier in this section.
The following specifies the procedure to remove a subscription:
If a valid Map-Request with the N-bit set to 1 only has one ITR-RLOC with AFI = 0 (i.e., Unknown Address), the Map-Server MUST remove the subscription state for that xTR-ID (unless this is disabled via configuration, see previous paragraph).
If the subscription state is removed, the Map-Server MUST send a Map-Notify to the source RLOC of the Map-Request.
If the subscription removal fails due to configuration, this triggers a Negative Map-Reply with ACT bits set to 4 "Drop/Policy-Denied" as described earlier in this section; the Map-Server sends the Negative Map-Reply to the source RLOC of the Map-Request in this case.
Removing subscription state at the Map-Server can lead to replay attacks. To soften this, the Map-Server SHOULD keep the last nonce seen per xTR-ID (and EID-Prefix, when applicable).
If the Map-Server does not keep the last nonces seen, then the Map-Server MUST require the xTRs to subscribe using the procedure described in Section 7.1 to create a new security association with the Map-Server.
If the Map-Server receives a Map-Request asking to remove a subscription for an EID-Prefix without subscription state for that xTR-ID and the EID-Prefix is covered by a less-specific EID-Prefix for which subscription state exists for the xTR-ID, the Map-Server SHOULD
stop publishing updates about this more-specific EID-Prefix to that xTR until the xTR subscribes to the more-specific EID-Prefix. The same considerations regarding authentication, integrity protection, and nonce checks, which are described in this section and Section 7
for Map-Requests used to update subscription state, apply for Map-Requests used to remove subscription state.
When an EID-Prefix is removed from the Map-Server (either when explicitly withdrawn or when its TTL expires), the Map-Server notifies its subscribers (if any) via a Map-Notify with TTL equal to 0.