1. LISP Security (LISP-SEC) MUST be implemented [RFC 9303]. This means that the S-bit MUST be set in the Map-Reply (Section 5.4), Map-Register (Section 5.6), and Encapsulated Control Messages (ECMs) (Section 5.8).
2. Implementations SHOULD use 'HMAC-SHA256-128+HKDF-SHA256' as the Algorithm ID (Section 12.5) in the Map-Register message (Section 5.6) and MUST NOT use 'None' or 'HMAC-SHA-1-96-None' as the Algorithm ID (Section 12.5) in the Map-Register message (Section 5.6).

Map-Server:

A network infrastructure component that learns of EID-Prefix mapping entries from an ETR, via the registration mechanism described below, or some other authoritative source if one exists. A Map-Server publishes these EID-Prefixes in a mapping database.

Map-Request:

A control plane message that queries the Mapping System to resolve an EID. A LISP Map-Request can also be sent to an RLOC to test for reachability and to exchange security keys between an encapsulator and a decapsulator. This type of Map-Request is also known as an RLOC-Probe Request.

Map-Reply:

A control plane message returned in response to a Map-Request sent to the Mapping System when resolving an EID. A LISP Map-Reply can also be returned by a decapsulator in response to a Map-Request sent by an encapsulator to test for reachability. This type of Map-Reply is known as an RLOC-Probe Reply.

Encapsulated Map-Request:

A LISP Map-Request carried within an ECM. This Map-Request has an additional LISP header prepended. Sent to UDP destination port 4342. The "outer" addresses are routable IP addresses, also known as RLOCs. Used by an ITR when sending to a Map-Resolver and by a Map-Server when forwarding a Map-Request to an ETR.

Map-Resolver:

A network infrastructure component that accepts LISP Encapsulated (ECM) Map-Requests, typically from an ITR, and determines whether or not the destination IP address is part of the EID namespace; if it is not, a Negative Map-Reply is returned. Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC mapping by consulting a mapping database system.

Negative Map-Reply:

A LISP Map-Reply that contains an empty Locator-Set. Returned in response to a Map-Request if the destination EID is not registered in the Mapping System, is policy-denied, or fails authentication.

Map-Register message:

A LISP message sent by an ETR to a Map-Server to register its associated EID-Prefixes. In addition to the set of EID-Prefixes to register, the message includes one or more RLOCs to reach ETR(s). The Map-Server uses these RLOCs when forwarding Map-Requests (reformatted as Encapsulated Map-Requests). An ETR MAY request that the Map-Server answer Map-Requests on its behalf by setting the "proxy Map-Reply" flag (P-bit) in the message.

Map-Notify message:

A LISP message sent by a Map-Server to an ETR to confirm that a Map-Register has been received and processed. An ETR requests that a Map-Notify be returned by setting the "want-map-notify" flag (M-bit) in the Map-Register message. Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both source and destination. Map-Notify messages are also sent to ITRs by Map-Servers when there are RLOC-Set changes.

     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=1 |A|M|P|S|p|s|R|R|  Rsvd   |L|D|   IRC   | Record Count  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Nonce . . .                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         . . . Nonce                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Source-EID-AFI        |   Source EID Address  ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              ...                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  / |   Reserved    | EID mask-len  |        EID-Prefix-AFI         |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \ |                       EID-Prefix  ...                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Map-Reply Record  ...                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

1 (Map-Request)

A:

This is an authoritative bit. It is set to 1 when an ITR wants the destination site to return the Map-Reply rather than the mapping database system returning a Map-Reply and is set to 0 otherwise.

M:

This is the map-data-present bit. When set, it indicates that a Map-Reply Record segment is included in the Map-Request.

P:

This is the probe-bit, which indicates that a Map-Request MUST be treated as a Locator reachability probe. The receiver MUST respond with a Map-Reply with the probe-bit set, indicating that the Map-Reply is a Locator reachability probe reply, with the nonce copied from the Map-Request. See "[RLOC-Probing Algorithm]" (Section 7.1) for more details. This RLOC-Probe Map-Request MUST NOT be sent to the Mapping System. If a Map-Resolver or Map-Server receives a Map-Request with the probe-bit set, it MUST drop the message.

S:

This is the Solicit-Map-Request (SMR) bit. See "[Solicit-Map-Request (SMR)]" (Section 6.1) for details.

p:

This is the Proxy Ingress Tunnel Router (PITR) bit. This bit is set to 1 when a PITR sends a Map-Request. The use of this bit is deployment specific.

s:

This is the SMR-invoked bit. This bit is set to 1 when an xTR is sending a Map-Request in response to a received SMR-based Map-Request.

R:

This reserved and unassigned bit MUST be set to 0 on transmit and MUST be ignored on receipt.

Rsvd:

This field MUST be set to 0 on transmit and MUST be ignored on receipt.

L:

This is the local-xtr bit. It is used by an xTR in a LISP site to tell other xTRs in the same site that it is part of the RLOC-Set for the LISP site. The L-bit is set to 1 when the RLOC is the sender's IP address.

D:

This is the dont-map-reply bit. It is used in the SMR procedure described in Section 6.1. When an xTR sends an SMR message, it doesn't need a Map-Reply returned. When this bit is set, the receiver of the Map-Request does not return a Map-Reply.

IRC:

This 5-bit field is the ITR-RLOC Count, which encodes the additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields are used, so a Map-Replier can select which destination address to use for a Map-Reply. The IRC value ranges from 0 to 31. For a value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, there are 2 ITR-RLOC addresses encoded, and so on up to 31, which encodes a total of 32 ITR-RLOC addresses.

Record Count:

This is the number of records in this Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record.

Nonce:

This is an 8-octet random value created by the sender of the Map-Request. This nonce will be returned in the Map-Reply. The nonce is used as an index to identify the corresponding Map-Request when a Map-Reply message is received. The nonce MUST be generated by a properly seeded pseudo-random source; for example, see [RFC 4086].

Source-EID-AFI:

This is the address family of the 'Source EID Address' field.

Source EID Address:

This is the EID of the source host that originated the packet that caused the Map-Request. When Map-Requests are used for refreshing a Map-Cache entry or for RLOC-Probing, an AFI value of 0 is used, and this field is of zero length.

ITR-RLOC-AFI:

This is the address family of the 'ITR-RLOC Address' field that follows this field.

ITR-RLOC Address:

This is used to give the ETR the option of selecting the destination address from any address family for the Map-Reply message. This address MUST be a routable RLOC address of the sender of the Map-Request message.

EID mask-len:

This is the mask length for the EID-Prefix.

EID-Prefix-AFI:

This is the address family of the EID-Prefix according to [AFN] and [RFC 8060].

EID-Prefix:

This prefix address length is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFN], the address length varies, and for the LCAF AFI, the format is defined in [RFC 8060]. When a Map-Request is sent by an ITR because a data packet is received for a destination where there is no mapping entry, the EID-Prefix is set to the destination IP address of the data packet, and the 'EID mask-len' field is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR wants to query a site about the status of a mapping it already has cached, the EID-Prefix used in the Map-Request has the same mask length as the EID-Prefix returned from the site when it sent a Map-Reply message.

Map-Reply Record:

When the M-bit is set, this field is the size of a single "Record" in the Map-Reply format. This Map-Reply record contains the EID-to-RLOC mapping entry associated with the source EID. This allows the ETR that will receive this Map-Request to cache the data if it chooses to do so. It is important to note that this mapping has not been validated by the Mapping System.

     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=2 |P|E|S|          Reserved               | Record Count  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Nonce . . .                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         . . . Nonce                           |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   |                          Record TTL                           |
|   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c   | Rsvd  |  Map-Version Number   |       EID-Prefix-AFI          |
o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r   |                          EID-Prefix                           |
d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |        Unused Flags     |L|p|R|           Loc-AFI             |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  \|                             Locator                           |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

2 (Map-Reply)

P:

This is the probe-bit, which indicates that the Map-Reply is in response to a Locator reachability probe Map-Request. The 'Nonce' field must contain a copy of the nonce value from the original Map-Request. See "[RLOC-Probing Algorithm]" (Section 7.1) for more details. When the probe-bit is set to 1 in a Map-Reply message, the A-bit in each EID-Record included in the message MUST be set to 1; otherwise, it MUST be silently discarded.

E:

This bit indicates that the ETR that sends this Map-Reply message is advertising that the site is enabled for the Echo-Nonce Locator reachability algorithm. SeeSection 10.1 of [RFC 9300] for more details.

S:

This is the Security bit. When set to 1, the following authentication information will be appended to the end of the Map-Reply. Details can be found in [RFC 9303].

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    AD Type    |       Authentication Data Content . . .       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reserved:

This unassigned field MUST be set to 0 on transmit and MUST be ignored on receipt.

Record Count:

This is the number of records in this reply message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record Count. Note that the reply count can be larger than the requested count, for instance, when more-specific prefixes are present.

Nonce:

This 64-bit value from the Map-Request is echoed in this 'Nonce' field of the Map-Reply.

Record TTL:

This is the time in minutes the recipient of the Map-Reply can store the mapping. If the TTL is 0, the entry MUST be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to store the mapping.

Locator Count:

This is the number of Locator entries in the given Record. A Locator entry comprises what is labeled above as 'Loc'. The Locator count can be 0, indicating that there are no Locators for the EID-Prefix.

EID mask-len:

This is the mask length for the EID-Prefix.

ACT:

This 3-bit field describes Negative Map-Reply actions. In any other message type, these bits are set to 0 and ignored on receipt. These bits are used only when the 'Locator Count' field is set to 0. The action bits are encoded only in Map-Reply messages. They are used to tell an ITR or PITR why an empty Locator-Set was returned from the Mapping System and how it stores the Map-Cache entry. See Section 12.3 for additional information.

(0) No-Action:

The Map-Cache is kept alive, and no packet encapsulation occurs.

(1) Natively-Forward:

The packet is not encapsulated or dropped but natively forwarded.

(2) Send-Map-Request:

The Map-Cache entry is created and flagged so that any packet matching this entry invokes sending a Map-Request.

(3) Drop/No-Reason:

A packet that matches this Map-Cache entry is dropped. An ICMP Destination Unreachable message SHOULD be sent.

(4) Drop/Policy-Denied:

A packet that matches this Map-Cache entry is dropped. The reason for the Drop action is that a Map-Request for the target EID is being policy-denied by either an xTR or the Mapping System.

(5) Drop/Auth-Failure:

A packet that matches this Map-Cache entry is dropped. The reason for the Drop action is that a Map-Request for the target EID fails an authentication verification check by either an xTR or the Mapping System.

A:

The Authoritative bit MAY only be set to 1 by an ETR. A Map-Server generating Map-Reply messages as a proxy MUST NOT set the A-bit to 1. This bit indicates to the requesting ITRs if the Map-Reply was originated by a LISP node managed at the site that owns the EID-Prefix.

Map-Version Number:

When this 12-bit value in an EID-Record of a Map-Reply message is non-zero, see [RFC 9302] for details.

EID-Prefix-AFI:

This is the address family of the EID-Prefix according to [AFN] and [RFC 8060].

EID-Prefix:

This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family.

Priority:

Each RLOC is assigned a unicast Priority. Lower values are preferable. When multiple RLOCs have the same Priority, they may be used in a load-split fashion. A value of 255 means the RLOC MUST NOT be used for unicast forwarding.

Weight:

When priorities are the same for multiple RLOCs, the Weight indicates how to balance unicast traffic between them. Weight is encoded as a relative weight of total unicast packets that match the mapping entry. For example, if there are 4 Locators in a Locator-Set, where the Weights assigned are 30, 20, 20, and 10, the first Locator will get 37.5% of the traffic, the second and third Locators will each get 25% of the traffic, and the fourth Locator will get 12.5% of the traffic. If all Weights for a Locator-Set are equal, the receiver of the Map-Reply will decide how to load-split the traffic. See Section 12 of [RFC 9300] for a suggested hash algorithm to distribute the load across Locators with the same Priority and equal Weight values.

M Priority:

Each RLOC is assigned a multicast Priority used by an ETR in a receiver multicast site to select an ITR in a source multicast site for building multicast distribution trees. A value of 255 means the RLOC MUST NOT be used for joining a multicast distribution tree. For more details, see [RFC 6831].

M Weight:

When priorities are the same for multiple RLOCs, the Weight indicates how to balance building multicast distribution trees across multiple ITRs. The Weight is encoded as a relative weight (similar to the unicast Weights) of the total number of trees built to the source site identified by the EID-Prefix. If all Weights for a Locator-Set are equal, the receiver of the Map-Reply will decide how to distribute multicast state across ITRs. For more details, see [RFC 6831].

Unused Flags:

These are set to 0 when sending and ignored on receipt.

L:

When this bit is set, the Locator is flagged as a local Locator to the ETR that is sending the Map-Reply. When a Map-Server is doing proxy Map-Replying for a LISP site, the L-bit is set to 0 for all Locators in this Locator-Set.

p:

When this bit is set, an ETR informs the RLOC-Probing ITR that the Routing Locator Address for which this bit is set is the one being RLOC-Probed and may be different from the source address of the Map-Reply. An ITR that RLOC-Probes a particular Locator MUST use this Locator for retrieving the data structure used to store the fact that the Locator is reachable. The p-bit is set for a single Locator in the same Locator-Set. If an implementation sets more than one p-bit erroneously, the receiver of the Map-Reply MUST select the first set p-bit Locator. The p-bit MUST NOT be set for Locator-Set records sent in Map-Request and Map-Register messages.

R:

This is set when the sender of a Map-Reply has a route to the Locator in the Locator data record. This receiver may find this useful to know if the Locator is up but not necessarily reachable from the receiver's point of view.

Locator:

This is an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR and used by an ITR as a destination RLOC address in the outer header of a LISP encapsulated packet. Note that the destination RLOC address of a LISP encapsulated packet MAY be an anycast address. A source RLOC of a LISP encapsulated packet can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router) and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it is being mapped from a multicast destination EID.

     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|        Reserved       |E|T|a|R|M| Record Count  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Nonce . . .                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         . . . Nonce                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Key ID     | Algorithm ID  |  Authentication Data Length   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                     Authentication Data                       ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   |                          Record TTL                           |
|   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c   | Rsvd  |  Map-Version Number   |        EID-Prefix-AFI         |
o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r   |                          EID-Prefix                           |
d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |        Unused Flags     |L|p|R|           Loc-AFI             |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  \|                             Locator                           |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

3 (Map-Register)

P:

This is the proxy Map-Reply bit. When set to 1, the ETR sending the Map-Register message is requesting the Map-Server to proxy a Map-Reply. The Map-Server will send non-authoritative Map-Replies on behalf of the ETR.

S:

This is the security-capable bit. When set, the procedures from [RFC 9303] are supported.

I:

This is the ID-present bit. This bit is set to 1 to indicate that a 128-bit 'xTR-ID' field and a 64-bit 'Site-ID' field are present at the end of the Map-Register message. If an xTR is configured with an xTR-ID and Site-ID, it MUST set the I-bit to 1 and include its xTR-ID and Site-ID in the Map-Register messages it generates. The combination of Site-ID plus xTR-ID uniquely identifies an xTR in a LISP domain and serves to track its last seen nonce.

Reserved:

This unassigned field MUST be set to 0 on transmit and MUST be ignored on receipt.

E:

This is the Map-Register EID-notify bit. This is used by a First-Hop Router that discovers a dynamic EID. This EID-notify-based Map-Register is sent by the First-Hop Router to a same site xTR that propagates the Map-Register to the Mapping System. The site xTR keeps state to later Map-Notify the First-Hop Router after the EID has moved away. See [EID-MOBILITY] for a detailed use case.

T:

This is the use TTL for timeout bit. When set to 1, the xTR wants the Map-Server to time out registrations based on the value in the 'Record TTL' field of this message. Otherwise, the default timeout described in Section 8.2 is used.

a:

This is the merge-request bit. When set to 1, the xTR requests to merge RLOC-Records from different xTRs registering the same EID-Record. See Signal-Free Multicast [RFC 8378] for one use-case example.

R:

This reserved and unassigned bit MUST be set to 0 on transmit and MUST be ignored on receipt.

M:

This is the want-map-notify bit. When set to 1, an ETR is requesting a Map-Notify message to be returned in response to sending a Map-Register message. The Map-Notify message sent by a Map-Server is used to acknowledge receipt of a Map-Register message.

Record Count:

This is the number of records in this Map-Register message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record Count.

Nonce:

This 8-octet 'Nonce' field is incremented each time a Map-Register message is sent. When a Map-Register acknowledgment is requested, the nonce is returned by Map-Servers in Map-Notify messages. Since the entire Map-Register message is authenticated, the 'Nonce' field serves to protect against Map-Register replay attacks. An ETR that registers to the Mapping System SHOULD store the last nonce sent in persistent storage, so when it restarts, it can continue using an incrementing nonce. If the ETR cannot support saving the nonce, then when it restarts, it MUST use a new authentication key to register to the Mapping System. A Map-Server MUST track and save in persistent storage the last nonce received for each ETR xTR-ID and key pair. If a Map-Register is received with a nonce value that is not greater than the saved nonce, it MUST drop the Map-Register message and SHOULD log the fact that a replay attack could have occurred.

Key ID:

This is a key-id value that identifies a pre-shared secret between an ETR and a Map-Server. Per-message keys are derived from the pre-shared secret to authenticate the origin and protect the integrity of the Map-Register. The Key ID allows rotating between multiple pre-shared secrets in a nondisruptive way. The pre-shared secret MUST be unique per each LISP Site-ID.

Algorithm ID:

This field identifies the Key Derivation Function (KDF) and Message Authentication Code (MAC) algorithms used to derive the key and to compute the Authentication Data of a Map-Register. This 8-bit field identifies the KDF and MAC algorithm pair. See Section 12.5 for codepoint assignments.

Authentication Data Length:

This is the length in octets of the 'Authentication Data' field that follows this field. The length of the 'Authentication Data' field is dependent on the MAC algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet.

Authentication Data:

This is the output of the MAC algorithm placed in this field after the MAC computation. The MAC output is computed as follows:

1. The KDF algorithm is identified by the 'Algorithm ID' field according to the table in Section 12.5. Implementations of this specification MUST implement HMAC-SHA-256-128 [RFC 4868] and SHOULD implement HMAC-SHA-256-128+HKDF-SHA256 [RFC 5869].
2. The MAC algorithm is identified by the 'Algorithm ID' field according to the table in Section 12.5.
3. The pre-shared secret used to derive the per-message key is represented by PSK[Key ID], that is, the pre-shared secret identified by the Key ID.
4. The derived per-message key is computed as: per-msg-key=KDF(nonce+PSK[Key ID],s). Where the nonce is the value in the 'Nonce' field of the Map-Register, "+" denotes concatenation and "s" (the salt) is a string that corresponds to the message type being authenticated. For Map-Register messages, it is equal to "Map-Register Authentication". Similarly, for Map-Notify and Map-Notify-Ack messages, it is "Map-Notify Authentication" and "Map-Notify-Ack Authentication", respectively. For those Algorithm IDs defined in Section 12.5 that specify a 'none' KDF, the per-message key is computed as: per-msg-key = PSK[Key ID]. This means that the same key is used across multiple protocol messages.
5. The MAC output is computed using the MAC algorithm and the per-msg-key over the entire Map-Register payload (from and including the LISP message type field through the end of the last RLOC-Record) with the authenticated data field preset to 0.

xTR-ID:

'xTR-ID' is a 128-bit field at the end of the Map-Register message, starting after the final Record in the message. The xTR-ID is used to uniquely identify an xTR. The same xTR-ID value MUST NOT be used in two different xTRs in the scope of the Site-ID.

Site-ID:

'Site-ID' is a 64-bit field at the end of the Map-Register message, following the xTR-ID. The Site-ID is used to uniquely identify to which site the xTR that sent the message belongs. This document does not specify a strict meaning for the 'Site-ID' field. Informally, it provides an indication that a group of xTRs have some relationship, either administratively, topologically, or otherwise.

     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/5|             Reserved                 | Record Count  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Nonce . . .                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         . . . Nonce                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Key ID     | Algorithm ID  |  Authentication Data Length   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                     Authentication Data                       ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   |                          Record TTL                           |
|   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c   | Rsvd  |  Map-Version Number   |         EID-Prefix-AFI        |
o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r   |                          EID-Prefix                           |
d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |        Unused Flags     |L|p|R|           Loc-AFI             |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  \|                             Locator                           |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

4/5 (Map-Notify/Map-Notify-Ack)

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |                       IPv4 or IPv6 Header                     |
 OH  |                      (uses RLOC addresses)                    |
   \ |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |       Source Port = xxxx      |       Dest Port = 4342        |
 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ |           UDP Length          |        UDP Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LISP |Type=8 |S|D|R|R|            Reserved                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |                       IPv4 or IPv6 Header                     |
 IH  |                  (uses RLOC or EID addresses)                 |
   \ |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |       Source Port = xxxx      |       Dest Port = yyyy        |
 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ |           UDP Length          |        UDP Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 LCM |                      LISP Control Message                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OH:

This is the outer IPv4 or IPv6 header, which uses RLOC addresses in the source and destination header address fields.

UDP:

This is the outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero.

LISP:

Type 8 is defined to be a "LISP Encapsulated Control Message", and what follows is either an IPv4 or IPv6 header, as encoded by the first 4 bits after the 'Reserved' field, or the 'Authentication Data' field [RFC 9303] if the S-bit (see below) is set.

Type:

8 (Encapsulated Control Message (ECM))

S:

This is the Security bit. When set to 1, the field following the 'Reserved' field will have the following Authentication Data format and follow the procedures from [RFC 9303].

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    AD Type    |       Authentication Data Content . . .       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D:

This is the DDT-bit. When set to 1, the sender is requesting a Map-Referral message to be returned. Details regarding this procedure are described in [RFC 8111].

R:

This reserved and unassigned bit MUST be set to 0 on transmit and MUST be ignored on receipt.

IH:

This is the inner IPv4 or IPv6 header, which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format, the destination address in this header is an EID.

UDP:

This is the inner UDP header, where the port assignments depend on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is selected by the ITR/PITR and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum field MUST be non-zero.

LCM:

The format is one of the control message formats described in Section 5. Map-Request messages are allowed to be control plane (ECM) encapsulated. When Map-Requests are sent for RLOC-Probing purposes (i.e., the probe-bit is set), they MUST NOT be sent inside Encapsulated Control Messages. PIM Join/Prune messages [RFC 6831] are also allowed to be control plane (ECM) encapsulated.

1. An ITR may receive an ICMP Network Unreachable or Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. Note that trusting ICMP messages may not be desirable, but neither is ignoring them completely. Implementations are encouraged to follow current best practices in treating these conditions [OPSEC-ICMP-FILTER].
2. When an ITR participates in the routing protocol that operates in the underlay routing system, it can determine that an RLOC is down when no Routing Information Base (RIB) entry exists that matches the RLOC IP address.
3. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [RFC 6832] and LISP-encapsulated data is sent to a non-LISP-capable site.
4. An ITR may receive a Map-Reply from an ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up, since the ETR was able to send the Map-Reply to the ITR. Please note that in some scenarios the RLOC -- from the outer header -- can be a spoofable field.
5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described below.

• An immediate Negative Map-Reply (with action code "Natively-Forward" and a 15-minute TTL) from the Map-Resolver if the Map-Resolver can determine that the requested EID does not exist. The ITR saves the EID-Prefix returned in the Map-Reply in its cache, marks it as non-LISP-capable, and knows not to attempt LISP encapsulation for destinations matching it.
• A Negative Map-Reply (with action code "Natively-Forward") from a Map-Server that is authoritative (within the LISP deployment (Section 1.1)) for an EID-Prefix that matches the requested EID but that does not have an actively registered, more-specific EID-Prefix. In this case, the requested EID is said to match a "hole" in the authoritative EID-Prefix. If the requested EID matches a more-specific EID-Prefix that has been delegated by the Map-Server but for which no ETRs are currently registered, a 1-minute TTL is returned. If the requested EID matches a non-delegated part of the authoritative EID-Prefix, then it is not a LISP EID and a 15-minute TTL is returned. See Section 8.2 for a discussion of aggregate EID-Prefixes and details regarding Map-Server EID-Prefix matching.
• A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or possibly from a Map-Server answering on behalf of the ETR. See Section 8.4 for more details on Map-Resolver message processing.

1. The Mapping System is secure and trusted, and for the purpose of these security considerations, the Mapping System is considered as one trusted element.
2. The ETRs have a preconfigured trust relationship with the Mapping System, including some form of shared secret. The Mapping System is aware of which EIDs an ETR can advertise. How those keys and mappings are established is out of scope for this document.
3. LISP-SEC [RFC 9303] MUST be implemented. Network operators should carefully weigh how the LISP-SEC threat model applies to their particular use case or deployment. If they decide to ignore a particular recommendation, they should make sure the risk associated with the corresponding threats is well understood.

• The 16-bit 'Key ID' field of the Map-Register and Map-Notify messages as defined in [RFC 6830] has been split into an 8-bit 'Key ID' field and an 8-bit 'Algorithm ID' field. Note that this change also applies to the Map-Notify-Ack message defined by this document. See Sections [5.6] and [5.7].
• This document defines a Map-Notify-Ack message to provide reliability for Map-Notify messages. Any receiver of a Map-Notify message must respond with a Map-Notify-Ack message. Map-Servers who are senders of Map-Notify messages must queue the Map-Notify contents until they receive a Map-Notify-Ack with the nonce used in the Map-Notify message. Note that implementations for Map-Notify-Ack support already exist and predate this document.
• This document has incorporated the codepoint for the Map-Referral message from the LISP-DDT specification [RFC 8111] to indicate that a Map-Server must send the final Map-Referral message when it participates in the LISP-DDT Mapping System procedures.
• Bits L and D have been added to the Map-Request message. See Section 5.3 for details.
• Bits S, I, E, T, a, R, and M have been added to the Map-Register message. See Section 5.6 for details.
• The nonce and the Authentication Data in the Map-Register message each behave differently; see Section 5.6 for details.
• This document adds two new action values that are in an EID-Record that appears in Map-Reply, Map-Register, Map-Notify, and Map-Notify-Ack messages. These new action values are Drop/Policy-Denied and Drop/Auth-Failure. See Section 5.4 for details.

• LISP IANA registry allocations should not be made for purposes unrelated to LISP routing or transport protocols.
• The following policies are used here with the meanings defined in [RFC 8126]: "Specification Required", "IETF Review", "Experimental Use", and "First Come First Served".

[RFC2119]

S. Bradner, "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>.

[RFC2404]

C. Madson, and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1998,
<https://www.rfc-editor.org/info/rfc2404>.

[RFC4086]

D. Eastlake 3rd, J. Schiller, and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.

[RFC4868]

S. Kelly, and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>.

[RFC5869]

H. Krawczyk, and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.

[RFC6833]

V. Fuller, and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013,
<https://www.rfc-editor.org/info/rfc6833>.

[RFC8085]

L. Eggert, G. Fairhurst, and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017,
<https://www.rfc-editor.org/info/rfc8085>.

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]

B. Leiba, "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>.

[RFC9300]

D Farinacci, V Fuller, D Meyer, D Lewis, and A Cabellos, "The Locator/ID Separation Protocol (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>.

[RFC9302]

L Iannone, D Saucez, and O Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 9302, DOI 10.17487/RFC9302, October 2022,
<https://www.rfc-editor.org/info/rfc9302>.

[RFC9303]

F Maino, V Ermagan, A Cabellos, and D Saucez, "Locator/ID Separation Protocol Security (LISP-SEC)", RFC 9303, DOI 10.17487/RFC9303, October 2022,
<https://www.rfc-editor.org/info/rfc9303>.

[RFC9304]

M Boucadair, and C Jacquenet, "Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations", RFC 9304, DOI 10.17487/RFC9304, October 2022,
<https://www.rfc-editor.org/info/rfc9304>.

[AFN]

IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers/>.

[ECDSA-AUTH]

Zededa, D. Farinacci, and E. Nordmark, "LISP Control-Plane ECDSA Authentication and Authorization", Internet-Draft draft-ietf-lisp-ecdsa-auth-09, September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-ecdsa-auth-09>.

[EID-ANONYMITY]

Ericsson, D. Farinacci, P. Pillay-Esnault, and W. Haddad, "LISP EID Anonymity", Internet-Draft draft-ietf-lisp-eid-anonymity-13, September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-anonymity-13>.

[EID-MOBILITY]

lispers.net, M Portoles, V Ashtaputre, F Maino, V Moreno, and D Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", Internet-Draft draft-ietf-lisp-eid-mobility-10, July 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-mobility-10>.

[GTP-3GPP]

3GPP, "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", June 2022,
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1699>.

[INTAREA-ILA]

Facebook, T. Herbert, and P. Lapukhov, "Identifier-locator addressing for IPv6", Internet-Draft draft-herbert-intarea-ila-01, March 2018,
<https://datatracker.ietf.org/doc/html/draft-herbert-intarea-ila-01>.

[LISP-MN]

Logical Elegance, D. Farinacci, D. Lewis, D. Meyer, and C. White, "LISP Mobile Node", Internet-Draft draft-ietf-lisp-mn-12, July 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-12>.

[LISP-PUBSUB]

Orange, A. Rodriguez-Natal, V. Ermagan, A. Cabellos-Aparicio, S. Barkai, and M. Boucadair, "Publish/Subscribe Functionality for LISP", Internet-Draft draft-ietf-lisp-pubsub-09, June 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09>.

[NVO3-VXLAN-GPE]

F Maino, L Kreeger, and U Elzur, "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Internet-Draft draft-ietf-nvo3-vxlan-gpe-12, September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-12>.

[OPSEC-ICMP-FILTER]

Cisco, F. Gont, G. Gont, and C. Pignataro, "Recommendations for filtering ICMP messages", Internet-Draft draft-ietf-opsec-icmp-filtering-04, July 2013,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsec-icmp-filtering-04>.

[RFC1035]

P. Mockapetris, "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987,
<https://www.rfc-editor.org/info/rfc1035>.

[RFC1071]

R.T. Braden, D.A. Borman, and C. Partridge, "Computing the Internet checksum", RFC 1071, DOI 10.17487/RFC1071, September 1988,
<https://www.rfc-editor.org/info/rfc1071>.

[RFC2890]

G. Dommety, "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000,
<https://www.rfc-editor.org/info/rfc2890>.

[RFC4984]

D. Meyer, L. Zhang, and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007,
<https://www.rfc-editor.org/info/rfc4984>.

[RFC6830]

D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.

[RFC6831]

D. Farinacci, D. Meyer, J. Zwiebel, and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013,
<https://www.rfc-editor.org/info/rfc6831>.

[RFC6832]

D. Lewis, D. Meyer, D. Farinacci, and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013,
<https://www.rfc-editor.org/info/rfc6832>.

[RFC6836]

V. Fuller, D. Farinacci, D. Meyer, and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013,
<https://www.rfc-editor.org/info/rfc6836>.

[RFC6837]

E. Lear, "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, DOI 10.17487/RFC6837, January 2013,
<https://www.rfc-editor.org/info/rfc6837>.

[RFC6973]

A. Cooper, H. Tschofenig, B. Aboba, J. Peterson, J. Morris, M. Hansen, and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.

[RFC7348]

M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, 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>.

[RFC7835]

D. Saucez, L. Iannone, and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016,
<https://www.rfc-editor.org/info/rfc7835>.

[RFC8060]

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

[RFC8061]

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

[RFC8111]

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

[RFC8378]

V. Moreno, 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>.

[RFC8402]

C. Filsfils, S. Previdi, L. Ginsberg, B. Decraene, S. Litkowski, and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018,
<https://www.rfc-editor.org/info/rfc8402>.

[RFC9147]

E. Rescorla, H. Tschofenig, and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.

[RFC9299]

A Cabellos, and D Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", RFC 9299, DOI 10.17487/RFC9299, October 2022,
<https://www.rfc-editor.org/info/rfc9299>.

[RFC9305]

F Maino, J Lemon, P Agarwal, D Lewis, 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>.

Dino Farinacci

Fabio Maino

Vince Fuller

Albert Cabellos